procmailrc und exitcodes

[Montesuma]

Wenn im procmailrc ein Exitcode ausgeführt wird, wird dann die aktuelle Übertragung mit dem Fehlercode unterbrochen, oder ist diese dann schon "durch" und es wird nur noch ein Bounce an die im Absender angegebene Email Adresse zurück geschickt?

 

[Huschi]

Deine Frage ist etwas diffuse, da es 2 Dinge durcheinander wirbelt.
Ich versuche es mit einer Antwort, die das Ganze mal etwas richtig stellt.

Wenn Procmail an eine Exitcode-Anweisung stößt, beendet es vollständig die Abarbeitung des Auslieferungsprozesses und beendet sich mit dem entsprechenden Exitcode.
(Ein Bounce wird niemals von Procmail versand.)

Das aufrufende Programm (meist der Mailserver) muß diesen Exitcode interpretieren. Postfix und Sendmail ignorieren ihn. Qmail hingegen braucht den Exitcode sogar um festzustellen, ob weitere Auslieferungsschritte in der Datei .qmail abgearbeitet werden sollen, oder nicht. (Hier wird also ebenfalls kein Bounce versand.)

Wenn Du einen Bounce anhand von Filter-Einstellungen versenden willst, implementierst Du dazu am Besten ein Script, welches dies tut. Das kannst Du dann in der procmailrc vor dem Exitcode einbinden.

Aber vielleicht beschreibst Du erstmal, was Deine Frage eigentlich bezwecken soll.

huschi.

 

[Montesuma]

Danke schon mal für die Ausführung. Mein Zweck ist, daß in der procmailrc spamassassin aufgerufen wird. Danach steht das Ergebnis in form des Scores fest. Wenn der Score über 10 ist, wird ein Exitcode ausgegeben und der Versender bekommt eine Fehlermeldung.

Wenn dieser Exitcode bewirken würde, daß die momentane (als Spam) berechnete Übertragung abgebrochen wird, ist alles gut.

Wenn jedoch ein Bounce zurück geschickt wird, dann bekommt es nicht der Versender, sondern nur derjenige, wessen Email in der ge-fake-ten Absenderadresse stehen würde. Das wäre schlecht.

Ich habe es sogar schon mal ausprobiert:

procmailrc

:0
* ^X-Spam-Status: Yes
{
EXITCODE=77
}

Der Versender bekommt sogar eine Nachricht mit dem "permission denied" (exitcode 77), ich konnte jedoch nur nicht auf die schnelle identifizieren, ob es während der Übertragung abgebrochen war, oder ein Bounce zurück gesendet wurde. Ich müsste mal in ruhe wieder die Logfiles studieren.

Daß Postfix es ignoriert kann ich nicht bestätigen. Mit dem oben genannten code tut sich wirklich was, ohne einen eigenen bounce generieren zu müssen. Könntest Du dir das erklären?

Gruß

Monty

 

[amnesie]

Wenn ich das richtig interpretiere, bist du auf der falschen Fährte. Procmail ist nicht in den postfix integriert, also wird keine Verbindung abgebrochen, sondern die Mail wurde vom Postfix schon angenommen. Es ist also praktisch zu spät, um irgendwas zurückgehen zu lassen, du hast den Spam schon auf der Platte stehen und der andere Mailserver ist wieder weg.

 

[Montesuma]

Aha. Dann wird also irgendwo noch ein Bounce erzeugt.
Mein Postfix sieht so aus:

smtp      inet  n       -       n       -       -       smtpd
smtpd_tls_wrappermode=yes
pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       n       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       n       -       -       smtp
        -o fallback_relay=
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
content_filter=
scache    unix  -       -       n       -       1       scache
==========================================================maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
cyrus     unix  -       n       n       -       -       pipe
  user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
procmail  unix  -       n       n       -       -       pipe
  flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient}
tlsmgr    unix  -       -       n       1000?   1       tlsmgr

