Skip to main content
Bonjour,



En voulant faire quelques tests je me suis aperçu d'un filtrage apparent sur vos lignes internets. J'en profite donc pour faire part de mon expérience mais aussi pour poser la question au support.

le sujet est le traffic telnet (qui est du traffic non chiffré donc) ou les paquets à destination d'un port 25 distant. Je ne suis pas encore sûr de l'exact sujet du problème.



Prenons le cas suivant:

Vous avez une newsletter et vous voulez tester l'existence de toutes les adresses internet reprises dans votre liste d'abonnés. Vous écrivez donc un script à cet effet (je résume donc ne vous intéressez pas aux modalités techniques) et pour tester les adresses il y a un moyen très simple qui consiste à se connecter en telnet au serveur smtp du domaine de l'adresse mail que vous essayez de joindre. Pour rappel un domaine est dans l'adresse test@gmail.com ce qu'il y a après le @.

Je passe les détails techniques mais il se fait que le seul point atteignable en faisant

telnet adresse.du.serveur.mail 25 est l'adresse du serveur mail de proximus ou skynet. Tous les autres sont inaccessibles. Que ce soit gmail, hotmail, ldlc, que sais je encore.

Les tests ont été effectués à partir de plusieurs postes clients, à différents niveaux du réseaux, et les postes clients étaient équipés de tous les OS possibles et inimaginables donc ça concernait aussi bien windows, linux, mac OS et autre.

Ce n'est pas relié ni à une protection de la bbox ni à une règle d'un autre équipementier réseau.

Les resultats de ces tests est un simple timeout.

Ca c'est pour une ligne fixe type particulier.



Maintenant quand ces mêmes tests sont effectués sur une ligne professionnelle à ip fixe pour être exact, ça ne pose aucun problème j'accède immédiatement aux ressources demandées.



Pour informations vous n,'êtes pas les seuls à bloquer ce genre de traffic puisque plusieurs VPN le font également dont Private Internet Access.



Mais je voulais néanmoins savoir si j'avais rater quelquec chose dans la documentation , si vous connaissiez la raison de ce blocage, si vous en étiez même au courant et si il y a moyen d'avoir de plus amples informations?



Merci d'avance
Salut @vigilian ,



Pour être franc, je n'en ai vraiment aucune idée ...

Mais j'ai peut être un spécialiste qui saura peut être vous répondre ...

@titi70, aurais-tu une idée ? 😉
Bonsoir @VincentM ,



Je pense que la question s'adresse plutôt à Proximus et la façon dont le port SMTP sortant est géré sur une ligne résidentielle...



Tout ce que je peux dire, c'est que le serveur SMTP de VOO n'est pas accessible à partir d'une connexion Proximus, et vice-versa.



