Für jede Domain, die E-Mail empfängt, muss es eine postmaster@ und eine abuse@ Adresse geben. E-Mails an diese Adressen müssen angenommen werden, und jemand sollte sie auch lesen. Geregelt ist das in RFC 5321 und RFC 2142.
Wofür die Adressen da sind
postmaster@domain.tld ist für technische Fragen zum Mailsystem. Wenn jemand Probleme hat, E-Mails an eine Domain zu schicken, wendet er sich an den Postmaster. Im schlechtesten Fall sitzt dort ein Mensch, der die Nachricht an den richtigen Admin weiterleiten kann.
abuse@domain.tld ist für Missbrauchsmeldungen. Wird die Domain zum Spam-Versand missbraucht, schreibt man an abuse. Eine Abuse-Adresse findet sich auch im WHOIS der meisten IP-Netze.
Warum das in der Praxis scheitert
Immer wieder kommen Beschwerden bei mir an, weil E-Mails an gehostete Domains abgewiesen werden. Also sucht man den Grund, findet ihn im Reject (Blockliste, fehlender Reverse-DNS, dynamische IP) und schreibt dem Postmaster der Absenderdomain. Vier Sekunden später kommt die Antwort: „Postfach nicht gefunden“ oder „Mailbox voll“.
Die Adressen existieren nicht, oder niemand liest sie. Das ist nicht nur ein Verstoß gegen die RFCs. Es macht die Fehlersuche für alle Beteiligten unmöglich.
Das eigentliche Problem: Filter
Selbst wenn die Adressen existieren, reicht das nicht. Wenn jemand Probleme hat, E-Mails an unsere Domain zu schicken, versucht er es über postmaster@. Wird diese E-Mail ebenfalls gefiltert, hat der Absender verloren. Ein Hinweis auf ein echtes Problem mit dem Mailsystem erreicht uns nicht.
Die Lösung: postmaster@ und abuse@ müssen an allen Filtern vorbei. Sowohl in Postfix als auch im Content-Filter.
Postfix: Empfänger whitelisten
In /etc/postfix/recipient-access die beiden Adressen mit OK eintragen:
# /etc/postfix/recipient-access
postmaster@kernel-error.de OK
abuse@kernel-error.de OK
Danach die Hash-Datei erzeugen:
postmap /etc/postfix/recipient-access
In /etc/postfix/main.cf muss check_recipient_access vor den Restrictions stehen. Die Reihenfolge ist entscheidend: Postfix arbeitet die Regeln von oben nach unten ab, die erste passende greift.
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_recipient_access hash:/etc/postfix/recipient-access,
reject_rbl_client zen.spamhaus.org,
...
Alle nachfolgenden HELO-Checks und RBL-Prüfungen greifen jetzt nicht mehr auf E-Mails an postmaster@ und abuse@.
Wo im SMTP-Dialog prüfen?
Postfix bietet mehrere Stellen für Restrictions:
smtpd_client_restrictions — nach connect
smtpd_helo_restrictions — nach HELO/EHLO
smtpd_sender_restrictions — nach MAIL FROM
smtpd_recipient_restrictions — nach RCPT TO
smtpd_data_restrictions — nach DATA
smtpd_end_of_data_restrictions — nach der Übertragung
Je früher man ablehnt, desto weniger Ressourcen verbraucht man. Wer im HELO prüft, nimmt erst gar keinen Empfänger entgegen. Wer erst nach DATA prüft, hat die komplette E-Mail schon angenommen. Für die meisten Setups ist smtpd_recipient_restrictions der sinnvolle Kompromiss.
Content-Filter: Spam durchlassen
Postfix lässt die E-Mails an postmaster@ und abuse@ jetzt durch. Aber der Content-Filter dahinter wird sie trotzdem filtern, wenn man ihm nicht sagt, dass er sie in Ruhe lassen soll.
In rspamd geht das über eine settings.conf Regel, die bestimmte Empfänger vom Spam-Filtering ausnimmt. In AMaViS (falls noch im Einsatz) über @spam_lovers_maps in /etc/amavis/conf.d/50-user:
# AMaViS: /etc/amavis/conf.d/50-user
@spam_lovers_maps = (
[
"postmaster\@kernel-error.de",
"abuse\@kernel-error.de",
]
);
Das bedeutet nicht, dass die E-Mail nicht geprüft wird. AMaViS testet weiterhin, lässt die Nachricht aber durch. Viren und verdächtige Anhänge filtere ich an dieser Stelle weiterhin. Nur Spam darf passieren. Denn wenn mir jemand über eine dynamische IP per Telnet eine Nachricht an postmaster@ schickt, soll sie ankommen.
Wer sich grundsätzlich gegen Spoofing absichern will: SPF hilft dabei, festzulegen, welche Server für eine Domain senden dürfen.
Fragen? Einfach melden.