Wo/wie könnte ich den Spamassassin einbauen, daß noch während der Übertragung auf Spam geprüft wird und im letzten Moment die Verbindung gekappt wird?

Wenn ich ein Bounce zurück sende, dann meistens an den Falschen Absender also will ich erst gar nicht, daß die Übertragung erfolgreich wird. Dann weiss der Spammer, daß hier gar nichts geht.

 

[Montesuma]

Nachdem das scheinbar keiner weiss, bin ich mal davon ausgegangen, daß es keiner Praktiziert. Dann habe ich mir also Gedanken gemacht, warum eigentlich nicht?

Ich bin auf folgende Theorie gestoßen: Die Spammer sollen erst gar nicht mitbekommen, daß sie geblockt wurden, das macht den Spammern viel mehr arbeit, als daß Sie das Ergebnis mit einem Fehlercode auf den Teller serviert bekommen. Bei einem Fehlercode würden sie nur neue Techniken erarbeiten. Ohne Fehlercode glauben sie, daß sie erfolgreich waren, und ändern nichts an der momentanen Technik, und haben sogar mehr Aufwand - mit so vielen gültigen Email Adressen und so wenig gewonnenen Kunden.

Liege ich da richtig?

Aber wie bekommt man dann die Spammer erkannt, die laut Spamassassin Regeln keine großen Punkte gesammelt haben und manuell auf die Blacklist gesetzt wurden, beim nächsten Angriff werden sie ja mit der gleichen Technik und einer anderen IP Nummer und anderen Absender Email Adresse wieder erfolgreich SPAM an mich versenden, wenn sie niemals eine Fehlermeldung bekommen.

 

[Huschi]

bin ich mal davon ausgegangen, daß es keiner Praktiziert.

Richtig. Denn ein onthefly-Scanning während der Einlieferung wäre nicht Ressourcen schonend. Ausserdem arbeiten Spammer anders:
Bei denen geht es um möglichst schnellen Output. Sie achten eh nicht auf Fehlermeldungen. Der Spammer hat bereits seine komplette Mail durchgeschickt, bevor der SMTP-Server überhaupt das "RCPT TO" ausgewertet hat.
(Schon mal "too many errors after DATA" im Maillog gesehen?)

mit so vielen gültigen Email Adressen und so wenig gewonnenen Kunden.

Liege ich da richtig?

Irgendwo hab ich mal gelesen, daß die Klick-Quote bei Spams bei 0.01% liegt.
Wenn man die Dunkelziffer der geblockten, fehlerhaften und per Spamfilter aussortierten Mails dazu rechnet, fragt man sich doch, wieviel Mails so ein Spammer eigentlich raushauen muß um wirklich Geld zu verdienen.
Und die müssen wohl ausreichend Geld verdienen, sonst würden die es ja nicht machen.

Fazit:
Wenn es Dir lediglich darum geht Spammer direkt abzublocken, dann schau Dir mal Greylisting an.
Für Postfix gibt es ein vorgefertigtes Paket Postgrey. Unter Debian ganz leicht zu installieren:
Postfix: Greylisting mit Postgrey (Debian)
Läßt sich aber auch schnell aus den Sourcen kompilieren und zum laufen bringen.

huschi.

 

[Montesuma]

Danke, Huschi,

das Greylisting habe ich mir schon angeschaut. Das Ziehe ich mir vielleicht noch rein. Ich habe noch etwas gemischte Gefühle dabei, da meine Firma per Email viel Geschäfte abwickelt und "schnellen" Support über Email an "unbekannte Kunden von Kunden" gibt. Ich weiss nicht, ob das mit Greylisting funktionieren würde.

Trotzdem nochmals: Danke, daß Du allen hier mit Rat und Tat bei stehst.

 

[Huschi]

und "schnellen" Support über Email an "unbekannte Kunden von Kunden" gibt.

Was glaubst Du was ich tue?

