Eben gerade erfolgreich Exchange Server von 2003 auf Version 2007 migriert. Stille Zufriedenheit. Alle Klippen elegant umschifft. Beinahe. Denn am nächsten Tag taucht der Man mit der schwarzen eckigen Hornbrille (der Webmaster) im Türrahmen auf: "eh, Mann, die Webformulare funktionieren nicht mehr, keine Mails mehr, was n`los?"

Anwendungsserver, Router oder auch Kopierer mit Scan/Send-by-email-Funktionalität benötigen oftmals die Möglichkeit, unauthentifiziert E-Mails versenden zu können. Solange Mails nur an interne Empfänger gesendet werden, stellt dies kein Problem dar. Ist der Empfänger jedoch ausserhalb der Exchange Organisation, so muss das Mail-Relaying konfiguriert werden. Der Exchange Server wird dazu sinnvollerweise als interner Mail Relay Server eingesetzt, um den Mailfluss zentral kontrollieren zu können.

In Exchange 2003 konnte dies durch das Hinzufügen der IP-Adresse des SMTP-Senders im Eigenschaftsfenster des SMTP Virtual Server bewerkstelligt werden:

In Exchange Server 2007 sollte für das un-authentifizierte Relaying ein eigenständiger Receive Connector erstellt werden. Der Standard Receive Connector, welcher den SMTP-Verkehr vom Internet entgegen nimmt sollte nicht für un-authentifiertes Relaying verwendet werden - zu gross ist die Gefahr einer Fehlkonfiguration und damit die Gefahr des Missbrauchs durch Spammer.

Für einen neuen Receive Connector wird eine neue (interne) IP-Adresse benötigt, damit der Standard Port 25 für SMTP verwendet werden kann. Wenn wir dazu zum Beispiel die IP-Adresse 192.168.10.12 zusätzlich auf die Netzwerkkarte des Exchange Servers hinterlegen und dem Server mit IP-Adresse 192.168.10.99 SMTP-Relay-Rechte geben möchten, so lautet der Befehl zur Erstellung des neuen Receive Connectors:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings '192.168.10.12:25' -fqdn relay.domain.local -RemoteIPRanges 192.168.10.99 -server EXCHSERVER -permissiongroups ExchangeServers -AuthMechanism 'TLS, ExternalAuthoritative'  

Der neue Receive Connector mit dem Namen RelayConnector erfordert so keine Authentifzierung für das Relaying von Mails ab der IP-Adresse 192.168.10.99. Zusätzlich werden damit auch sämtliche Spam-Filter-Einstellungen für Mails ab dieser Adresse ignoriert.

Weitere IP-Adressen, von welchen aus der neue Relay-Connector genutzt werden kann, können danach auch einfach per Exchange 2007 Konsole hinzugefügt werden:

Damit wird der Versand an externe Empfänger wieder problemlos klappen - und der Mann mit der eckigen Brille kann seine Zigarettenpause beruhigt geniessen!

Eine ausführliche, weiterführende Beschreibung der Relay-Thematik für Exchange 2007 ist hier zu finden. 

Eine Bemerkung vom Security-Officer
Natürlich ist der Versand von E-Mails mit Authentifizerung aus Sicherheitsgründen der obigen Konfiguration vorzuziehen - die meisten Anwendungen und Netzwerk-Geräte bieten inzwischen entsprechende Konfigurationsmöglichkeiten, zum Beispiel per LDAP.

Eine Anfrage aus der Praxis: wie kann das Senden von E-Mails an spezifische Domains verhindert werden? Im konkreten Fall sollte verhindert werden, dass der Mail-to-SMS-Gateway des Providers von allen internen Benutzern verwendet, respektive "missbraucht" werden kann.

Der erste Gedanke: ein klarer Fall für die flexiblen Transport Rules welche in Exchange 2007 neu eingeführt wurden, kein Problem. Falsch gedacht: die Regeln erfordern Mailempfänger oder Verteilerlisten als Adressaten - sie erlauben nicht die Eingabe von Domain-Wildcards in der Form von @domain.com.

Die obligate Doku-, Technet- und Google-Suche brachte auch keine weiteren Erkenntnisse. Wir geben nicht auf - noch nicht! Und schauen uns die Transport Rules nochmals an; auch die Doku der Kommandozeile. Und dann blüht Hoffnung auf: der Message Header kann ausgewertet werden. Und der heisst in unserem Fall To. Mit dieser Condition testen wir:

Und erhalten anschliessend beim Testversand an diese Testdomain die entsprechende 5.7.1 Meldung:

Generierender Server: mail.in4out.ch

info@dummy-domain.com
#550 5.7.1 Sending e-mail to this domain is not allowed! #

Das rettet den Tag! Und hier noch die Erfüllung für die Freunde der Kommandozeile:

set-TransportRule -Name 'Prevent @dummy-domain.com' -Comments 'Prevent sending e-mail to @dummy-domain.com' -Conditions 'Microsoft.Exchange.MessagingPolicies.Rules.Tasks.HeaderContainsPredicate' -Actions 'Microsoft.Exchange.MessagingPolicies.Rules.Tasks.RejectMessageAction' -Exceptions  -Identity 'Test'