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]>
