Probleme mit Greylisting

Update am 03.08.2008: Ein Hotfix zur Lösung des Problems ist jetzt verfügbar.
Update am 16.07.2008: Es gibt einen neueren Artikel zu diesem Thema: Neues von der Greylisting-Front

Bei meinem alten Arbeitgeber hatte ich unter anderem eine Spamfilter-Lösung entwickelt, welche verschiedene Techniken zum Filtern von Emails nutzte. Eine davon war Greylisting, welche mit Exchange 2003 Servern als Gegenstelle in seltenen Fällen Probleme bereitet. Exchange 200U3 setzt (im Gegensatz zu Exchange 2007) auf die SMTP-Engine von Windows Server 2003 auf, welche in seltenen Fällen unter ganz bestimmten Umständen mit Gegenstellen, die Greylisting verwenden, Probleme bekommen.

Sie äußern sich in der Form, dass die Email von der Gegenseite mit einem 4xx-Fehler temporär abgewiesen wird und danach wie in einem schwarzen Loch verschwunden zu sein scheint. Es erfolgt keine Rückmeldung an den Sender oder den Empfänger, dass die Nachricht noch nicht zugestellt werden konnte. Bei dem schwarzen Loch handelt es sich um SMTP Mailbox Temp Tables.

Sobald man den SMTP-Dients (oder den ganzen Server) neu startet, tauchen die Nachrichten plötzlich wieder in der Queue auf. Abhängig vom Alter der Nachrichten kann es dann sein, dass diese erneut verschickt werden oder dass ein NDR erzeugt wird, weil die Nachricht zu lange in dem schwarzen Loch verschwunden war.

Solche Vorfälle wurden von verschiedenen Administratoren im Internet diskutiert. Sie treten selten auf und sind schwer zu reproduzieren. Für das Problem gibt es aber verschiedene mögliche Workarounds:

  1. Senden aller ausgehenden Emails über einen Smarthost des Providers.
  2. Tägliches stoppen und starten des SMTP-Dienstes:
    net stop smtpsvc && net start smtpsvc
  3. Ändern des Glitch Retry- und Per Message Failures Before Marking As Problem-Verhaltens von Exchange:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Queuing

Value name: PerMsgFailuresBeforeMarkingAsProblem
Data type:REG_DWORD
Radix: Decimal
Default: 2

Value name: GlitchRetrySeconds
Data type: REG_DWORD
Radix: Decimal
Default: 60

Letzteres ist der bisher sinnvollste Workaround. Dabei muss (GlitchRetrySeconds * PerMsgFailuresBeforeMarkingAsProblem) > (Greylisting-Timeout) sein. Bei zum Beispiel 10 Minuten Greylisting-Timeout kann man GlitchRetrySeconds auf 200 und PerMsgFailuresBeforeMarkingAsProblem auf 3 setzen (die Standardwerte sind 60 für GlitchRetrySeconds und 2 für PerMsgFailuresBeforeMarkingAsProblem). Standardmäßig existieren die Einträge nicht, daher muss man den Unterordner Queuing auch in der Registry per Hand anlegen.

Wir arbeiten zur Zeit im Rahmen des Servicerequests SRQ061213601094 an einer generellen Lösung des Problems.