Proxmox Mail Gateway: professioneller Spam- und Virenschutz.

Architektur

Eingehende und ausgehende Nachrichten erhalten getrennte, kontrollierte Wege.

Für eingehende E-Mails verweist der MX-Eintrag der geschützten Domain auf das Gateway. PMG nimmt die SMTP-Verbindung an, prüft Empfänger und Inhalt und leitet akzeptierte Nachrichten zum zuständigen Mailserver weiter. Relay-Domains und Transportziele müssen eindeutig definiert sein. Eine Empfängerprüfung kann verhindern, dass Nachrichten an nicht vorhandene Postfächer unnötig angenommen und später als unzustellbar zurückgesendet werden.

1. Absendender Mailserver im Internet
2. PMG prüft SMTP, Reputation und Inhalt
3. Interner oder cloudbasierter Mailserver
4. Postfach des berechtigten Empfängers

Ausgehende Nachrichten können über einen separat konfigurierten Relay-Weg an PMG übergeben werden. Nur berechtigte Systeme und Netze dürfen diesen Weg verwenden; ein offenes Relay darf nicht entstehen. Ausgehende Inhaltsprüfung, DKIM-Signierung, TLS-Richtlinien und Protokollierung werden bewusst getrennt vom eingehenden Mailfluss geplant.

Der Zielserver sollte direkte SMTP-Verbindungen für die geschützten Domains nur aus den vorgesehenen Gateway-Netzen annehmen. Andernfalls könnten Angreifer den Filter durch eine Zustellung direkt an den internen Mailserver umgehen. Alternative MX-Einträge, IPv6, NAT, Firewallregeln, Cloud-Connectoren und vorhandene Drittanbieterfilter gehören deshalb vollständig in die Bestandsaufnahme.

Filterstufen

Mehrstufiger Spamschutz ist belastbarer als eine einzelne Prüfung.

Proxmox Mail Gateway verbindet SMTP-Prüfungen mit Inhaltsanalyse. Postfix übernimmt den Mailtransport, SpamAssassin bewertet zahlreiche Merkmale und ClamAV prüft auf bekannte Schadprogramme. Ein einzelner Treffer ist häufig noch kein ausreichender Beleg. Erst das Zusammenspiel der Signale, die Gewichtung und die konfigurierten Schwellen bestimmen, ob eine Nachricht zugestellt, markiert, zurückgehalten oder abgewiesen wird.

Reputation und DNS-basierte Listen

DNSBL- und SURBL-Abfragen liefern Hinweise zu auffälligen sendenden Systemen oder Links im Nachrichtentext. Auswahl, Nutzungsbedingungen, Abfragelimits und Ausfallverhalten müssen geprüft werden. Eine zu aggressive Konfiguration kann legitime Kommunikation beeinträchtigen.

SMTP-Prüfungen und Empfängerverifikation

Protokollverhalten, Absenderinformationen und vorhandene Empfänger helfen schon vor der vollständigen Annahme einer Nachricht. Der Mailserver oder ein geeignetes Verzeichnis muss verlässliche Empfängerdaten liefern, damit gültige Aliase und Verteiler nicht versehentlich abgewiesen werden.

Greylisting

Ausgewählte Erstzustellungen werden temporär abgewiesen und erst bei einem korrekten erneuten Zustellversuch akzeptiert. Das kann einfache Spam-Sender reduzieren, erzeugt aber unter Umständen Verzögerungen. Nutzen und Nebenwirkungen werden anhand des realen Verkehrs bewertet.

Spam-Score und Bayes

Header, Text, Struktur und weitere Merkmale fließen in eine Bewertung ein. Statistische Klassifizierung kann diese Entscheidung ergänzen. Geeignete Trainingsdaten und ein kontrollierter Lernprozess sind wichtig, weil falsch zugeordnete Beispiele die Qualität verschlechtern können.

AOIT startet nach Möglichkeit mit einem beobachteten Testbetrieb und nachvollziehbaren Schwellenwerten. False Positives und False Negatives werden gemeinsam bewertet; Ausnahmen bleiben eng begrenzt und dokumentiert. Pauschale Zusagen wie „100 Prozent spamfrei“ wären technisch nicht belastbar.

