Vielen Druckern und Legacy-Anwendungen fehlt die Möglichkeit, E-Mails über Submission mit Authentifizierung über einen Standardmailserver zu versenden. Stattdessen agiert der Drucker selbst als Versender, ohne DKIM-Signatur und oftmals ohne SPF endet dies bestenfalls im Spam. Um diese Mails entsprechend der Anforderungen gängiger moderner Mailserver zu versenden, ist ein Gateway erforderlich, welches die Mail signiert und dessen IPs zum Versand unter der Absenderdomäne autorisiert sind.
Eine kostenlose, quelloffene Lösung für dieses Problem stellt das Proxmox Mail Gateway dar. Entwickelt als Spam- und Virenfilter für ein- und ausgehenden Mailverkehr ist der Funktionsumfang der Software größer als für diese Aufgabe nötig, dank der umfassenden WebGUI ist die Einrichtung jedoch schnell erledigt.
Nach der Installation entsprechend der offiziellen Dokumentation mit einem gültigen FQDN ist für die kostenfreie Verwendung das Enterprise-Repository zu entfernen und durch das no-subscription Repository zu ersetzen. Diese Einstellung ist unter Administration –> Repositories zu finden. Danach wird das System unter Updates auf den aktuellen Stand gebracht.
DNS und Zertifikate
Für den verschlüsselten Mailversand ist ein gültiges Zertifikat erforderlich, welches kostenfrei mit automatischer Erneuerung über Let’s Encrypt erhältlich ist. Dafür sind DNS-Einträge und gegebenenfalls Firewalleinstellungen erforderlich.
Der konfigurierte Hostname muss im public DNS mit den IPs des Servers konfiguriert werden, ein A-Record für die IPv4 des NAT-Geräts oder eigene öffentliche IPv4 des PMG sowie ein AAAA-Record für die IPv6 des Servers. Die meisten empfangenden Mailserver setzen zudem einen entsprechenden Reverse DNS Eintrag voraus, dieser kann idR. im Portal des Internetproviders oder Hostingproviders angelegt werden. Hier ist jeweils ein PTR-Record für die IPv4 und IPv6 erforderlich, welcher zum konfigurierten Hostnamen auflöst.
pmg.local.bllmnn.de. 3600 IN AAAA 2001:db8::755.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 3600 IN PTR pmg.local.bllmnn.de.Um die IPs des Servers für den Versand unter der gewünschten Domäne zu autorisieren muss SPF (Sender Policy Framework) durch einen TXT-Record konfiguriert werden bzw. der bestehende erweitert werden. Beispiel:
local.bllmnn.de. 3600 IN TXT "v=spf1 ip4:203.0.113.75 ip6:2001:db8::75 -all"Um die versendeten Mails kryptografisch zu signieren, ist ein weiterer TXT-Record erforderlich. Um den Inhalt dieses Records in Erfahrung zu bringen, muss im PMG unter Configuration –> Mail Proxy –> DKIM die gewünschte Absenderdomain als Sign Domain hinzugefügt werden. Daraufhin kann DKIM Signing aktiviert, ein individueller Selektor (Beispiel: pmg) angegeben und die Signatur für alle ausgehenden Mails aktiviert werden.
Unter „View DNS Record“ kann der im DNS zu veröffentlichende Schlüssel ausgelesen werden. Je nach DNS-Server muss der in Klammern gefasste Inhalt für die Eintragung zu einem String zusammengefasst werden, dazu werden unterbrechende Anführungszeichen und Leerzeichen entfernt. Der DNS-Server kümmert sich bei der Auslieferung des Records um die richtige Teilung. Beispiel für den veröffentlichten Record:
pmg._domainkey.local.bllmnn.de. 3600 IN TXT "v=DKIM1;h=sha256;k=rsa;p=MII[...]AB"Um nun mit der HTTP-Challenge ein Zertifikat über Let’s Encrypt zu erhalten, muss in der Firewall Port 80/tcp zu der IP des PMG-Servers freigegeben werden. Anschließend kann unter Configuration –> Certificates –> ACME Accounts/Challenges ein Let’s Encrypt Account angelegt werden. Ist dies erfolgt, wird unter Certificates –> ACME –> Add die Zertifikatsanforderung und -verwendung konfiguriert: Challenge Type HTTP, Domain FQDN des PMG-Servers, Usage SMTP und optional API für das Webinterface. Mit „Order Certificates Now“ wird das Zertifikat angefordert und bei korrekter Konfiguration ausgestellt. Die Erneuerung erfolgt von nun an automatisch.
Mail Proxy
Für die Konfiguration als ausgehendes Mailgateway sind die Tabs unter Configuration –> Mail Proxy durchzugehen:
Unter Relay Domains werden die Domains hinzugefügt, welche der PMG-Server bedienen soll.
Unter Ports können die internen und externen Ports getauscht werden – einige Drucker erwarten den Mailserver auf Port 25 und erlauben keine anderen Angaben. Soll PMG auch für eingehende Mails verwendet werden, kann Port Forwarding zur Umleitung von auf Port 25 über WAN eingehender Mails zum intern konfigurierten Port verwendet werden – auch für IPv6.
Unter Networks werden die zur Nutzung des Gateways berechtigten IPs bzw. Netze konfiguriert, das Subnetz des PMG ist standardmäßig zugelassen und hier nicht gelistet.
Unter TLS kann drei mal Ja gewählt werden, DKIM wurde zuvor schon konfiguriert.
Test des Gateways
Die Grundkonfiguration des Gateways ist abgeschlossen, Clientgeräte können nun für die Nutzung des Gateways konfiguriert werden. Zu Testzwecken sollte zuerst der Versand an einen selbst verwalteten Mailserver getestet werden, um Spameinstufung der IPs zu vermeiden und Logs auf Empfängerseite zu prüfen.
Beim Troubleshooting sollte zuerst der Versand vom Client an PMG geprüft werden. Funktioniert dieser, sind Fehlermeldungen des Gateways beim Versand an den Zielserver unter Administration –> Queues zu finden. Klappt der ausgehende Versand nicht, helfen die Logs des empfangenden SMTP-Servers und Spamfilters weiter. Die Zustellungschancen an externe Mailserver können sich zudem durch die Einrichtung eines DMARC-Records verbessern.
Sollen E-Mails an t-online.de Adressen versendet werden, ist gegebenenfalls eine Entsperrung der IPs erforderlich. Weitere Infos dazu sind im vorherigen Beitrag zu finden.