Exchange SMTP-Routing
Diese Seite beleuchtet das SMTP-Routing von Exchange 2007 und höher mit den vielen Receive Connectoren und möglichen Send-Connectoren etwas genauer.
Wer mit wem?
Ehe wir in die Details gehen, sollten Sie sich folgende einfachen Nachrichtenflüsse noch mal in Erinnerung rufen:
Absender |
Empfänger |
Beschreibung |
---|---|---|
Internet |
Exchange Empfänger |
Aus dem Internet werden Mails per MX-Record an den ersten Mailserver gesendet. Das ist fast immer ein Spamfilter in der Cloud oder OnPremises, der dann die Mails zu einem beliebigen Exchange Server sendet. Exchange muss dazu auf Port 25 eingehende Verbindungen per SMTP annehmen. Dafür ist der automatische installierte Receive-Connector mit dem Namen "Default Frontend <Servername>" zuständig. Das ist einfach und wie es danach weitergeht, ist Teil des nächten Kapitels. |
Exchange Postfach |
Exchange Empfänger |
Seit Exchange 2007 werden auch Mails zwischen Benutzern generell per SMTP "vermittelt", selbst wenn die Anwender ihr Postfach in der gleichen Datenbank haben. |
Exchange Postfach |
Internet |
Wenn eine Mail von einem authentifizierten Absender (Anmeldung oder Trusted-IP) nicht intern auflösbar ist oder eine Weiterleitung über einen MailUser/MailContact konfiguriert ist, dann muss Exchange die Mail versenden. In der Standardkonfiguration hat Exchange keinen Send-Connector, d.h. jeder Server kann selbst die Mail per MX-Record versenden. Ein Send-Connector erlaubt aber dem Administrator besser zu steuern, für welche Zieldomain und über welchen Quellserver die Nachrichten an welchen Zielserver geroutet werden. |
Internet |
Internet |
Diese Konfiguration möchten wir natürlich nicht zulassen. |
Wenn Sie die Tabelle sehen, dann würde im Grunde doch ein Receive-Connector pro Server reichen, der einfach nur Mails anonym aus dem Internet annimmt. Gerne mit davor geschaltetem Spamfilter, denn Exchange Server selbst haben nicht wirklich einen Spamfilter
Receive-Connectoren
Wenn Sie aber nach der Installation eines Exchange Servers nachschauen, dann finden sie gleich fünf Receive-Connectoren:
[PS] C:\>Get-ReceiveConnector -Server ex01 | fl identity,bindings,remoteipranges
Da bedarf es mal einer Erklärung, wozu diese Connectoren alle da sind. Zwei davon sind für die Kommunikation mit anderen
Identity | Bindings | Rolle | RemoteIP |
---|---|---|---|
EX01\Default Frontend EX01 |
{[::]:25, 0.0.0.0:25} |
Frontend |
Der Connector lauscht für alle IP-Adressen auf Port 25 und ist damit prädestiniert zur Annahme von Verbindungen aus dem Internet. Allerdings ist es kein vollwertiger SMTP-Server, sondern leitet die Verbindung als SMTP-Proxy zu einem verfügbaren Server auf den Port 2525 weiter. Es ist also ein intelligenter Loadbalancer, der den Status der Mailserver kennt und nur die erreichbaren Server nutzt. Der Port 25 ist der Standardport für die Übertragung von Mails zwischen Mailservern und wird von Endanwendern normal nicht verwendet. Im Internet wird hier keine Authentifizierung erzwungen. Ein SMTP AUTH ist aber nicht verboten und wird von Exchange auch genutzt. Mit "STARTTLS" kann auch eine verschlüsselte Verbindung gestartet werden. [PS] C:\>Get-ReceiveConnector "EX01\Default Frontend EX01" | fl AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer Banner : 220 EX01\Default Frontend EX01 Bindings : {[::]:25, 0.0.0.0:25} PermissionGroups : AnonymousUsers, ExchangeServers, ExchangeLegacyServers RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255} |
EX01\Default EX01 |
{0.0.0.0:2525, [::]:2525} |
Mailbox |
Der Port 2525 ist aber schon ungewöhnlich und wird offiziell nur zwischen und innerhalb von Exchange Servern verwendet. Eine Mail aus dem Internet über den Connector auf Port 25 wird zum Connector auf Port 2525 quasi als "Proxy" durch geleitet. [PS] C:\>Get-ReceiveConnector "EX01\Default EX01" | fl AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer Bindings : {0.0.0.0:2525, [::]:2525} PermissionGroups : ExchangeUsers, ExchangeServers, ExchangeLegacyServers RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255} Früher wurde 2525 als "alternativer Port" für SMTP angegeben und theoretisch könnte jeder User auch über diesen Weg Mails zustellen, denn auch "ExchangeUsers" ist in den PermissionGroups enthalten. |
EX01\Client Frontend EX01 |
{[::]:587, 0.0.0.0:587} |
Frontend |
Der Port 587 kennzeichnet den Connector wieder für den Empfang von Anwendern die ansonsten per POP3/IMAP4 auch ihre Mails abholen. Der Client muss sich per SMTPAUTH anmelden und das Konto Mitglied von "Exchange Users" sein. Der Zugang kann also nicht Anonym oder als "ExchangeServer$" genutzt werden. Der Connector fragt die Anmeldedaten ab und agiert dann als ReverseProxy zum "Backend" Server, der die Mailbox hat. Der Port 587/TCP ist der Standardport für Mailclients, die per SMTP mit Authentifizierung Mails an einen Mailserver übergeben. Mit "STARTTLS" kann auch eine verschlüsselte Verbindung gestartet werden. RFC2476
3.1. Submission Identification Port 587 is
reserved for email message submission as
specified in this document. Messages received on
this port are defined to be submissions. The
protocol used is ESMTP [SMTP-MTA, ESMTP], with
additional restrictions as specified here. |
EX01\Client Proxy EX01 |
{[::]:465, 0.0.0.0:465} |
Mailbox |
Nimmt Verbindungen des EX01\Client Frontend EX01 an. Früher wurde der Port 465/TLS für SMTPS-Submission reserviert, SMTP-Zustellung direkt per TLS ohne STARTTLS. Heute sollte der Port nicht mehr für SMTPS-Submisssion genutzt werden. Das stört hier aber nicht, da der Connector eigentlich nur intern verwendet wird. Er ist aber durchaus erreichbar und sogar mit Authentifizierung für "ExchangeUser" nutzbar. [PS] C:\>Get-ReceiveConnector "EX01\Client Proxy EX01" | fl AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer Banner : 220 EX01\Client Proxy EX01 Bindings : {[::]:465, 0.0.0.0:465} Fqdn : EX01.UCLABOR.DE Enabled : True PermissionGroups : ExchangeUsers, ExchangeServers RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255} TransportRole : HubTransport |
EX01\Outbound Proxy Frontend EX01 |
{[::]:717, 0.0.0.0:717} |
Frontend |
Auf den Connector verbindet sich die interne Transportrolle, um Mails zu versenden, wenn Sie im Send-Connector die Checkbox bei "Frontend" gemacht haben.
Normalerweise ist die Checkbox aus und dieser Receiveconector damit nicht in Verwendung. |
Unsichtbar: Mailbox delivery Receive connector |
{[::]:475, 0.0.0.0:475} |
Mailbox |
Eingehende Verbindungen von anderen Mailboxservern. |
Die RemoteIPRanges "{::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}" sind bei allen Receive Connectoren gleich.
Das bedeutet, dass neue Connectoren auf dem gleichen Port mit kleineren Netzwerkbereichen die Konfiguration für diese Remote-IP-Adressen überstimmen.
Es gibt aber Unterschiede bei der Authentifizierung. Die ganze Konstruktion basiert noch auf der Trennung der Exchange 2013 Serverrollen die aber nicht mehr getrennt installiert werden können. Das ändert nichts daran, dass Sie dennoch vorhanden sind. Bei den Exchange 2007 Rollen war dies noch anders.
- Default Receive connectors in the Front End Transport
service on Mailbox servers
https://learn.microsoft.com/en-us/exchange/mail-flow/connectors/receive-connectors?#default-receive-connectors-in-the-front-end-transport-service-on-mailbox-servers - Default Receive connectors in the Transport service on
Mailbox servers
https://learn.microsoft.com/en-us/exchange/mail-flow/connectors/receive-connectors?#default-receive-connectors-in-the-transport-service-on-mailbox-servers - Service Name and Transport Protocol Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt - Which SMTP port should I use? Understanding ports 25, 465 & 587
https://www.mailgun.com/blog/email/which-smtp-port-understanding-ports-25-465-587/ - Wie man den richtigen SMTP-Port wählt (Port 25, 587, 465 oder 2525)
https://kinsta.com/de/blog/smtp-port-waehlen/
Microsoft Übersicht
Auf der Exchange 2013 Hilfe-Seite hat Microsoft ein Blockdiagramm aufgezeigt, welches die verschiedenen Komponenten beim Mailrouting visualisiert. Leider wurde dabei aber nicht mit hinterlegt, wo die verschiedenen Konfigurationen der Receive Connectoren angewendet werden.
Quelle:
https://learn.microsoft.com/en-us/exchange/mail-flow/mail-flow?view=exchserver-2019
Das Bild gibt es auch noch mal in der Exchange 2019 Dokumentation. Dabei wurden nur die Blöcke etwas anders angeordnet aber die Abläufe sind identisch. Zudem sind einige Abläufe überschnitten, z.B. kommt eine externe Mail aus dem Internet oben Rechts auf dem SMTP-Receive-Baustein des Client Access Server an und wird nach dem Bild dann quer nach Links zum SMTP-Send-Modul geleitet, welches diese Mails dann zum "SMTP Receive-Baustein" des "Transport Service" auf dem Mailbox-Servers leitet. Über verschiedene Queues landet es dann beim "SMTP-Receive"-Baustein des Mailbox Transport Service. Nur die Connectoren sind hier natürlich nicht gesondert ausgewiesen.
- Mail flow and the transport pipeline
https://learn.microsoft.com/en-us/exchange/mail-flow/mail-flow?view=exchserver-2019 - Exchange 2013 Mailflow - Hat sich nichts zu 2016/2019
geändert.
https://learn.microsoft.com/en-us/exchange/mail-flow-exchange-2013-help
Ports und Prozesse
Also habe ich mir einen Standardserver nach der Installation einfach einmal die Ports und dazugehörigen Dienste angeschaut. Exchange installiert nämlich nicht nur den "MSExchangeIS" für die Datenbanken und einige IIS-Verzeichnisse sondern auch mehrere Dienste, die etwas mit dem Transport zu tun haben:
Bei einer Analyse der Dienste und genutzten Port erscheinen natürlich weitere Ports, die aber wohl nur zur internen Verwendung bestimmt sind und nicht weiter dokumentiert wurden.
Name | EXE | Ports | Beschreibung |
---|---|---|---|
Frontend Transport |
MSExchangeFrontendTransport.exe" |
25 |
Mit dem Dienst kommunizieren die Clients und andere Mailserver über Port 25 und 587. Der Port 717 ist ein "ausgehender Proxy", wenn die Transportrolle nicht selbst senden soll. |
Transport |
MSExchangeTransport.exe |
9700 |
Dieser Prozess ist zwar der Transport aber startet seinerseits den eigentlichen Worker "EdgeTrasnsport.exe". Das hat den Vorteil, dass bei einer "defekten" Mail der EdgTransport durchaus auch Abstürzen kann und dies so erkannt und repariert wird. |
- |
EdgeTransport.exe |
2525 |
Der Transport routet Mails im "Innern" von Exchange zwischen Servern und Postfächern und kann auch selbst Mails über Connectoren senden. |
Mailbox Transport Submission |
MSExchangeSubmission.exe |
9847 |
Dieser Dienst holt die Mails aus "Postausgang" und sendet sie per SMTP an den Transport. Er empfängt zumindest nichts per SMTP |
Mailbox Transport Delivery |
MSExchangeDelivery.exe" |
475 |
Eingehende Mails nimmt er an und legt Sie im Postfach ab. |
Sie sehen auf dem Bild die drei Ebenen des Frontend, der nur ein Stateless Proxy ist und zwischen den Clients und dem eigentlichen Transport vermittelt, dem Transport in der Mitte, der die Hauptarbeit (Routing, Transportagenten, Queuing, etc.) macht und unten die Zuarbeiter für den Informationsspeicher die Mails vom Transport annehmen und in die Datenbank legen oder ausgehende Mails aufgreifen und einem Transport übergeben.
Es gibt aber keine Kommunikation zwischen den Frontend auf verschiedenen Servern oder den Mailbox-Ebene. Nur der Transport in der Mitte kann mit anderen Transport-Diensten anderer Server oder den Mailbox-Diensten sprechen.
Durch diese klare Trennung der Zuständigkeiten kann Exchange sehr effektiv Mails auch über wenige Verbindungen übertragen. Insbesondere der Zugriff per RPC auf die Postfächer in den Datenbanken bleibt den Mailbox Transport Submission- und Mailbox Transport Delivery-Diensten auf dem gleichen Server überlassen.
- Mail flow and the transport pipeline
https://learn.microsoft.com/en-us/Exchange/mail-flow/mail-flow?view=exchserver-2019 - Exchange 2016 + 2019 Mail Flow mit TCP-Ports
https://granikos.eu/exchange-2016-2019-mail-flow-with-ports/
Name und Zertifikat
Mit diesem Wissen können wir nun auch viel bessere Aussagen zu Zertifikaten und Namen machen. Wenn Sie sich an die Microsoft Vorgaben halten und nur die Port 25 und 587 nutzen, dann sind es die "Frontend Receive Connectoren", die die eingehende Mals zum Exchange Server relevant und von SMTP-Clients genutzt und gesehen werden.
Die "internen Verbindungen" zwischen Exchange Servern (außer Edge) über die Ports 465, 475, 2525, 717, haben Sie nicht zu interessieren und können Sie sogar per Firewall weiter einschränken. Microsoft macht das ja auch mit seiner Cloud:
outlook.office.com 25 Erreichbar outlook.office.com 587 Erreichbar outlook.office.com 465 NICHT Erreichbar outlook.office.com 475 NICHT Erreichbar outlook.office.com 717 NICHT Erreichbar outlook.office.com 2525 NICHT erreichbar
Prüfen Sie dies noch mal mit ihrem OnPremises Server von einem Desktop Client
aus.
Ein Exchange Server muss eigentlich nur über die Ports 80/443/25/587 und
eventuell 995/993 erreichbar sein. Alle anderen Ports, insbesondere RPC,
(135,137-139), SMB (445) u.a. können und sollten aus dem Internet aber auch von
nicht vertrauenswürdigen Clients und Servern geblockt werden. Idealerweise sind
ihre Exchange Server in einem eigenen VLAN mit entsprechenden Filtern.
Wie ich aber schon auf Exchange 2007/2010 Receiveconnector geschrieben habe, können Sie mehrere Receive Connectoren konfiguriere, die auf die gleiche IP-Adresse:Port-Kombination lauschen, solange Sie sich dann bei der RemoteIP-Range unterscheiden und nicht überlappen. Das war bei Exchange 2003 und früher nicht möglich.
Jeder Connector kann dann einen eigenen DNS-Namen mit eigenen HELO-Namen und Receive Connector Zertifikat erhalten. Für die interne Kommunikation von Exchange wird immer FQDN des Server genutzt. Daher ist auf Port 2525 u.a. auch das selfsigned Zertifikat des Exchange Servers kein Problem.
Ein Exchange Server spricht eigentlich nie "von draußen" mit dem Frontend Receive Connector, es sei denn es ist eine ander Exchange Organisation.
Wenn Sie daher eigene Connectoren anlegen, dann ist es entweder ein Send Connector zum Versand oder "Frontend Receive Connectoren
Weitere Links
- Connectoren und Routing
- Exchange 2007/2010 Receiveconnector
- Receive Connector Zertifikate
- Exchange 2013 Serverrollen
- Exchange 2007 Rollen
- Exchange Routing mit GWART und LinkState
- Mail flow and the transport pipeline
https://learn.microsoft.com/en-us/exchange/mail-flow/mail-flow - Edge Transport servers with hybrid deployments
https://learn.microsoft.com/en-us/exchange/edge-transport-servers - Transport routing in Exchange hybrid deployments
https://learn.microsoft.com/en-us/exchange/transport-routing - Exchange 2016 + 2019 Mail Flow mit TCP-Ports
https://granikos.eu/exchange-2016-2019-mail-flow-with-ports/ - Exchange 2013: Nachrichtenfluss, Connectoren und
Warteschlangen
https://www.frankysweb.de/exchange-2013-nachrichtenfluss-connectoren-und-warteschlangen/ - Exchange 2013 Mail Flow (Part 3)
https://mail2013.blogspot.com/2015/03/exchange-2013-mail-flow-part-3.html - Exchange 2013 Mail routing
https://learn.microsoft.com/en-us/exchange/mail-routing-exchange-2013-help - Exchange 2019 Mail Flow and Transport Services
https://practical365.com/exchange-2019-mail-flow-and-transport-services/ - Which SMTP port should I use? Understanding ports 25, 465 & 587
https://www.mailgun.com/blog/email/which-smtp-port-understanding-ports-25-465-587/ - Wie man den richtigen SMTP-Port wählt (Port 25, 587, 465 oder 2525)
https://kinsta.com/de/blog/smtp-port-waehlen/