Some applications or devices require an anonymous relay to be able to send mails. However, a distinction must be made here between internal relay and external relay. The internal relay, i.e. the anonymous sending of mails to the domains accepted by Exchange, works out-of-the-box:
However, external relay, i.e. sending mails to external users without authentication, is not possible:
The anonymous external relay should also always be viewed with caution, as Exchange can quickly be misused as a SPAM sling if configured incorrectly. It is therefore important to restrict the connectors accordingly and only allow certain IPs, but not entire subnets or even worse "everyone".
However, as already mentioned at the beginning, there are applications such as ticket systems or CRMs that need to send mails to external recipients but cannot authenticate themselves. To allow these applications or devices to send mail, a new receive connector can be created:
The settings in the next dialog can be applied
In the "Remote network settings" settings, all IP addresses for which the anonymous external relay is to be permitted must now be added:
It only makes sense to specify individual IPs here that really require this functionality; entire subnets should not be specified here unless absolutely necessary (server network, management network or similar).
Note: Exchange 2016 CU2 currently contains a bug, it is not possible to create a new receive connector on the same IP via EAC. However, a corresponding connector can still be created via Exchange Shell. The steps described above create the connector:
New-Receiveconnector -Server FWEX2016 -Name "Relay" -RemoteIPRange ("172.16.100.102") -TransportRole "FrontendTransport" -Bindings ("0.0.0.0:25") -Usage "Custom"
After clicking on "Finish", the connector is created:
In order for the connector to accept anonymous mails, the security settings must be changed accordingly:
However, in order to be able to send mails to external recipients, the corresponding corrections for the new connector still need to be assigned. The quickest way to do this is via the Exchange Management Shell:
Get-ReceiveConnector "Anonymous Relay FWEX2016" | Add-ADPermission -User "NT-Authority\Anonymous-Login" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"
There is a small stumbling block with the second command:
- For German servers it is called "NT-Authority\Anonymous login"
- For English servers it is called "NT AUTHORITY\ANONYMOUS LOGON"
The connector is now active and accepts mails anonymously from the correspondingly activated IPs (see remote network settings). For systems that produce a high volume of mail or send very large mails, additional parameters may need to be changed:
Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -TarpitInterval 00:00:00 Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -ConnectionTimeout 00:30:00 Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -ConnectionInactivityTimeout 00:20:00 Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -MaxAcknowledgementDelay 00:00:00 Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -MaxInboundConnection 10000 Set-ReceiveConnector -identity "Anonymous Relay FWEX2016" -MaxInboundConnectionPerSource unlimited
And last but not least Important note:
If you find yourself in the following environment, you must never enter the internal IP address of the router in the remote network settings of the connector:
MX-Record points to WAN IP of the router, router forwarded port 25 (SMTP) via NAT to the Exchange Server. In this case, the Exchange server only sees the internal router IP as the source IP. If the internal router IP is now added to the connector, this is an open relay and therefore very quickly a SPAM sling.
Hallo Frank,
ich habe auf 2 Exchange 2016 ein unterschiedliches verhalten:
Auf einem Server funktioniert:
Send-MailMessage -To me@my-domain.de -From anmeldung@my-domain.de -Subject „Test“ -SmtpServer $env:Computername
Auf dem zweiten funktioniert der Aufruf nicht:
Send-MailMessage -To me@my-domain.de -From anmeldung@my-domain.de -Subject „Test“ -SmtpServer $env:Computername
Send-MailMessage : Dienst nicht verfügbar. Übertragungskanal wird geschlossen. Die Serverantwort war: 4.3.2 Service not available
Es funktioniert aber:
Send-MailMessage -To me@my-domain.de -From anmeldung@my-domain.de -Subject „Test“ -SmtpServer localhost
Hast du eine Erklärung für mich?
Danke
Hi Frank,
ich habe eine interne Verteilergruppe aufm EX2019.
Geräte schicken über den anonymous Relay connector Mails dorthin.
Ich will diese Gruppe aber mittels „Authentifizierung“ nur auf interne Absender einschränken.
Dann haut mir aber der Versand nicht mehr hin, weil der Verteiler quasi keinen anonymen User annimmt.
Kann man sowas irgendwie technisch abbilden?
Hi Resal,
schon ein paar Tage her, aber Du kannst die Berechtigung unter Zustellungsverwaltung auf „Absender innerhalb und außerhalb meiner Organisation“ setzen und zusätzlich das Ganze explizit einschränken durch Angabe von bestimmten Personen (letztes Kästchen).
Beste Grüße
Daniel
Hallo Franky,
wie kann ich im Emfangsconnector IP Adressbereiche eingeben?
Also wie bei Ex2010…
diese zum Beispiel:
192.168.0.160-192.168.0.254
192.168.3.150-192.168.3.254
172.16.10.0/24
192.168.25.150-192.168.25.254
Danke für deine Antwort.
…und Danke für deine Arbeit und Zeit.
Funzt hervorragend, vielen Dank!
Gelten die gleichen Einstellungen auch für einen 2019ner. Ich habe diese übernommen, allerdings ohne Erfolg. Die Meldungen bleiben.
Hallo Frank,
nach dem ich deine Anleitung angewendet habe, keine Frage funktioniert wie immer :-) empfängt mein Exchange keine Email von Außen / Firewall Sophos.
Wo habe ich Fehler gemacht?
Benötigt das anonyme Relay weiterhin ein angelegtes Postfach oder einen angelegten Kontakt, oder ist das eine Wildcard-Freigabe für alle möglichen Mailadressen der Domain, nur eben begrenzt auf eine IP die SMTP anfragt?
Funtioniert es für itern genau so? Wenn man nur Bestimmten Server(IP’s) an intern über Port 25 Senden erlauben möchte, und nicht automatisch allen?
Hallo Frank,
Deine Artikel sind immer wieder schön zu lesen. :-) Dank dafür.
Was mich jedoch seit einer Weile beschäftigt, ist die Frage inwiefern man „internal Relays“ überhaupt einsetzen soll.
Ich persönlich vertrete die Auffassung, dass ein „Sender“ sich ggü. dem Exchange Server authentifizieren muss.
Mich würde Deine Meinung zu folgendem Konstrukt interessieren:
Auth. Benutzer = Standard Mailbox
Auth. System/Software = Funktions Mailbox
Non Auth System/Software -> interne Empfänger = InternalRelay
Non Auth System/Software -> interne + externe Empfänger die bekannt sind = Exchange Contacts
Non Auth System/Software -> interne + externe Empfänger die nicht bekannt sind= External Relay
Vorteil wäre ein Maximum an Sicherheit, da so das Versenden von Emails über nicht authentifizierte Sender auf ein Minimum reduziert wird.
Nachteil bei den Funktions Postfächern ist, dass jemand regelmäßig die Postfächer leeren muss um ein überlaufen zu verhindern. Anderenfalls wäre eine PremiumCal fällig und man müsste das über Richtlinien regeln.
Wie siehst du das oder hast du hier eine noch tollere Lösung in petto? :-)
Grüße
Hallo Frank,
das anonmye Relay funktioniert wunderbar! Danke für deine Anleitung.
Nun hätte ich hierzu noch eine Frage, kann man das Relay auch auf einzelne Benutzer beschränken, so dass nur dieser Benutzer über den Connector senden kann?
Vielen Dank und viele Grüße!
Hi Frank,
erst einmal ein großes Lob an dich. Mich begleitet/hilft deine Webseite schon seit meiner Ausbildung :-) Nun habe ich deine oben stehende Anleitung befolgt, jedoch bekomme ich beim Versenden der Test Nachricht via Shell folgende Fehlermeldung
Send-MailMessage : Dienst nicht verfügbar. Übertragungskanal wird geschlossen. Die Serverantwort war: 4.3.2 Service
not available
In Zeile:1 Zeichen:1
+ Send-MailMessage -SmtpServer localhost -From XXXXXXx.l …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpExcept
ion
+ FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMes
Kannst du etwas mit dieser Meldung anfangen?
Beste Grüße
Gregor
Servus Frank,
habe das selbe Problem wie Frank im Post davor.
Auf dem Server gehen die Mails per POP3 Konnektor ein, dieser ist auf dem Exchange selber installiert und der Empfangskonnektor hört auf seine eigene Adresse. Das funktioniert soweit.
Ich habe nun Drucker die direkt nach außen aber über den Exchange gehen sollen. Wen ich nun den vorhandenen Konnektor ändere und auf Anonymes Relaying und die Adressen der Drucker hinzufüge habe ich die Befürchtung das damit auch die per POP3 kommenden Mails die Erlaubnis dazu hätten.
Wie schon erwähnt kann kein neuer Konnektor erstellt werden mit der gleichen Port Nr. und als als Front-End konfiguriert sein.
Ich könnte einen neuen Konnektor erstellen als Hub mit einer anderen Port Nr. (ich kann das an den Druckern ebenfalls ändern). Aber es ist ja nur ein Hub-Transport.
Danke für deine Mühe
Chris
Hi Chris, Hi Frank,
bei Exchange 2016 CU2 kann man leider keinen Relay Connector über die GUI anlegen. Der Hintergrund ist einfach: Es ist ein Bug. Der Weg über die Shell funktioniert allerdings weiterhin. Das Anlegen funktioniert über folgenden Befehl:
New-Receiveconnector -server EX1 -Name „Relay“ -RemoteIPRange („192.168.100.99“) -TransportRole „FrontendTransport“ -Bindings („0.0.0.0:25“) -usage „Custom“
Der Rest (Berechtigungen, etc) bleibt gleich.
Gruß, Frank
PS: Habe den Artikel aktualisiert.
Hallo Frank,
besten Dank für Deine auführlichen Anleitungen.
Eine Frage zum neuen Empfangsconnector:
– es besteht doch bereits ein Connector auf Port 25 mit der Bindung an die gleiche Netzwerkkarte
Ich kann daher keinen Connector zusätzlich einrichten. Ausserdem kann ich die Rolle nicht auswählen (FrontEnd-Transport). Bei mir ist ‚HubTransport‘ vorbelegt und ausgegraut.
(Exchange 2016 mit CU2)
Danke und Gruß
Frank
Wäre schön, wenn Microsoft das „alles um jeden Preis übersetzen“-Prinzip mal fallen lassen würde. :)
Kleine Korrektur: bei einem normalen Port Forwarding wird die Source-IP nicht geändert, der Exchange sieht also, woher die Verbindung kommt. (Ausser auf der Firewall läuft ein SMTP-Proxy, dann muss man tatsächlich aufpassen.)
Hi Manuel,
korrekt, ich hätte das präziser ausdrücken sollen. Danke für den Hinweis.
Gruss, Frank