Eine der ärgerlichsten Sachen, wenn man Mails noch während des SMTP-Dialogs auf Spam und Viren filtert, ist ganz klar, daß man das ja auch für Mails von Mailing-Listen tut. Und wenn man da zu oft Mails ablehnt, dann fliegt man relativ schnell von der Liste runter. Nun sind solche Mails meistens durch das Vorhandensein von speziellen Headern gekennzeichnet, z.B:


Will man nun vermeiden, von einer Mailingliste zu fliegen, wenn dort zuviel Spam an Start ist, dann kann man sich natürlich als erstes Mal eine Policy-Bank definieren (dazu hatte ich hier was geschrieben), die Spam und Viren nicht hart ablehnt, sondern einfach wegwirft und/oder in eine Quarantäne schmeißt. Das könnte mit amavisd-new z.B. so aussehen:



Wenn also die obige Policy aktiviert würde (und damit die vordefinierten Werte überschreibt), dann würden Mails und Viren verworfen und in einer SQL-Datenbank abgespeichert, die der Benutzer dann z.B. über ein Webinterface kontrollieren kann. Das Problem an der Sache ist nur: Wie kriege ich diese Policy aktiviert?

Hier hat Alexander Wirt, auch bekannt als „formorer”, in knapp 10 Minuten eine Lösung in Form eines sog. „custom packages” für amavisd-new entworfen:



Diese Datei (die man auch hier runterladen kann, was man auch tun sollte, da obiger Code einige Zeichen verfälscht) legt man dann bei Debian z.B. einfach unter /etc/amavis/conf.d/60-low-precedence ab, startet amavisd-new neu und freut sich. Und natürlich kann man das ganze auf beliebige andere Header erweitern.

Danke, formorer!

Wer erinnert sich noch eigentlich noch daran? Das Geschrei damals war groß, vor allem weil das Update für ClamAV auf 0.95.2 im volatile-Archiv für lenny doch recht lange hat auf sich warten lassen.

Woran die wenigsten Leute denken: Natürlich sind auch andere Komponenten des Systems von sowas betroffen, hier eben konkret von der Unfähigkeit, kaputte ZIP-Archive auszupacken. Wenn man jetzt z.B. ein Framework für die Filterung von Mails verwendet, das wie amavisd-new auf Perl basiert, dann führt das zu dem unschönen Effekt, daß man Dateien, die der Filter laut Policy eigentlich ablehnen müsste, mit etwas Glück doch versenden kann, indem man sie einfach in so ein kaputtes ZIP-Archiv verpackt (ihr glaubt gar nicht, wie viele Leute Mails, die der Scanner nicht checken kann, an den Empfänger weiterleiten).

Um das zu verhindern, ist es notwendig, einiges an Perl-Modulen nachzuinstallieren. Ich habe mir erlaubt, ein kleines Tarfile zu bauen, daß den ZIP/Zlib-Teil auch Dependency-mäßig abdeckt. Aber aufpassen: Das ist sehr quick und sehr dirty, die Pakete sind nicht downgegradet und was passiert, wenn man versucht, Abhängigkeiten z.B. in Hinsicht auf BZIP2 zu installieren, das will ich gar nicht wissen - ihr wurdet gewarnt.

Übrigens würde mich mal interessieren, wie das in anderen Distributionen aussieht, namentlich solche wie z.B. RHEL, CentOS (ja ja, ich weiß, doppelte Nennung und so) oder SuSE.

Nachdem ich mich hier und hier schon zum Deppen gemacht habe bei dem Versuch, einen längeren Blog-Eintrag zu schreiben und gleichzeitig etwas dagegen zu unternehmen, daß er weg ist, wenn ich aus Versehen (Ctrl - W!) das Fenster schließe, war die Lösung eigentlich ganz einfach: Es gibt ein Firefox-Plugin namens Lazarus, welches den Inhalt von Eingabefeldern automatisch und periodisch sichert. Auf Wunsch verschlüsselt es die Inhalt auf der Platte sogar, was praktisch sein kann, wenn man es z.B. in der Firma einsetzt.