Malware und Social Engineering

Virenprüfung, Anhangsregeln und Phishing-Schutz greifen ineinander.

ClamAV untersucht Nachrichten anhand verfügbarer Signaturen. Ergänzend lassen sich Dateitypen, MIME-Merkmale, Archive und andere Inhalte über das Regelwerk behandeln. Ausführbare Dateien, Skripte oder Makro-Dokumente können beispielsweise zurückgehalten werden, wenn sie für den Geschäftsprozess nicht erforderlich sind. Welche Aktion sinnvoll ist, hängt von Branche, Arbeitsablauf und Risiko ab.

Passwortgeschützte oder stark verschachtelte Archive lassen sich ohne den passenden Schlüssel nicht vollständig inhaltlich prüfen. Auch neue Schadprogramme können an signaturbasierten Kontrollen vorbeikommen. Ein erlaubter Anhang ist deshalb kein Beweis für Unbedenklichkeit. Endpoint-Schutz, aktuelle Anwendungen, restriktive Benutzerrechte und sichere Makro-Richtlinien bleiben erforderlich.

Beim Phishing werden häufig Anzeigenamen bekannter Personen, ähnlich geschriebene Domains, gefälschte Rechnungen oder dringliche Aufforderungen verwendet. Eine technisch authentifizierte Nachricht kann dennoch betrügerisch sein, etwa wenn ein echtes Konto übernommen wurde. Auffällige Zahlungs- oder Kontowechsel werden deshalb über einen zweiten, bekannten Kommunikationsweg verifiziert.

Absender und Transport

SPF, DKIM, DMARC und TLS lösen unterschiedliche Aufgaben.

PMG unterstützt SPF-Prüfungen und die ausgehende DKIM-Signierung. Die konkrete Bewertung eingehender Authentifizierungsergebnisse hängt von Version, SpamAssassin-Konfiguration und Regeln ab. Für die eigene Domain werden sämtliche legitimen Versandquellen erfasst: Mailserver, Microsoft 365, Newsletter, CRM, Ticketsystem und Fachanwendungen. Erst nach Auswertung der DMARC-Berichte wird eine restriktivere Policy eingeführt.

Beispielhafte DNS-Einträge für eine reservierte Testdomain

example.org.          IN MX 10 mx1.example.org.
mx1.example.org.      IN A 203.0.113.10
example.org.          IN TXT "v=spf1 ip4:203.0.113.10 -all"
_dmarc.example.org.   IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.org"
selector._domainkey.example.org. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"

Diese reservierten Werte sind keine produktive Konfiguration. Der DKIM-Schlüssel muss vollständig veröffentlicht, das Reporting-Postfach vorbereitet und SPF erst nach Erfassung aller Versandquellen abgeschlossen werden. PTR, Hostname, HELO, IPv6 und TLS-Zertifikat werden separat geprüft.

Kontrollierte Entscheidungen

Filterregeln, Quarantäne und Tracking machen den Mailverkehr steuerbar.

Das objektorientierte Regelwerk verknüpft Absender und Empfänger, Zeitbedingungen, Inhalte und Aktionen. So lassen sich hohe Spam-Bewertungen in Quarantäne verschieben, riskante Anhänge zurückhalten, bestimmte Nachrichten kennzeichnen oder klar unerwünschte Inhalte abweisen. Prioritäten und bereits ausgeführte Aktionen werden bei der Planung berücksichtigt.

Ausnahmen werden möglichst eng formuliert. Eine pauschale Freigabe einer gesamten Domain kann missbraucht werden, wenn Absender gefälscht oder Konten kompromittiert sind. Für Geschäftspartner werden daher der konkrete Anlass, notwendige Bedingungen, verantwortliche Person und ein Prüftermin dokumentiert.

In der Quarantäne bleiben zurückgehaltene Nachrichten kontrolliert verfügbar. Benutzerberichte und Freigaberechte werden so konfiguriert, dass Mitarbeitende legitime Nachrichten finden können, ohne gefährliche Inhalte unkontrolliert zu verteilen. Aufbewahrungszeiten, Zugriffsrechte und Eskalationen unterscheiden Spam-, Virus- und Anhangsquarantäne.