EDIT: Un serveur mail de OVH est accessible en telnet (port 25) depuis une connexion VOO, mais pas Proximus. Il semble donc bien y avoir un blocage (je ne pense pas que le blocage vienne d'OVH...)
Non non le blocage ne vient pas des gestionnaires de serveurs mails. Dans tous les cas. Sinon ma démonstration ne tiendrait pas. Et comme je vous le disais, d'autres le font comme des providers de VPN comme "PIA" Donc c'est pas comme si c'était quelque chose d'inédit. J'aurais par contre bien voulu en connaitre la raison par rapport à proximus car dans le cadre d'un vpn je comprends que les administrateurs réseaux pour éviter les problèmes de poursuites judiciaires filtrent ce genre de traffic. Mais dans le cadre de proximus qui travaille tous les jours avec la justice et qui n'a pas de fonctionnalité pour remplacer son adresse ip par une autre adresse ip (ce que fait grosso modo le vpn) je vois pas l'intérêt.

Donc si vous pouviez renvoyer la question à plus haut dans la chaîne alimentaire de proximus ça serait pas mal.

Merci d'avance
Salut @vigilian ,



Un collègue a examiné votre demande et il me demande si possible que vous m'envoyez par message privé, un exemple concret et quelques adresses mails qui posent problème ...

Merci d'avance !
heu c'est pas des adresses mails....

Est-on sûr de bien comprendre le problème ici.

On parle deux deux possibilités ici .

1/ filtrage du protocole telnet qui est un protocole (et je ne parle pas du port) qui transite en clair sur le réseau sans cryptage quelqu'il soit. Les routeurs ou la gateway ou pare-feu peuvent lire le traffic qui transite du moment qu'il n'est pas crypté. Un traffic crypté par exemple est https et dans ce cas-là le routeur ou autre équiepement réseau ne peut pas lire le contenu, uniquement ce qu'on appelle les metadata. Telnet puisqu'on peut lire le contenu, une règle a pu être facilement incorporée dans vos centraux ou DSLAM ou autre pour dire que tout traffic correspondant à ce protocole doit être re-routé vers une adresse unique qui est dans ce cas-ci votre serveur smtp.skynet.be ou smtp.proximus.be et dans tout autre cas doit être dropped c'est-à-dire ignoré.



2/ filtrage du port distant. Ici on parle justement des metadata. C'est-à-dire que de nouveau, dans n'importe quelle partie de vos équipements réseau, une règle a pu être incorporée qui dit: tout traffic qui veut aller au port distant numéro 25 à n'importe quelle adresse dans le monde, doit être dropped (donc ignoré).



Donc on parle ici de filtrage réseau, pas d'adresse mail ce qui ne fait pas partie du fiiltrage réseau. Les adresses mails c'est quelque chose qui se situe bien au delà du spectre de léquipement réseau et se situe dans la couche application du modèle OSI. https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI



Ici on parle de la partie matérielle du modèle pas au-delà. ET oui je suis aussi un spécialiste même si je ne poste pas grand chose ici vu que la plupart des questions ne sont pas suffisamment techniques pour que je m'y intéresse.



Donc dites à votre collègue:



"Tiens teste un peu à partir d'une ligne commerciale pour particulier dans une invite de commande ms-dos sous windows(il faut que le client telnet soit installé dans les features de windows) ou dans le terminal sous linux ou sur mac 'telnet alt3.gmail-smtp-in.l.google.com 25" et dis moi si tu arrives à y être connecté"



ou bien vous pouvez suivre l'un des nombreux tuto: exemple https://www.massmailsoftware.com/verify/help/05_commandline.html



A nouveau, à partir d'une ligne particulier sans ip fixe, tout ce qu'il ya de plus basique. Car comme je l'ai dit il y a visiblement une différence de traitement entre une ligne business et particuliers.



l'adresse: alt3.gmail-smtp-in.l.google.com est un des serveur mails de google

les adresses de SERVEUR mail (à pas confondre avec les adresses mails!!!) peuvent être obtenues via la commande "nslookup -q=mx nomdudomaine" sous windows dans une invite de commande par exemple. "-q=mx" étant pour définir le type de la recherche que l'on demande mx = mail exchange

nslookup étant un des programmes clients de résolutions d'adresses DNS.



Et pour la petite histoire, tous les serveurs mails du monde entier sont accessibles comme ça en clair sans autorisation particulière car c'est comme ça qu'ils peuvent communiquer entre eux. Donc pas d'inquiétude d'étonnement. Vous pouvez contacter google, ovh, quelque soit le propriétaire du serveur il doit être accessible et son port 25 ou autre doit être accessible pour communiquer.

Et donc su vos lignes particuliers il n'y a que votre serveur mail qui semble être accessible. Tout autre traffic semble être ignoré et donc résulte en des timeout.
heu c'est pas des adresses mails....

Est-on sûr de bien comprendre le problème ici.

On parle deux deux possibilités ici .

1/ filtrage du protocole telnet qui est un protocole (et je ne parle pas du port) qui transite en clair sur le réseau sans cryptage quelqu'il soit. Les routeurs ou la gateway ou pare-feu peuvent lire le traffic qui transite du moment qu'il n'est pas crypté. Un traffic crypté par exemple est https et dans ce cas-là le routeur ou autre équiepement réseau ne peut pas lire le contenu, uniquement ce qu'on appelle les metadata. Telnet puisqu'on peut lire le contenu, une règle a pu être facilement incorporée dans vos centraux ou DSLAM ou autre pour dire que tout traffic correspondant à ce protocole doit être re-routé vers une adresse unique qui est dans ce cas-ci votre serveur smtp.skynet.be ou smtp.proximus.be et dans tout autre cas doit être dropped c'est-à-dire ignoré.



2/ filtrage du port distant. Ici on parle justement des metadata. C'est-à-dire que de nouveau, dans n'importe quelle partie de vos équipements réseau, une règle a pu être incorporée qui dit: tout traffic qui veut aller au port distant numéro 25 à n'importe quelle adresse dans le monde, doit être dropped (donc ignoré).



Donc on parle ici de filtrage réseau, pas d'adresse mail ce qui ne fait pas partie du fiiltrage réseau. Les adresses mails c'est quelque chose qui se situe bien au delà du spectre de léquipement réseau et se situe dans la couche application du modèle OSI. https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI



Ici on parle de la partie matérielle du modèle pas au-delà. ET oui je suis aussi un spécialiste même si je ne poste pas grand chose ici vu que la plupart des questions ne sont pas suffisamment techniques pour que je m'y intéresse.



Donc dites à votre collègue:



"Tiens testes un peu à partir d'une ligne commerciale pour particulier dans une invite de commande ms-dos sous windows(il faut que le client telnet soit installé dans les features de windows) ou dans le terminal sous linux ou sur mac 'telnet alt3.gmail-smtp-in.l.google.com 25" et dis moi si tu arrives à y être connecté"



ou bien vous pouvez suivre l'un des nombreux tuto: exemple https://www.massmailsoftware.com/verify/help/05_commandline.html



A nouveau, à partir d'une ligne particulier sans ip fixe, tout ce qu'il ya de plus basique. Car comme je l'ai dit il y a visiblement une différence de traitement entre une ligne business et particuliers.



l'adresse: alt3.gmail-smtp-in.l.google.com est un des serveur mails de google

les adresses de SERVEUR mail (à pas confondre avec les adresses mails!!!) peuvent être obtenues via la commande "nslookup -q=mx nomdudomaine" sous windows dans une invite de commande par exemple. "-q=mx" étant pour définir le type de la recherche que l'on demande mx = mail exchange

nslookup étant un des programmes clients de résolutions d'adresses DNS.



Et pour la petite histoire, tous les serveurs mails du monde entier sont accessibles comme ça en clair sans autorisation particulière car c'est comme ça qu'ils peuvent communiquer entre eux. Donc pas d'inquiétude d'étonnement. Vous pouvez contacter google, ovh, quelque soit le propriétaire du serveur il doit être accessible et son port 25 ou autre doit être accessible pour communiquer.

Et donc su vos lignes particuliers il n'y a que votre serveur mail qui semble être accessible. Tout autre traffic semble être ignoré et donc résulte en des timeout.
Y aurait-il un problème avec l'un de mes posts que je sois modéré?

J'ai fait un long post d'explication et visiblement il est en attente de modération.... enfin c'est ce que j'ai comme message d'erreur...
Salut @vigilian ,



Apparemment vos posts n'ont pas été tout de suite publiés. J'ai fait le nécessaire pour qu'à ce niveau ce soit en ordre. Toutes mes excuses en tous cas.

Effectivement, je pense que nous nous sommes peut être mal compris et je tiens à vous remercier pour ces précisions. Je viens de transmettre celles-ci à des collègues plus spécialisés que moi dans ce domaine. Je recevrai certainement une réponse demain que je ne manquerai pas de vous communiquer.

Je reste à votre entière dispositon ...
@vigilian Telnet n'est pas à proprement parler un protocole, l'application telnet (ou putty en mode telnet) ne fait que se connecter au port spécifié et envoyer les caractères correspondant aux touches tapées (et afficher les caractères reçus du serveur). Il est donc impossible de distinguer une connexion établie à l'aide de cette application d'une connexion établie par un "vrai" serveur SMTP (sauf éventuellement la vitesse à laquelle les caractères sont envoyés). On peut de la même manière utiliser telnet sur le port 80 pour envoyer des requêtes HTTP. Je ne vois donc pas comment l'application telnet pourrait être bloquée...
EDPnet bloque également tout trafic provenant d'une adresse IP dynamique vers un autre serveur SMTP que le leur:



https://www.edpnet.be/fr/support/analyser-et-resoudre/e-mail/le-port-25-est-ferme,-que-faire.html
Bonsoir,



il y a quelques années, j'ai testé l'installation d'un serveur SMTP chez moi et ça avait fonctionné (ligne ADSL belgacom). A cette période, j'avais du diminuer la sécurité de la ligne ADSL (via interface web chez belgacom). Aujourd'hui, je viens de regarder dans la config et on ne parle pas d'ouverture du port 25 (donc pour un particulier). Je ne me souviens pas d'avoir fait des test en telnet proprement dit sur port 25.



Ici, je pense comme vigilian, il doit y avoir un blocage de ce port actuellement vers l'extérieur (après avoir fait des tests sur quelques serveurs SMTP) mais tout ok avec relay.proximus.be.

D'un autre coté, je ne trouve pas anormal qu'un provideur bloque le port SMTP avec des autres FAI pour les particuliers.

Voilà mon petit grain de sel ;-)



