[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Admin] Mailprobleme von Arcor Richtung UUGRN ... und die Loesung.
[Thread Prev] | [Thread Next]
- Subject: Re: [Admin] Mailprobleme von Arcor Richtung UUGRN ... und die Loesung.
- From: Raphael Becker <rabe@xxxxxxxxx>
- Date: Fri, 24 Apr 2009 15:48:54 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hallo Alexander, On Fri, Apr 24, 2009 at 03:09:27PM +0200, Alexander Holler wrote: 1) 5sec ist konfiguriert fuer die greet_pause. 2) Dazu kommt ein DNS-Timeout, der *ebenfalls* *vor* 220 kommt. 3) Vollkommen egal *was* vor dem 220 scheint: SMTP-Kommunikation darf auf dem Socket erst begonnen werden, wenn das initiale 220 gekommen ist. 4) Statt "quit" zu sagen waere das richtige Verhalten, die TCP-Connection zu schliessen, denn "quit" ist bereits SMTP. Und ohne den 220 kann der Client nicht davon ausgehen, dass er wirklich mit einem SMTP-Server spricht, der auch funktioniert. 5) Jeder, der aus egal welchem Grund nicht auf das 220 wartet, wird abgehaengt. Dabei ist es egal, ob die Wartezeit durch einen kuenstlichen Fehler (5sec) oder durch einen *realen* Fehler entsteht (naemlich der DNS-Timeout von 30sec). Sinn und Zweck das Warterei ist es, dass der *annehmende* Mailserver Vorbereitungen treffen muss, bevor er Daten tatsaechlich zuverlaessig verarbeiten kann, zB DNS-Lookup, was in diesem Fall ein sehr guter Grund ist, keine Mails anzunehmen und eigentliche (vorzeitige) Uebertragungsversuche abzulehnen. Wuerde der MTA feststellen, dass irgendwas nicht stimmt, aber vorher die Mail annehmen, wuerde er im Zweifel die Mail verlieren aber dem einliefernden MTA signalisieren, dass er sie angenommen hat. Nur weil es meistens klappt, heisst es nicht, dass es so vorgesehen ist. Es ist also kein Akt von "Freundlichkeit" oder "SMTP-Etikette", sondern die Sicherstellung einer Funktion, die vor allem der Einliefernde zurecht *erwartet*. Nur eben dass der einem dann auch die Chance lassen muss, das sinnvoll mitzuteilen. Ein Provider, der im Auftrag seiner (hoffentlich) vielen Kunden Mails zustellt, sollte in der Lage sein, dieses auch wirklich zuverlaessig zu tun, soweit es seine eigenen Systeme betrifft. Er sollte im Gegenzug auch zuverlaessig Mails annehmen oder eben abweisen, wenn er sie nicht annehmen kann. Das "220" signalisiert dem einliefernden MTA, dass wir bereit sind fuer den Empfang einer Mail bzw. mit einer gewissen Wahrscheinlichkeit ausschliessen koennen, dass ein Fehler passieren wird bei/nach der Uebermittlung der Mail. Wenn eine Mail, die man angenommen hat, nachtraeglich verworfen wird, muesste man dies getrennt signalisieren, indem eine Mail zurueckgeschickt wird. > die Verbindung wegen ausbleibendem Greeting eurerseits gekappt haben. > Das die wirklich Mails zustellen ist doch sicher wieder nur ... ... was? Mails von Arcor werden seit gestern wieder angenommen, mit einem Delay von <10sec gemessen an den timestamps Received-Zeilen (zu mindest wir sind ntp-stratum2 syncron). Und ... haetten wir Mailprobleme auch mit dem Rest der Welt gehabt, waere ich der letzte der behaupten wuerde, dass wir im Recht sind, weil sich die ganze Welt nicht an einen RFC haelt. Es ist nur einer - zum wiederholten Male: Arcor. Gruss Raphael -- Raphael Becker <rabe@xxxxxxxxx> http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/