Exchange: Authentifiziertes SMTP-Relay
Einen Exchange als authentifiziertes SMTP-Relay zu verwenden, kann verschiedene Gründe haben. Im Normalfall nutzt man dazu die Funktion des Anonymous-SMTP-Relays und schaltet dieses für eine fixe IP innerhalb des Netzwerks frei. Was macht man allerdings, wenn sich der Client in einem anderen Netz befindet oder gar über eine wechselnde Public-IP angesprochen wird? In diesem Fall kann keine Adresse freigegeben werden und man muss auf ein authentifiziertes SMTP-Relay zurückgreifen.
Unterschied zwischen Anonymous- und Authenticated SMTP-Relay
Beim Anonymous SMTP-Relay wird, wie es der Name bereits vermuten lässt, eine anonyme Verbindung hergestellt. Das bedeutet, dass sich das jeweilige Device nicht beim Exchange authentifizieren und somit auch keine Login-Credentials vorweisen muss. Doch wie stellt man dabei sicher, dass das Relay trotzdem nur von ausgewählte Personen verwendet werden dann? Durch Einschränkung der IPs – nur gewisse IPs und Netze sind dazu berechtigt, mit dem Receive-Connector zu interagieren. Es kann jedoch auch vorkommen, dass man ein Device nicht auf eine IP festnageln kann. Das kommt beispielsweise vor, wenn sich der Client in einem völlig anderen Netz, hinter einer sich wechselnden Public-IP verbirgt. Dann bleibt nur der Weg des authentifizierten Relays.
Konfigurieren des Receive-Connectors
Jede Nachricht, welche von unserem Client an den Exchange gesendet wird, muss zuerst an einem entsprechenden Receive-Connector validiert werden. Dabei wird immer jener Konnektor ausgewählt, welcher von den Bindings am ehesten zum Benutzer passt. Dazu ein kleines Beispiel:
Mein Computer besitzt die IP-Adresse 192.168.1.10 und ich möchte über meinen Exchange -Server eine E-Mail versenden. Der Exchange besitzt 2 Empfangskonnektoren (192.168.1.0/24 „A“ und 192.168.0.0/16 „B“). Beide könnten theoretisch für mich verantwortlich sein, da meine IP in beiden Netzen vorhanden wäre. Da aber, wie bereits oben vermerkt, immer jener Konnektor verwendet wird, welcher meine IP am nächsten beschreibt, werden meine Mails vom Konnektor „A“ empfangen und weiterverarbeitet.
Genug Theorie, zurück zum eigentlichen Thema. Die Standard Receive-Connectors sehen wie folgt aus:
[PS] C:\Windows\system32>Get-ReceiveConnector
Identity Bindings Enabled
-------- -------- -------
SW-EX01\Default SW-EX01 {0.0.0.0:2525, [::]:2525} True
SW-EX01\Client Proxy SW-EX01 {[::]:465, 0.0.0.0:465} True
SW-EX01\Default Frontend SW-EX01 {[::]:25, 0.0.0.0:25} True
SW-EX01\Outbound Proxy Frontend SW-EX01 {[::]:717, 0.0.0.0:717} True
SW-EX01\Client Frontend SW-EX01 {[::]:587, 0.0.0.0:587} True
Der SW-EX01\Client FrontendSW-EX01 übernimmt dabei die ehrenvolle Aufgabe, sich mit den Clients auszutauschen. Damit wir diesen Konnektor als SMTP-Relay verwenden können, müssen wir sicherstellen, dass er einen korrekten FQDN (full qualified domain name) verwendet. Grundlegend wählt man hier die gleiche Subdomain, welche man auch für den MX-Record verwendet hat. Um den FQDN per Exchange Managementshell zu setzen, kann folgender Befehl verwendet werden:
[PS] C:\Windows\system32>Set-ReceiveConnector "SW-EX01\Client Frontend SW-EX01" -Fqdn mail.schweigers.at
Auf der nächsten Seite befassen wir uns mit dem Zuweisen eines SSL-Zertifikates, sowie den finalen Einstellungen.
Hallo, ich bin auf Ihre Seite gestossen, da bei uns eine Software via SMTP e-Mails über den Exchange 2016 verschicken soll. Ich bekomme es aber leider nicht hin. Zertifikate, alles da. Ich habe folgende Kommandos ausgeführt (ohne Fehler – xxx steht für die Domain, da man die ja nicht unbedingt öffentlich zeigen muss). $cert = Get-ExchangeCertificate -Thumbprint xxxxx $tlscertificatename = „<i>$($cert.Issuer)<s>$($cert.Subject)“ Set-ReceiveConnector „SRV2-EXCH\Client Frontend SRV2-EXCH“ -Fqdn remote.xxx.de -TlsCertificateName $tlscertificatenam Leider zeigt OWA nur an, dass keine SMTP-Einstellung verfügbar ist. Wenn ich über die Software einen Sendetest mache kommt die Meldung: 5.7.60 SMTP; Client does not have permissions to send as… Weiterlesen »
Hallo, dass die SMTP Einstellungen im OWA nicht angezeigt werden, ist nicht weiter schlimm und schränkt die Funktionalität vom Connector nicht ein. Die Fehlermeldung weist darauf hin, dass sich der Client durchaus mit den angegebenen Anmeldedaten am Exchange authentifizieren kann, allerdings scheint es so, als würde das Exchange Postfach die angegebene SMTP Adresse nicht besitzen. Sprich: Client möchte mit der test-smtp@test.com versendet. Das Exchange Postfach besitzt als Alias Adresse allerdings nur die test@test.com und somit wäre der Benutzer nicht dazu berechtigt, E-Mails mit der Absenderadresse test-smtp.test.com zu versenden. Man müsste hier die jeweilige SMTP Adresse am Client einstellen, dann sollte… Weiterlesen »
Hallo Kevin, vielen Dank für die Rückmeldung. Ich habe nun noch alles Mögliche ausprobiert und mich am Rechner auch mal mit test@Domänenenname.local oder mit test@Domain.de angemeldet (habe dafür im AD die UPN-Suffix ergänzt). Der User „test“ ist auch nur lokaler Admin und Domänen-Benutzer. Im Exchange gibt es für den User die Adresse „test@Domänenenname.local“ und als Standardadresse „test@Domain.de“. OWA funktioniert einwandfrei und ich probiere den Versand zum Test über Thunderbird hinzubekommen. Egal wie ich mich anmelde und als SMTP-Server „remote@Domain.de“ eingebe kommt die Meldung: „5.7.60 SMTP; Client does not have permissions to send as this sender“. Wenn ich als SMTP-Server „srv2-exch.Domäne.local“… Weiterlesen »