S/MIME Teil 4: Empfänger-Öffentlich-Schlüssel einfach sammeln – mit SparkPost Inbound Relay Webhooks

Vogel

01.02.2019

E-Mail

1 min read

S/MIME Teil 4: Empfänger-Öffentlich-Schlüssel einfach sammeln – mit SparkPost Inbound Relay Webhooks

Wichtige Erkenntnisse

    • Prämisse: S/MIME-verschlüsselte E-Mails zu senden ist nicht schwer, sobald Sie den öffentlichen Schlüssel jedes Empfängers automatisch sammeln können. Dieser Beitrag schließt diese Lücke, indem er SparkPost Inbound Relay Webhooks verwendet, um signierte E-Mails zu empfangen, Zertifikate zu extrahieren und sie für die spätere Verschlüsselung zu speichern.

    • Ziel: Erstellen Sie einen auf Flask basierenden Webhook-Dienst, der eingehende signierte Nachrichten abhört, diese validiert (DKIM + Zertifikatsprüfungen) und jeden öffentlichen Schlüssel sicher auf der Festplatte für den Einsatz in ausgehenden sicheren E-Mails schreibt.

    • Highlights:

      1. Problem: Manuelle Schlüsselaustausche skalieren nicht für app-generierte E-Mails.

      2. Lösung: Laden Sie Benutzer ein, eine signierte E-Mail zu senden; der eingehende Webhook analysiert und speichert automatisch ihr PEM-Zertifikat.

      3. Einrichtungsmaßnahmen:

        • Konfigurieren Sie eine Inbound-Domain und MX-Einträge (z.B. inbound.ihrdomain.com).

        • Erstellen Sie einen Inbound Relay Webhook über die SparkPost API, der auf Ihren App-Endpunkt zeigt.

        • Bereitstellen einer kleinen Flask-App (webapp.py) unter Verwendung der Konfiguration aus webapp.ini.

        • Führen Sie umfangreiche Protokollierungen für Transparenz durch; integrieren Sie Pytest + Travis CI für die automatisierte Validierung.

      4. Sicherheitsmaßnahmen:

        • Überprüfen Sie DKIM-Signaturen und die Authentizität der Nachricht.

        • Überprüfen Sie die Zertifikats-Vertrauensstellung, bevor Sie diese speichern.

        • Verwenden Sie ein geheimes Authentifizierungs-Token in Webhook-Headern.

      5. Ausgabe:

        • Jede gültige eingehende Nachricht erstellt eine Zertifikatsdatei wie bob.lumreeker@gmail.com.crt.

        • Sobald sie gespeichert sind, ermöglichen diese Schlüssel verschlüsselte Antworten unter Verwendung früherer Skripte aus den Teilen 2 und 3.

Q&A Highlights

  • Warum ist das Sammeln von Empfängerschlüsseln so kritisch für S/MIME?

    Da die Verschlüsselung den öffentlichen Schlüssel jedes Empfängers erfordert, ermöglicht die Automatisierung dieses Schritts, dass jede App sichere E-Mails senden kann, ohne dass ein manueller Austausch erforderlich ist.

  • Wie vereinfacht SparkPost Inbound Relay Webhook die Schlüsselsammlung?

    Es wandelt jede signierte eingehende E-Mail in ein strukturiertes JSON-Payload um, wodurch Ihre App Zertifikate programmatisch analysieren und speichern kann.

  • Welche Schutzmaßnahmen verhindern Spoofing oder Junk-Einreichungen?

    Der Dienst überprüft DKIM-Signaturen, erzwingt Authentifizierungstoken und weist fehlerhafte oder unsignierte Nachrichten zurück.

  • Wo werden Zertifikate gespeichert und in welchem Format?

    Sie werden im PEM-Format (.crt-Dateien) auf die Festplatte geschrieben, bereit für die Verwendung durch die in den vorherigen Teilen erstellte Signier-/Verschlüsselungstoolkette.

  • Wie sieht der Entwickler-Workflow aus?

    Führen Sie die Flask-App aus, überprüfen Sie sie mit Postman anhand der bereitgestellten Beispielnutzlast und verbinden Sie sie dann mit SparkPosts Live-Webhook für den kontinuierlichen Betrieb.

  • Gesamte Erkenntnis?

    S/MIME-Schlüsselmanagement kann mit wenigen Zeilen Python und SparkPost APIs vollständig automatisiert werden—skalierbare Verschlüsselung für jeden app-generierten E-Mail-Workflow bringen.

