Exchange LAB 2026 und 2027 Teil 6: Mails von außen: Warum zwei Gateways in der DMZ stehen

Technisch könnte Exchange Mails aus dem Internet direkt annehmen. In der Praxis tun das die wenigsten Umgebungen, und meine Demo auch nicht. Vor den Exchange-Servern stehen zwei Mailgateways in einer eigenen DMZ. Sie sind die einzigen Systeme, die Mails von außen überhaupt sehen.

Warum ein Gateway davor?

Die Idee ist einfach: Alles, was aus dem Internet kommt, wird geprüft, bevor es das interne Netz erreicht. Spam, Viren und offensichtlich gefälschte Absender bleiben draußen. Exchange bekommt nur noch, was den Filter passiert hat.

Dazu kommt die Entkopplung. Die Gateways stehen in einem Netz, aus dem nur genau definierte Verbindungen nach innen erlaubt sind: Mails an Exchange zustellen, Namensauflösung und Uhrzeit von den Domain Controllern holen, sonst nichts. Wird ein Gateway kompromittiert, steht der Angreifer nicht automatisch im internen Netz.

Zwei statt einem

Ich setze das Open-Source-Produkt Proxmox Mail Gateway ein, als Verbund aus zwei Knoten. Konfiguriert wird nur auf einem, der andere übernimmt die Einstellungen automatisch. Beide stehen mit gleicher Priorität als Mailempfänger der Domäne im DNS.

Das sorgt für eine angenehme Eigenschaft von E-Mail: Fällt ein Gateway aus, versuchen sendende Server es einfach beim anderen. Dafür braucht es keinen Load Balancer und keine Zusatztechnik. In der Demo schalte ich ein Gateway ab und schicke dieselbe Testmail noch einmal. Sie kommt an.

Der Weg einer Mail

Eingehend nehmen die Gateways die Mail an, prüfen sie und stellen sie an einen internen Namen zu, hinter dem beide Exchange-Server stehen. Ist einer davon gerade nicht erreichbar, versucht das Gateway den anderen.

Ausgehend schicken die Exchange-Server ihre Mails an die Gateways, die sie dann ins Internet zustellen. Wichtig ist dabei die Absenderadresse: Empfänger prüfen heute sehr genau, ob ein Mailserver zur Domäne passt. Wie die Demo zu einer festen öffentlichen Adresse kommt, die genau das erfüllt, erkläre ich im nächsten Teil.

Wenn der Filter zu gut ist

Eine Lektion aus dem Aufbau: Mein Testszenario schickt eine Mail mit einem Absender aus einer fremden Domäne vom Demo-Client an das Gateway. Genau solche Mails sind aber verdächtig, und die Schutzfunktionen hätten sie verzögert oder abgewiesen. Der Testclient steht deshalb auf einer Ausnahmeliste. In echten Umgebungen gilt dasselbe in größer: Vor dem Scharfschalten eines Filters gehört geprüft, welche legitimen Absender er treffen würde.

Und der Spam?

Für die Vorführung gibt es eine allgemein bekannte Test-Zeichenkette namens GTUBE, die Spamfilter als Spam einstufen. Eine Mail damit landet zuverlässig in der Quarantäne, ohne dass ich echten Spam in die Demo holen muss.

Ein ehrlicher Hinweis zum Schluss: Proxmox stellt Updates ohne Abo über eine eigene Paketquelle bereit, ausdrücklich für Test und Nicht-Produktion. Für die Demo passt das, für den Betrieb sollte ein Abo eingeplant werden.