Aus dem Alltag eines Sysadmin: Policyd

An mein treues Postfix habe ich so einiges angeflanscht, zum Beispiel Spamassassin und Virenfilter - und nun: Policyd. Das Addon bindet sich nicht wie andere über den »content_filter«-Mechanismus ein, sondern per »check_policy_service«, den es ab Postfix 2.2 gibt. Das eröffnet mir die Möglichkeit, Policyd an sinnvoller Stelle in mein Regelwerk zu integrieren. So jage ich Spam, der schon abgelehnt ist, nicht durch den Policy-Daemon - oder umgekehrt. Die Installation des C-Programms von [1] ist einfach, nach dem Entpacken genügt

gmake build && gmake install

im »policyd«-Verzeichnis. MySQL ist nötig, Policyd liefert ein SQL-Skript mit, das alle Tabellen erzeugt. Und ich lege einen Cronjob an, der veraltete Einträge periodisch aus der Datenbank entfernt:

0 * * * * /usr/local/policyd/cleanup -c /usr/local/policyd/policyd.conf

Die vielen Policyd-Prüfungen lassen sich in der Konfigurationsdatei einzeln (de-) aktivieren - besonders nützlich.

HELO Random Prevention

Spammer fälschen praktisch immer die Serveridentifikation im »HELO«-Kommando, korrekte MTAs senden hier ihren FQDN. Um sich vor den HELO-Blacklisten zu schützen, schicken Spammer gern jede Mail sogar mit einem anderen HELO. Policyd, nicht faul, ist in der Lage, Mails abzuwehren, die von der gleichen IP-Adresse, aber mit unterschiedlichen HELOs kommen.

Auch die erwähnten HELO-Blacklists beherrscht Policyd. Einsichtiger Sonderfall: Meldet sich ein Mailer mit dem FQDN meines eigenen Servers an, setze ich ihn ohne Zögern sofort vor die Tür.

Sender Throttling

Policyd versteht es, zu verhindern, dass derselbe Absender den Mailserver mit einer großen Zahl Mails überflutet. Als Detektor eignen sich die From-Adresse oder deren Domain-Part, der SASL-Benutzername oder die IP-Adresse beziehungsweise ein Netzblock. Als limitierende Kriterien dienen die Anzahl der eingelieferten Mails oder deren Gesamtgröße, je nachdem, welche Grenze zuerst überschritten ist.