Spamassassin before-queue statt post-queue gegen Backscatter?

[Adrian Reyer]

Hi,

ich habe mir hier mal testweise einen PMG aufgesetzt. Bisher habe ich meine Antispam- und Antivirenlösungen immer selbst implementiert. Die verwendeten Komponenten sind im Wesentlichen dieselben, aber das Webfrontend vom PMG ist schon sehr nett.
Was ich aber nicht verstehe, ist warum die Filter post-queue eingebunden sind (/etc/postfix/master.cf: content_filter). Das heißt, wir nehmen die Mail an, prüfen sie und wenn die die Kriterien für gute Mails nicht erfüllt, d.h. ein 'Block' bei den Regeln ist das Ergebnis, dann wird eine Fehlermail an den Urheber zurück geschickt.
Das gefällt mir nicht, weil der PMG dadurch Backscatter Spam produziert.
Sehr gut ist das auch unter Administration/Warteschlangen zu sehen. Da steht ein Haufen Blödsinn in der Queue.
Quarantäne stattdessen macht mir entweder eine Menge Arbeit oder verstößt mit automatischer Löschung wie auch ein kommentarloses Verwerfen der Mail nach meinem Verständnis sowohl gegen die DSGVO als auch diverse andere Gesetze.
Bei meinen selbst installierten Systemen nehme ich statt content_filter smtpd_proxy_filter.
Ich habe nun einfach mal in /etc/postfix/master.cf

smtpd       pass  - -       -       -       100      smtpd
  -o content_filter=scan:127.0.0.1:10024
  -o receive_override_options=no_address_mappings
  -o smtpd_discard_ehlo_keywords=silent-discard,dsn
  -o mynetworks=127.0.0.0/8,10.0.3.2

durch

smtpd       pass  - -       -       -       100      smtpd
  -o smtpd_proxy_filter=127.0.0.1:10024 -o smtpd_proxy_timeout=600
  -o receive_override_options=no_address_mappings
  -o smtpd_discard_ehlo_keywords=silent-discard,dsn
  -o mynetworks=127.0.0.0/8,10.0.3.2

ersetzt und postfix neu gestartet.
Mails kommen an oder werden abgewiesen wie das auch sein soll.
Quarantäne sollte immer noch funktionieren (nutze ich nicht).
Nach einem Restart ist die Änderung wieder rückgängig gemacht, deshalb habe ich sie analog in /var/lib/pmg/templates/master.cf.in hinterlegt.
Das funktioniert.

Das führt zu zwei Fragen:
Wird diese Datei bei PMG-Updates überschrieben? Ich fürchte ja.
Warum wird content_filter statt smtpd_proxy_filter überhaupt (noch) an dieser Stelle verwendet?

Grüße
Adrian

 

[Stoiko Ivanov]

Hallo,

Bezüglich der stabilen aenderung der postfix (und anderer) Templates - das steht im pmg-admin-guide recht gut beschrieben (Kapitel 4.3):
https://www.proxmox.com/images/download/pmg/docs/pmg-admin-guide.pdf

Hoffe das hilft mal weiter

 

[Adrian Reyer]

Hallo,

Hallo,
Bezüglich der stabilen aenderung der postfix (und anderer) Templates - das steht im pmg-admin-guide recht gut beschrieben (Kapitel 4.3):
https://www.proxmox.com/images/download/pmg/docs/pmg-admin-guide.pdf
Hoffe das hilft mal weiter

Ja, hilft weiter, den Teil habe ich übersehen. Die andere Frage ist aber eigentlich die für mich wichtigere:
Warum wird überhaupt post-queue Spam behandelt per Default? Früher ging das mit Postfix nicht anders, aber das ist vorbei.
DROP ist rechtlich in Europa angreifbar, post-queue REJECT führt zu Backscatter Bounces, Quarantäne ergibt riesige Halden die zu kontrollieren sind, wenn das nicht nur für strittige Mails, z.B. Spamassassin-Level 2-5 oder so) genutzt wird.
Da scheint mir ein before-queue REJECT ab z.B. Spamassassin 5 Punkte und Quarantäne für 4-5 Punkte (oder was auch immer) besser handhabbar zu sein.

Grüße,
Adrian

 

[heutger]

DROP ist rechtlich in Europa angreifbar, post-queue REJECT führt zu Backscatter Bounces, Quarantäne ergibt riesige Halden die zu kontrollieren sind, wenn das nicht nur für strittige Mails, z.B. Spamassassin-Level 2-5 oder so) genutzt wird.
Da scheint mir ein before-queue REJECT ab z.B. Spamassassin 5 Punkte und Quarantäne für 4-5 Punkte (oder was auch immer) besser handhabbar zu sein.

