Fehlerhafte "From:" Zeile in QMail blocken

A

Alwin

New Member
Hallo,

ich habe die Tage ein sehr unschönes Problem bekommen:

Ein Kunde hatte mehrfach Emails an eine Adresse verschickt, welche keinen gültigen "From:" Kopfeintrag enthielten. Der Empfänger-MTA hatte die Teile sofort zurückgewiesen (Greylisting) und nach einer Zeit landete unser MTA bei Backscatterer.org in der Blacklist, wodurch dann beim Empfänger MTA erst Recht die Tore runtergingen. Und ja - ich weigere mich, dem Erpressungsversuch von Backscatterer stattzugeben und einen Haufen Kohle für das vorzeitige De-Listing zu bezahlen.

Zur eigentlichen Frage:
Wie kann ich es zukünftig verhindern, dass QMail Mails ohne gültiges "From" von authentifizierten Nutzern überhaupt annimmt und weiterleitet? Unschön und unkorrekt ist es ja wirklich, aber ich habe auch nach mehrtägiger Suche und Doku-Studium zu diesem Thema nichts gefunden.

Achja: System ist ein Plesk 9.2 mit qmail von Plesk, qmail mit spamdyke.

Ciao

A.
Ciao
 
Durch korrekt implementiertes Greylisting kann kein Backscatter erzeugt werden. Der empfangende MTA sagt noch bevor die Mail vollständig eingeliefert wurde, dass er sie nicht annimmt. Dadurch wird keine einzige Bounce-Mail generiert.

Wenn Dein qmail dabei Bounce-Mails erzeugt ist das Dein Problem und Du bist zu Recht auf der Blacklist gelandet. In diesem Fall hat das auch nichts mit einer falschen From:-Zeile zu tun. Das korrekte Verhalten wäre, die Mail in der queue zu halten und die Zustellung später wieder zu versuchen, solange bis die Mail entweder angenommen wurde oder mit einem permanenten Fehler (5xx) abgelehnt wurde.

Bei Mails, die permanent abgelehnt wurden, sieht die Situation schon anders aus. Da musst Du natürlich eine Nachricht generieren und bist auf die hoffentlich korrekten Angaben Deines Kunden angewiesen. Da der Kunde ja mehrere Domains haben kann, ist es nicht ohne weiteres möglich auf eine korrekte Absenderadresse zu prüfen. Manche Provider (t-online in manchen Tarifen) ersetzen prinzipiell die Absenderadresse, aber dieses Verhalten ist nicht sonderlich "freundlich".
 
Ich denke ebenfalls, dass hier zwei verschiedene Vorfälle in den selben Topf geworfen werden.

Zusätzliche Gegenfrage:
Wie sah der fehlerhafte From-Header denn aus?
Kannst Du uns den Part mit Logfiles belegen?

huschi.
 
MOD: Full-Quote entfernt!
Ganz simpel: Es gab keine From-Zeile. Dadurch hat der Empfänger MTA das GreyListing auf seiner seite nicht auflösen können (scheint keine leeren From. einzutragen) und hat den von mir betreuten Server dann bei Backscatterer gemeldet.

Und ja: Greylisting ist klar, würde bei externen Zustellen zu einer von mir gehosteten Mailadresse zuschlagen. Das problem ist hier ein User, der authentifiziert eine mal-formed mail abeschickt hat -> spamdyke überprüft die gar nicht erst.

Hier mal Logeintrag womit es begann: (ipadressen etc. maskiert)

Code: 
Dec  7 15:38:29 yyyyyyyy smtp_auth: SMTP connect from (null)@xxxxx [xx.xx.xx.xx]
Dec  7 15:38:29 yyyyyyyy smtp_auth: smtp_auth: SMTP user xxxx@xxxx.com : logged in from (null)@xxxxx [xx.xx.xx.xx]
Dec  7 15:38:29 yyyyyyyy spamdyke[21112]: ALLOWED from: (unknown) to: xxxx.xxxx@xxxx.de origin_ip: xx.xx.xx.xx origin_rdns: xxxxx.xxxx.net auth: xxxx@xxxx
Dec  7 15:38:29 yyyyyyyy qmail-queue-handlers[21125]: Handlers Filter before-queue for qmail started ...
Dec  7 15:38:29 yyyyyyyy qmail-queue-handlers[21125]: from=
Dec  7 15:38:29 yyyyyyyy qmail-queue-handlers[21125]: to=xxxx@xxxx.de
Dec  7 15:38:29 yyyyyyyy qmail-queue-handlers[21125]: hook_dir = '/usr/local/psa/handlers/before-queue'
...
Dec  7 15:38:30 yyyyyyyy qmail: 1260196710.975268 delivery 5158: deferral: xx.xx.xx.xx_does_not_like_recipient./Remote_host_said:_450_Temporary_rejected:_450_(V4.07-RULE-1104)_Greylisted,_come_back_within_the_next_24_hours./Giving_up_on_xx.xx.xx.xx./

Diese Greylisted-Meldungen für diese Mail zogen sich bis ca. 9.12. hin, danach kann man der Hinweis mit Backscatterer von diesem Host. Ich kanns ihm nicht übermässig verdenken, allerdings find ich es schon herb - spamdyke lässt auch sowas schon mal durchs greylisting normal, d.h., macht einen Eintrag dafür.

insbesonderen
Code: 
ec  7 15:38:29 yyyyyyyy qmail-queue-handlers[21125]: from=

tut mir weh. Weil Spamdyke das nicht abfängt für authentifizierte user - und ich bei qmail nichts gefundne habe, wie der das selber blocken könnte. Sprich, so dass der KUnde/Client selber ne Fehlermeldung bekommt "Nee, Du, das lassen wir mal lieber, da fehlt noch was.".

Ich hoffe, jetzt ist es etwas eindeutiger.

Ciao und danke für die Antworten.

Alwin
 
Last edited by a moderator:
Alwin said:
der authentifiziert eine mal-formed mail abeschickt hat -> spamdyke überprüft die gar nicht erst.
...
Weil Spamdyke das nicht abfängt für authentifizierte user
Click to expand...

Dafür dass Spamdyke es nicht prüft, verlangst Du recht viel von ihm. :D

Klar könnte man von den vielen vielen Programmen die da zwischen geschaltet waren verlangen, dass eins davon diesen Fehler abfängt. Dumm nur, wenn sich jedes Programm darauf verlässt vom anderen Programm korrekt bedient zu werden...
Aber im Grund läuft alles auf eins hinaus:
Dein Kunde schreibt fehlerhafte Emails. Dem musst Du mal als Erstes bescheid geben.

Wer letztendlich Deine IP bei Backscatterer gemeldet hat bleibt ungewiss. Denn wenn der Kunde bereits längere Zeit solche Emails versendet (evtl. sogar einen Newsletter?), dann kommen dafür massenweise Server in Frage.

huschi.
 
Hab noch mal recherchiert, im letzten halben Jahr war es definitiv das einzige mal das sone kaputten mails von einem Kunden verschickt wurden. Also gehe ich davon aus, dass diese der Auslöser waren.

Spamdyke: Tja, wenns keine andere Lösung gibt, muss ich mich wohl mal durch die sourcen wühlen, ob man dem nicht beibiegen kann, bestimmte Checks auch für authentifizierte Nutzer zu machen.... Ich hatte gehofft, dass man im Qmail selber irgendwas einstellen kann.

Falls es da noch mal Ideen gibt - immer her damit.

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