In Teil 1 hatten wir eine kurze Tour durch S/MIME und betrachteten die Signierung und Verschlüsselung unserer Nachrichtenströme über eine Reihe von Mail-Clients. Teil 2 führte uns durch ein einfaches Kommandozeilenwerkzeug, um E-Mails zu signieren und zu verschlüsseln, und sie dann über SparkPost zu senden. Teil 3 zeigte, wie man sichere Mail-Ströme in lokale Plattformen wie Port25 PowerMTA und Momentum einfügt.

In dieser Serie haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Versenden von S/MIME-verschlüsselten Mails ist komplexer, da man öffentliche Schlüssel der Empfänger beschaffen muss. Es ist eine Sache, wenn man einen Mail-Client für Menschen wie Thunderbird benutzt – aber wie funktioniert das mit App-generierten E-Mail-Strömen? App-generierte E-Mails, wie sie von Dating-Plattformen verwendet werden, erfordern eine sorgfältige Strategie, um das Engagement zu maximieren. Sehen Sie, wie Dating-Apps überzeugende, ausgelöste E-Mail-Erlebnisse schaffen.

Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu bekommen. Ihr Service kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte Mail an eine bekannte Kundenservice-Adresse zurückzusenden. Mithilfe der magischen Kräfte der SparkPost Inbound Relay Webhooks werden wir diesen öffentlichen Schlüssel extrahieren und speichern, damit Sie ihn verwenden können.

Wir können dies in einem einfachen Anwendungsfall zusammenfassen:

  • Als Empfänger von Nachrichten stelle ich Ihrem Service meine persönliche E-Mail-Signatur per E-Mail zur Verfügung, damit mir in Zukunft E-Mails in S/MIME-verschlüsselter Form gesendet werden können.

Daraus wollen wir einige detailliertere Anforderungen ableiten:

  • Wir benötigen einen stets aktiven, zuverlässigen Eingangs-Mail-Service, um diese signierten E-Mails zu empfangen.

  • Es sollten keine speziellen Anforderungen an das Mail-Format gestellt werden, außer dass es eine S/MIME-Signatur enthalten sollte.

  • Da jeder versuchen kann, eine Mail an diesen Service zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von böswilligen Akteuren abzuweisen. Es wird mehrere Überprüfungsebenen geben.

  • Wenn alles in Ordnung ist, speichert der Service das Zertifikat in einer Datei im bekannten Klartextformat Privacy-Enhanced Mail (PEM).

Es gibt einige nicht-funktionale Anforderungen:

  • Maschine-zu-Maschine-Webhooks-Dienste können nur schwer durch Rückmeldungen das Innere erkennen lassen. Der Dienst sollte umfangreiche, menschenlesbare Anwendungsprotokolle bereitstellen. Insbesondere das Parsen und Prüfen der Zertifikate sollte protokolliert werden.

  • Wir fügen Testfälle für die Anwendungsinternen hinzu, indem wir das nette Pytest Framework verwenden und diese Tests automatisch bei Check-in mit der Travis CI-Integration mit GitHub ausführen.

OK – fangen wir an!

In Teil 1 hatten wir eine kurze Tour durch S/MIME und betrachteten die Signierung und Verschlüsselung unserer Nachrichtenströme über eine Reihe von Mail-Clients. Teil 2 führte uns durch ein einfaches Kommandozeilenwerkzeug, um E-Mails zu signieren und zu verschlüsseln, und sie dann über SparkPost zu senden. Teil 3 zeigte, wie man sichere Mail-Ströme in lokale Plattformen wie Port25 PowerMTA und Momentum einfügt.

