Heutiger Anspruch: MX-Server mit zuverlässigem und rechtssichierem Spam- und Virenfilter
Es gibt zu diesem Thema etliche Bücher, gefühlte 100.000 Howtos und annähernd eine Million Fragen bei Google dazu.
Was ich jedoch im Kern vermisse ist eine aktuelle Bestandsaufnahme, was denn sinnvoll ist um Ressourcen zu schonen, es den Spammern so schwer wie möglich zu machen und alle rechtlichen Anforderungen zu erfüllen.
Herausgekommen ist ein interner 2-Tage Workshop bei uns (cubewerk) um das Thema zu durchleuchten. Hier die Fakten:
Wer Mails einmal annimmt, muss sie zustellen
Der Benutzer möchte im Idealfall ein spam- und virenfreies Postfach
Der Admin möchte seine Serverlast schonen und ein Setup so einfach wie möglich
Teure Checks (CPU-Leistung) sind Inhaltsfilterkontrollen wie Spam- oder Virenprüfungen – diese sollen vermieden werden oder nur als letzte Option zum Einsatz kommen.
Als Basis dient uns Postfix mit postscreen. Postscreen ist eine Postfix-Erweiterung um es den Spammern besonders schwer zu machen. Konkret werden Missachtungen des SMTP-Protokolls bestraft und einlieferende Absender können sich eine positive Reputation aufbauen. Zusätzlich kommen Tricks zum Einsatz, welche z.B. spontan die Verbindung trennen, Einlieferer ausbremsen oder falsche Infos streuen, damit der Sender kurzzeitig verwirrt ist. Ein echter Absender versucht es einfach erneut. Der Spammer verliert hier längst die Geduld. Hierdurch lässt sich die Masse der Spam-Mails aus Botnetzen ausbremsen.
Da es viele Methoden gibt um eine E-Mail auf Ham oder Spam abzuklopfen, ist die richtige Reihenfolge entscheidend. Auch hier um eigene Rechenleistung zu schonen. Hier unser empfohlenes Setup: (Reihenfolge von oben nach unten). Jeder Check der scheitert, führt zur Terminierung der SMTP-Verbindung.
Postscreen mit genannten Checks / Tests
Prüfen der Absender-IPs gegen gängige Blacklists (spamhaus, zen usw.)
Prüfung ob Absender im MAIL FROM FQDN verwendet – kein <a> erlaubt sondern nur <a@b.de>
Prüfen ob Empfänger im RCPT TO gültigen FQDN darstellt – kein <stefan> erlaubt sondern nur <stefan@machine.tld>
Prüfen ob Absender im MAIL FROM eine Domain verwendet, die gültige DNS-Einträge besetzt (A,MX)
Prüfen ob Empfänger im RCPT TO gültige Domain verwendet, die gültige DNS-Einträge besitzt (A,MX)
Bis zu diesem Zeitpunkt hat der Absender noch keine Gelegenheit, überhaupt den Body also Mailinhalt zu übermitteln – konnte aber bereits aus vielerlei Gründen abgelehnt worden sein.
Jetzt erfolgt eine Prüfung, ob der Empfänger selbst, überhaupt lokal bzw. auf nachgelagerten Systemen existiert.
Hat es der Absender bis hier geschafft, kann darf er jetzt mit DATA den Body/Inhalt der E-Mail übermitteln. Keine Annahme – nur Übermittlung!
ACHTUNG: Auch bis hier hin, wurde die E-Mail nicht angenommen. Die Verbindung zwischen Sender->Empfänger besteht, die Mail wurde aber noch nicht angenommen.
Jetzt erfolgt eine interne Übergabe der Mail über das Milter-Protokoll an Amavis (amavis-milter).
Hier wird geprüft, ob die E-Mail selbst, nach üblichen Kriterien nach Spam aussieht oder ob ein Anhang virenversucht ist. Zur Erinnerung – der Absender wartet immer noch.
Kommt es hierbei zu Auffälligkeiten, wird die Verbindung erneut einfach terminiert und die E-Mail abgelehnt.
Final – wenn alle Schritte erfolgreich sind, wird dem Absender die Annahme mit einem 250-Statuscode quittiert und die E-Mail zugestellt.
Nachtrag: Milter / Proxies
Es wurde bewusst darauf verzichtet, in Postfix smtpd_proxy_filter zu verwenden. Dies vereinfacht das Setup nicht.
Postfix selbst kann über den amavis-milter einfach ein nachgelagertes Programm aufrufen, bekommt eine Info über den erfolgreichen Check und wertet diesen aus. SPAM/VIREN oder OK.
In setups mit smtpd_proxy_filter muss der nachgelagerte Proxy, die geprüften E-Mails weiterleiten oder zustellen. Dies ist nicht gewollt.
Quellen:
http://www.postfix.org/postconf.5.html#smtpd_milters
https://blog.sys4.de/amavisd-milter-howto-de.html
http://www.postfix.org/POSTSCREEN_README.html
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Antispam/Antispam-Strategien.pdf