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.

Das könnte Dich auch interessieren …

Abonnieren
Benachrichtige mich bei
guest
3 Comments
Älteste
Neuste Meist bewertet
Inline Feedbacks
View all comments
Peter
Peter
12 Tage zuvor

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 »

Peter
Peter
Reply to  Kevin
8 Tage zuvor

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 »

3
0
Hinterlass' doch deine Meinung zu diesem Artikelx
()
x
Datenschutz
Ich, Kevin Schweiger (Wohnort: Österreich), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht mir aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl:
Datenschutz
Ich, Kevin Schweiger (Wohnort: Österreich), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht mir aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl: