il se passe quelque chose avec la MTU. je n ai pas eu le probleme en SMTP mais je l ai eu sur du ssh et sur des formulaires web, heberges sur des serveurs chez online , et les symptomes sont proches.
plus de problemes apres avoir baisse la mtu a 1400. il semble que je ne sois pas le seul, voir ma reponse complete sur : http://serverfault.com/questions/210408/ssh-access-problem-debug1-expecting-ssh2-msg-kex-dh-gex-reply/676026#676026 Je n ai jamais eu ce probleme depuis plus de 10 ans que je gere des serveurs, seulement ces derniers mois. Certains suggerent que ca pourrait etre lie a des option de DPI des routeurs cisco . . . dans tous les cas il serait interessant que des experts se penchent sur le sujet. desole si ca n a rien a voir avec ton probleme, mais au cas ou . . . je signale mon experience, vu que les symptomes sont proches. 2016-04-15 7:32 GMT-05:00 JC PAROLA <cont...@sels-ingenierie.com>: > On Fri, 15 Apr 2016 09:30:01 +0200 > Pierre DOLIDON <sn...@sn4ky.net> wrote: > >> Le 14/04/2016 15:17, JC PAROLA a écrit : >> > Bonjour à tous, >> > >> > Des clients m'ont remontés l'erreur suivante sur les serveurs SMTP: >> > >> > Apr 14 09:30:12 postfix/error[25452]: 7D3191BF0488: >> > to=<innxxx...@xxxxxx.com>, relay=none, delay=4.8, delays=4.8/0/0/0.07, >> > dsn=4.4.2, >> > status=deferred (delivery temporarily suspended: conversation with >> > ah16.wadax.ne.jp[203.183.218.26] timed out while sending end of data -- >> > message >> > may be sent more than once) >> > >> > >> > PS: le serveur SMTP distant est au japon, il y a donc de la latence. Dans >> > l'exemple ci-dessus le delay est de 4.8s mais dans certains cas il est >> > plus important. >> >> Comme manifestement, j'ai été le seul choqué par cela, je voudrais dire >> que non, le delay de 4,8sec n'est pas la latence vers le japon. >> Depuis postfix 2.3.13 : >> >> Better insight into the nature of performance bottle necks, with >> detailed logging of delays in various stages of message delivery. >> Postfix logs additional delay information as "delays=a/b/c/d" where >> a=time before queue manager, including message transmission; b=time in >> queue manager; c=connection setup time including DNS, HELO and TLS; >> d=message transmission time. >> >> Les 4,8 sec sont donc "perdues" dans ton pipe local (antispam antivirus, >> etc.). >> Il n'y a que 70ms de transmission de data a proprement parler. >> >> Pierre. >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > Je viens de supprimer toutes les policy et le mail est correctement envoyé. > > indépendemment de cela, j'avais observé un temps de traitement en file > d'attente important dans postfix. > > Je pense que tout était lié. > > Merci à tous, Merci Pierre. tu avais bien vu. > > bonne fin de journée > > -- > Jean-christophe PAROLA > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ -- Cordialement ----------------------------------- William Waisse http://waisse.org | http://neoskills.com | http://ww7.pe | https://careers.stackoverflow.com/neofutur "Computers are like air conditionners. They work better when you close windows." "You have enemies? Good. That means you've stood up for something in your life." "First they ignore you, then they laugh at you, then they fight you, then you win" --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
