Altbekanntes Problem: Ein Mailserver nimmt Mails an unbekannte Empfänger seiner Organisation erstmal an, um kurz danach einen NDR an den (vermeintlichen) Absender zurückzuschicken. Der einliefernde Spammer ist da aber schon wieder weg ist. Die Unzustellbarkeitsnachricht geht also an eine ohnehin gefälschte Absenderadresse.

So ein Mailserver-Verhalten lässt sich einfach verhindern, wenn bereits im SMTP-Dialog nach Bekanntgabe des „RCPT TO:“ die Konversation bei ungültigem Empfänger abgebrochen wird. Das kann auch Exchange seit Ewigkeiten. Aber seit der Version 2013 nimmt es Mails von externen Systemen über die Frontend-Transportrolle an. Leider hat diese die unangenehme Eigenschaft, auch bei korrekt eingestellten Antispam-; Content-; Recpient-Verification-Filtern den SMTP-Dialog erst nach dem DATA mit einem 5-er-Fehlecode abzulehnen.

Das wäre technisch eigentlich nicht schlimm, denn der einliefernde Client ist zu dem Zeitpunkt ja noch da. Es sei denn…der einliefernde Client ist die vorgelagerte Sophos (als Beispiel für einen Proxy).

Mailproxys werden im Zusammenhang mit Exchange schon seit Jahrzehnten eingesetzt, lange bevor Exchange selbst das Spam- und Virenscannen lernte. Ist auch heute noch die bessere Wahl. Im Falle des SMTP-Dialogs verwenden Proxys ein „Callout“, indem sie das RCPT TO an den eigentlichen Postfachserver durchreichen („Recipient Verfification“).

Leider liefert die Frontend-Rolle immer ein fröhliches 2xx und nicht direkt schon 5xxx . Insofern geht die Mail des Clients erstmal fröhlich durch die Sophos Spam- und Virenscan-Maschienerie und danach in seine Queue. Doch – oh Wunder – der Exchange will die E-Mails gar nicht haben, weil er den Empfänger immer noch nicht kennt. Na gut, dann zurück mit der Nachricht zum Spammer, der aber schon über alle Berge ist. Insofern erzeugt die Sophos einen Bounce an den vermeintlichen Absender, so wie er/sie eben im Header steht…

Das Verhalten kann man ändern, indem man die Sophos direkt an die Hubtransportrolle durchstellen lässt. Da sich in der Sophos der anzusprechende Port fürs Callout (ist meiner Kenntnis nach immer nach Standard die 25) nicht ändern lässt, muss man zunächst diesen Port für den Frontend-Transport vom Exchange wegnehmen und einen neuen Hubtransport auf Port 25 erzeugen. Als Bereich würde ich für das geschilderte Szenario als Remotenetzwerke auch nur die Sophos und den Exchange selbst eintragen (der schickt sich für seine Health-Test selbst gerne Mails).

Nach der Umstellung und dem obligatorischen Restart des Exchange-Transport-Agent-Dienstes (nicht des ganzen Windows-Servers!) ist das SMTP-Verhalten des Exchange wie früher. Und Sie werden deutlich weniger Spamtraffic haben.

Achtung: Im Sophos werkelt als MTA ein Exim. Dessen Callout-Mechanismus speichert Abfragen bis zu 24 Stunden zwischen. Wo genau, weiß ich nicht. Also nicht wundern, wenn sich das gewünschte Verhalten bei einigen ungültigen Empfängern nicht sofort zeigt.