Huhu,
Ich rate bei solchen Szenarien dazu, für die reinen Proxy-/Relayserver kein UCS sondern ein einfaches Debian oder Ubuntu zu verwenden. Hat mehrere Gründe:
Sicherheit. Eine DMZ betreibt man, um Angriffsfläche zu minimieren. Ein UCS-System ist aufgrund der vielen Komponenten, die in ihm laufen, eine ganze Stufe komplexer, als ein reines Debian- oder Ubuntu-System. Hinzu kommt, dass ein UCS-System auf verschiedenen Wegen (ssh, Directory Listener, falls Samba installiert ist dann auch damit…) mit seinem DC Master kommunizieren muss. Sprich für ein UCS-System in der DMZ müssen deutlich mehr Regeln für die Firewall erstellt werden, die zwischen der DMZ und dem Intranet vermittelt.
Komplexität ist der natürliche Feind von Sicherheit.
Die Komplexität kann es wert sein, wenn es klare Vorteile gibt, die diese rechtfertigen. Bei UCS-Systemen ist der primäre Vorteil, dass man die zentrale Benutzerverwaltung hat und dass man einfach Apps auf den Systemen installieren kann. Beides ist für ein Reverse-Proxy- & SMTP-Relaysystem aber komplett irrelevant. Benötigt man die Benutzerinformationen, so kann man einfach direkte LDAP-Suche gegen den DC Master implementieren, was firewalltechnisch viel einfacher zu handlen ist. Und für SMTP-Relay benötigt man diese Informationen noch nicht einmal (mehr dazu unten).
Weiterhin: Konfigurationskomplexität. Bei einem Reverse-Proxy-/SMTP-Relay-System möchte man ausschließlich diese Funktionalität haben, nicht aber z.B. die Univention Management Console. Man muss also bei einem UCS in der DMZ erst mal gegen die Standardkonfiguration ankämpfen, um mitgelieferte Sachen auszuschalten. Weiterhin muss man dagegen ankämpfen, dass UCS die Konfigurationen der Dienste über Templates managet. Will man bei Postfix aber plötzlich Sachen anpassen, die die Templates so nicht vorsehen, so muss man die Templates selber anpassen, was man wiederum bei Updates beachten muss.
Also noch mehr Komplexität, die man sich mit einem reinen Debian/Ubuntu erspart.
Trivial. Man muss nur Postfix bekannt geben, welche Domänen er weiterleiten soll (über Parameter relay_domains), wohin er diese schicken soll (über einen Eintrag in einer transport_maps), und dass er unbekannte Empfänger ablehnt (siehe Address Verification, Option reject_unverified_recipient für Parameter smtpd_recipient_restrictions).
Was Postfix dann macht, ist:
- Einliefernder Client meldet sich, sagt, von wem und an wen die Mail gehen soll.
- Postfix hält die Verbindung und baut im Hintergrund eine Verbindung zum internen Mailserver auf.
- Postfix sagt dem internen Mailserver das, was er in Schritt 1 erfahren hat.
- Interner Mailserver sagt, ob er den Empfänger akzeptiert oder nicht.
- Postfix bedankt sich, baut die Verbindung zum internen Mailserver ab.
- Anhand des Resultats aus 4. nimmt Postfix die Mail vom externen Client an oder lehnt sie ab.
Postfix in der DMZ braucht nicht mal Zugriff aufs LDAP.
Man kann als Letztes noch dafür sorgen, dass das DMZ-Postfix Mails aus dem LAN ebenfalls akzeptiert und z.B. nach extern weiterleitet. Das geht trivial über den Parameter mynetworks.
Bitte nicht. Das bringt kein Mehr an Sicherheit und statt dessen einen Haufen unschöner Mailprobleme.
Variante 1: man nimmt ein Catch-All-Postfach, das man per POP3 abholt. Hier ist ein Problem, dass BCCs nicht als reguläre Mail-Header auftauchen, und der abholende Client (fetchmail) daher diese Information des ursprünglichen Empfängers nicht mehr zur Verfügung hat. Viele Mail-Provider schreiben daher glücklicherweise einen zusätzlichen Header wie z.B. X-Orignal-To oder X-Envelope-To mit in die Mail, der den ursprünglichen Empfänger enthält. Man kann dann fetchmail dazu konfigurieren, diesen Header zu nutzen, aber das ist in der initialen Einrichtung halt alles andere als trivial und eine häufige Quelle für Mailverlust oder Mailverdoppelung oder ungewollten Bounces, bis man es ordentlich hinbekommen hat.
Problem Nummer 2 sind unbekannte Empfänger. Hat man ein Catch-All-Postfach, so wird providerseitig nicht überprüft, ob es den Empfänger in der Domäne wirklich gibt. fetchmail prüft das auch nicht, sondern leitet die Mail nur an den lokalen Postfix weiter. Der merkt erst: oh, den Empfänger gibt’s nicht, also bounce ich die Mail. Und schon hat man ein anderes Problem: man versendet plötzlich Bounces an die vermeintlichen Absender. Vermeintlich deshalb, weil Absenderadressen ja beliebig gefälscht sein können. Und genau diese Technik (gefälschter Absender, bewusst nicht existierender Empfänger, und Zielmailserver schickt dann eine Bounce an den gefälschten Absender) wird oftmals von Spammern benutzt (heißt »backscatter«), was wiederum die Gefahr erhöht, dass der eigene Mailserver auf Spam-Blacklisten landet.
Kurz: bei Catch-All-Postfächern wird die Situation »Empfänger existiert nicht« plötzlich zu meinem Problem, und nicht zum Problem des Absenders.
Möchte man providerseitig beides nun umgehen, so kann man auf ein Catch-All-Postfach verzichten und statt dessen für jeden Empfänger ein eigenes Postfach einrichten, dazu auch für jedes Postfach einen Eintrag in der fetchmail-Konfiguration vornehmen, und dann sieht man seine Benutzerliste mit 40 Leuten und geht erst mal einen trinken. Auch keine Lösung.
Letzter offensichtlicher Nachteil von Abholung vs. direkter Zustellung: Verzögerung. Ja, Mail ist ein asynchrones Medium, aber durch die Intervalle, in denen Mails abgeholt werden, kommt noch mal mehr Verzögerung hinzu. Der Kunde ist gerade am Telefon und sagt »ich schicke Ihnen das gerade rüber«, und Sie sagen dann… »ja cool, wir warten jetzt zehn Minuten, bis unsere Mails wieder abgeholt wurden«?
Sag »Nein!« zu Abholung per POP3/IMAP.
Das ist das Szenario, das ich oben beschrieben habe; der reguläre Callout-Verifikations-Mechanismus von Postfix.
All das ist kein offenes Relay. Selbst in der Standardkonfiguration ist Postfix kein offenes Relay. Man muss Postfix schon explizit über so etwas wie permit in smtpd_…restrictions dazu konfigurieren, ein offenes Relay zu sein.
Und wenn man während der Implementation Zweifel hat, dann einfach mit dem Open Relay Test von MXToolBox prüfen.
Gruß
mosu
