(Anmerkung: Ich schreibe diesen Artikel gerade zum zweiten Mal - habe also auf die harte Tour herausgefunden, daß das Autosave-Plugin meines S9Y nicht mit dem Plugin für erweiterte Eigenschaften von Einträgen harmoniert. Toller Roller! Was ich damit sagen will: Seid mir nicht böse, wenn einige Formulierungen etwas kurz ausfallen.)

Ich hatte es lange vor mir hergeschoben, aber in den letzten Tagen habe ich dann doch mal mein Mailsystem von ein paar alten Krücken befreit und den Mailfluss logischer gestaltet. Im Einzelnen hatte das alte Setup folgende Probleme:

1. Mails, die von Mailman erzeugt wurden, sind an amavisd-new vorbei gegangen. Im Prinzip müssen die zwar auch nicht gescannt werden, aber da sie dann natürlich auch nicht im SQL-Logging landen, kann man den Bounce-Killer nicht einschalten.
2. Von Sender-Verifikationstechniken wie DKIM, DomainKeys und SPF mag man halten, was man will, aber ohne tut man sich schwer, Mails bei einigen großen Freemail-Providern abzuladen. Für die Signierung mit DKIM und DomainKeys habe ich die sendmail-Milter benutzt - hier wollte ich DomainKeys rauswerfen und den DKIM-Part dann an amavisd-new deligieren.
3. Da ich amavisd-new in einem before-queue-Setup betreibe und unerwünschte Inhalte direkt im SMTP-Dialog ablehnen lasse, aber auch einen Secondary MX mein Eigen nenne, hatte ich für Mails, die der Secondary einliefert, ein etwas krudes Setup, mit eigener Transportweg-Definition auf dem Secondary und zweitem smtpd auf dem Primary - auch das war mir zu kompliziert.

Die Filterung auf schädliche bzw. unerwünsche Inhalte in Postfix bedeutet eigentlich immer, daß die Mail zweimal mit Postfix in Berührung kommt. Wenn man nun den Server auch noch zum Versand von Nachrichten und als Mailinglsiten-Server einsetzt, evt. lokal eine Webmail-Oberfläche installiert hat und wie oben erwähnt einen Secondary MX betreibt, dann muß man sich über ein paar Punkte ernsthafte Gedanken machen:

1. Header- und Body-Checks: In einem before-queue-Setup kommen die Header- und Body-Checks sowieso nicht zum Tragen, wenn man nun also die Anzahl der zusätzlichen smtpd-Einträge in der master.cf begrenzen will, dann sollte man sich Gedanken darüber machen, daß man auch die Wege durch amavisd-new, in denen after-queue-Filtering definiert ist, möglichst konsistent gestaltet (Parameter receive_override_options, Wert no_header_body_checks). Erschwerden kommt ein kleiner Bug in neuen amavisd-new-Versionen hinzu.
2. Es ist nicht immer sinnvoll oder möglich, before-queue-Filterung zu betreiben. Typische Beispiele sind das lokale Einliefern von Mails z.B. via pickup(8) oder die Mails, die eine Mailingliste generiert.
3. Ein Ablehnen von Mails sollte man tunlichst unterlassen, wenn man dabei Backscatter erzeugen könnte.
4. Das Umschreiben von Adressen, z.B. via virtual_alias_maps, sollte man tunlichst immer nur einmal durchführen. Am besten ist es natürlich, wenn amavisd-new keine umgeschriebenen Empfänger zu sehen bekommt, nur so kann man z.B. für die postmaster@ eigene Regeln definieren (Parameter receive_override_options, Wert no_address_mappings).
5. Die Verifikation von Empfängeradressen sollte man ebenfalls nicht zweimal durchführen - und bei Mailinglisten-Programmen kann es z.B. sinnvoll sein, ganz darauf zu verzichten (Parameter receive_override_options, Wert no_unkown_recipient_checks).

Zusätzlich sollte man sich überlegen, ob die verarbeiteten Mails von einem selbst (lokal, durch Benutzer, die sich authentifizieren etc.) erzeugt werden oder nicht - im ersten Fall könnte man dann zustäzlich noch Benachrichtigungen konfigurieren, falls einer der eigenen Benutzer oder eine Workstation im eigenen Netz (das war jetzt der Hinweis, daß man @mynetworks korrekt konfigurieren, also z.B. auch den Secondary MX aufnehmen sollte!) oder gar der eigene Server plötzlich Spam oder Viren verschicken sollte.

Nachdem ich fast zehn Minuten lang mit Stift und Papier (kein Witz!) beschäftigt war, habe ich für mich die folgenden fünf Wege durch mein System gefunden:

1. Mail von irgendwelchen Dritten an Empfänger auf dem System: Hier deaktiviert man Body- und Header-Checks sowie Adressumschreibungen, überprüft die Mail, bevor sie in die Postfix-Queue gelangt, lehnt Spam- und Viren direkt ab, deaktiviert DKIM-Signing in amavisd-new und lässt auf dem smtpd, den man im zweiten Durchgang benutzt, die Prüfung von Empfängeradressen unter den Tisch fallen.
2. Falls die Mail aus einem der eigenen Netze kommt, dann verfährt man wie in Punkt 1., lässt unerwünschte Inhalte jedoch passieren und aktiviert die DKIM-Signierung. Für die Reinjection kann man getrost den smtpd aus Punkt 1 wiederverwenden.
3. Mail von Benutzern, die sich authentifizieren: Hierzu verwendet man die beiden dedizierten Ports 465 und 587, aktiviert das Signieren von Mails, lehnt unerwünschte Inhalte sofort ab und konfiguriert die Postifx-Seite ansonsten wie bei Punkt 1., verwendet also den gleichen smtpd für die Reinjection (den zweiten Durchgang halt) wie bei Punkt 1., die Konfiguration des Filters kann man wie in Punkt 2. handhaben.
4. Mail, die lokal via sendmail(8), also pickup(8) in die Queue gelangte: Hier setzt man natürlich einen after-queue-Filter, definiert in der master.cf, ein, aktiviert das Signieren, lässt unerwünschte Inhalte durch und kann für den smtpd im zweiten Durchgang getrost alle erwähnten Werte für receive_override_options setzen.
5. Für die Mails, die Mailman erzeugt, legt man einen gesonderten smtpd an, der im after-queue-Filter alle Checks deaktiviert hat und nur signiert. Für den zweiten Durchgang kann man den smtpd aus Punkt 4 recyclen.