Es kommt oft vor, das manche Programme Status Meldungen oder Berichte per Mail verschicken können, aber keine Art der Authentifizierung bieten. Häufig kann man nur einen SMTP Server angeben, aber leider keine Kontoinformationen. Für solche Fälle kann man einen neuen Empfangsconnector erstellen, der auch Mails ohne vorherige Authentifizierung annimmt und weiterleitet. Diese Möglichkeit ist allerdings mit Vorsicht zu genießen und sollte auf IP-Adressen beschränkt werden, denn es ein Relay lässt sich leicht für SPAM missbrauchen.
Ein neuer Empfangsconnector kann entweder über die Mangement Console oder über die Management Shell erstellt werden, zunächst der Weg über die Konsole:
Unter der Serverkonfiguration / Hub Transport klickt man im Aktionsfeld auf „Neuer Empfangsconnector“
Im nächsten Dialog wird der Name des Connectors angegeben und der Typ der Verwendung festgelegt, in diesem Fall „Intern“, dann wird mit „Weiter“ bestätigt.
Im darauffolgenden Dialog ist es wichtig nur die Server oder Systeme anzugeben, die auch wirklich berechtigt sind, Mails ohne Authentifizierung zu senden. Auf keinen Fall sollte hier das komplette Subnetz oder ein zu großer Bereich angegeben werden. In diesem Fall wird nur die IP 192.168.1.123 berechtigt sein, diesen Connector zu nutzen. Mit einem Klick auf „Weiter“ und im nächsten Dialog auf „Neu“ wird der Connector angelegt.
Per Management Shell wird der Connector mit diesem Befehl angelegt:
new-ReceiveConnector -Name ‚Allow Interal Relay‘ -Usage ‚Internal‘ -RemoteIPRanges ‚192.168.1.123‘ -Server ‚EXSRV01‘
Jetzt legen wir in den Eigenschaften des neuen Connectors fest, das Anonyme Benutzer Mails an diesen Connector senden dürfen, also Häkchen bei „Anonyme Benutzer“ setzen:
Oder wieder per Powershell:
Set-ReceiveConnector -PermissionGroups ‚AnonymousUsers‘ -Identity ‚EXSRV01\Allow Interal Relay‘
Zum Schluss der wichtigste Schritt, wir haben zwar erlaubt das die IP 192.168.1.123 ohne Angabe von Benutzer und Passwort auf den Connector zugreifen darf, aber nicht das auch über diesen Connector Mails verschickt werden dürfen, um dies zu ändern müssen wir die Powershell bemühen, da es die entsprechende Einstellung in der Console nicht gibt:
Get-ReceiveConnector „Allow Internal Relay“ | Add-ADPermission -User „NT-Autorität\Anonymous-Anmeldung“ -ExtendedRights „Ms-Exch-SMTP-Accept-Any-Recipient“
Hier gibt es einen kleinen Stolperstein:
- Bei deutschen Servern heißt es „NT-Autorität\Anonymous-Anmeldung“
- Bei englischen Servern heißt es „NT AUTHORITY\ANONYMOUS LOGON“
Die Ausgabe des Befehls sollte so aussehen:
Ab jetzt sollte der Rechner mit der IP 192.168.1.123 in der Lage sein, über diesen Connector Mails zu verschicken.
Möchte man das Recht wieder entziehen, geht das über diesen Befehl:
Get-ReceiveConnector „Allow Internal Relay“ | Remove-ADPermission -User „NT-Autorität\Anonymous-Anmeldung“ -ExtendedRights „Ms-Exch-SMTP-Accept-Any-Recipient“
Bei den ersten zwei Powershell Befehlen in der Anleitung steht „Allow Interal Relay“ beim letzten steht es korrekt „Allow Internal Relay“. Also wem es nicht auffällt bei Internal fehlt das „n“.
Hallo und vielen Dank für diesen Beitrag. Vor einiger Zeit habe ich mich an die Anleitung gehalten und es hat wunderbar funktioniert. Nun läuft der Connector nicht mehr, obwohl weder Einstellungen noch IP-Adressen geändert wurden. Am Kyocera TASKalfa 3050ci kommt immer die Fehlermeldung „Ziel ist nicht festgelegt. (0x1104)“, welche soweit nicht valide ist, als das auch die Mailadressen unverändert sind (die Meldung kommt sogar beim senden an interne Adressen).
Beste Grüße
Michael
Die SMTP Logs können dort sicher weiterhelfen:
C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs
Gruß, Frank
Hallo Frank,
ich habe es nochmals getestet und vom Gerät eine Mail versenden lassen (was nicht geklappt hat und wieder mit der Meldung „Ziel ist nicht festgelegt. (0x1104)“ fehlschlug).
Leider gibt es in den Log-Dateien und auch in der Windows Ereignisanzeige kein Ereignis, welches die passende Zeit oder einen passenden Fehler (Warnung, etc.) hätte. Vielleicht schreibt er die Log aber auch erst später auf die Platte, so das ich es jetzt noch gar nicht finden kann?
Schöne Grüße
Michael
Die Logs werden mit Zeitverzögerung und mit UTC Timestamps geschrieben. Hast du mal die Verbindung mittels Telnet getestet?
Vielen Dank für das Posten. Hat mir viel Mühe gespart ! Warum das aber nicht über die Mgmt-Console einzustellen geht, weiss wohl nur MS.
Sch… sorry das war für den Exchange-Reporter gedacht und nicht für hier, bitte einfach den Comment löschen oder verschieben. Thx.
Super Bericht, nach dem zweiten Anlauf hat auch die Installation geklappt :-)
Folgender Verbesserungsvorschlag:
Sendelimit von Postfächern:
Du läufst über die „Globale Einstellung“ der Datenbank, wenn bei einem User, aber eine Individuelle Einstellung getroffen wurde, wird das hier nicht berücksichtigt und wie in meinem Fall falsch ausgegeben.
Schöne Grüße