Hinweis: Der Eintrag "messagelabs.com SMTP bricht RFC821/RFC2821?" ist vor mehr als einem Jahr geschrieben oder zuletzt editiert worden und unter Umständen veraltet oder nicht mehr korrekt.

So. Einige Mails von deutschen Firmen werden seit letzter Woche in der Arbeit bis zu 70 Mal innerhalb ca. 4 Tagen eingeliefert. An der infrastruktur oder der Konfiguration im Haus wurde nichts geändert.

Nachdem sichergestellt wurde, daß die Mails sich nicht intern vermehren, sodern wirklich zu Hauf per SMTP abgegeben werden, steht folgendes fest:

  • Es handelt sich um Mails von 4 deutschen Firmen, die auf den ersten Blick nichts gemeinsam haben. Auf den 2. Blick fällt auf, dass alle über Server von messagelabs.com senden. Prima, Outsourcing!
  • recordio vor qmail-smtpd zeigt, dass keine der Mails einen 4xx SMTP-Fehler provoziert, der den sendenden Server denken lassen könnte, die Zustellung wäre fehlgeschlagen.
  • Es zeigt auch, dass der sendende Server keine Mail-Abgabe nach dem Ende (<crlf>.<crlf>) mit einem QUIT beendet, und auch nicht wartet, bis sich mein qmail-Server nach einigen Minuten vergeblichen Wartens mit einem 250 ok xxxxxxxxxxxxx qp xxxxxx bedankt. – Er trennt die Verbindung vorher ([EOF]) und bekommt deswegen das 250 ok ... wahrscheinlich garnicht mehr mit.

Muß mein qmail-smtpd ein QUIT abwarten?

In RFC821, Abschnitt 4.1.1., „COMMAND SEMANTICS“, steht:

Auf Deutsch:

RFC 821 ist zwar abgelöst, aber in der nachfolgenden RFC2821, Abschnitt 4.1.1.10, „QUIT (QUIT)“ steht:

Auf Deutsch:

Mr. Bernstein

D. J. Bernstein, der Autor von qmail schreibt:

Was mit RFC2821 absolut einhergeht:

  • Als Client nicht abslichtlich trennen ohne vorhergehendes QUIT
  • Als Server nichts rückgängig machen, was bisher getan wurde

Meine Logs

Erklärung: „< ", also "rechts nach links" ist mein Empfang, ">„, also „links nach rechts“ ist was ich sende.

So wär’s richtig

Dialog mit einem fremden Mailserver, der „normal“ ist:

Er sendet <crlf>.<crlf> zum Beenden der Mail, danach QUIT, da er keine weiteren Mails mehr für mich hat. 55 Sekunden später antworte ich 250 ok ....

Oder so (auch normaler Server):

Er sendet auch <crlf>.<crlf> zum Beenden der Mail, danach QUIT. 1:22 Minuten später antworte ich 250 ok .... Bissl spät, aber was soll’s. War noch nie ein Problem, wie gesagt.

So geht’s nicht

Das st eine Mail, die von serverXX.towerYY.messagelabs.com kommt:

Ein <crlf>.<crlf>, kein QUIT. Stattdessen nach 4 Minuten ohne Antwort von mir ein Disconnect, mein 250 ok ... hört er nicht mehr.

So auch nicht:

Das selbe, nach exakt 4 Minuten ein Disconnect.

Und so auch nicht:

Und wieder nach 4 Minuten.

Zusammenfassung – Meine Seite

Nach RFC2821 verhalte ich mich (fast) korrekt:

Mache ich, wenn ich das QUIT bekomme.

Tue ich nicht. Der Sender trennt.

Ich mache keine ausgeführten Aktionen rückgängig. Die Mail wird zugestellt. Jeeeedes verdammte Mal…

Ich kann nicht mehr antworten, wenn getrennt wurde. Ganz einfach.

Zusammenfassung – Messagelabs

Das tut Messagelabs aber – entgegen der RFC.

Das interessiert Messagelabs nicht.

Sollte Messagelabs.

Muß mein qmail-smtpd auf . antworten?

In RFC2821, Abschnitt 4.2.5 „Reply Codes After DATA and the Subsequent .“ steht:

Wenn ich mit einem 2xx ok... antworte, bin ich für die Mail verantwortlich.

Wenn ich mit einem 5xx-Fehler antworte, ist der Client für die Mail verantwortlich. Soweit noch nichts von „ich muß antworten“. Doch in Abschnitt 6.1, „Reliable Delivery and Replies by Email“ steht:

Also die Antwortzeit von empfangenen <crlf>.<crlf> bis zur Antwort muss vom Server möglichst gering gehalten werden. qmail antwortet hier 4 Minuten nicht.

Ein Fehler in qmail?

RFC1047, „DUPLICATE MESSAGES AND SMTP“, sagt:

Ok, nach <crlf>.<crlf> bearbeiten und Antworten.

Bingo.

… oder Spamassassin kotzt sich mit der Alles-auch-in-HTML-Mail einen ab.

qmail-scanner-queue.pl hat die Mail jeweils laut Log in ca. 5-25 Sekunden durchgecheckt, und auch das Umstellen von qmail-scanner auf sa_fast (Socket statt Netzwerk-Verbindung zu spamd) bringt nichts. Schon ausprobiert.

Weiter heißt es:

Ende

Messagelabs wartet exakt 4 Minuten, und trennt dann die Verbindung, ohne ein QUIT zu senden. Das ist gegen die RFC.

Warum qmail nicht gleich auf <crlf>.<crlf> antwortet, ist mir momentan unerklärlich. Kommt ein <crlf>.<crlf> gefolgt von einem QUIT, antwortet qmail innerhalb kürzester Zeit.

Eine Idee wäre ein qmail-SPP Plugin, das nach <crlf>.</crlf> immer mit 220 ok antwortet – aber es gibt keinen Hook für <crlf>.<crlf>, nur für DATA.

Mal sehen, was noch so passiert. Morgen qmail noch einmal kompilieren und weitertesten.

ITStudent.org und andere Seiten berichten auch über wiederkehrende (andere) Probleme mit Messagelabs.