Kleines Gotcha: Die Version, die man auf der offiziellen Firefox-Plugin-Seite bekommt, funktionierte zumindest hier auf einem 64Bit-Linux nicht. Abhilfe schafft der Download dann direkt von der Homepage.

Heute mal moderner: Modest Mouse, „Spitting Venom”.

Wißt ihr eigentlich, was wirklich doof ist? Wenn man, um das Autosave-Plugin von S9Y wiederzubeleben das Plugin für die erweiterten Eigenschaften von Einträgen rausnimmt. Damit funktioniert dann nämlich auch der Paßwortschutz nicht mehr.

Danke, Jakob. Du hättest ruhig was sagen können!

Gestern wollte ich es dann offiziell mal wissen: Wie schwer ist das denn eigentlich wirklich, eine Mailingliste zu betreiben und die Mails so durchzukriegen, daß auch Otto-Normalverbraucher, der kein Mailprogramm kennt und auch in der Weboberfläche nur mit Mühe Knöpfe findet, die mit Texten wie „Diese Email ist kein Spam” beschriftet sind, mitkriegt, daß er Post hat. An meinem Test nahmen Teil:

• web
• gmx
• freenet
• hotmail
• gmail
• yahoo

Nachdem ich mir bei jedem dieser Provider einen Testzugang angelegt hatte, waren zwei Testszenarien zu bestehen: Zum einen eine ganz normale Testmail, die ich von meinem DialUp-Rechner zu Hause via SMTP AUTH bei meinem Mailserver eingeliefert habe - und hier die gute Nachricht: Mit DKIM und SPF konnte ich an alle o.g. Provider so eine Mail verschicken, daß man zumindest leicht sehen konnte, daß da auch eine neue Mail im Posteingang war. Hotmail hat zwar darauf hingewiesen, daß man den Absender evt. nicht kennt, aber zumindest konnte man die Mail sehen.

Das zweite Szenario war dann das üble, oder eher jenes, welches mich zum Wahnsinn getrieben hat: Ich habe die obigen Accounts auf jeweils eine Mailing-Liste bei mir auf vier verschiedenen Servern eingetragen (auf vier Servern deshalb, weil einige der Daten ja im DNS liegen und ich auf jeden Fall vermeiden wollte, da evt. mit alten Daten zu arbeiten) und dann von jedem Account aus Mails an die Post-Adresse der Liste geschickt. Und was denkt ihr, was passiert ist? Genau: Ich konnte keine einzige Konstellation erreichen, in der von jedem Anbieter aus alle anderen so erreicht werden konnten, daß sie nicht als Spam erkannt wurden. Konkret habe ich alle denkbaren Kombinationen der folgenden Einstellungen ausprobiert:

• senden mit und ohne DKIM- und/oder DomainKeys-Signaturen der ML-Server
• Entfernen der originalen DKIM- und/oder DomainKeys-Signaturen in Mailman
• Senden mit und ohne SPF- oder SenderID-Einträge im DNS
• volle Personalisierung (From-Header umschreiben), normale Absenderadressen (listname-bounces@... im SMTP-Dialog), geVERP'te Absendeadressen im SMTP-Dialog

(das genauer Vorgehen spare ich mir hier mal, ihr dürft aber sicher sein, daß ich an Dinge wie DNS-TTL gedacht habe), Ich bin jetzt nicht nur frustriert, sondern auch leicht entsetzt, denn gerade bei der Kombination Yahoo - Hotmail sah das alles viel eher nach Zufall aus als danach, daß meine Änderungen hier irgendetwas hätten bewirken können. Die einzig gute Nachricht ist: Wenn man die Absender manuell freigeschaltet hat, dann hat es bei allen Providern funktioniert.

Tortzdem: Irgendwie ist das Medium Email doch sehr kaputt, finde ich

(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.