Ich weiss nicht, ob das mit Greylisting funktionieren würde.

Ja, würde es. Du mußt Dir das Prinzip verinnerlichen. Dann erkennst Du, daß reale Emails nicht geblockt werden. Bei aktiven Kundenkontakt wird auch nur die erste Email bei der ersten Einlieferung geblockt. Das bringt eine Verzögerung von ein paar Minuten mit sich. Danach läuft alles in Echtzeit weiter.

huschi.

 

[Montesuma]

Ahhhja. Überall lese ich, daß Greylisting wegen schlecht installierten Mailservern manchmal gleich um Stunden verzögert. Bei wie viel Erstkontakten kommt das nach Deiner Erfahrung vor?

 

[Huschi]

Das muß nicht an schlechter Konfiguration liegen. Es hängt auch davon ab, wieviel der jeweilige andere Mailserver zu tun hat. Schließlich hängt sich diese Mail wieder am Ende der Queue ein.

Wer einen Einfluss darauf haben will, kann dies mit einem Secondary MX lösen:
Ein realer Mail-Server versucht nach dem missglückten Einliefern seine Mail an den Secondary MX einzuliefern. (Dies ist bereits etwas, was Spammer nicht tun!)
Der Secondary betreibt kein Greylisting und nimmt die Email an. Er versucht direkt eine Zustellung an den Primary. Dies wird erstmal geblockt. (Findet aber innerhalb weniger Sekunden nach Einlieferung statt). Mit der richtigen Konfiguration auf dem Secondary, liefert er die zwischengespeicherte Email genau 5-6 Minuten später wieder ein.
So hat man selber in der Hand, wie groß die Verzögerung ist.

Theoretisch kann man das sogar mit ein und dem selben Server lösen:
Greylisting-Block auf wenige Sekunden (unter 10) setzen und die selbe oder eine zweite IP des selben Servers als Secondary-MX eintragen.
Könnte aber sein, daß es auch schief geht.

PS: Auf die Idee bin ich gerade am Freitag gestoßen, als ich bei einem Kunden Greylisting installiert habe, der einen Sec.MX hatte und ich einen "seltsamen Seiteneffekt" feststellen mußte.

huschi.

 

[Montesuma]

Die Idee ist genial. Das werde ich in den nächsten Wochen mal ausprobieren - mit zwei Servern.

 

[amnesie]

:
Ein realer Mail-Server versucht nach dem missglückten Einliefern seine Mail an den Secondary MX einzuliefern. (Dies ist bereits etwas, was Spammer nicht tun!)

Einspruch. Viel Spam wird ausschliesslich über die secondary MXe geschickt, in der berechtigten Annahme, daß dieser nicht so streng konfiguriert ist (weil ihm beispielsweise die Liste der gültigen EMail-Adressen fehlt).

Ich habe einen secondary MX laufen, mit denselben Einstellungen wie der primary (also die DUL und die Blacklist der iX, und sonstigen etwas strengen Anforderungen). Es kamen mehrere Spammails am Tag durch. Seitdem ich auf dem secondary zusätzlich noch Greylisting aktiviert habe, kommt kein Spam mehr über den 2nd MX. Insgesamt gibt es dort etwa 50 bis 100 Zustellungsversuche (ist nur meine private Domain), alles Spam.

 

[Huschi]

in der berechtigten Annahme, daß dieser nicht so streng konfiguriert ist

Das stimmt natürlich. Aber auch der Secondary wird erstemal bei der Einlieferung vom Primary geblockt. Schließlich zählt immer das Tripel IP+Absender+Empfänger. Nachteil des Secondary: Er nimmt viele Emails an und stellt sie alle an den Primary mit der selben IP zu. Wenn dann mal das Tupel Absender+Empfänger übereinstimmt und das Empfänger-Postfach existiert, wird diese Email tatsächlich zugestellt.

