Bonjour,
depuis vendredi j'ai un problème d'accès depuis chez moi au smtp de free sur le port 587.
voila ce que donne traceroute -p 587 -T smtp.free.fr
1 mon.lan (192.168.1.1) 2.635 ms 2.632 ms 2.627 ms
2 monIP.fbx.proxad.net (xxx.xxx.xxx.xxx) 31.634 ms 31.646 ms 32.836 ms
3 213.228.8.254 (213.228.8.254) 33.743 ms 35.764 ms 35.767 ms
4 p11-crs16-1-be1009.intf.routers.proxad.net (194.149.161.13) 36.619 ms 36.627 ms 40.863 ms
5 bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2) 40.824 ms 36.602 ms 40.810 ms
6 bzn-9k-2-sys-be2000.intf.routers.proxad.net (194.149.161.242) 40.807 ms 34.989 ms 34.985 ms
7 * * *
et à partir de là on tourne en boucle.
traceroute -T smtp.free.fr atteint sa cible sans soucis.
Étrangement, mais sans que je sache l'interpréter, depuis un serveur externe un traceroute -T monip atteint sa cible alors que traceroute monip donne:
1 uneip.rev.poneytelecom.eu (xxx.xxx.xxx.xxx) 8.495 ms 8.581 ms 8.680 ms
2 a9k1-45x-s31-1.dc3.poneytelecom.eu (195.154.1.32) 0.815 ms 2.397 ms 2.390 ms
3 bzn-crs16-1-be1500-t.intf.routers.proxad.net (212.27.58.49) 0.946 ms 0.951 ms 0.937 ms
4 194.149.166.57 (194.149.166.57) 1.055 ms 1.045 ms 1.061 ms
5 cbv-9k-1-be1000.intf.routers.proxad.net (194.149.161.10) 1.391 ms 1.412 ms 1.452 ms
6 213.228.8.132 (213.228.8.132) 1.149 ms 1.050 ms 0.964 ms
7 * * *
et ça se met à boucler aussi.
Comme tout sort correctement de chez moi, et que je n'ai pas touché à ma config, je ne pense pas que le problème vienne de mon coté, mais je n'ai pas réussi à trouver d'autres cas que le mien.
L'envoi de mail en utilisant Tor comme proxy fonctionne très bien, donc je suspecte un problème de routage depuis free sur son réseau.
Comment puis je améliorer mon diagnostique avant de joindre la hotline de free ?
Merci
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: IP bloquée ?
Posté par Anonyme . Évalué à 2. Dernière modification le 09 septembre 2019 à 17:10.
le ping atteint sa cible
openssl et telnet sur le port 587 reste muet jusqu'au timeout
Pourquoi auraient-ils bloqué mon IP qui est sur leur réseau et ce depuis une dizaine d'années ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# IP fixe ? Full stack ?
Posté par AncalagonTotof . Évalué à 1.
Bon, ça m'étonnerait que ça vienne de là, vu que c'est dans le sens sortant.
Mais depuis un bon moment, Free triche.
Encore que je ne connaisse pas bien le mécanisme impliqué par l'option -T. Peut-être que ça vient de là. Tu as essayé sans ?
En tout cas, si c'est ça, ça peut venir de chez Free. Face à la pénurie d'adresse IPv4, Free "divise" une adresse en 4 blocs de ports. Pour une adresse IP, 4 clients se partagerons une plage de ports, soit 65536 (à un ou deux près, hein, zéro, toussa) divisé par 4 : 0 à 16383.
Le plus chanceux aura les ports de 0 à 16383.
Le second client aura les ports de 16384 à 32767, mappés sur 0 à 16383.
Le troisième de 32768 à 49151 et le dernier de 49152 à 65535, toujours mappés sur 0 à 16383.
On se fait enfumer des 3/4 des ports !
La solution : demander (via l'interface Web il me semble) une IP fixe, qui implique ce que Free appelle "IP Full Stack". En clair, une fois l'IP figée, on a droit à la totalité des ports, de 0 à 65535.
Quoi qu'il en soit, chez moi, ça donne ça :
Un traceroute simple donne :
Aucun soucis particulier.
[^] # Re: IP fixe ? Full stack ?
Posté par Anonyme . Évalué à 2.
Je suis en ADSL et j'ai une IP fixe depuis le début de mon abonnement il y a plus de 10 ans.
A moins que le partage de port ne se soit fait sans changement d'IP et sans prévenir, je ne pense pas que ce soit cela. De plus je ne vois pas en quoi cela aurait une incidence sur l'accès au port 587 de leurs serveurs SMTP, le tout depuis seulement trois jours.
l'option T sert à utiliser TCP comme le fait le protocole SMTP
[^] # Re: IP fixe ? Full stack ?
Posté par AncalagonTotof . Évalué à 1.
Oui, peu probable qu'ils aient changé ta config.
Je ne suis pas expert, mais je vois un problème potentiel sur le chemin du retour des paquets. Encore une fois, super pas certain de moi.
Pour être exact, -T, c'est
Je pense que c'est un peu plus subtil que juste utiliser TCP. Ça a un rapport avec la façon dont s'établit une connexion TCP (SYN, ACK, etc. Je ne connais pas ça par cœur).
Un autre test à faire :
Ça bloque aussi ?
[^] # Re: IP fixe ? Full stack ?
Posté par Anonyme . Évalué à 2.
oui => timeout
[^] # Re: IP fixe ? Full stack ?
Posté par Marc Quinton . Évalué à 2.
ce n'est pas du SSL :-)
# Mail déclencheur
Posté par Anonyme . Évalué à 2.
Il se trouve que j'envoie un mail journalier à un destinataire consentant, ayant le même contenu à un lien près, via un service hébergé localement.
Hier soir la connexion vers le SMTP a été rétabli et a perduré jusqu'à ce matin.
J'ai donc fait un test:
- envoi d'un mail de test via mutt, sujet et contenu limité au mot "test"
=> pas de coupure d'accès, le mail est distribué correctement
- activation du service qui envoie le mail automatiquement
=> bloquage de l'accès, le mail n'est pas distribué
Il me semblait que dans le cas de mail qui pouvait sembler suspect à un serveur SMTP, celui ci devait renvoyer un message au destinataire expliquant la non distribution éventuelle.
Se pourrait il que Free ait rajouté une mesure de ban IP temporaire ?
[^] # Re: Mail déclencheur
Posté par Anonyme . Évalué à 2.
Si ça intéresse quelqu'un, le newsgroup proxad.free.service.messagerie sur news.free.fr est l'endroit où vous pourrez avoir des interlocuteurs compétents en interne.
J'ai tout coupé pendant une nuit, et j'en ai profité pour mieux checker mes logs => la base de données retry d'exim avait pris un coup et je suppose que ça n'a pas plus à exim qui s'est emballé et a bombardé de connexions leur serveur (1300 en 3 min), du coup _o/BAN ! Ajoutons la dessus un mail quotidien avec une enveloppe invalide et j'imagine que cela explique l'attention particulière portée à mon IP.
tout semble revenu à la normal pour le moment
Merci pour vos réponses
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.