Ein Dialog mit einem der beiden MXe von Web.de (mx-ha01.web.de):
(+ bedeutet von Web.de bekommen, - bedeutet hingesendet.
Empfaenger verfaelscht zum Schutz seiner Privatsphaere)
+220 mx32.web.de ESMTP WEB.DE V4.103#192 Wed, 23 Feb 2005 10:31:48 +0100
-EHLO mail.jors.net
+250-mx32.web.de Hello mail.jors.net [213.183.3.131]
+250-SIZE 70254592
+250-PIPELINING
+250 HELP
-MAIL FROM:<nospa...@jors.net> SIZE=6899
-RCPT TO:<............@web.de>
-DATA
+250 <nospa...@jors.net> is syntactically correct
+250 <............@web.de> verified
+550 Protocol violation
-RSET
-QUIT
Meinem Verstaendnis sowohl von RFC 2821 als auch dem obsoleten 821
nach darf der Mailserver (3.3 Mail transactions) ist das Verhalten
vom Web.de Mailserver falsch. Oder uebersehe ich da was?
Speziell: 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, die Verhaltensweise des WEb.de Servers also
ein Standardverstoss. Oder liege ich da falsch?
PS: Mein MTA macht das schon immer so. Web.de muss das also erst
kuerzlich kaputt gemacht haben.
(Thematisch wohl eher in dcsm zuhause, daher xpost+fup2 dahin)
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Die Meldung des Mailservers rührt nicht daher, daß Du zwei Zeilen in einem
Paket an den Server übermitteln möchtest, sondern daß einer der
Spamerkennungsmechanismen von web.de zugeschlagen hat. Wir haben die Mail
nicht mehr angenommen, weil prozentual zu viele nicht existente Adressen
als Empfänger angegeben worden sind. Ich gebe zu, daß sie geschickter
formuliert sein könnte.
> PS: Mein MTA macht das schon immer so. Web.de muss das also erst
> kuerzlich kaputt gemacht haben.
Am Mailer von web.de hat sich nichts geändert. Bitte überprüfe die Qualität
Deiner Adreßlisten.
Wenn Du legitim Newsletter versendest (also confirmed opt-in fährst),
besteht die Möglichkeit, sich an die Spamcops von web.de zu wenden und sich
in eine Whitelist einzutragen zu lassen, z.B. über
http://kundenservice.web.de/Angebote/FreeMail/Klassen/Abuse/Spamcops/.
Damit kommst Du in jedem Fall an diesem speziellen Spamfilter vorbei, was
das Problem der Adreßlistenqualität jedoch für Dich nicht löst.
Gruß,
Kristian Köhntopp
--
Kristian Köhntopp, http://comwin.name/kr...@webde-ag.de
Senior Security Engineer
> Die Meldung des Mailservers rührt nicht daher, daß Du zwei Zeilen in einem
> Paket an den Server übermitteln möchtest, sondern daß einer der
> Spamerkennungsmechanismen von web.de zugeschlagen hat. Wir haben die Mail
> nicht mehr angenommen, weil prozentual zu viele nicht existente Adressen
> als Empfänger angegeben worden sind.
Äh, sorry, aber das glaube ich nicht. Ich zitiere nochmals, was Jürgen
geschrieben hatte:
-MAIL FROM:<nospa...@jors.net> SIZE=6899
-RCPT TO:<............@web.de>
-DATA
+250 <nospa...@jors.net> is syntactically correct
+250 <............@web.de> verified
+550 Protocol violation
Der Empfänger wurde also sogar "verified", wie sollte er da nicht
existent sein? Oder ist Web.de auch schon unter die gegangen, die
meinen jeden RCPT mit 250 beantworten zu müssen?
>> PS: Mein MTA macht das schon immer so. Web.de muss das also erst
>> kuerzlich kaputt gemacht haben.
> Am Mailer von web.de hat sich nichts geändert. Bitte überprüfe die Qualität
> Deiner Adreßlisten.
Im Beispiel ging es wohl gerade nicht um einen Newsletter, sondern
um eine einzelne Mail an einen einzelnen Empfänger.
Grüße, Dominik
Allerdings. Das haette einiges an Verwirrung erspart.
(und prozentual ist gut, das ist eine Empfaengeraddresse, die auch
einzeln - also ohne pipelining - mit 250 akzeptiert wird, und beim
DATA wieder mit dieser falschen Fehlermeldung abgelehnt wird.), oder war
das ein nicht-Empfaengeraddressen-basierter Spamfilter?
PS: Man kann SPAM-Filter durchaus auch Standardkonform
implementieren, dieser 550 Protocol violation ist an dieser Stelle
aber auf keinen Fall zulaessig. Nach dem 250 auf den (einzigen) RCPT To:
sollte euer Server auf eine DATA nur mit einem der folgenden Codes
antworten:
DATA
E: 451, 554, 503
oder waehrend der Uebertragung (also wenn nach DATA ein 345 kam)
E: 552, 554, 451, 452
Ein 554 mit korrekter Meldung ("command rejected for SPAM policy reason"
o.ae.) waere also weit besser als der unvorhergesehene 550 mit noch
dazu voellig falschem Reason-Text.
Oder gleich vor dem DATA die SPAM-blockierten Rcpt To: Addressen
direkt anmeckern, und nicht erst mit 250 akzeptieren, wenn dann doch
nichts angenommen wird. Das ist extrem Unfein.
>> PS: Mein MTA macht das schon immer so. Web.de muss das also erst
>> kuerzlich kaputt gemacht haben.
>
> Am Mailer von web.de hat sich nichts geändert. Bitte überprüfe die Qualität
> Deiner Adreßlisten.
Siehe haeder. Eine einzige Absenderaddresse, eine einzige
Empfaengeraddresse. Envelope-From matched der IP (SPF rueckwaerts) und
der Envelope-To: ist @web.de.
> Wenn Du legitim Newsletter versendest (also confirmed opt-in fährst),
> besteht die Möglichkeit, sich an die Spamcops von web.de zu wenden und sich
> in eine Whitelist einzutragen zu lassen, z.B. über
> http://kundenservice.web.de/Angebote/FreeMail/Klassen/Abuse/Spamcops/.
Das das kein Newsletter ist, oder sonst eine BULK-mail war, duerfte
das nicht passen.
> Damit kommst Du in jedem Fall an diesem speziellen Spamfilter vorbei, was
> das Problem der Adreßlistenqualität jedoch für Dich nicht löst.
Ich wollte lediglich einem eurer Kunden eine Mail schreiben.
Kristian Köhntopp, WEB.DE AG <kr...@webde-ag.de> wrote:
>Juergen P. Meier wrote:
>> Speziell: 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, die Verhaltensweise des WEb.de Servers also
>> ein Standardverstoss. Oder liege ich da falsch?
>Die Meldung des Mailservers rührt nicht daher, daß Du zwei Zeilen in einem
>Paket an den Server übermitteln möchtest, sondern daß einer der
>Spamerkennungsmechanismen von web.de zugeschlagen hat. Wir haben die Mail
>nicht mehr angenommen, weil prozentual zu viele nicht existente Adressen
>als Empfänger angegeben worden sind. Ich gebe zu, daß sie geschickter
>formuliert sein könnte.
In dem Beispiel ging es um einen Recipient, von daher wäre eine Ablehnung
dieser Empfängeradresse beim RCPT TO eher das Mittel der Wahl.
>[...]
Gruß,
Hannah.
[Verspaeteter und ungeschickter Spam-filter-5xx nach DATA bei Pipelining]
>>Die Meldung des Mailservers rührt nicht daher, daß Du zwei Zeilen in einem
>>Paket an den Server übermitteln möchtest, sondern daß einer der
>>Spamerkennungsmechanismen von web.de zugeschlagen hat. Wir haben die Mail
>>nicht mehr angenommen, weil prozentual zu viele nicht existente Adressen
>>als Empfänger angegeben worden sind. Ich gebe zu, daß sie geschickter
>>formuliert sein könnte.
>
> In dem Beispiel ging es um einen Recipient, von daher wäre eine Ablehnung
> dieser Empfängeradresse beim RCPT TO eher das Mittel der Wahl.
ACK. Ich habe auch noch keine weiter Reaktion von Kristian oder
Sonst jemanden bei Web.de bekommen.
Mittlerweile hab ich die Mail auch schon geloescht, die ich an einen
Web.de Kunden schicken wollte. Mir egal, wer nicht will der hat schon.