Spamassassin before-queue statt post-queue gegen Backscatter?

[heutger]

Ich kenne Deine Headerchecks jetzt nicht, aber prinzipiell war der Ablauf vorher:
Internet -> Postfix mit allem aus /etc/postfix/main.cf (evtl. reject hier) -> Queue -> Port 10024 (evtl drop/qurantäne hier) -> Port 10025 -> Empfänger
Jetzt ist es
Internet -> Postfix mit allem aus /etc/postfix/main.cf -> Port 10024 -> Port 10025 -> Queue/Empfänger
Damit gibt es nur noch einmal einen Postfix der irgend etwas zurück weist, nicht mehr zweimal. Das führt eventuell zu anderen Bewertungen in der Statistik.
Die Headerchecks sollten eigentlich trotzdem greifen, die stehen bei Dir sicher in der main.cf, das Ergebnis siehst Du aber natürlich nicht mehr wenn der Postfix oder Spamassassin die Mail schon zurück weist.

Tschoe,
Adrian

Hi,

es geht um Mails, die reinlaufen/durchlaufen. Soweit ich das verstanden habe, deaktiviert die neue master.cf auch nicht die Header Checks, trotzdem werden sie nicht durchgeführt. U.a. steht in meiner main.cf

header_checks = regexp:/etc/postfix/header_checks

Und das steht in der /etc/postfix/header_checks:

/^From:/ INFO
/^To:/ INFO
/^Subject:/ INFO

