Konfiguration Postfix Reject Codes und Verwendung der Regular Expressions

Konfiguration Postfix Reject Codes und Verwendung der regular Expressions

Wenden wir uns den in diesem Zusammenhang sinnvollen Einstellungen zu: wir wollen nicht nur keinen Spam mehr annehmen, sondern auch klar die Mails ablehnen und dazu unsere Regular Expressions auf PTR und helo als Validierungswerkzeuge heranziehen.
[divider height=“5″ line=“1″]

Werbung

[divider height=“3″ line=“1″]
Damit ein MTA eine Nachricht nicht in seine Queue ablegt, sondern einen Fehler an den Absender zurückschickt, muss der Server mit einem 5xx-Fehlercode antworten. Würden wir mit einem 4xx-Fehlercode antworten, kämen die Kollegen ja wieder und das wollten wir ja gerade vermeiden. Auch nach ein paar Stunden. Also setzen wir jetzt die 5xx-Fehlercodes für alles was wir zurückweisen (rejecten). In der „main.cf“ setzen wir dazu die nun folgende Werte ein, da diese sonst unseren ungeliebten 4xx-Fehlercode ausgegeben hätten:

[...]
#soft_bounce = yes
[...]
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550
unknown_address_reject_code = 550
[...]

und dann gehts auch schon in die Antispam-Abteilung (Erläuterungen darunter):

[...]
# Antispam
smtpd_hard_error_limit = 1

smtpd_client_restrictions = permit_sasl_authenticated,
reject_unknown_client_hostname,
regexp:$sample_directory/regex/ptr.cf,
permit

# HELO
smtpd_helo_required = yes
smtpd_helo_restrictions =    permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
regexp:$sample_directory/regex/helo.cf,
permit

# FROM
smtpd_sender_restrictions =  reject_non_fqdn_sender,
reject_authenticated_sender_login_mismatch,
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_sender_domain,
regexp:$sample_directory/regex/sender.cf,
warn_if_reject reject_unverified_sender,
permit

# RCPT TO
smtpd_recipient_restrictions =    reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
permit_sasl_authenticated,
permit_mynetworks,
reject_unverified_recipient,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:2501,
permit

# DATA
smtpd_data_restrictions =       reject_unauth_pipelining
[...]

[divider height=“5″ line=“1″]

Werbung

[divider height=“3″ line=“1″]
Erläuterungen:

smtpd_hard_error_limit

Einfache Sache: einen Fehler und der Sender bekommt einen Schuss vor den Bug – der default-Wert von 20 stammt sicherlich noch aus den 80ern.

smtpd_client_restrictions

Hier prüfen wir wer sendet, also den PTR. Benutzer die sich direkt einloggen sind natürlich erlaubt. Dann wird geprüft, ob der Hostname auch vorwärts auflösbar ist (falls nicht: Tschüss). Dann kommt die Prüfung gegen unsere regular Expressions. Wer das passiert hat darf weitermachen.

smtpd_helo_required

Ein HELO ist immer Voraussetzung – das gehört nicht nur zum guten Ton, sondern ist Bestandteil des Mailprotokolls.

smtpd_helo_restrictions

Erlaubt sind Angemeldete Benutzer und auch meine Maschinen. Ein HELO im Internet hat natürlich einen gültigen Hostnamen zu haben. Darauf folgt die Prüfung nach der Syntax des HELO. Dann kommt die Prüfung ob das helo im DNS aufgelöst werden kann (hier scheitern oft die Hinterhofmailserver die in kleinen und mittleren Firmen stehen – aber laut RFC2821 hat es so zu sein). Dann erst kommt unsere REGEX-Prüfung. Wer das passiert hat darf weitermachen.

smtpd_sender_restrictions

Hier kommen einige Prüfungen auf die FROM-Adresse – ich hab den Block nur stehen lassen, weil wir hier auch eine REGEXP verwenden, die allerdings z.Zt. leer ist und weil hier auch eine Überprüfung auf einen möglichen Bounce stattfindet (warn_if_reject reject_unverified_sender) den wir später benötigen um die PTR-Regex zu erweitern (Abschnitt „Erweitern der Regular Expressions durch Validitätsprüfung des Absenders„).

smtpd_recipient_restrictions

Hier hab ich eine Besonderheit, die Anfangs für Irritation gesorgt hat: Die Gültigkeitsprüfungen vor dem genehmigten Einliefern durch angemeldete Benutzer. Falsch geschriebene Mailadressen wurden direkt abgeschmettert und haben nicht mal das Outlook des Kunden verlassen. Das Kursiv geschriebene ist das Greylist-Modul. Ansonsten ist das in der Reihenfolge das übliche um nicht zu relayen.

smtpd_data_restrictions

Einige Spambots haben nach einem 5xx Fehler dennoch Daten übermittelt, wer das macht bekommt die Leitung gekappt.
[divider height=“5″ line=“1″]

Werbung

[divider height=“3″ line=“1″]
Wenn man dann die Konfig geändert hat, muss Postfix neu gestartet werden.

Danach kann man dann mal im Logfile beobachten, was da alles abgeschmettert wird – das ist echt stark! Speziell die erste PTR-Regel haut sofort praktisch alles weg, was wir eh nicht wollen.

Du musst angemeldet sein, um einen Kommentar abzugeben.