Das habe ich Proxmox schon mehrfach erklärt, aber man ignoriert dies bzw. bezweifelt diese Aussage (DROP angreifbar, es gibt klare rechtliche Aussagen sogar, dass DROP in DE sogar schlichtweg illegal ist). In meinem Advancing PMG Thread habe ich beschrieben, wie man PMG mit einem spamass-milter versieht, leider wird dadurch doppelt gescannt, aber nur so kann man pre-queue realisieren. Bisher gibt es leider weder jemanden, der den PMG-SMTP-Filter entsprechend umprogrammieren wollte und auch Proxmox scheint bisher keine Ambitionen diesbezüglich zu haben. Daher gibt es bisher nur diesen Workaround. Funktioniert aber bei mir prima. Noch toller wäre natürlich auch eine Umsetzung seitens PMG wie es rspamd macht (fand ich eine richtig geniale Idee): Mails ins Greylisting ebenso ab einem gewissen Score laufen zu lassen (sozusagen auf dem Niveau "weiß nicht, könnte Spam sein", statt rejecten, Quarantäne oder taggen). Hat den Vorteil, dass wenn die Mail wieder kommt womöglich auf irgendwelchen Blacklists bereits bekannt ist, ja, das ist ein Spammer und er dann sauber rejected werden kann.

 

[tom]

ein 'Block' bei den Regeln ist das Ergebnis, dann wird eine Fehlermail an den Urheber zurück geschickt.

Proxmox schickt bei "Block" Regeln nichts an den Sender zurück, ausser im Regelsystem wird das explizit konfiguriert.

 

[Adrian Reyer]

Proxmox schickt bei "Block" Regeln nichts an den Sender zurück, ausser im Regelsystem wird das explizit konfiguriert.

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
• DROP ohne den Sender zu benachrichtigen, wenn es doch valide Mail war bekommt der das nie mit und rechtlich ist das problematisch
• DROP mit Benachrichtigung, bzw. REJECT post-queue: wenn es Spam war, produziere ich Backscatter Spam

Das ist mit der Rechtslage in Deutschland nicht nicht zu vereinbaren, deshalb hätte ich gerne den before-queue Reject. Da wird die Mail nicht angenommen und der einliefernde MTA muss das behandeln. Wenn es ein Spam-MTA ist hat der Admin dort das Problem, kann sein System ja in Ordnung bringen, wenn es eine valide Mail war, bekommt der Sender eine anständige Fehlermeldung.

MfG,
Adrian Reyer

 

[heutger]

Das ist mit der Rechtslage in Deutschland nicht nicht zu vereinbaren, deshalb hätte ich gerne den before-queue Reject.

Genau das sieht leider Proxmox nicht, damit ist die Lösung an sich in Deutschland nicht rechtssicher verwendbar, wenn man rejecten möchte. Daher habe ich auch den Workaround gebaut, den man meinem Advancing PMG-Thread entnehmen kann, die zusätzliche Last ist durch vorkompilieren der Regeln zu vernachlässigen, denn das nimmt Last und Durchlaufzeit raus, die durch den zusätzlichen Scan wieder dazu kommt, also unterm Strich kein Verlust.

 

[tom]

Genau das sieht leider Proxmox nicht,

Na ja, keine Panik verbreiten. Wenn wir alle deine Vorschläge sofort umsetzen würden, hätte wir das Mail Gateway in den letzten Monaten schon mehrmals mal komplett neu programmiert...

Wir ignorieren keine Request aus der Community und alle diese Requests werden hier im Detail diskutiert. Aber solche Umstellung haben auch Einfluss auf die Performance der Mail Verarbeitung und daher ist hier mit Vorsicht vorzugehen. (siehe als Beispiel http://www.postfix.org/SMTPD_PROXY_README.html)

Bei passender Konfiguration sehe ich derzeit nicht wirklich große rechtlichen Probleme.

 

[heutger]

Na ja, keine Panik verbreiten. Wenn wir alle deine Vorschläge sofort umsetzen würden, hätte wir das Mail Gateway in den letzten Monaten schon mehrmals mal komplett neu programmiert...

Wir ignorieren keine Request aus der Community und alle diese Requests werden hier im Detail diskutiert. Aber solche Umstellung haben auch Einfluss auf die Performance der Mail Verarbeitung und daher ist hier mit Vorsicht vorzugehen. (siehe als Beispiel http://www.postfix.org/SMTPD_PROXY_README.html)

Bei passender Konfiguration sehe ich derzeit nicht wirklich große rechtlichen Probleme.

So viele Vorschläge hatte ich ja nun auch wieder nicht. ;-)

Grundsätzlich ist die Software ja gut, es sind nur einige Tweaks sinnvoll und die fehlende Mobile-Unterstützung sehr schade.

Und die Erweiterung zum Mailserver mit Mailarchiv würde die Lösung zu einer eierlegenden Wollmilchsau machen. ;-)