In dieser Serie haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Versenden von S/MIME-verschlüsselten Mails ist komplexer, da man öffentliche Schlüssel der Empfänger beschaffen muss. Es ist eine Sache, wenn man einen Mail-Client für Menschen wie Thunderbird benutzt – aber wie funktioniert das mit App-generierten E-Mail-Strömen? App-generierte E-Mails, wie sie von Dating-Plattformen verwendet werden, erfordern eine sorgfältige Strategie, um das Engagement zu maximieren. Sehen Sie, wie Dating-Apps überzeugende, ausgelöste E-Mail-Erlebnisse schaffen.

Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu bekommen. Ihr Service kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte Mail an eine bekannte Kundenservice-Adresse zurückzusenden. Mithilfe der magischen Kräfte der SparkPost Inbound Relay Webhooks werden wir diesen öffentlichen Schlüssel extrahieren und speichern, damit Sie ihn verwenden können.

Wir können dies in einem einfachen Anwendungsfall zusammenfassen:

  • Als Empfänger von Nachrichten stelle ich Ihrem Service meine persönliche E-Mail-Signatur per E-Mail zur Verfügung, damit mir in Zukunft E-Mails in S/MIME-verschlüsselter Form gesendet werden können.

Daraus wollen wir einige detailliertere Anforderungen ableiten:

  • Wir benötigen einen stets aktiven, zuverlässigen Eingangs-Mail-Service, um diese signierten E-Mails zu empfangen.

  • Es sollten keine speziellen Anforderungen an das Mail-Format gestellt werden, außer dass es eine S/MIME-Signatur enthalten sollte.

  • Da jeder versuchen kann, eine Mail an diesen Service zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von böswilligen Akteuren abzuweisen. Es wird mehrere Überprüfungsebenen geben.

  • Wenn alles in Ordnung ist, speichert der Service das Zertifikat in einer Datei im bekannten Klartextformat Privacy-Enhanced Mail (PEM).

Es gibt einige nicht-funktionale Anforderungen:

  • Maschine-zu-Maschine-Webhooks-Dienste können nur schwer durch Rückmeldungen das Innere erkennen lassen. Der Dienst sollte umfangreiche, menschenlesbare Anwendungsprotokolle bereitstellen. Insbesondere das Parsen und Prüfen der Zertifikate sollte protokolliert werden.

  • Wir fügen Testfälle für die Anwendungsinternen hinzu, indem wir das nette Pytest Framework verwenden und diese Tests automatisch bei Check-in mit der Travis CI-Integration mit GitHub ausführen.

OK – fangen wir an!

In Teil 1 hatten wir eine kurze Tour durch S/MIME und betrachteten die Signierung und Verschlüsselung unserer Nachrichtenströme über eine Reihe von Mail-Clients. Teil 2 führte uns durch ein einfaches Kommandozeilenwerkzeug, um E-Mails zu signieren und zu verschlüsseln, und sie dann über SparkPost zu senden. Teil 3 zeigte, wie man sichere Mail-Ströme in lokale Plattformen wie Port25 PowerMTA und Momentum einfügt.

In dieser Serie haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Versenden von S/MIME-verschlüsselten Mails ist komplexer, da man öffentliche Schlüssel der Empfänger beschaffen muss. Es ist eine Sache, wenn man einen Mail-Client für Menschen wie Thunderbird benutzt – aber wie funktioniert das mit App-generierten E-Mail-Strömen? App-generierte E-Mails, wie sie von Dating-Plattformen verwendet werden, erfordern eine sorgfältige Strategie, um das Engagement zu maximieren. Sehen Sie, wie Dating-Apps überzeugende, ausgelöste E-Mail-Erlebnisse schaffen.

Aber warten Sie – es gibt einen anderen Weg nach Mordor, um diese Schlüssel zu bekommen. Ihr Service kann Ihre Kunden (natürlich per E-Mail) einladen, Ihnen eine signierte Mail an eine bekannte Kundenservice-Adresse zurückzusenden. Mithilfe der magischen Kräfte der SparkPost Inbound Relay Webhooks werden wir diesen öffentlichen Schlüssel extrahieren und speichern, damit Sie ihn verwenden können.

Wir können dies in einem einfachen Anwendungsfall zusammenfassen:

  • Als Empfänger von Nachrichten stelle ich Ihrem Service meine persönliche E-Mail-Signatur per E-Mail zur Verfügung, damit mir in Zukunft E-Mails in S/MIME-verschlüsselter Form gesendet werden können.