Jean-Luc
Bonsoir,



De toute manière le changement de niveau de sécurité dans MyProximus concerne les ports entrants, pas sortants. Les essais indiquent que Proximus applique la même règle que celle expliquée sur le site de EDPnet, à savoir port sortant 25 bloqué depuis une adresse IP dynamique vers une autre adresse que le serveur SMTP du provider.
Salut @vigilian ,



Je viens de recevoir la réponse de mon collègue 😉

Je vous la transmet ici ...

Le trafic TCP sur le port 25 est bloqué vers l’extérieur (adresses non-proximus) pour des raisons de sécurité.



Telnet, c’est du TCP : https://www.proximus.be/support/en/id_sfaqr_ports_unblock_secu/personal/support/internet/security-and-protection/internet-ports-and-security/open-internet-ports.html



Je reste à votre disposition 😉
@titi70

Ecoute, travaillant dans le secteur, et si je me rappelle de mes cours et si je fais confiance que ce soit à la page wikipedia, où aux différentes RFC qui le définissent, on parle bien de "protocole". Alors oui c'est à différencier de la notion de "protocole "TCP" ou"UDP" mais ça n'en est pas moins un.

Et comme je l'ai expliqué, c'est un protocole qui transite en clair.

Au même titre, l'échange de mail est un protocole, le dns est aussi un protocole etc etc. Tu les considères peut-être toi-même dans ta compréhension que comme des applications mais à partir du moment où c'est défini par une RFC ça en devient un protocole. Et en l'occurence ici un protocole de la couche applciative.

