Sowohl MailScanner als auch Amavis sind
Frameworks, um Mails auf einem Mailserver nach Viren und Spam zu durchsuchen.
Neben vielen Gemeinsamkeiten (beide in Perl geschrieben, beide sind unter GPL
lizensiert), gibt es wie bei allen größeren Programmen auch Unterschiede.
Da ich mir beide Programme inzwischen etwas genauer angesehen und beide auch produktiv einsetze (MailScanner ab 2003, amavisd-new ab Anfang 2006), will ich einen Vergleich wagen, vielleicht hilft es ja dem einen oder anderen.
Vorweg möchte ich aber noch sagen, dass ich mich inzwischen nicht mehr als neutral betrachten kann: Anfang 2006 habe ich begonnen, amavisd-new selbst zu erweitern (größeres Refactoring der Spamscanner-API, ein DSPAM-Plugin, einige Patches sind auch bereits in amavisd-new 2.4 eingeflossen. Ich hätte mir die Zeit für die Patches wohl nicht genommen, wenn ich nicht davon überzeugt gewesen wäre, dass amavisd-new für mich die bessere Lösung darstellt. Einen Lobgesang auf MailScanner sollte also keiner erwarten ;-)
Was gleich ist
Sowohl MailScanner als auch amavisd-new sind komplett in Perl geschrieben und laufen nur unter Unix-Systemen. Beide kooperieren mit allen gängigen SMTP-Servern und Virenscannern. Für die Spamprüfung wird SpamAssassin als Library eingesetzt (quasi alternative Implementierungen von spamd). Abhängig von bestimmten Regeln (z.B. Empfängeradresse) ist es möglich, mit einer Mail bestimmte Dinge zu tun oder eben nicht (z.B. keine Virenprüfung).
Bezüglich der Code-Qualität unterscheiden sie sich auch nicht viel: Beide Projekte haben viel Spaghetti-Code und häufig schlechte Bezeichner. Amavisd-new hat die längeren Methoden (z.T. über 950 Zeilen, s. Amavis::check_mail()), MailScanner dafür die verworreneren Abhängigkeiten und schlechteren Variablenbezeichnungen.
MailScanner
Zunächst zu MailScanner: Da XAMS eine Anleitung zur Einbindung von MailScanner beinhaltete, habe ich im Jahr 2003 begonnen, MailScanner zu benutzen.
MailScanner basiert darauf, dass eine Instanz des SMTP-Servers die Mail annimmt und erst mal auf der Platte abspeichert, wo MailScanner sie dann holt, bearbeitet und einer anderen Instanz des SMTP-Servers zur weiteren Verarbeitung übergibt.
Besondere Vorteile
Das Regelformat von MailScanner ist relativ einfach aufgebaut und daher leicht zu verstehen. Es basiert vornehmlich auf einfachen Textdateien. Über selbstgeschriebene Perl-Funktionen können auch andere Speicherungsmöglichkeiten realisiert werden.
Die MailScanner-Mailingliste ist sehr aktiv, nach meinem Gefühl gab es schnellere Antworten als bei amavisd-new (allerdings ist der amavisd-new-Support ebenfalls gut!).
Besondere Nachteile
Es gibt keine klare Aufgabentrennung: So fragt z.B. MailScanner standardmäßig auch Blacklisten ab und markiert eine Mail ggf. als Spam, obwohl die SpamAssassin-Prüfung eindeutig "kein Spam" ergibt. Weiterhin gibt es eine Phishing-Prüfung, die Mails ggf. verändert.
Es gibt keine Möglichkeit, SpamAssassin zu deaktivieren und den RAM dafür zu sparen (SpamAssassin wird immer geladen, nur manchmal nicht benutzt).
Das Regelwerk zur Konfiguration ist sehr simpel, Speicherung in der Datenbank wird aber schnell sehr umständlich.
Konzeptionell nicht schön: MailScanner verwendet direkt die nicht-standardisierten Queue-Formate der Mailserver. Dies ist natürlich fehleranfällig und macht die Unterstützung neuer Server aufwändig. Allerdings ändert sich das Queue-Format nicht oft und die meisten Mailserver sind ohnehin freie Software, so dass es genaue Informationen über die Formate gibt.
Der Mailfluss lässt sich nur sehr begrenzt steuern (zumindest bei Verwendung von Exim): Sämtliche Exim-Optionen (z.B. Umschreiben von Adressen, Router mit spez. Effekten) kommen erst zum Tragen, nachdem MailScanner die Mail bearbeitet hat.
MailScanner ist sehr "mutig": So werden bei bestimmten Aktionen einfach Signaturen an E-Mails angehängt, so dass bei Nicht-ASCII-Mails (deutsche Umlaute) bzw. MIME-Kodierungen die versandte Mail dann RFCs verletzt. Auch diverse Dateitypen stehen standardmäßig auf einer schwarzen Liste, weil z.B. Outlook früher einmal Fehler bei der Bearbeitung dieses Dateityps hatte (z.B. bei BMP-Dateien). Dies sind Aktionen, die für mich ganz klar in einen Viren- oder einen separaten Securityscanner gehören.
MailScanner ist nicht ganz einfach zu debuggen: Der MailScanner-Daemon ruft selbstständig den Mailserver auf und übergibt diesem bearbeitete Mails. Man kann also nicht einfach eine Mailserver-Instanz mit max. Loglevel starten, um die kompletten Debug-Ausgabe zu sehen.
Es gibt keine RPMs für MailScanner, so dass Aktualisierungen kompliziert von Hand durchgeführt werden müssen. Die Erstellung eines RPMs ist auch relativ schwierig (zumindest habe ich es bei meinem Versuch nicht geschafft), weil MailScanner eine etwas merkwürdige Verzeichnisstruktur in den Original-Quellen verwendet.
MailScanner bringt ein eigenes Startskript in /etc/init.d unter, das sowohl SMTP-Server als auch MailScanner zusammen startet. Hier muss man sehen, dass man das distributionseigene Skript für den SMTP-Server immer deaktiviert lässt.
Auf Grund des MailScanner-Designs (Mails werden im Dateisystem übernommen, Mailserver wird direkt über spezielle Programme wie "exim" statt über SMTP angesprochen) ist es kaum möglich, MailScanner in ein chroot zu sperren, um z.B. das Risiko eventueller Lücken kommerzieller Virenscanner zu minimieren.
Zumindest mit der Kombination Exim und MailScanner 4.43 gingen Mails verloren, wenn /tmp voll war: MailScanner übernahm (löschte!) die Mail aus der Exim-Queue, jedoch lief MIME::Parser auf einen Fehler, weil auf tmp kein Platz mehr war. MailScanner erkannte diesen Fehler jedoch nicht und löschte auch die Kopie in der eigenen Queue.
amavisd-new
amavisd-new ist der aktivste und meistgenutzte Fork von AMaViS. amavisd-new ist ein eigenständiger Daemon, der die Mails über SMTP entgegen nimmt (auf Wunsch mit Authentifizierung und TLS-Verschlüsselung) und sie auch wieder über SMTP ausliefert.
Besondere Vorteile
Es ist möglich (und wird offiziell unterstützt), amavisd-new in ein chroot zu sperren. Virenscanner sind auf Grund ihrer Arbeitsweise mit potenziell böswilligen Dateien immer gefährdet und bei proprietärer Software ist es manchmal schon beruhigend, wenn man weiß, dass die Software sicher eingesperrt ist.
Über die Exim-Konfiguration kann man beliebig steuern, wann amavisd-new aufgerufen werden soll.
Da die von amavisd-new gescannten Mails über einen separaten Port wieder zum MTA geleitet werden, ist es leicht möglich, Mails ohne große Probleme an amavisd-new vorbei zu schleusen (Beispiel: Freigeben einer Mail aus der Quarantäne). Mit MailScanner geht dies zwar auch, jedoch muss man eine spezielle "Protokoll"-Option bei Exim setzen, was nur Administratoren dürfen.
Die Regeln (z.B. Spamprüfung für bestimmte Absender abschalten) müssen nicht in der Konfigurationsdatei gespeichert sein: Statt dessen sind auch Textdateien, Datenbanken oder LDAP-Verzeichnisse denkbar.
Spam- und Virenprüfung (amavisd-new) sind problemlos auf andere Rechner auslagerbar ohne den eigentlichen MTA zu verlagern, da amavisd-new seine Mails über das TCP/IP-Protokoll empfängt und versendet.
Für amavisd-new gibt es viele vorgefertige RPM- (und DEB-)Pakete, die problemloses Aktualisieren erlauben.
amavisd-new unterstützt (mit meinen Patches) auch DSPAM als alternativen Virenscanner (= bessere Erkennungsraten, schneller, weniger RAM, Änderung des Bodies zum leichten Trainieren).
Besondere Nachteile
Die Konfigurationsdatei ist ein vollwertiges Perl-Skript. Dadurch ergeben sich gewisse Restriktionen in Bezug auf die Syntax. Das Befüllen eines Hashs (ev. verschachtelt) ist für viele vielleicht nicht ganz so intuitiv. Auch muss man daran denken, dass Perl ein @ mit folgenden Buchstaben in einem String (doppelte Anführungsstriche) als Verweis auf eine Array-Variable interpretiert, so dass ggf. maskiert werden muss.
Die Konfiguration mit policy banks ist zwar sehr mächtig, aber ebenfalls nicht so intuitiv und - wie ich finde - nur spärlich dokumentiert.
Sämtliche Module sind in einer großen Perl-Datei (780 kB!) untergebracht.
Es gibt z.T. grauenhaften Code (Version 2.3.3, amavisd, Zeile 355):
Vor einigen Jahren war ich gegenüber amavisd-new etwas skeptisch, weil amavisd-new einen SMTP-Mailserver simuliert. Damals nahm ich an, dass Clients sich direkt zu amavisd-new verbinden bzw. dass amavisd-new vor Exim vorgeschaltet wird. Dies ist natürlich problematisch, da weil es immer wieder kaputte Clients gibt und Erfahrungen mit den ganzen Feinheiten und Bugs in den herkömmlichen Mailservern schon existieren. Außerdem müsste in so einem Fall eine möglicherweise komplexe Mailkonfiguration des Mailservers in amavisd-new dupliziert werden. Diese Bedenken sind aber unbegründet, weil eben amavisd-new nur mit dem eigentlichen MTA kommunziert und gegenüber den Clients gar nicht in Erscheinung tritt.