Daraus wollen wir einige detailliertere Anforderungen ableiten:

  • Wir benötigen einen stets aktiven, zuverlässigen Eingangs-Mail-Service, um diese signierten E-Mails zu empfangen.

  • Es sollten keine speziellen Anforderungen an das Mail-Format gestellt werden, außer dass es eine S/MIME-Signatur enthalten sollte.

  • Da jeder versuchen kann, eine Mail an diesen Service zu senden, sollte er defensiv gestaltet sein, um beispielsweise „Spoof“-Nachrichten von böswilligen Akteuren abzuweisen. Es wird mehrere Überprüfungsebenen geben.

  • Wenn alles in Ordnung ist, speichert der Service das Zertifikat in einer Datei im bekannten Klartextformat Privacy-Enhanced Mail (PEM).

Es gibt einige nicht-funktionale Anforderungen:

  • Maschine-zu-Maschine-Webhooks-Dienste können nur schwer durch Rückmeldungen das Innere erkennen lassen. Der Dienst sollte umfangreiche, menschenlesbare Anwendungsprotokolle bereitstellen. Insbesondere das Parsen und Prüfen der Zertifikate sollte protokolliert werden.

  • Wir fügen Testfälle für die Anwendungsinternen hinzu, indem wir das nette Pytest Framework verwenden und diese Tests automatisch bei Check-in mit der Travis CI-Integration mit GitHub ausführen.

OK – fangen wir an!

1. Lösungsübersicht

Hier ist, wie die Gesamtlösung aussehen wird.

Diagram depicting a secure email flow illustrating how emails are verified using certificates for secure transmission.

Hier ist, wie die Gesamtlösung aussehen wird.

Diagram depicting a secure email flow illustrating how emails are verified using certificates for secure transmission.

Hier ist, wie die Gesamtlösung aussehen wird.

Diagram depicting a secure email flow illustrating how emails are verified using certificates for secure transmission.

2. Installation, Konfiguration und Start der Web App

Wir beginnen mit diesem Teil, damit wir ihn vollständig getestet haben, bevor wir die eingehenden Relay-Webhooks einrichten.

Die Web-Anwendung ist im selben GitHub-Projekt wie die Teile 1 – 3 enthalten, also wenn Sie diesen Teilen gefolgt sind, haben Sie es schon. Hier sind die neuen Teile:

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- und Benutzerzertifikate parsen.

  • Programm webapp.py – einfache mit Flask kompatible Webanwendung zur Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für die obige Anwendung. Eine Konfigurationsdatei ermöglicht es, dieselben Werte sowohl für Befehlszeilen- als auch Webanwendungen einfach zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen von außen geöffnet hat, damit SparkPost Nachrichten an Ihre App senden kann. Wenn Sie beispielsweise auf AWS EC2 gehostet sind, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anweisungen zum Konfigurieren und Starten der Web-Anwendung finden Sie in unserem Einrichtungsleitfaden – es ist ziemlich einfach. Um zu überprüfen, ob Ihre App läuft und von der Außenwelt zugänglich ist, können Sie (leere) Anfragen von einem anderen Host senden, z.B. mit curl:

curl -X POST https://app.trymsys.net:8855/

Sie sollten eine Antwort wie folgt sehen:

{"message":"Unknown Content-Type in request headers"}

Das ist eine gute Sache – Ihre App läuft!

In webapp.log auf Ihrem Host sehen Sie eine Ausgabe ähnlich dieser:

2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None
2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None

Um Ihnen zu helfen, sofort mit echten Daten in Ihrer App zu spielen, können Sie diese spezielle Postman-Anfrage aus dem Projekt-Repo importieren. Dies simuliert, was Ihr SparkPost-Konto tun wird, d. h. es sendet ein https POST, das eine E-Mail mit einem bestimmten, gültigen Zertifikat (das zu einem Testkonto von mir gehört) an Ihre App sendet.

Sie müssen nur die Zieladresse in der Anfrage (im grauen Feld oben) ändern, um Ihrer Installation zu entsprechen. Wenn Sie den Tokenwert in webapp.ini geändert haben, passen Sie den Header-Wert in Postman entsprechend an.