Si c'était juste une application parmi d'autre, il'ny aurait pas de RFC le définissant comme par exemple pour powerdns qui est une application de gestion DNS authoritarive et qui doit suivre les RFC qui définissent justement les DNS.

https://fr.wikipedia.org/wiki/Telnet

RFC854

RFC855



tu remarqueras aussi que dans la page de wireshark on parle également de protocole, ainsi que dans IOS de cisco, de l'interface du packet analyzer d'ubiquiti ou ceux de mikrotik.

https://wiki.wireshark.org/Telnet



A nouveau tu considères ça peut-être comme un abus de language mais c'est pourtant comme ça qu'on le définit, bien comme un protocole.
Néanmoins @titi70 je te remercie pour tes tests et tes interventions même si je considère certaines comme erronnées professionnellement parlant. Au moins ça avait le mérite de démontrer que je n'étais pas fou ;)



@Jean Luc G oui jean-luc évidemment ça n'a pas grand chose à voir avec ce dont je parlais mais en effet oui comme disait titi les ports entrants ce n'est pas la même chose que les sortants.



@VincentM votre mail vous l'avez pris de votre serveur perso outlook ou pro, peu importe. Mais du coup comme vous l'avez pris de là i lest soumis au filtre de SPAM de microsoft mais l'adresse ne peut-être atteinte que pour un certain laps de temps. Donc faudra changer ce lien avec la réelle adresse.. En somme le lien que vous avez fourni, c'est à nouveau pour les ports entrants et pas concernant le blocage ou la raison du blocage de proximus de certains ports VERS l'extérieur. J'aurais préféré une page de cette sorte-là: https://www.privateinternetaccess.com/helpdesk/kb/articles/why-do-you-block-ipv6-2 ici ça concerne l'ipv6 car je ne retrouve plus la page FAQ de PIA expliquant pourquoi ils bloquent certains ports vers l'extérieur mais c'est du même tonneau.