Das Tracking Center fasst den Transportweg zusammen. Für eine Suche sind Empfänger, ungefährer Versandzeitpunkt und möglichst die Message-ID hilfreich. „Nicht angekommen“ kann bedeuten, dass der Absender noch nicht zugestellt hat, PMG abgewiesen hat, die Nachricht in einer Queue wartet oder bereits erfolgreich an den Zielserver übergeben wurde. Erst danach werden Regeln und Ordner des Postfachsystems separat untersucht.

Vorhandene Mailplattformen

Exchange, Microsoft 365, Postfix und Plesk benötigen ein jeweils passendes Routing.

Entscheidend ist der SMTP-Mailweg, nicht die Verwaltungsoberfläche des Zielsystems. Bei Exchange werden Receive- und Send-Connectoren, berechtigte Gateway-Adressen und interne Transportregeln abgestimmt. In Microsoft 365 sind Connectoren, akzeptierte Domains, Enhanced Filtering beziehungsweise vergleichbare Vertrauenseinstellungen und die Vermeidung von Routing-Schleifen zu prüfen.

Bei Postfix sind Relay-Ziele, Transporttabellen, erlaubte Netze und Empfängerprüfung relevant. Auf einem Plesk-System müssen Änderungen mit der von Plesk verwalteten Mailkonfiguration vereinbar sein; unkontrollierte manuelle Anpassungen können bei späteren Updates überschrieben werden. AOIT dokumentiert deshalb, welche Einstellungen im Gateway, in Plesk, im DNS und in der Firewall liegen.

Vor der Umstellung werden Domains, Aliase, Verteiler, Catch-all-Einstellungen, SMTP-Anwendungen, Multifunktionsgeräte und externe Versanddienste inventarisiert. Tests prüfen legitime Zustellung, ungültige Empfänger, ausgehende Signaturen, TLS, NDR-Verhalten und die Absicherung gegen ein offenes Relay. Bestehende Spamfilter werden auf Überschneidungen geprüft, damit Nachrichten nicht mehrfach oder widersprüchlich behandelt werden.

Hochverfügbarkeit

Mehrere Gateways verbessern die Verfügbarkeit – ersetzen aber kein vollständiges Notfallkonzept.

Mehrere Gateways können den Empfang über mehrere MX-Ziele oder Adressen verteilen. Bei Nichterreichbarkeit versuchen sendende Mailserver nach ihrem eigenen Verhalten alternative Ziele. Das ist kein synchroner Lastverteiler und garantiert keine verzögerungsfreie Umschaltung. Für ausgehende Nachrichten benötigt auch der Mailserver eine definierte Auswahl erreichbarer Relay-Ziele.

Ein PMG-Cluster synchronisiert zentrale Konfigurationen zwischen Master und Knoten. Lokale SMTP-Warteschlangen sind jedoch nicht automatisch ein gemeinsam replizierter Nachrichtenspeicher. Bereits angenommene Nachrichten auf einem ausgefallenen Gateway müssen bei Wiederherstellung und Wartung ausdrücklich berücksichtigt werden.

Auch zwei Gateways können gemeinsame Ausfallpunkte haben: Stromversorgung, Internetzugang, DNS, Firewall, Virtualisierungshost oder der nachgelagerte Mailserver. Ein belastbares Design verteilt die Systeme auf geeignete Fehlerdomänen, überwacht beide Wege und kontrolliert die Queue vor, während und nach Wartungsarbeiten.

Einführung

Die Migration folgt überprüfbaren Schritten und besitzt einen Rückfallplan.

Der Rückfallplan enthält vorherige DNS-Werte, Connectoren, Ansprechpartner und eindeutige Abbruchkriterien. Da DNS-Caches länger als das Wartungsfenster wirken können, müssen alter und neuer Weg in der Übergangsphase sinnvoll behandelt werden.

Praxis und Administration

