ce [15/Avr/2004 13:31], Cedric Gavage nous offrait sa prose dans "Re: [CCMC] sterpin.net ;)"
> > C'est un serveur de liste qui n'a que �a � faire, j'ai regard� sur le > serveur d'unixtech, il doit aussi contacter � plusieurs reprises ;) > mais il n'a aussi que �a � faire. Vu que c'est hors thread, j'en > resterai l� ;) > moi pas :-) -> sur combien sont r�gl�s vos timeouts? dans l'en-t�te je vois ceci: >sm-que[6747]: i3EEdJC0015992: to=<[EMAIL PROTECTED]>, delay=15:44:00, >xdelay=00:00:26, mailer=esmtp, pri=120906, relay=mx.ibbbs.net. >[195.13.31.117], dsn=4.0.0, stat=Deferred: Connection timed out with >mx.ibbbs.net. -> xdelay=00:00:26 ce qui pour moi signifie 26 secondes... Mais ce n'est peut-�tre pas la bonne valeur... Et si on lit les rfc: From RFC 2821 (ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt) >4.5.3.2 Timeouts > > An SMTP client MUST provide a timeout mechanism. It MUST use per- > command timeouts rather than somehow trying to time the entire mail > transaction. Timeouts SHOULD be easily reconfigurable, preferably > without recompiling the SMTP code. To implement this, a timer is set > > > >Klensin Standards Track [Page 56] > >RFC 2821 Simple Mail Transfer Protocol April 2001 > > > for each SMTP command and for each buffer of the data transfer. The > latter means that the overall timeout is inherently proportional to > the size of the message. > > Based on extensive experience with busy mail-relay hosts, the minimum > per-command timeout values SHOULD be as follows: > > Initial 220 Message: 5 minutes > An SMTP client process needs to distinguish between a failed TCP > connection and a delay in receiving the initial 220 greeting > message. Many SMTP servers accept a TCP connection but delay > delivery of the 220 message until their system load permits more > mail to be processed. > > MAIL Command: 5 minutes > > RCPT Command: 5 minutes > A longer timeout is required if processing of mailing lists and > aliases is not deferred until after the message was accepted. > > DATA Initiation: 2 minutes > This is while awaiting the "354 Start Input" reply to a DATA > command. > > Data Block: 3 minutes > This is while awaiting the completion of each TCP SEND call > transmitting a chunk of data. > > DATA Termination: 10 minutes. > This is while awaiting the "250 OK" reply. When the receiver gets > the final period terminating the message data, it typically > performs processing to deliver the message to a user mailbox. A > spurious timeout at this point would be very wasteful and would > typically result in delivery of multiple copies of the message, > since it has been successfully sent and the server has accepted > responsibility for delivery. See section 6.1 for additional > discussion. > > An SMTP server SHOULD have a timeout of at least 5 minutes while it > is awaiting the next command from the sender. On constate des 5 minutes, 3 minutes, le temps le plus court �tant 2 minutes... Soit plus de 4 x les 26 secondes, non? Mais peut-�tre n'est-ce pas 26 secondes? -> je suis ouvert au d�codage des en-t�tes... Si c'est 26 secondes, pendant ces 26 secondes, mon serveur mail interroge plusieurs blacklists (8), question de savoir s'il laisse passer ou pas. Ca me pr�serve du spam et j'en suis ravi -> si le prix � payer est de recevoir les mails de "skynet" 12 heures apr�s, en moyenne, ben c'est en fait tr�s bon march� :-) -- Andr� Sterpin <http://www.sterpin.net> ------------------------------------ -- CyberCafe c'est chaque semaine le mardi 19h et 22h30 sur La 2! Cette liste vous est offerte par Emakina <http://www.emakina.com/> Emakina: technologie et creativite au service de vos projets Web. Desabonnement par email : <mailto:[EMAIL PROTECTED]>
