MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

HIN und NoSpamProxy

Am Beispiel des Schweizer HIN-Gateway zeige ich eine exemplarische Einbindung in NoSpamProxy. Die Beschreibung funktioniert natürlich auch mit anderen Zusatzfunktionen, die per SMTP in einen Nachrichtenfluss  eingeschliffen werden und vielleicht darf NoSpamProxy irgendwann auch einmal selbst HIN-Nachrichten verschlüsseln und entschlüsseln.

Hinweis: Diese Seite beschreibt (Stand April 2025) noch eine funktionierende Konfiguration sondern die Vorüberlegungen dazu. Aktuell stellt HIN als Backend für die Zertifikate keine öffentliche Schnittstelle für den Abruf der Zertifikate bereit.

Überlegungen

Das geschlossene Mailsystem der HIN sichert die Kommunikation zwischen den Partnern über SMIME ab. Es ist damit zwar keine 100% Ende-zu-Ende-Verschlüsselung von Postfach zu Postfach, sondern nur eine Verschlüsselung zwischen den Servern der Kommunikationspartnern. Das ist immer noch besser, als eine Absicherung mittels SMTPTLS/STARTTLS. HIN-Kommunikation können Sie dabei entweder über ein Postfach bei HIN als Provider oder mit einem lokalen HIN-Gateway, welches zwischen Internet und ihrem Server platziert wird, erreichen.

Wenn Sie nun aber das HIN-Gateway "nach  vorne" stellen, damit es eingehende Mails erst entschlüsselt, dann müsste das HIN-Gateway auch den Spamschutz bereitstellen. Vielleicht wollen Sie hier aber die Leistung von NoSpamProxy nutzen. Stellen Sie das Gateway aber hinter ihren Spamfilter, dann kann der Spamfilter nicht die Inhalte der verschlüsselten Mails analysieren. Daher ist hier eine "sowohl als auch"-Konfiguration sinnvoll:

Ausgehend müssen Sie darauf achten, dass z.B. Mails erst verschlüsselt werden, damit dann ihre primäre AntiSpam-Lösung z.B. eine DKIM-Signatur anbricht. Die würde durch die Verschlüsselung und SMIME-Signierung sonst ungültig. Damit ihre Schutzlösung aber auch ausgehende Mails z.B. auf Viren prüfen kann, gilt auch hier ein Sowohl-als-auch

Wenn Sie Exchange Online haben, dann können Sie solche Zusatzfunktionen auch in den Exchange Online Transport einbinden, wie ich auf folgenden Seiten beschrieben habe:

Planung

Beim Mailrouting mit einem HIN-Gateway müssen sie zwei Dinge immer im Hinterkopf haben:

  • Domainliste
    Die HIN als Dienstleister pflegt eine Liste aller "HIN-Domains", d.h. Empfänger und Sender, die einen Vertrag mit HIN haben und entsprechend verschlüsselte und signierte Mails senden und empfangen können. Als Teilnehmer bei HIN müssen Sie sicherstellen, dass alle Mails an diese Domains zwingend per SMIME mit dem Domain-Zertifikate der Empfängerseite verschlüsselt und eingehende Mails von diesem Domain vom Absender signiert wurden.
  • Header "X-HIN-Encrypt"
    Das HIN-Gateway nutzt diesen Header, um signierte/verschlüsselte Mails zu kennzeichnen

Beide Kriterien helfen uns, dass nur Mails diese Domains oder mit dem Kennzeichen auch wirklich über das HIN-Gateway geschleust werden müssen. Im klassischen Setup wird das HIN-Gateway nämlich direkt zwischen den Mailserver und dem Internet platziert.

Das bedeutet aber auch, dass alle Mails des Unternehmens immer durch das HIN-Gateway als zusätzliche Station gehen, obwohl die HIN-Zusatzfunktion nur für einen Teil der Mails zutrifft. Daher können wie das HIN-Gateway auch "neben" unseren primären Mailfluss stellen, und nur die Mails anders routen, die tatsächlich durch das Gateway bearbeitet werden müssen.