Konkrete Fälle zeigen, welche Informationen im Betrieb zählen.

aoit@pmg01:~$ sudo pmgversion -v
aoit@pmg01:~$ systemctl is-active postfix pmg-smtp-filter pmgproxy

aoit@pmg01:~$ postqueue -p
aoit@pmg01:~$ qshape deferred

aoit@pmg01:~$ journalctl -u postfix --since "1 hour ago" --no-pager
aoit@pmg01:~$ journalctl -u pmg-smtp-filter --since "1 hour ago" --no-pager

aoit@pmg01:~$ dig MX example.org +short
aoit@pmg01:~$ dig TXT example.org +short
aoit@pmg01:~$ openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org

Laufender Betrieb

Monitoring, Updates, Sicherung und Wiederherstellung werden gemeinsam geplant.

Ein Mailgateway benötigt regelmäßige Betreuung. Dazu gehören System- und PMG-Updates, aktuelle Virensignaturen, Zertifikatslaufzeiten, Speicherauslastung, Queue-Länge, Zustellfehler und Clusterstatus. Zusätzlich wird die Filterqualität anhand realer Rückmeldungen bewertet. Ein erreichbares Webinterface allein beweist keinen funktionierenden Mailtransport.

Kontrollierte Testzustellungen und definierte Alarmgrenzen ergänzen das technische Monitoring. Stark wachsende Queues, ungewöhnliche Ablehnungsraten, Signaturfehler oder auffälliges ausgehendes Volumen können auf Störungen oder kompromittierte Konten hinweisen. Eskalationswege, Servicezeiten und Reaktionsziele werden für die gewählte Betriebsform vereinbart.

PMG kann Konfiguration, Filterregeln und Statistikdaten sichern; aktuelle Versionen unterstützen auch die Anbindung an Proxmox Backup Server. Die Sicherung umfasst jedoch nicht automatisch Netzwerksetup, lokale Postfix-Queue oder sämtliche Quarantänedaten. Deshalb werden Konfigurationssicherung, Schlüsselmaterial, Dokumentation, Wiederherstellung des Systems und Umgang mit noch wartenden Nachrichten getrennt betrachtet und getestet.

aoit@pmg01:~$ sudo pmgbackup backup --notify error
aoit@pmg01:~$ sudo pmgbackup list

Governance

Nachrichteninhalte, Metadaten und Zugriffsrechte benötigen klare Regeln.

Ein Mailgateway verarbeitet Nachrichteninhalte und Metadaten wie Absender, Empfänger, Zeitstempel und technische Bewertungen. Zugriff auf Quarantäne, Tracking, Protokolle und Administration wird deshalb rollenbasiert vergeben. Sichere Managementzugänge, MFA an vorgeschalteten Zugängen, Löschfristen, Protokollierung und regelmäßige Rechteprüfungen reduzieren unnötige Zugriffe.

Für einen betreuten oder gehosteten Betrieb werden der tatsächliche Standort, beteiligte Dienstleister, Supportzugriffe und gegebenenfalls eine Auftragsverarbeitung konkret bewertet. Ein Standort in Deutschland allein begründet keine pauschale Datenschutzkonformität. Entscheidend sind die tatsächliche Verarbeitung, technische und organisatorische Maßnahmen sowie passende Vereinbarungen.

PMG ersetzt weder revisionsgerechte E-Mail-Archivierung noch Ende-zu-Ende-Verschlüsselung. Falls diese Anforderungen bestehen, werden sie als eigene Bausteine geplant und mit Mailfluss, Aufbewahrung und Berechtigungen abgestimmt.

Leistungen von AOIT

Vom Assessment bis zum laufenden Betrieb bleibt die Verantwortung nachvollziehbar.

Ein Angebot trennt Software und optionale Proxmox-Subscription, Infrastruktur, Projektleistung und laufende Betreuung. Die Open-Source-Software kann ohne Subscription eingesetzt werden; eine Subscription ergänzt je nach Modell Enterprise-Repositories und Herstellersupport. Infrastruktur, sichere Administration und Betriebsprozesse verursachen unabhängig davon Aufwand.