Il serait peut-être bon de mettre justement ça en place... Une page FAQ expliquant et donnant précisément les ports qui sont bloqués vers l'extérieur sur les lignes des particuliers....

Merci d'avance
Oh et by the way, à propos de protocole, il y en a à toutes les couches du modèles TCP/IP ou du modèle OSI.

La norme ethernet par exemple est aussi un protocole de la couche 2,

Ethernet n'a pourtant rien à voir avec la notion de protocole tel que TCP/UDP.

Ipv4 et ipV6 sont des protocoles également mais d'adressage de la couche 3. Et pourtant à nouveau ça n'a rien à voir avec le protocole TCP ou UDP etc etc

Donc ça serait bien que pour ne pas donner de mauvaises informatioons et de mal éduquer (au sens donenr des connaissances) aux gens on ne raconte pas n'importe quoi et qu'on utilise les termes de la littérature techniques/scientifiques.

Thanks :;)
@vigilian Cette discussion est stérile et inutile. Je travaille aussi dans le domaine depuis 25 ans et j'ai ma propre (ou pas) idée de ce qu'est un protocole. Tout ce que j'essaye de dire, c'est qu'en utilisant l'application telenet pour se connecter à un serveur SMTP, il n'est pas question du protocol TELNET, mais du protocole SMTP. Il n'y a aucune différence au niveau des bytes échangés que la connexion soit établie à partir de l'application telnet ou à partir d'un serveur SMTP et un firewall ne peut pas faire la différence (ce qui était, me semble-t'il, le sujet initial, pas un cours de terminologie)



Si on utilise l'application telnet pour se connecter à un serveur TELNET, alors oui on peut parler du protocol TELNET. Au final L'application telenet ouvre simplement un port TCP et envoie les caractères tapés au clavier.



Bref, ce sera ma dernière intervention (et consultation) sur ce sujet, mention ou pas, car je ne vois pas l'intérêt dans tout ce bla-bla. Il me semble de plus que la réponse à la question a été donnée.
@titi70 Eh bien donc a du se croiser dans le cadre de nos boulots respectifs très cher :)

Masi c'est que tu n'as pas lu les RFC ni ce qu'est le contenu du protocole telent ni comment ça fonctionne alors:)

Ou bien tu as clairement pas compris ce que je disais d'un protocole qui transite en clair. à contrario avec ssh par exemple. Et toi tu as directement parlé de l'application telnet comme si magiquement il savait qu'il devait utiliser la protocole SMTP. C'est que tu ne sais pas exactement à partir de quand dans une transaction on parle de SMTP et quand on parle de telnet.

Et pourquoi j'ai parlé de protocole qui transite en clair, parce que pour rappel, ils auraient pu non pas mettre une règle sur le port 25 distant mais bien sur l'adresse contenue dans le paquet de la couche 3. Car à priori rien n'empêche à un admin IT de mettre une autre application spéicfique qu'un mail exchange sur le port 25 au travail ou dans son datacenter qu'il voudrait contacter depuis chez lui de sa ligne particulière.

Mais bon peu importe on est pas d'accord et je suis certaine pas d'accord avec ta définition de "protocole"

bonne journée

Commenter