Ich hab es jetzt erst bei einem Kunden installiert und noch keine brauchbaren Ergebnisse. Aber rein aus meiner Vorstellung sollte dennoch ein Großteil der einmaligen Versuche draußen bleiben.

So wie Du Deinen Fall beschreibst klingt es so, als wäre Dein Secondary ohne das Greylisting an den Primary gebunden. Dann wirkt diese Lösung natürlich nicht.

huschi.

 

[amnesie]

Das stimmt natürlich. Aber auch der Secondary wird erstemal bei der Einlieferung vom Primary geblockt. Schließlich zählt immer das Tripel IP+Absender+Empfänger. Nachteil des Secondary: Er nimmt viele Emails an und stellt sie alle an den Primary mit der selben IP zu. Wenn dann mal das Tupel Absender+Empfänger übereinstimmt und das Empfänger-Postfach existiert, wird diese Email tatsächlich zugestellt.

Ich habe mich vielleicht missverständlich ausgedrückt: Nur der secondary betreibt Greylisting. Und wenn ich auf dem primary MX auch greylisting betreiben würde, würde ich den secondary natürlich auf eine whiteliste setzen, keine Frage. Und über den secondary kommt jetzt kein Spam mehr.

So wie Du Deinen Fall beschreibst klingt es so, als wäre Dein Secondary ohne das Greylisting an den Primary gebunden. Dann wirkt diese Lösung natürlich nicht.

Das habe ich jetzt nicht verstanden.

 

[Huschi]

würde ich den secondary natürlich auf eine whiteliste setzen

Genau das ist der springende Punkt. Das sollte man eben nicht tun.

Ich fasse nochmal kurz die Idee von oben zusammen:
Es geht darum die Zeit der wiederholten Einlieferung einer realen Email (beim Erstkontakt) in die eigene Hand zu nehmen.
Dazu das Scenario mit zwei MX, damit die Email schon mal auf einem eigenen Server ist und man selber den Einfluß darauf hat.
Dazu darf der Secondary aber nicht auf einer Whitelist sitzen.

Und genau da kommt der Haken an der Sache, warum es tatsächlich nicht funktioniert, wenn ein Spammer direkt an den Secondary liefert: Die Wiederholung der Emails übernimmt dann der Secondary.


Daher stelle ich jetzt folgendes Scenario zur Diskussion:
Vorraussetzung:
- Root-Server mit zwei IP's; erste IP MX1; zweite IP MX2;
- Ein Mailserver mit Greylisting, der an beiden IP's lauscht.

Wenn das Blocken vom Greylisting auf nur eine Sekunde eingestellt wird, so würde eine reale Email beim Zustellversuch auf MX1 scheitern, kurz drauf aber beim MX2 durchkommen.
Spams mit nur einem Zustellversuch (egal auf welchem MX) scheitern.

huschi.

 

[amnesie]

Die Idee klingt ziemlich gut, allerdings ist 1 Sekunden als Timeout unbrauchbar. Du darfst in diesem Fall nicht auf Zeit gehen, sondern auf die Anzahl der Versuche: Den ersten immer greylisten, den zweiten immer annehmen. Ansonsten bremst du sehr schnelle Mailserver aus ;-)

 

[Montesuma]

Welchen Zeitrahmen würdest Du dann vorschlagen / einstellen?

 

[Huschi]

Es hängt von der Implementation des Greylistings ab.
Postgrey z.B. arbeitet glaube ich nicht mit Timeout's sondern nach "hat schon mal" oder "ist das erste Mal".
Mein Howto für Greylisting unter Plesk+Qmail arbeitet eben mit Timeouts im Minuten-Takt. Läßt sich aber leicht in Sekunden umschreiben.

huschi.

 

[Sinepp]

Frage mich bei der Diskussion nur, wie lange es wohl dauert, bist die Spammer die Greylisting Methode aushebeln, in dem sie mindestens zwei mal probieren eine Mail zuzustellen...

Hast Du da eine Meinung zu Huschi?

Danke,
Sinepp