Microsoft Exchange SMTP Recipient Validation

Viele Spamfilter überprüfen anhand eines SMTP Checks, ob eine Mail Alias im Backend existiert und lehnen E-Mails im Voraus ab, sofern dies nicht der Fall ist.

Bei Microsoft Exchange ist das Verhalten des SMTP Servers etwas anders als bei Postfix, Dovecot oder anderen bekannten Mail Servern und führt hier zu Problemen.

In diesem Artikel beschreibe ich kurz, wie das Verhalten Exchange-seitig angepasst werden kann.

Technischer Hintergrund:
Die meisten Mailserver überprüfen nachdem RCPT TO, ob eine entsprechende Mail Alias existiert, ist dies nicht der Fall, antworten Sie normalerweise mit einem „550 Address Unknown“, siehe:

Exchange wiederum antwortet standardmäßig mit einem „250 Recipient OK“, statt einem „550 Address unknown“.
In der Standardeinstellung wird erst ein Fehler ausgegeben, sobald die eigentlich Nachricht mit „DATA“ übertragen wurde.

Dieses Verhalten führt natürlich zu „False-Positives“ bei Spamfiltern, welche SMTP Address Validation verwenden.
Obwohl der Spamfilter nach dem „RCPT TO:“ eine negative Rückantwort (550) bekommen sollte, wird eine positive Rückantwort (250) vom Exchange gesendet.

Der folgende PowerShell Befehlsatz konfiguriert die Hub Transport Connectoren so, dass dieses Verhalten umgestellt wird und SMTP Verifizierung problemlos möglich ist.
Bitte die Befehle nacheinander ausführen, da es hier zu Rückfragen kommt.

 


Nachtrag aufgrund einer Rückfrage:
Es kam die Frage auf, ob es nicht sinnvoller ist LDAP basierte Recipient Validation durchzuführen.
Dazu gibt es von mir ein klares „Jein!“.
Um LDAP Validation durchzuführen, muss das Mail Gateway LDAP basierten Zugriff auf das Active Directory (oder einen anderen Verzeichnisdienst) haben, was oft aber Sicherheitskritisch sein kann, da Mail Gateways meistens in einer DMZ stehen.

Hier kann man z.B. Abhilfe schaffen, durch ein repliziertes Verzeichnes, welches nur die notwendigen Attribute, also SMTP Adressen und je nach Szenario vielleicht noch sAMAccountNames und Passwörter (vorsicht, auch hier wieder Sicherheitskritisch) enthält.
Dies lässt sich z.B. über den Microsoft Identity Manager (den kostenlosen Synchronization Service Part) und ein ADAM/OpenLDAP Verzeichnis in der DMZ lösen.

Anderenfalls sollte das Mail Gateway (sofern nicht notwendig) aus der DMZ keinen LDAP Zugriff auf den/die Domain Controller erhalten.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

About the author

Kommentar verfassen