Aber das wird eben nicht gemacht. Im Tracking Center und in den Statistiken mag das sowieso dann nicht mehr stimmen, aber auch in der mail.log über Shell sehe ich diese Informationen nicht mehr. :-( Es handelt sich um Mails, die durchgehen, keine abgewiesenen. Die SA-Details stehen auch nicht mehr im Log und auch nicht mehr im Tracking Center, aber das wäre zu verschmerzen, die Infos finde ich aber nicht so toll, wenn diese verschwinden.

Wenn eine Mail abgewiesen wird von SpamAssassin oder von Drop-Rules, wie sieht das dann eigentlich aus?

Grüße,
Christian

 

[Adrian Reyer]

es geht um Mails, die reinlaufen/durchlaufen. Soweit ich das verstanden habe, deaktiviert die neue master.cf auch nicht die Header Checks, trotzdem werden sie nicht durchgeführt. U.a. steht in meiner main.cf
header_checks = regexp:/etc/postfix/header_checks

Hab mir die master.cf angeschaut. header_checks passieren im 'cleanup', das wiederum kommt in dem Postfix der das in die Queue schreibt.Also der zweite auf Port 10025.
Dort steht in der master.cf:

127.0.0.1:10025 inet  n       -       n       -       -      smtpd
...
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
...

Das dürfte das sein.

Wenn eine Mail abgewiesen wird von SpamAssassin oder von Drop-Rules, wie sieht das dann eigentlich aus?

Wenn 'abgewiesen' 'reject' heisst, dann bekommt das der erste Postfix noch während dem SMTP-Dialog mit dem einliefernden MTA und leitet das an den entsprechend weiter. Die Mail kommt dann nie bis zu den Header Checks.

 

[DvM]

Also ohne Block im Regelwerk ist ja alles "sauber",also wenn man die Quarantäne nutzt und/oder dann eben die Mails tagged und später dann aussortiert o. Ä. ist das Setup durchaus zulässig.
Stimmt sehe ich genau so, und ist meiner Meinung auch der richtige Weg!

Möchte man aber eben blocken bzw. ab einem gewissen Spam Score rejecten, dann geht das nur mit meinen o.g. Anpassungen mit milter-reject.
Wir haben sehr gute Erfahrung in Kombination mit DNSBL und Reject Unknown Senders + Verify Receivers.

Ja, das ist ungefähr das Problem, ich habe ohne Änderungen nur die folgenden Optionen:

• Quarantäne, das ganze Zeug muss dann doch noch verarbeitet werden
  Die Tägliche SpamReport Mail ist innerhalb einer Minute erledigt, alles schön übersichtlich und nahezu 0 aufwand sich die Liste kurz anzusehen.
• DROP ohne den Sender zu benachrichtigen, wenn es doch valide Mail war bekommt der das nie mit und rechtlich ist das problematisch
  Ohne Block ist alles sauber (Anfang vom Post)
• DROP mit Benachrichtigung, bzw. REJECT post-queue: wenn es Spam war, produziere ich Backscatter Spam
  Ohne Block ist alles sauber (Anfang vom Post)

Verstehe daher leider nicht weshalb man unbedingt schon vorher blocken möchte / muss.
Before-queue content filter erzeugen zusätzlichen last am PMG, dies könnte u.U. bei schnellen Internetleitungen und Massives Aufkommen neuer Spammails in einer Art DDOS enden.

 

[Adrian Reyer]

Verstehe daher leider nicht weshalb man unbedingt schon vorher blocken möchte / muss.
Before-queue content filter erzeugen zusätzlichen last am PMG, dies könnte u.U. bei schnellen Internetleitungen und Massives Aufkommen neuer Spammails in einer Art DDOS enden.

Ja, das könnte sein. Bei entsprechend schlechter Konfiguration. Ich betreibe seit Jahren Antispam Gateways ohne Probleme. Der Hauptlastempfänger hat schon vor 6-7 Jahren 1.8 Millionen Spammails am Tag aussortiert. Before-Queue. Das ist derzeit ein Dual AMD Opteron(TM) Processor 6238, 32GB RAM und Hardware RAID-6. Würde ich nicht als optimales System für den Task bezeichnen, tut trotzdem. Und es gab tatsächlich mal einen echten DDOS auf das System, da haben wir damals auf 5000 gleichzeitige smtp eingehend erhöht. Normalerweise sind es 400 ohne Probleme, die Systeme machen nebenher noch ein paar andere Dinge.
Die Serverüberlast vermeidest Du am besten indem Du einfach das Setup an die Ressourcen anpasst, insbesondere die Anzahl gleichzeitiger smtp-Verbindungen eingehend. Und das dann durch bis zum Ende durch alle benutzten Dienste in der master.cf. Der Default ist 100 Verbindungen, wenn man vorne 200 zulässt müssen 100 warten. Und insgesamt so dimensionieren dass das System auf keinen Fall Swappen muss. Prinzipiell gilt das für Post Queue genau so, dadurch dass es asynchron ist merkt man aber nicht gleich dass das System eigentlich kaputt und überlastet ist. Schneller kommt die Mail trotzdem nicht an.

 

[heutger]

Wenn 'abgewiesen' 'reject' heisst, dann bekommt das der erste Postfix noch während dem SMTP-Dialog mit dem einliefernden MTA und leitet das an den entsprechend weiter. Die Mail kommt dann nie bis zu den Header Checks.

Thx, werde ich mal probieren. Nur blöd, dass bei einem Reject dann das nicht greift/möglich ist, dann kann ich da leider nicht mehr analysieren wie zuvor, das finde ich sehr schade.

 

[heutger]

Stimmt sehe ich genau so, und ist meiner Meinung auch der richtige Weg!

Finde ich nicht, was bringt mir ein Spam-Filter, der trotzdem Spam durchlässt. Markiert oder nicht, bin ich ja dann auch wiederum gesetzlich verpflichtet, regelmäßig den Spamordner oder eben die Quarantäne auf false-positives durchzuschauen, das vermeide ich, wenn ich die Mail bereits sauber abgewiesen habe, die sicher oder ziemlich sicher Spam sein sollte.

Wir haben sehr gute Erfahrung in Kombination mit DNSBL und Reject Unknown Senders + Verify Receivers.

Meine Quote ist da auch nicht schlecht, aber ich möchte es halt noch optimaler.

Verstehe daher leider nicht weshalb man unbedingt schon vorher blocken möchte / muss.
Before-queue content filter erzeugen zusätzlichen last am PMG, dies könnte u.U. bei schnellen Internetleitungen und Massives Aufkommen neuer Spammails in einer Art DDOS enden.

Es ist für mich ein echter Spamfilter, wo das durchaus auch möglich ist. Es kommt sicherlich auf das Mailaufkommen an, bei meinem privaten Test ist das vernachlässigbar, in der Firma aber eben weniger und hoch frequentierte Empfänger sieht es wieder ganz anders aus. Eins kann ich bspw. gerade auch schon wieder sehen und das ist mir schon aufgefallen, seit dem ich mein System rechtlich sauber blocken lasse: Wenn ein System offen ist oder desto offener es ist (offensichtlich, ob danach "getagged" oder "quarantiert" wird oder nicht, sieht der Absender ja nicht), desto mehr Spam kommt grundsätzlich rein (also wird versucht, mehr "Schund" abzuladen), sobald man recht aggressiv offensichtlich blockt, lassen die Spammer einen auch mehr in Ruhe. Die Mailquote an Schund hat sich seit dem ich jetzt teste (und in erster Phase eben ohne reject) mehr als verdoppelt. Wäre auch mal in Hinblick auf Last zu berücksichtigen.

 

[heutger]

Hab mir die master.cf angeschaut. header_checks passieren im 'cleanup', das wiederum kommt in dem Postfix der das in die Queue schreibt.Also der zweite auf Port 10025.
Dort steht in der master.cf:

127.0.0.1:10025 inet  n       -       n       -       -      smtpd
...
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
...

Das dürfte das sein.


Wenn 'abgewiesen' 'reject' heisst, dann bekommt das der erste Postfix noch während dem SMTP-Dialog mit dem einliefernden MTA und leitet das an den entsprechend weiter. Die Mail kommt dann nie bis zu den Header Checks.

Also die Header Checks funktionieren wie beschrieben bei "sauberen" Mails, leider ist das Tracking Center jetzt etwas eingeschränkt, man sieht bspw. den Spam Score nicht mehr.

Die Frage wäre, woran erkenne ich eine rejected mail nun? Wie lautet die reject-"Begründung" dann hierfür? Ich habe Block nun ab Score 10 aktiv, aber woher weiß ich, welche Mail da reingerutscht ist?

 

[heutger]

Hmm, also ich habe nun im Log entdeckt, dass ich nach "block mail" suchen kann und dann die betreffenden Mails finde. Trotzdem komme ich nicht weiter, weil wenn ich ehrlich bin sieht mir das hier nicht wirklich danach aus, als sei der Absender per reject informiert und die SMTP-Verbindung abgebrochen worden:

Mar 19 21:03:00 mg postfix/postscreen[25370]: CONNECT from [95.213.165.50]:47050 to [xxx]:25
Mar 19 21:03:06 mg postfix/postscreen[25370]: PASS NEW [95.213.165.50]:47050
Mar 19 21:03:07 mg postfix/smtpd[25391]: connect from mail.atimone.eu[95.213.165.50]
Mar 19 21:03:12 mg pmg-smtp-filter[15344]: 2019/03/19-21:03:12 CONNECT TCP Peer: "[127.0.0.1]:60564" Local: "[127.0.0.1]:10024"
Mar 19 21:03:12 mg postfix/cleanup[25397]: BF34640509: message-id=<20190319200312.BF34640509@xxx>
Mar 19 21:03:12 mg postfix/qmgr[4594]: BF34640509: from=<double-bounce@xxx>, size=231, nrcpt=1 (queue active)
Mar 19 21:03:12 mg postfix/smtpd[25391]: NOQUEUE: client=mail.atimone.eu[95.213.165.50]
Mar 19 21:03:12 mg postfix/smtp[25398]: Trusted TLS connection established to xxx[xxx]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 19 21:03:12 mg postfix/smtp[25398]: BF34640509: to=<xxx>, relay=mail.heutger.net[94.130.191.164]:25, delay=0.09, delays=0/0.03/0.03/0.03, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
Mar 19 21:03:12 mg postfix/qmgr[4594]: BF34640509: removed
Mar 19 21:03:12 mg pmg-smtp-filter[15344]: 412335C914B00C89E8: new mail message-id=<8ab201d4dea3$fa4ddf70$f731c854@yqcixdm>
Mar 19 21:03:19 mg pmg-smtp-filter[15344]: 412335C914B00C89E8: SA score=14/5 time=6.229 bayes=0.999999999831876 autolearn=no autolearn_force=no hits=BAYES_99,BAYES_999,DCC_CHECK,DIGEST_MULTIPLE,EMPTY_MESSAGE,FROM_EXCESS_BASE64,FSL_BULK_SIG,HTML_MESSAGE,KAM_HTMLNOISE,MIME_HTML_MOSTLY,PYZOR_CHECK,RELAYCOUNTRY_BAD,SPF_PASS
Mar 19 21:03:19 mg pmg-smtp-filter[15344]: 412335C914B00C89E8: block mail to <xxx>
Mar 19 21:03:19 mg pmg-smtp-filter[15344]: 412335C914B00C89E8: processing time: 6.272 seconds (6.229, 0.02)
Mar 19 21:03:19 mg postfix/smtpd[25391]: proxy-accept: END-OF-MESSAGE: 250 2.5.0 OK (412335C914B00C89E8); from=<yqcixdm@atimone.eu> to=<xxx> proto=ESMTP helo=<mail.atimone.eu>
Mar 19 21:03:19 mg postfix/smtpd[25391]: disconnect from mail.atimone.eu[95.213.165.50] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Mar 19 21:03:39 mg pmg-smtp-filter[15333]: starting database maintainance
Mar 19 21:03:39 mg pmg-smtp-filter[15333]: end database maintainance (22 ms)
Mar 19 21:06:39 mg postfix/anvil[25394]: statistics: max connection rate 1/60s for (smtpd:95.213.165.50) at Mar 19 21:03:07
Mar 19 21:06:39 mg postfix/anvil[25394]: statistics: max connection count 1 for (smtpd:95.213.165.50) at Mar 19 21:03:07
Mar 19 21:06:39 mg postfix/anvil[25394]: statistics: max cache size 1 at Mar 19 21:03:07

 

[Adrian Reyer]

Hmm, also ich habe nun im Log entdeckt, dass ich nach "block mail" suchen kann und dann die betreffenden Mails finde. Trotzdem komme ich nicht weiter, weil wenn ich ehrlich bin sieht mir das hier nicht wirklich danach aus, als sei der Absender per reject informiert und die SMTP-Verbindung abgebrochen worden:

Ich nehme an es geht um die Mail von mail.atimone.eu. Das Log sieht für mich nicht nach before-queue aus.
Eher nach 'filter'. Bei before-queue-Setups sieht man normalerweise ziemlich am Anfang im Log den Connect vom einliefernden Server und ziemlich am Ende den Disconnect. Dazwischen gibt es keine NOQUEUE o.ae. und wenn der Proxy einen 250 zurück gibt, dann hat die Mail bestanden und wird zugestellt. Das passiert hier. Aber der Proxy ist wohl so konfiguriert, dass er noch eine eigene Mail zurück schreibt. Oder es war schon ein double-bounce, so genau sehe ich das aus dem log nicht.
Tschoe,
Adrian

 

[heutger]

Ich nehme an es geht um die Mail von mail.atimone.eu. Das Log sieht für mich nicht nach before-queue aus.
Eher nach 'filter'. Bei before-queue-Setups sieht man normalerweise ziemlich am Anfang im Log den Connect vom einliefernden Server und ziemlich am Ende den Disconnect. Dazwischen gibt es keine NOQUEUE o.ae. und wenn der Proxy einen 250 zurück gibt, dann hat die Mail bestanden und wird zugestellt. Das passiert hier. Aber der Proxy ist wohl so konfiguriert, dass er noch eine eigene Mail zurück schreibt. Oder es war schon ein double-bounce, so genau sehe ich das aus dem log nicht.
Tschoe,
Adrian

Das Setup wurde so umgesetzt wie oben von Ihnen beschrieben. Ich weiß leider nicht, ob man da noch weiteres anpassen muss, damit ein Block bspw. im PMG bzw. im pmg-smtp-filter tatsächlich auch einen reject auslöst. Haben Sie denn das Setup wie von Ihnen beschrieben getestet und einen reject ausgeliefert bekommen, wenn Ihre Block-Rule gegriffen hat oder habe ich einen Schritt übersehen?

Im Log als erstes erfolgt ein Double-Bounce, das ist korrekt, der eigentliche Mailflow, der einen Reject liefern sollte hier an einem anderen Beispiel ohne Double-Bounce (habe ich übersehen):

Mar 20 23:36:10 mg postfix/postscreen[14356]: CONNECT from [62.141.32.162]:47548 to [195.201.120.145]:25
Mar 20 23:36:16 mg postfix/postscreen[14356]: PASS NEW [62.141.32.162]:47548
Mar 20 23:36:17 mg postfix/smtpd[14379]: connect from mail.alretion.art[62.141.32.162]
Mar 20 23:36:21 mg pmg-smtp-filter[7412]: 2019/03/20-23:36:21 CONNECT TCP Peer: "[127.0.0.1]:33308" Local: "[127.0.0.1]:10024"
Mar 20 23:36:21 mg postfix/smtpd[14379]: NOQUEUE: client=mail.alretion.art[62.141.32.162]
Mar 20 23:36:22 mg pmg-smtp-filter[7412]: 4050B5C92C065DC68D: new mail message-id=<iyqepzs77863281.28310536@mail.alretion.art>
Mar 20 23:36:31 mg pmg-smtp-filter[7412]: 4050B5C92C065DC68D: SA score=26/5 time=7.695 bayes=0.651207203640482 autolearn=spam autolearn_force=no hits=BAYES_60,DCC_CHECK,DIGEST_MULTIPLE,HTML_IMAGE_ONLY_12,HTML_IMAGE_RATIO_02,HTML_MESSAGE,HTML_SHORT_LINK_IMG_1,KAM_EU,KAM_GRABBAG2,MAILING_LIST_MULTI,PYZOR_CHECK,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_IVMSIP,RELAYCOUNTRY_BAD,RELAYCOUNTRY_GOOD,SCHAALIT_HEADER_3790,SPF_PASS,URIBL_ABUSE_SURBL,URIBL_BLACK,URIBL_IVMURI
Mar 20 23:36:31 mg pmg-smtp-filter[7412]: 4050B5C92C065DC68D: block mail to <xxx>
Mar 20 23:36:31 mg pmg-smtp-filter[7412]: 4050B5C92C065DC68D: processing time: 9.033 seconds (7.695, 0.472)
Mar 20 23:36:31 mg postfix/smtpd[14379]: proxy-accept: END-OF-MESSAGE: 250 2.5.0 OK (4050B5C92C065DC68D); from=<iyqepzs@alretion.art> to=<xxx> proto=ESMTP helo=<mail.alretion.art>
Mar 20 23:36:31 mg postfix/smtpd[14379]: disconnect from mail.alretion.art[62.141.32.162] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

Kann es sein, dass pmg-smtp-filter dann gar keine geeignete Antwort liefert, damit rejected werden kann?

 

[Falconbase]

Hi,

konntet ihr da schon eine Lösung finden, ich würde dieses Setup mit dem smtpd_proxy_filter auch bevorzugen?

 

[heutger]

Hi,

konntet ihr da schon eine Lösung finden, ich würde dieses Setup mit dem smtpd_proxy_filter auch bevorzugen?

Leider gab es kein weiteres Feedback, die Vermutung legt aber nahe (und auch der in der Zeit wieder aufsteigende Mailcount), dass es zu keinem Reject kam sondern die Mail intern zwar geblockt wurde, der Absender aber davon nichts mitbekam.

Wenn @dietmar @martin in neuen PMG releases nicht eine offizielle Unterstützung dieses Setups durch geeignete Reaktion des PMG-SMTP-Filter vorsehen (was zu begrüßen wäre, vermutlich den geringsten Aufwand vs. einer Reimplementierung als Milter-Setup oder Amavis-Erweiterung darstellen dürfte und insbesondere flagartig (also über ein Setting in der Konsole und ein paar Zeilen Code) sogar wahlweise freistellen könnte, ob man pre oder post nutzen möchte (default ja gerne auf post und die Bedenken für pre in Doku und im Zweifel GUI mit roter Warnung in fett, bevor aktiviert werden kann)), wäre es auf jeden Fall die eleganteste Lösung.

Aktuell bleibt nur meine Lösung, die super funktioniert, neben mir haben einige andere diese auch implementiert. Sie zieht leider etwas mehr Last und ist auch im Logging nicht wirklich integriert, aber sie hilft massiv und führt auch dazu, dass einige Spammer fern bleiben.

 

[Falconbase]

Schade eigentlich, weil das Produkt an sich ist super. Muss mal deinen Thread durchlesen.

 

[heutger]

Schade eigentlich, weil das Produkt an sich ist super. Muss mal deinen Thread durchlesen.

Ja, finde ich auch.

 

[tom]

Schade eigentlich, weil das Produkt an sich ist super. Muss mal deinen Thread durchlesen.

Kein Grund zur Traurigkeit, nur weil nicht alle 100 neue Ideen innerhalb von ein paar Wochen drin sind. Das Proxmox Mail Gateway wird ständig weiterentwickelt, nächster Riesenschritt wird das upgrade auf Debian Buster, mit unzähligen neuen Packetversionen - hier steckt sehr viel Test- und Detailarbeit drin.