Zum Inhalt springen
clausvb.de

Greylisting: fünf Fehler, die Mails wirklich kosten

Falsche Reihenfolge der Restriktionen, fehlende Whitelists, zu enges Bestätigungsfenster: die Konfigurationsfehler, die aus einer harmlosen Verzögerung ein echtes Zustellproblem machen.

Zuletzt geprüft:

Das Wichtigste

  • Greylisting vor permit_sasl_authenticated verzögert die eigenen Nutzer – ein Fehler, der beim Testen vom Server aus unsichtbar bleibt.
  • Ein zu enges Bestätigungsfenster verwirft Zustellungen von Servern mit langen Wiederholungsintervallen endgültig.
  • Ohne Whitelist für Transaktionsmails warten Kunden minutenlang auf Bestätigungen und Codes.
  • Eine volle oder nicht beschreibbare Triplet-Datenbank lässt den Policy-Dienst scheitern – und Postfix weist dann pauschal ab.

Greylisting gilt als risikoarm, weil es nichts endgültig ablehnt. Das stimmt – solange die Konfiguration stimmt. Die folgenden fünf Fehler machen aus einer harmlosen Verzögerung ein Zustellproblem.

1. Falsche Reihenfolge in den Restriktionen

# FALSCH: eigene Nutzer werden mit verzögert
smtpd_recipient_restrictions =
    check_policy_service inet:127.0.0.1:10023,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    permit

Postfix arbeitet die Liste von oben nach unten ab. Steht der Policy-Dienst vorne, trifft Greylisting auch angemeldete Nutzer und die eigenen Netze. Richtig ist:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    check_policy_service inet:127.0.0.1:10023,
    permit

Der Fehler bleibt beim Testen oft unsichtbar, weil ein Test vom Server selbst durch permit_mynetworks läuft. Auffällig wird er erst, wenn Mitarbeiter von unterwegs versenden.

2. Zu enges Bestätigungsfenster

Zwei Werte müssen zusammenpassen: die Sperrfrist, nach der ein zweiter Versuch akzeptiert wird, und das Fenster, innerhalb dessen er kommen muss.

Wiederholungsintervalle in freier Wildbahn reichen von einer Minute bis zu mehreren Stunden. Ist das Bestätigungsfenster auf eine Stunde gesetzt und ein Absender wiederholt erst nach zwei, passt das Triplet nicht mehr – die Zustellung beginnt von vorn, und im ungünstigen Fall gibt der sendende Server irgendwann auf.

POSTGREY_OPTS="--delay=300 --max-age=45"

Vier bis acht Stunden Bestätigungsfenster sind ein tragfähiger Bereich.

3. Fehlende Whitelists für Transaktionsmails

Der Fall, der am häufigsten zu Beschwerden führt: Ein Kunde fordert einen Passwort-Reset oder einen Zwei-Faktor-Code an und wartet fünf Minuten. Aus seiner Sicht funktioniert der Dienst nicht.

Auf die Whitelist gehören mindestens:

  • Zahlungsdienstleister und Shopsysteme
  • Systeme, die Anmeldecodes verschicken
  • Monitoring- und Alarmsysteme
  • Ticketsysteme von Kunden und Lieferanten

Grosse Versender rotieren zusätzlich die Absender-IP zwischen den Versuchen. Für die passt das Triplet nie, und ohne Whitelist wird jede einzelne Mail verzögert statt nur die erste.

4. Triplet-Datenbank nicht beschreibbar

Postgrey legt seine Daten unter /var/lib/postgrey ab. Ist das Verzeichnis voll, falsch berechtigt oder nach einem Update einem anderen Benutzer zugeordnet, antwortet der Policy-Dienst nicht mehr.

Was Postfix dann tut, hängt an der Konfiguration: Ohne permit als Abschluss der Restriktionsliste oder mit einem strengen smtpd_policy_service_default_action weist er pauschal ab – aus einer Verzögerung wird eine generelle Ablehnung.

# Zustand prüfen
systemctl status postgrey
ls -la /var/lib/postgrey/
df -h /var

# Erreichbarkeit des Policy-Dienstes
nc -zv 127.0.0.1 10023

In die Überwachung gehört der Dienst deshalb genauso wie Postfix selbst.

5. Keine Ausnahme für die eigene Infrastruktur

Systeme, die vom eigenen Netz aus zustellen – Webserver mit Kontaktformular, Monitoring, Backup-Berichte – laufen häufig nicht über permit_mynetworks, weil sie in einem anderen Segment stehen. Dann verzögert Greylisting die eigene Systempost.

Bei einer Alarmmail ist das mehr als lästig: Die Meldung, dass ein Dienst ausgefallen ist, kommt fünf Minuten später an. Solche Absender gehören explizit freigegeben.

Prüfliste

# Reihenfolge kontrollieren
postconf smtpd_recipient_restrictions

# Policy-Dienst erreichbar
nc -zv 127.0.0.1 10023

# aktuelle Verzögerungen
grep 'greylist' /var/log/mail.log | tail -20

# Whitelist aktiv?
grep -c . /etc/postgrey/whitelist_clients{,.local} 2>/dev/null

Danach ein echter Test von aussen: eine Mail von einer Adresse senden, die der Server noch nie gesehen hat, und die Zeit bis zur Zustellung messen. Alles, was deutlich über der eingestellten Sperrfrist liegt, ist ein Hinweis auf einen der Punkte oben.

Funktionsweise, Zeitwerte und Einrichtung stehen ausführlich im Greylisting-Guide.

Häufige Fragen

Können durch Greylisting Mails endgültig verlorengehen?

Bei korrekter Konfiguration nicht: Ein temporärer Fehler wird von jedem standardkonformen Mailserver wiederholt. Verloren gehen Mails, wenn das Bestätigungsfenster kürzer ist als das Wiederholungsintervall der Gegenstelle, oder wenn ein schlecht gebautes Versandsystem einen 4xx wie eine endgültige Ablehnung behandelt.

Warum werden meine eigenen Mails verzögert?

Weil check_policy_service in der Restriktionsliste vor permit_sasl_authenticated steht. Angemeldete Nutzer müssen vor dem Policy-Dienst freigegeben werden, sonst greift Greylisting auch für sie.

Passend dazu