Wenn Ihre App funktioniert, sehen Sie ein „200 OK“ in Postman. Ihre Host-webapp.log-Datei enthält eine Ausgabe wie diese:

2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778
2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223
2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed
2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature
2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998
2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'}
2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'}
2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True

Für einen schnellen Plausibilitätscheck suchen Sie nach der letzten Zeile – wenn sie „written file“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Check und den Zertifikatsvalidierungsprozess.

Wir beginnen mit diesem Teil, damit wir ihn vollständig getestet haben, bevor wir die eingehenden Relay-Webhooks einrichten.

Die Web-Anwendung ist im selben GitHub-Projekt wie die Teile 1 – 3 enthalten, also wenn Sie diesen Teilen gefolgt sind, haben Sie es schon. Hier sind die neuen Teile:

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- und Benutzerzertifikate parsen.

  • Programm webapp.py – einfache mit Flask kompatible Webanwendung zur Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für die obige Anwendung. Eine Konfigurationsdatei ermöglicht es, dieselben Werte sowohl für Befehlszeilen- als auch Webanwendungen einfach zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen von außen geöffnet hat, damit SparkPost Nachrichten an Ihre App senden kann. Wenn Sie beispielsweise auf AWS EC2 gehostet sind, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anweisungen zum Konfigurieren und Starten der Web-Anwendung finden Sie in unserem Einrichtungsleitfaden – es ist ziemlich einfach. Um zu überprüfen, ob Ihre App läuft und von der Außenwelt zugänglich ist, können Sie (leere) Anfragen von einem anderen Host senden, z.B. mit curl:

curl -X POST https://app.trymsys.net:8855/

Sie sollten eine Antwort wie folgt sehen:

{"message":"Unknown Content-Type in request headers"}

Das ist eine gute Sache – Ihre App läuft!

In webapp.log auf Ihrem Host sehen Sie eine Ausgabe ähnlich dieser:

2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None
2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None

Um Ihnen zu helfen, sofort mit echten Daten in Ihrer App zu spielen, können Sie diese spezielle Postman-Anfrage aus dem Projekt-Repo importieren. Dies simuliert, was Ihr SparkPost-Konto tun wird, d. h. es sendet ein https POST, das eine E-Mail mit einem bestimmten, gültigen Zertifikat (das zu einem Testkonto von mir gehört) an Ihre App sendet.

Sie müssen nur die Zieladresse in der Anfrage (im grauen Feld oben) ändern, um Ihrer Installation zu entsprechen. Wenn Sie den Tokenwert in webapp.ini geändert haben, passen Sie den Header-Wert in Postman entsprechend an.

Wenn Ihre App funktioniert, sehen Sie ein „200 OK“ in Postman. Ihre Host-webapp.log-Datei enthält eine Ausgabe wie diese:

2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778
2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223
2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed
2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature
2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998
2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'}
2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'}
2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True

Für einen schnellen Plausibilitätscheck suchen Sie nach der letzten Zeile – wenn sie „written file“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Check und den Zertifikatsvalidierungsprozess.

Wir beginnen mit diesem Teil, damit wir ihn vollständig getestet haben, bevor wir die eingehenden Relay-Webhooks einrichten.

Die Web-Anwendung ist im selben GitHub-Projekt wie die Teile 1 – 3 enthalten, also wenn Sie diesen Teilen gefolgt sind, haben Sie es schon. Hier sind die neuen Teile:

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- und Benutzerzertifikate parsen.

  • Programm webapp.py – einfache mit Flask kompatible Webanwendung zur Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für die obige Anwendung. Eine Konfigurationsdatei ermöglicht es, dieselben Werte sowohl für Befehlszeilen- als auch Webanwendungen einfach zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen von außen geöffnet hat, damit SparkPost Nachrichten an Ihre App senden kann. Wenn Sie beispielsweise auf AWS EC2 gehostet sind, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anweisungen zum Konfigurieren und Starten der Web-Anwendung finden Sie in unserem Einrichtungsleitfaden – es ist ziemlich einfach. Um zu überprüfen, ob Ihre App läuft und von der Außenwelt zugänglich ist, können Sie (leere) Anfragen von einem anderen Host senden, z.B. mit curl:

curl -X POST https://app.trymsys.net:8855/

