| | |
|
|
|
|
DSPAM in Postfix integrieren |
|
|
|
DSPAM ist ein alternativer Spamfilter, der deutlich weniger Ressourcen als z.B. SpamAssassin benötigt. Auf von mir betreuten Mailservern ist er mittlerweile die favorisierte Lösung geworden und ich würde ihn gegen keine andere Lösung mehr eintauschen wollen. Um DSPAM mit Postfix zu nutzen, gibt es prinzipiell drei Möglichkeiten:
- Als Inhaltsfilter: Hierbei positiv zu erwähnen ist, dass die Integration sehr einfach und schnell möglich ist. Mit zwei zusätzlichen Zeilen in der Postfix Konfiguration ist man prinzipiell bereits dabei, genauso einfach wie man z.B. ClamSMTP einbinden kann. Dazu noch ein zusätzlicher Listener - damit DSPAM die gescannten Mails wieder zurück an Postfix schicken kann und nach einer Anpassung der DSPAM Konfigurationsdatei sollte alles laufen. Außerdem wird jede E-Mail so nur einmal überprüft, egal wie viele Empfänger sie hat. Doch dazu später mehr, da das nicht nur positiv ist.
Code: # main.cf
ontent_filter = lmtp:unix:/var/run/dspam/dspam.sock
receive_override_options = no_address_mappings
# master.cf
localhost:10024 inet n - n - - smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8 |
Der größte Nachteil bei dieser Lösung ist allerdings, dass auch versendete E-Mails durch den Spamfilter laufen. Das ist natürlich ungünstig, wenn man die automatische Lernfunktion aktiviert hat und danach keine einfache Möglichkeit mehr hat, die durchgereichten E-Mails umzulernen. Außerdem werden so die Zieladressen vorher nicht aufgelöst (Stichwort Alias) und man bekommt schnell einen ordentlichen Murks in der DSPAM Datenbank zusammen. Falls man bereits andere Inhaltsfilter verwendet, müssen diese mit DSPAM über die entsprechenden Listener in der master.cf nacheinander verkettet werden. Dabei wird es schnell unübersichtlich und Fehler sind nur sehr schwer zu debuggen. Deshalb weiter zu...
- Als Zugriffsfilter: Auch diese Möglichkeit ist relativ schnell eingerichtet.
Code: # main.cf
smtpd_recipient_restrictions = [...],
check_recipient_access pcre:/etc/postfix/dspam_filter_access
# dspam_filter_access
/./ FILTER dspam:dspam
# master.cf
dspam unix - n n - - pipe
flags=Ru user=dspam argv=/usr/bin/dspam
--client
--deliver=innocent,spam
--user ${recipient}
--mail-from=${sender}
localhost:10024 inet n - n - - smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8 |
Nachteile: Lokal versendete E-Mails (u.a. auch vom Webmailer), die z.B. an lokale Zieladressen gehen, werden so nicht gefiltert. Weitergeleitete Mails werden so ebenfalls durch den Spamfilter geschickt, wodurch wir wieder bei den Problemen aus Punkt Eins wären. Deshalb weiter zu...
- Als Zustellagent: DSPAM kann aber auch einfach als MDA eingebunden werden, der sich danach an die Zustellung zum echten LDA (z.B. Dovecot) kümmert. Der Vorteil hierbei ist, neben der noch einfacheren Konfiguration, dass wirklich nur die lokalen Mailboxen als Ziel ihre E-Mails durch DSPAM gefiltert bekommen. Die Adressen sind zu diesem Zeitpunkt bereits komplett aufgelöst, wodurch definitiv keine E-Mail nach draußen durch den Spamfilter gelangt. Davon ausgenommen sind maximal Weiterleitungsregeln in den Mail-Clients oder Serverseitig mit z.B. Sieve.
Code: # main.cf
virtual_transport = dspam
virtual_destination_recipient_limit = 1
# master.cf
dspam unix - n n - - pipe
flags=Ru user=dspam argv=/usr/bin/dspam
--client
--deliver=innocent,spam
--user ${recipient}
--mail-from=${sender} |
Der Nachteil dabei könnte je nach Konfiguration sein, dass nur der "virtuelle" Transport betroffen ist. Lokale Mails von Systembenutzern bleiben davon unberührt. Außerdem wird die E-Mail so für jeden Empfänger separat geprüft, was bei vielen Zieladressen mehr Ressourcen kosten könnte. Trotzdem halte ich die dritte und letzte Möglichkeit für die sinnvollste.
Bei fast allen Lösungen muss man noch die Sockets und andere Konfigurationsdateien entsprechend verfügbar machen, falls Postfix in einem Chroot läuft.
Oder man deaktiviert das virtuelle Gefängnis für lmtp in der master.cf von Postfix. Ansonsten wird es zu unerklärbaren Fehlern über nicht gefundene Dateien kommen.
Wenn man Address Extensions verwendet, sollte man den --user Parameter noch anpassen:
Code: # --user ${recipient}
--user ${user}@${domain} |
So ist sichergestellt, dass nur die echten Postfachadressen in der DSPAM-Datenbank landen!
Achtung: Alle gezeigten Beispielkonfigurationen sind nur für Demonstrationszwecke gedacht und müssen vor dem Einsatz auf echten Mailservern noch an das eigene Setup angepasst werden!
Die Rechte von Sockets und die Firewalleinstellungen sollten ebenfalls vorher kontrolliert werden. Die jeweilige DSPAM Konfiguration wurde hier absichtlich nicht gezeigt.
Dieser Beitrag soll nur als Denkanstoß für eigene Konfigurationen dienen! Alles getestet unter Debian Wheezy mit Postfix/DSPAM/Dovecot.
|
|
Kommentare: 0 |
Kommentare sind deaktiviert |
|
Autor |
Nachricht |
Für diesen Beitrag können zur Zeit keine neuen Kommentare verfasst werden. Kontaktiere den Autor des Beitrages, falls du Fragen dazu hast. |
Verwendete Zeitzone: CET (Europe/Berlin ) Aktuelles Datum & Uhrzeit: 13.01.2025, 21:45 |
Nach oben |
|
|
|
|
|
|
| | |