web.de meldet: 550 Protocol violation (in reply to DATA command)

S

s24!

Registered User
Hallo,

ich habe ein merkwürdiges Problem mit unserem Mailserver festgestellt: Gestern sollte eine Mail (per PHP) an eine web.de-Adresse rausgehen. Zurück kam dann folgendes:

Code: 
This is the mail system at host mail.unsere-domain.de.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<empfaenger@web.de>: host mx-ha01.web.de[217.72.192.149] said: 550 Protocol
    violation (in reply to DATA command)



Reporting-MTA: dns; mail.unsere-domain.de
X-Postfix-Queue-ID: 6F7D534F6008
X-Postfix-Sender: rfc822; support@unsere-zweite-domain.de
Arrival-Date: Sun,  5 Jun 2011 22:10:15 +0200 (CEST)

Final-Recipient: rfc822; empfaenger@web.de
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx-ha01.web.de
Diagnostic-Code: smtp; 550 Protocol violation

Nach etwas Googlen fand ich sowohl alte als auch neue Beiträge zu dieser Meldung, die meisten waren aber alt bis uralt. Allerdings soll diese Meldung wohl bei web.de bedeuten, dass der Empfänger nicht existent ist. Könnte ja prinzipiell sein. Jetzt wird es aber komisch: Die nicht zugestellte Mail habe ich dann über meine private Adresse nachgereicht. Ergebnis: Die Nachricht kommt an. :confused:
Also, sie kommt garantiert an - es kam eine Antwort.

Was ist da los?


Grüße
 
Last edited by a moderator:
Der Spam-Filter von Web.de ist mal wieder völlig kaputt konfiguriert und verstösst dadurch gegen den zuständigen RFC.
Bitte bei Web.de beschweren und hoffen, dass sie es noch in diesem Jahrzehnt fixen...
 
Ich würde es nicht gleich auf web schieben. Stimmen den die üblichen Verdächtigen auf dem Server ? (PTR <-> helo , PTR <-> forward DNS)
 
In der DATA-Phase kann man eigentlich nicht mehr so viel falsch machen.
Mir fallen im wesentlichen die Zeilenumbrüche (kein CR/LF) und nicht kodierte Umlaute ein. Eventuell noch eingebettete 0-Bytes.
 
Hallo,
das schließe ich eigentlich aus. Die Kommunikation mit Web.de klappt ja sonst auch, und ein erneuter Versand der Mail zu Testzwecken klappte.

Grüße
 
cosimo said:
Ich würde es nicht gleich auf web schieben.
Click to expand...
Ich vertraue da doch eher auf die Aussagen bekannter deutscher Postmaster grosser Mailfarmen, sowie dem ehemaligen Sicherheitschef von Web.de, auch wenn diese Aussagen bereits etwas älter sind. Die Symptome sind jedenfalls 100%ig identisch und das Problem taucht in unregelmässigen Abständen immer wieder auf, so dass man davon ausgehen kann, dass an der eigentlichen Ursache bei Web.de nie ernsthaft gearbeitet wurde.
 
Whistler said:
In der DATA-Phase kann man eigentlich nicht mehr so viel falsch machen.
Mir fallen im wesentlichen die Zeilenumbrüche (kein CR/LF) und nicht kodierte Umlaute ein. Eventuell noch eingebettete 0-Bytes.
Click to expand...

Ok, das hatte ich überlesen. Aber auch dann kann man immernoch eine .EXE verschicken und der Empfänger lehnt das ab.
 
<Moderation>
@peppy0402: unqualifizierter Beitrag!
</Moderation>