Wir können und die beiden Richtungen einmal genauer anschauen:

  • Ausgehende Mail
    Die Mail wird vom Mailserver direkt zu NoSpamProxy gesendet. NoSpamProxy erkennt natürlich den einliefernden Mailserver als vertrauenswürdig, z.B. anhand der IP-Adresse oder einem Zertifikat und anderen Kriterien, so dass es auch mit Exchange Online funktioniert.
    Zuerst sollte NoSpamProxy prüfen, ob die Mail überhaupt versendet werden soll, d.h. Spamschutz und Virenschutz sollten Sie auch ausgehend aktiv nutzen.
    NoSpamProxy kann dann die Zieldomains auswerten und entsprechend zum SMIME-Gateway routen, wenn NoSpamProxy nicht selbst die SMIME-Behandlung machen darf. Das HIN-Gateway signiert und verschlüsselt die Mail und liefert sie wieder an NoSpamProxy ein. NoSpamProxy erkennt die Mail weiter als Ausgehend und das der Header "X-HIN-Encrypt" gesetzt ist, wird sie z.B. DKIM-signiert und ins Internet versendet.
  • Eingehende Mail
    In die Gegenrichtung kann NoSpamProxy den klassischen Spamschutz (DKIM, SPF, Content) anwenden aber für verschlüsselte Mails ist dies nicht auf den Inhalt möglich. Aber anhand des Headers "X-HIN-Encrypt" oder auch anhand der Absenderdomain kann NoSpamProxy die Mails an das externe SMIME-Gateway routen, damit sie von dort nach der Entschlüsselung wieder bei NoSpamProxy ankommen.
    Ehe die Mails dann zum eigentlichen Mailserver gehen, kann noch mal eine Bewertung des Inhalts und Anlagen auf Viren oder Spam erfolgen. Ein Ablehnen ist dann natürlich nicht mehr möglich.

Oder als kurze Übersicht:

Eingehend Default    :Internet---MX-->NSP(SPF/DKIM/RBL + AV/Malware) --> Mailserver
Eingehend HinDomains :Internet---MX-->NSP(SPF/DKIM/RBL)-> HIN-Gateway--> NSP(AV/Malware) -> Mailserver Mailserver
Ausgehend Default    :Mailserver----->NSP(+DKIM) -------> Internet
Ausgehend HINDomains :Mailserver----->NSP(AV/Malware) -> HINGW -> NSP(+DKIM) ->  Internet

Damit brauchen wir nun nur noch eine Beschreibung der Konfiguration, wenn es denn von HIN eine Schnittstelle zum Abruf der Zertifikate gibt.

Offen

Ich bin sicher, dass neben NoSpamProxy auch viele andere SMIME-Gateway sehr problemlos mit Domain-Zertifikaten umgehen können und mit wenig Aufwand sogar ein automatischer "Import/Update" solcher Zertifikate möglich sein sollte. Oder sie werden direkt in Zertifikatsplattformen wie "Open Keys" u.a. vorgehalten. Das Problem ist hierbei, dass es keinen Standard für "SMIME Domain Zertifikate" gibt und das Feld "E-Mail-Adresse" vom Empfänger mit dem Absender der Mail verglichen wird. Offiziell gibt es kein Wildcard-Zertifikate mit einer Mailadresse wie "*@msxfaq.de" und auch die üblichen Mailclients vertrauen eine so signierten Mail nicht. Auf einem entsprechenden SMIME-Gateway können Sie als Administrator natürlich schon solche Prüfungen umsetzen und positiv validierte Mails dann nach intern mit einem Signaturreport aber ansonsten unsigniert durchreichen.

Bis dahin ist diese Seite nicht viel mehr als eine Problembeschreibung, wenn Sie Spamschutz, Virenschutz als eine Komponente und SMIME/PGP-Funktionen als zweite Komponente getrennt aufsetzen.

Ich hoffe, dass die Firmen, die bislang proprietäre Lösungen auf Basis solcher "SMIME Domain-Zertifikate/Wildcard-Zertifikate" ihre Spezifikation offenlegen.

Weitere Links