Sie sollten eine Antwort wie folgt sehen:

{"message":"Unknown Content-Type in request headers"}

Das ist eine gute Sache – Ihre App läuft!

In webapp.log auf Ihrem Host sehen Sie eine Ausgabe ähnlich dieser:

2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None
2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None

Um Ihnen zu helfen, sofort mit echten Daten in Ihrer App zu spielen, können Sie diese spezielle Postman-Anfrage aus dem Projekt-Repo importieren. Dies simuliert, was Ihr SparkPost-Konto tun wird, d. h. es sendet ein https POST, das eine E-Mail mit einem bestimmten, gültigen Zertifikat (das zu einem Testkonto von mir gehört) an Ihre App sendet.

Sie müssen nur die Zieladresse in der Anfrage (im grauen Feld oben) ändern, um Ihrer Installation zu entsprechen. Wenn Sie den Tokenwert in webapp.ini geändert haben, passen Sie den Header-Wert in Postman entsprechend an.

Wenn Ihre App funktioniert, sehen Sie ein „200 OK“ in Postman. Ihre Host-webapp.log-Datei enthält eine Ausgabe wie diese:

2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/
2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778
2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223
2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed
2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None
2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature
2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998
2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'}
2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'}
2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True

Für einen schnellen Plausibilitätscheck suchen Sie nach der letzten Zeile – wenn sie „written file“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Check und den Zertifikatsvalidierungsprozess.

3. SparkPost Eingang Weiterleitungs-Webhooks Einrichtung

Erstens wählen wir eine Domain aus, die wir als unsere eingehende Nachrichtenadresse verwenden – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain gemäß diesem Leitfaden ein. Hier sind die Schritte, die ich im Detail verwendet habe:

3.1 MX-Einträge hinzufügen

Sie benötigen Zugriff auf Ihr spezifisches Internetdienstanbieter-Konto. Wenn dies erledigt ist, können Sie sie mit dig überprüfen – hier ist der Befehl für meine Domain.

dig +short MX inbound.thetucks.com

Sie sollten folgendes sehen:

10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com

3.2 Erstellen einer eingehenden Domain

Verwenden Sie die SparkPost Postman API collection, indem Sie den Inbound Domains / Create .. Aufruf auswählen. Der Körper der POST-Anfrage enthält Ihre Domain, zum Beispiel:

{ "domain": "inbound.thetucks.com" }
Postman desktop application with an open tab displaying a 'Create an Inbound Domain' API request, featuring fields such as domain input, several header options, and a JSON payload, aimed at testing and automating API workflows.


3.3 Erstellen eines Relay-Webhooks

Erstellen Sie einen eingehenden Relay-Webhook mit dem entsprechenden Postman-Aufruf. Der Nachrichtenkörper enthält in meinem Fall:

{
  "name": "Certificate Collection Webhook",
  "target": "https://app.trymsys.net:8855/",
  "auth_token": "t0p s3cr3t t0k3n",
  "match": {
    "protocol": "SMTP",
    "domain": "inbound.thetucks.com"
  }
}

Wie bereits erwähnt, empfehle ich, ein auth_token festzulegen, das Ihrem eigenen geheimen Wert entspricht, wie es in der webapp.ini-Datei auf Ihrem Host festgelegt ist.

Ihr „target“-Wert muss mit Ihrer Host-Adresse und dem TCP-Port übereinstimmen, auf dem Sie die Webanwendung hosten werden.

Ihr „domain“-Wert muss mit den MX-Einträgen übereinstimmen, die Sie in Schritt 1 eingerichtet haben.

Postman interface, showing the process of creating a relay webhook with detailed JSON configuration, with sections including request method, parameters, and code snippet.


Das war's! Die Einrichtung ist abgeschlossen. Sie sollten nun in der Lage sein, Zertifikate an Ihre eingehende Adresse zu senden, sie werden verarbeitet und auf Ihrem Webanwendungshost angezeigt – in diesem Fall eine Datei namens bob.lumreeker@gmail.com.crt.

Jetzt können Sie verschlüsselte E-Mails an Bob senden, indem Sie die in den Teilen 2 & 3 dieser Serie beschriebenen Werkzeuge verwenden.