Das Post-Queue-Filtering ist halt sehr „old style“. Ist eine Milter-Integration hier ggf. performanter? Oder wäre eine Amavis-Implementation es? Der Link scheint ja ein weiterer Weg, dieser wirkt wir ein „Workaround“, Post-Queues auf Pre-Queue zu bekommen. Wäre das wie beschrieben einfach so möglich? Kann man den Content Filter tatsächlich so umstellen? Er arbeitet ja wie ein SMTP-Server. Die Cons sind klar, aber bei heutigen Performancemöglichkeiten bzw. den damit verbundenen Kosten sowie der Clustermöglichkeit von PMG sollte das doch keine Probleme mehr darstellen?

Ja, natürlich ist PMG nicht grundsätzlich rechtlich unsicher, aber möchte man halt bestimmtes rejecten und eben wirklich rejecten, bleibt nur die manuelle Anpassung oder das illegale Drop, möchte man nicht zum Backscatterer werden.

 

[Adrian Reyer]

Wir ignorieren keine Request aus der Community und alle diese Requests werden hier im Detail diskutiert. Aber solche Umstellung haben auch Einfluss auf die Performance der Mail Verarbeitung und daher ist hier mit Vorsicht vorzugehen. (siehe als Beispiel http://www.postfix.org/SMTPD_PROXY_README.html)

Mir sind die Implikationen bewusst. Ich baue seit Jahren selbst Anti-Spam und Anti-Viren Mailgateways auf Basis von postfix/amavisd-new/spamassassin für Kunden auf. Eines davon mit täglich mehreren 100k guten Mails und (leider) Millionen von Spammails. Mit einer an die Hardwareleistung angepasste Postfixkonifguration, hauptsächlich die Anzahl gleichzeitiger eingehende Verbindungen, per Default 100, lassen sich die im obigen Link unter 'con' genannten Probleme reduzieren. Ich habe da derzeit Setups zwischen 5 und 3500 Verbindungen am Laufen. Wobei alles unter 100 eher überholt ist, so langsame Hardware mit so wenig RAM gibt es nicht mehr in meiner Welt.
Ich schaue mir das PMG an weil meine Lösung keine GUI hat und mindestens ein Kunde tatsächlich eine Quarantänefunktion für gewisse Mails benötigt. Die GUI ist nett, die Funktionialität gefühlt die, die ich benötige.
Deshalb hab ich hier PMG mal zum Testen aufgesetzt vor einer Domain die Mailinglisten für einen Verein behandelt.
Das von mir bemängelte Verhalten der Standardkonfiguration ist für mich ein Showstopper. Ich muss um auf der sicheren Seite zu sein und die gewohnte Qualität zu liefern meinen Kunden ein PMG verkaufen und das dann umkonfigurieren, weit unterhalb der GUI. Und potentiell spiele ich das Spiel mit jedem Update von vorne, will ich nicht neue Standardfunktionalität verpassen.

Bei passender Konfiguration sehe ich derzeit nicht wirklich große rechtlichen Probleme.

Ich leider schon und ich würde das ungerne erst richterlich klären lassen wenn es vorher schon Möglichkeiten gibt das zu umgehen. Es gibt zumindest für Deutschland schon Urteile die post-queue Filterung mit DROP eine Absage erteilen.
Da hab ich eine gewisse Angst davor, die lässt sich auch nicht mit einer anderen Sichtweise reduzieren.
Sehr wohl lässt sich die aber beheben mit einer Aussage wie 'post-queue ist nur historisch bedingt, in der nächsten Version wechseln wir auf before-queue'. Da wäre ich glücklich und könnte meinen Kunden eine Perspektive bieten.
Nicht dass das Proxmox Millionen an Kunden von mir bringen wird, wir sind ein kleines Unternehmen, aber unseren eigenen HA-Virtualisierungscluster haben wir im wesentlichen schon zu Gunsten von PVE aufgegeben und das hat Proxmox ein paar zufriedene un zahlende Kunden gebracht, Tendenz steigend. Den Weg gehe ich gerne auch mit PMG.

Tschoe,
Adrian

 

[heutger]

Ich muss um auf der sicheren Seite zu sein und die gewohnte Qualität zu liefern meinen Kunden ein PMG verkaufen und das dann umkonfigurieren, weit unterhalb der GUI. Und potentiell spiele ich das Spiel mit jedem Update von vorne, will ich nicht neue Standardfunktionalität verpassen.

Also wie gesagt, das Setup in meinem Advancing-Thread mit milter-reject ist sicher, performant und auch updatesicher. Ja, man muss dann schon hin und wieder mal die Templates gegen die angepassten checken, aber bisher hat nur ClamAV mit den angepassten Signaturen "geknallt", davon würde ich zu Gunsten Avast inzwischen Abstand nehmen.

Ich leider schon und ich würde das ungerne erst richterlich klären lassen wenn es vorher schon Möglichkeiten gibt das zu umgehen. Es gibt zumindest für Deutschland schon Urteile die post-queue Filterung mit DROP eine Absage erteilen.
Da hab ich eine gewisse Angst davor, die lässt sich auch nicht mit einer anderen Sichtweise reduzieren.
Sehr wohl lässt sich die aber beheben mit einer Aussage wie 'post-queue ist nur historisch bedingt, in der nächsten Version wechseln wir auf before-queue'. Da wäre ich glücklich und könnte meinen Kunden eine Perspektive bieten.
Nicht dass das Proxmox Millionen an Kunden von mir bringen wird, wir sind ein kleines Unternehmen, aber unseren eigenen HA-Virtualisierungscluster haben wir im wesentlichen schon zu Gunsten von PVE aufgegeben und das hat Proxmox ein paar zufriedene un zahlende Kunden gebracht, Tendenz steigend. Den Weg gehe ich gerne auch mit PMG.

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. 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. Milter-reject taucht leider dann auch nicht im Tracking Center auf, ich habe ein angepasstes pmg-tracker, der das dann doch wieder anzeigt, aber noch nicht alles 100%ig schön (man sieht wirklich nur den Reject und nicht die Zeilen davor und danach bisher). Vielleicht kann da ja wer helfen. Ansonsten fand ich den Tipp von @tom interessant, womöglich lässt sich mit dem besprochenen Link sogar direkt der PMG-SMTP-Filter auf Pre-Queue umstellen, hier hoffe ich/warte ich noch auf Feedback.

Durchaus würde mich die Aussage auch freuen, da es ein wichtiges Element ist. Hätte noch so einige Ideen, die aber sicher aufwändiger sind.

 

[tom]

Es gibt zumindest für Deutschland schon Urteile die post-queue Filterung mit DROP eine Absage erteilen

Gibt es detaillierte Infos zu diesen Urteilen?

 

[heutger]

Gibt es detaillierte Infos zu diesen Urteilen?

Ich hatte hier schon auf https://www.heinlein-support.de/sites/default/files/Rechtsfragen_fuer_Administratoren.pdf verwiesen und den klaren Wortlaut des §303a StGB, der auch das Unterdrücken von Daten unter Strafe stellt. Ein silent drop erfüllt zu 100% den Tatbestand des Unterdrückens.

 

[tom]

Danke, aber die konkrete Frage war, ob es Informationen zur Urteilen gibt.

 

[heutger]

Danke, aber die konkrete Frage war, ob es Informationen zur Urteilen gibt.

Mir ist dergleichen nicht bekannt, womöglich kann Heinlein hier helfen oder der Thread Owner.

 

[Adrian Reyer]

Gibt es detaillierte Infos zu diesen Urteilen?

Tut mir leid, die habe ich nicht parat. Ein mir noch in Erinnerung befindlicher Fall war, dass Mail von einer Exmitarbeiterin an deren Exkollegen vom Mailsystem automatisch ohne Meldung gelöscht wurde.
In https://www.oreilly.de/german/freebooks/spamvirger/pdf/313-318.pdf wir auf ein Urteil des Oberlandesgerichts Karsruhe vom 10.01.2005 Bezug genommen. Das ist möglicherweise dieses. Auf das wird ebenfalls von https://wiki.gsi.de/foswiki/pub/Personalpages/MmuItSicherheit/download.pdf verwiesen.
Da wir zumindest in Deutschland kein Case-Law haben, reicht es mir auch von einem entsprechenden gesetz gehört zu haben das mir Ärger machen kann, die Referenz bei Heinlein war schon da, https://www.heise.de/ct/artikel/Strafbares-Filtern-289128.html ist eine andere.
Die Empfänger um Erlaubnis zu fragen ist mir nicht möglich.
Auf gut Glück mal 5 Jahre Gefängnis möchte ich dann doch nicht riskieren. Ich bin kein Anwalt, ich muss mich an bestehende Gesetze halten so wie ich sie verstehe. Es kann dann immer noch passieren dass jemand das anders sieht. Ich bilde mir vor Gericht dann gute Chancen ein. Wenn mein Handeln aber schon nicht mit meinem eigenen Verständnis vereinbar ist, wohl eher nicht.

 

[Adrian Reyer]

Ansonsten fand ich den Tipp von @tom interessant, womöglich lässt sich mit dem besprochenen Link sogar direkt der PMG-SMTP-Filter auf Pre-Queue umstellen, hier hoffe ich/warte ich noch auf Feedback.
Durchaus würde mich die Aussage auch freuen, da es ein wichtiges Element ist. Hätte noch so einige Ideen, die aber sicher aufwändiger sind.

Das ist das was ich gemacht habe und der Ursprung des Threads. Ich sehe immer noch Statistiken mit sinnvollem Inhalt, weiss aber nicht ob da nicht doch was hinten schief geht, z.B. ob für die die das benötigen die Quarantänefunktionalität noch tut.

 

[heutger]

Das ist das was ich gemacht habe und der Ursprung des Threads. Ich sehe immer noch Statistiken mit sinnvollem Inhalt, weiss aber nicht ob da nicht doch was hinten schief geht, z.B. ob für die die das benötigen die Quarantänefunktionalität noch tut.

Achso, okay, cool, das habe ich überlesen. Wäre natürlich toll, wenn @tom noch mal kurz bestätigen könnte, dass unter Berücksichtigung der möglichen Probleme aus der von ihm verlinkten Dokumentation das Setup funktionieren würde. Dann würde ich auch darauf umstellen und den milter-reject wieder rauswerfen, das ist ja deutlich besser.

Ein kurzes Tutorial, was man tun muss, wäre toll, auch wenn Erfahrungswerte existieren für die Anzahl Sessions, die man einstellen sollte. Ich würde das dann, wenn gestattet, in meinen Advancing PMG-Thread einarbeiten und natürlich auf das Tutorial verlinken.

 

[heutger]

Das ist das was ich gemacht habe und der Ursprung des Threads. Ich sehe immer noch Statistiken mit sinnvollem Inhalt, weiss aber nicht ob da nicht doch was hinten schief geht, z.B. ob für die die das benötigen die Quarantänefunktionalität noch tut.

Also ich habe nun einfach mal nur das von ganz oben gemacht: Meinen Miltercheck auskommentiert und die Originalzeile mit dem Post-Scan ebenfalls und dafür die Zeile mit dem smtpd-Proxy reingenommen. Soweit so gut, die Frage, die sich für mich gerade aber schon mal stellt: Meine Header-Checks scheinen nicht mehr zu greifen. Ich bekomme keine Infozeilen mehr angezeigt für den tatsächlichen Absender, Empfänger und insbesondere nicht für das Betreff. Eine Idee, wie man das auch mit smtpd-Proxy kompatibel bekommt? Ansonsten werde ich jetzt mal abwarten, wie da nun auf die Mails reagiert wird und werde anschließend mal eine Block-Regel ab einem gewissen Spam-Score einfügen. Diese sollte ja dann ein reject statt einem silent drop ausführen, korrekt?

 

[Adrian Reyer]

Also ich habe nun einfach mal nur das von ganz oben gemacht: Meinen Miltercheck auskommentiert und die Originalzeile mit dem Post-Scan ebenfalls und dafür die Zeile mit dem smtpd-Proxy reingenommen. Soweit so gut, die Frage, die sich für mich gerade aber schon mal stellt: Meine Header-Checks scheinen nicht mehr zu greifen. Ich bekomme keine Infozeilen mehr angezeigt für den tatsächlichen Absender, Empfänger und insbesondere nicht für das Betreff. Eine Idee, wie man das auch mit smtpd-Proxy kompatibel bekommt? Ansonsten werde ich jetzt mal abwarten, wie da nun auf die Mails reagiert wird und werde anschließend mal eine Block-Regel ab einem gewissen Spam-Score einfügen. Diese sollte ja dann ein reject statt einem silent drop ausführen, korrekt?

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