Folgendes aus der verlinkten Diskussion:
Meinem Verstaendnis sowohl von RFC 2821 als auch dem obsoleten 821
nach [...]
[...]die Tatsache, das mein Server MAIL FROM:, RCPT TO: und
DATA in einem TCP Paket sendet (also in einem Rutsch), ist nach
SMTP Standard erlaubt
Click to expand...
Sowohl in der (niemals gültig gewordenen) RFC2821 als auch in heutigen RFC5321 sind klare Timeouts vorgegeben. U.a. nach eine RCPT (5 min.) und nach DATA (2 min.).
Demnach ist das "in einem Rutsch" nicht erlaubt. (Wo auch immer Juergen P. Meier diese Information gelesen haben will.)
Ein "Protocol violation" ist in diesem speziellen Fall also tatsächlich gerechtfertigt gewesen, denn das DATA kam ohne Antwort auf den RCPT zu warten.

Aber auf diesen Punkt ist in der ganzen Diskussion dort niemand eingegangen. Statt dessen wird einfach mal auf Web.de eingeschimpft und dieser Fall heute noch für Bare Münze genommen.

Wer sich jetzt unsicher ist, ob sein MTA sich korrekt verhält oder nicht, sollte das Logging (beim Postfix ganz einfach) aktivieren und auf eine solche Fehlermeldung warten. Sobald jemand einen Protokoll-Auszug hat, welche mit dieser Meldung terminiert, würden sicherlich alle gerne einen Blick darauf werfen. ;)

huschi.
 
RFC5321 verweist auf Seite 8 im vorletzten Absatz auf PIPELINING (RFC2920).
 
Last edited by a moderator:
Ok, das mit dem Pipelining ist mir entgangen. Aber dennoch sind einige Fehler im Gedankengang:
Z.B. muss bei Pipelining der Client (der eigene MTA) damit rechnen, dass Fehlermeldungen auf vorherige SMTP-Commands während der DATA-Übertragungen als Response kommen (RFC 2920 3.1). D.h. hier darf man nicht die strenge Antwort-Regeln der RFC's zugrunde legen. Also ist auch ein 550 (fast) jederzeit möglich.

Ich sehe darin also keine Anzeichen von "Spam-Filter [...] ist [...] völlig kaputt konfiguriert und verstösst dadurch gegen den zuständigen RFC".

huschi.
 
Sowohl der FROM als auch der RCPT TO wurden mit 250 beantwortet und im DATA ist ebenfalls kein Fehler, da die gleichen Mails zu anderen Zeitpunkten angenommen wurden. Einen RCPT TO erst mit 250 anzunehmen und ihn dann später doch noch mit einem 5xx abzulehnen, verstösst nunmal gegen die RFCs und genau das macht der Spamfilter bei Web.de seit Jahren immer wieder.

Jürgen, Dominik, Marc und Thomas gehören übrigens (nicht nur) im Bereich SMTP zu den Leuten, die sehr genau wissen, wovon sie sprechen.

Hier nochmal beide Teile des Crosspost auf Google Groups:
http://groups.google.com/group/de.comm.provider.mail/browse_thread/thread/9bfe737efb9f227c
http://groups.google.com/group/de.c...read/thread/9bfe737efb9f227c/3b235cf42aec52a5
 
Leute, ihr verwirrt mich. Ist vielleicht auch nicht mehr ganz meine Zeit. Aber:
Wie sage ich postfix denn nun, dass er das richtig machen soll mit den Timeouts etc.? Scheinbar liegt bei uns ja doch noch eine Teilschuld.

Grüße
 
Postfix macht das schon völlig richtig. Der Spam-Filter von Web.de ist das Problem und der kann nur von Web.de gefixt werden. Das ist zwar blöd für Dich und alle anderen Betroffenen, aber nunmal nicht zu ändern.

Eine Möglichkeit gibt es aber noch: Lasse Deinen Mailserver bei Web.de auf die Whitelist setzen, dann kommt der kaputte Spam-Filter nicht mehr zum Einsatz.
 
Warum sollte web.de diese IP auf die Whitelist setzen? Das versteh nur bedingt. :D Dass wir momentan nicht auffällig sind, heißt ja nicht, dass wir nicht trotzdem mal zum Spammer werden können.
(In der Theorie natürlich, praktisch sichern wir uns ab ;))


Gute Nacht
 
You must log in or register to reply here.
Back
Top