Sie können den Inhalt eines Zertifikats mit folgendem Befehl prüfen:

openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout

Erstens wählen wir eine Domain aus, die wir als unsere eingehende Nachrichtenadresse verwenden – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain gemäß diesem Leitfaden ein. Hier sind die Schritte, die ich im Detail verwendet habe:

3.1 MX-Einträge hinzufügen

Sie benötigen Zugriff auf Ihr spezifisches Internetdienstanbieter-Konto. Wenn dies erledigt ist, können Sie sie mit dig überprüfen – hier ist der Befehl für meine Domain.

dig +short MX inbound.thetucks.com

Sie sollten folgendes sehen:

10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com

3.2 Erstellen einer eingehenden Domain

Verwenden Sie die SparkPost Postman API collection, indem Sie den Inbound Domains / Create .. Aufruf auswählen. Der Körper der POST-Anfrage enthält Ihre Domain, zum Beispiel:

{ "domain": "inbound.thetucks.com" }
Postman desktop application with an open tab displaying a 'Create an Inbound Domain' API request, featuring fields such as domain input, several header options, and a JSON payload, aimed at testing and automating API workflows.


3.3 Erstellen eines Relay-Webhooks

Erstellen Sie einen eingehenden Relay-Webhook mit dem entsprechenden Postman-Aufruf. Der Nachrichtenkörper enthält in meinem Fall:

{
  "name": "Certificate Collection Webhook",
  "target": "https://app.trymsys.net:8855/",
  "auth_token": "t0p s3cr3t t0k3n",
  "match": {
    "protocol": "SMTP",
    "domain": "inbound.thetucks.com"
  }
}

Wie bereits erwähnt, empfehle ich, ein auth_token festzulegen, das Ihrem eigenen geheimen Wert entspricht, wie es in der webapp.ini-Datei auf Ihrem Host festgelegt ist.

Ihr „target“-Wert muss mit Ihrer Host-Adresse und dem TCP-Port übereinstimmen, auf dem Sie die Webanwendung hosten werden.

Ihr „domain“-Wert muss mit den MX-Einträgen übereinstimmen, die Sie in Schritt 1 eingerichtet haben.

Postman interface, showing the process of creating a relay webhook with detailed JSON configuration, with sections including request method, parameters, and code snippet.


Das war's! Die Einrichtung ist abgeschlossen. Sie sollten nun in der Lage sein, Zertifikate an Ihre eingehende Adresse zu senden, sie werden verarbeitet und auf Ihrem Webanwendungshost angezeigt – in diesem Fall eine Datei namens bob.lumreeker@gmail.com.crt.

Jetzt können Sie verschlüsselte E-Mails an Bob senden, indem Sie die in den Teilen 2 & 3 dieser Serie beschriebenen Werkzeuge verwenden.

Sie können den Inhalt eines Zertifikats mit folgendem Befehl prüfen:

openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout

Erstens wählen wir eine Domain aus, die wir als unsere eingehende Nachrichtenadresse verwenden – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain gemäß diesem Leitfaden ein. Hier sind die Schritte, die ich im Detail verwendet habe:

3.1 MX-Einträge hinzufügen

Sie benötigen Zugriff auf Ihr spezifisches Internetdienstanbieter-Konto. Wenn dies erledigt ist, können Sie sie mit dig überprüfen – hier ist der Befehl für meine Domain.

dig +short MX inbound.thetucks.com

Sie sollten folgendes sehen:

10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com

3.2 Erstellen einer eingehenden Domain

Verwenden Sie die SparkPost Postman API collection, indem Sie den Inbound Domains / Create .. Aufruf auswählen. Der Körper der POST-Anfrage enthält Ihre Domain, zum Beispiel:

{ "domain": "inbound.thetucks.com" }
Postman desktop application with an open tab displaying a 'Create an Inbound Domain' API request, featuring fields such as domain input, several header options, and a JSON payload, aimed at testing and automating API workflows.


3.3 Erstellen eines Relay-Webhooks

Erstellen Sie einen eingehenden Relay-Webhook mit dem entsprechenden Postman-Aufruf. Der Nachrichtenkörper enthält in meinem Fall:

{
  "name": "Certificate Collection Webhook",
  "target": "https://app.trymsys.net:8855/",
  "auth_token": "t0p s3cr3t t0k3n",
  "match": {
    "protocol": "SMTP",
    "domain": "inbound.thetucks.com"
  }
}

Wie bereits erwähnt, empfehle ich, ein auth_token festzulegen, das Ihrem eigenen geheimen Wert entspricht, wie es in der webapp.ini-Datei auf Ihrem Host festgelegt ist.

Ihr „target“-Wert muss mit Ihrer Host-Adresse und dem TCP-Port übereinstimmen, auf dem Sie die Webanwendung hosten werden.

Ihr „domain“-Wert muss mit den MX-Einträgen übereinstimmen, die Sie in Schritt 1 eingerichtet haben.

Postman interface, showing the process of creating a relay webhook with detailed JSON configuration, with sections including request method, parameters, and code snippet.


Das war's! Die Einrichtung ist abgeschlossen. Sie sollten nun in der Lage sein, Zertifikate an Ihre eingehende Adresse zu senden, sie werden verarbeitet und auf Ihrem Webanwendungshost angezeigt – in diesem Fall eine Datei namens bob.lumreeker@gmail.com.crt.

Jetzt können Sie verschlüsselte E-Mails an Bob senden, indem Sie die in den Teilen 2 & 3 dieser Serie beschriebenen Werkzeuge verwenden.

Sie können den Inhalt eines Zertifikats mit folgendem Befehl prüfen:

openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout

4. Internals: DKIM-Prüfung, Zertifikatsvalidierung

Die App überprüft, ob empfangene E-Mails gültige DKIM haben und überprüft, dass die Zertifikate selbst gültig sind, wie hier beschrieben. Es gibt dort auch Implementierungshinweise und Ideen für die weitere Arbeit.

Die App überprüft, ob empfangene E-Mails gültige DKIM haben und überprüft, dass die Zertifikate selbst gültig sind, wie hier beschrieben. Es gibt dort auch Implementierungshinweise und Ideen für die weitere Arbeit.

Die App überprüft, ob empfangene E-Mails gültige DKIM haben und überprüft, dass die Zertifikate selbst gültig sind, wie hier beschrieben. Es gibt dort auch Implementierungshinweise und Ideen für die weitere Arbeit.

Zusammenfassend…

Wir haben gesehen, wie Empfänger-öffentliche Schlüssel einfach mithilfe einer E-Mail an eine eingehende Relay-Webhooks-Adresse gesammelt werden können. Sobald dies erledigt ist, können diese Empfänger ihre Nachrichten in S/MIME-verschlüsselter Form erhalten.

Das war's für den Moment! Viel Spaß beim Versenden.

Wir haben gesehen, wie Empfänger-öffentliche Schlüssel einfach mithilfe einer E-Mail an eine eingehende Relay-Webhooks-Adresse gesammelt werden können. Sobald dies erledigt ist, können diese Empfänger ihre Nachrichten in S/MIME-verschlüsselter Form erhalten.

Das war's für den Moment! Viel Spaß beim Versenden.

Wir haben gesehen, wie Empfänger-öffentliche Schlüssel einfach mithilfe einer E-Mail an eine eingehende Relay-Webhooks-Adresse gesammelt werden können. Sobald dies erledigt ist, können diese Empfänger ihre Nachrichten in S/MIME-verschlüsselter Form erhalten.

Das war's für den Moment! Viel Spaß beim Versenden.

Andere Neuigkeiten

Mehr lesen aus dieser Kategorie

A person is standing at a desk while typing on a laptop.

Die komplette AI-native Plattform, die mit Ihrem Business skalierbar ist.

Kontaktieren Sie den Vertrieb

Kostenlos starten

© 2025 Bird

Support kontaktieren

A person is standing at a desk while typing on a laptop.

Die komplette AI-native Plattform, die mit Ihrem Business skalierbar ist.

Kontaktieren Sie den Vertrieb

Kostenlos starten

© 2025 Bird

Support kontaktieren

A person is standing at a desk while typing on a laptop.

Die komplette AI-native Plattform, die mit Ihrem Business skalierbar ist.

Kontaktieren Sie den Vertrieb

Kostenlos starten

© 2025 Bird

Support kontaktieren