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 dieser Reihe haben wir gesehen, dass das Hinzufügen einer S/MIME-Signatur ziemlich unkompliziert ist. Das Senden von S/MIME-verschlüsselten E-Mails ist komplexer, da Sie die öffentlichen Schlüssel der Empfänger benötigen. Es ist eine Sache, wenn Sie einen E-Mail-Client für Menschen wie Thunderbird verwenden – aber wie kann das mit von Anwendungen generierten E-Mail-Streams funktionieren?

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ösung Überblick

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. Installieren, Konfigurieren und Starten der Web-App

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

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

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- sowie Benutzersignaturen herausparsen.

  • Programm webapp.py – einfache, mit Flask kompatible Webanwendung für die Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für das oben Genannte. Eine Konfigurationsdatei ermöglicht es, dieselben Werte einfach sowohl an Befehlszeilen- als auch an Webanwendungen zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen aus der Außenwelt geöffnet hat, damit SparkPost Nachrichten an Ihre App POSTen kann. Wenn Sie zum Beispiel auf AWS EC2 gehostet werden, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anleitungen zum Konfigurieren und Starten der Web-App finden Sie in unserem Einrichtungsleitfaden – es ist ganz einfach. Um zu überprüfen, ob Ihre App läuft und von außen zugänglich ist, können Sie (leere) Anfragen von einem anderen Host über curl senden, zum Beispiel:

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 arbeiten, können Sie diese spezifische 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 meiner Testkonten gehört) zu Ihrer App enthält.

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

Wenn Ihre App funktioniert, sehen Sie eine „200 OK“-Antwort zurück in Postman. Ihre Host-Datei webapp.log wird eine Ausgabe wie diese enthalten:

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 eine schnelle Überprüfung, suchen Sie nach der letzten Zeile – wenn sie „geschriebene Datei“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Prüfungs- und Zertifikatsvalidierungsprozess.

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

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

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- sowie Benutzersignaturen herausparsen.

  • Programm webapp.py – einfache, mit Flask kompatible Webanwendung für die Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für das oben Genannte. Eine Konfigurationsdatei ermöglicht es, dieselben Werte einfach sowohl an Befehlszeilen- als auch an Webanwendungen zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen aus der Außenwelt geöffnet hat, damit SparkPost Nachrichten an Ihre App POSTen kann. Wenn Sie zum Beispiel auf AWS EC2 gehostet werden, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anleitungen zum Konfigurieren und Starten der Web-App finden Sie in unserem Einrichtungsleitfaden – es ist ganz einfach. Um zu überprüfen, ob Ihre App läuft und von außen zugänglich ist, können Sie (leere) Anfragen von einem anderen Host über curl senden, zum Beispiel:

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 arbeiten, können Sie diese spezifische 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 meiner Testkonten gehört) zu Ihrer App enthält.

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

Wenn Ihre App funktioniert, sehen Sie eine „200 OK“-Antwort zurück in Postman. Ihre Host-Datei webapp.log wird eine Ausgabe wie diese enthalten:

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 eine schnelle Überprüfung, suchen Sie nach der letzten Zeile – wenn sie „geschriebene Datei“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Prüfungs- und Zertifikatsvalidierungsprozess.

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

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

  • Programm readSMIMEsig.py – eine E-Mail lesen und Zwischen- sowie Benutzersignaturen herausparsen.

  • Programm webapp.py – einfache, mit Flask kompatible Webanwendung für die Verwendung mit SparkPost Inbound Relay Webhooks.

  • webapp.ini – Konfigurationsdatei für das oben Genannte. Eine Konfigurationsdatei ermöglicht es, dieselben Werte einfach sowohl an Befehlszeilen- als auch an Webanwendungen zu übergeben.

Sie müssen sicherstellen, dass Ihr Host die richtige TCP-Portnummer für eingehende Anfragen aus der Außenwelt geöffnet hat, damit SparkPost Nachrichten an Ihre App POSTen kann. Wenn Sie zum Beispiel auf AWS EC2 gehostet werden, müssen Sie die Security Group Ihrer Instanz konfigurieren.

Anleitungen zum Konfigurieren und Starten der Web-App finden Sie in unserem Einrichtungsleitfaden – es ist ganz einfach. Um zu überprüfen, ob Ihre App läuft und von außen zugänglich ist, können Sie (leere) Anfragen von einem anderen Host über curl senden, zum Beispiel:

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 arbeiten, können Sie diese spezifische 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 meiner Testkonten gehört) zu Ihrer App enthält.

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

Wenn Ihre App funktioniert, sehen Sie eine „200 OK“-Antwort zurück in Postman. Ihre Host-Datei webapp.log wird eine Ausgabe wie diese enthalten:

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 eine schnelle Überprüfung, suchen Sie nach der letzten Zeile – wenn sie „geschriebene Datei“ sagt, dann sind Sie gut. Der Rest zeigt den DKIM-Prüfungs- und Zertifikatsvalidierungsprozess.

3. SparkPost Inbound-Relay-Webhooks-Einrichtung

Zunächst wählen wir eine Domain aus, die wir als unsere Eingangs-Nachrichtenadresse verwenden – hier wird es inbound.thetucks.com sein. Richten Sie Ihre Domain gemäß dieser Anleitung 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 Eine Eingangs-Domain erstellen

Verwenden Sie die SparkPost Postman API-Sammlung, indem Sie den Inbound Domains / Create.. Aufruf auswählen. Der POST-Anfragetext 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 Sie einen Relay-Webhook

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

{
  "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 im webapp.ini-Datei auf Ihrem Host festgelegt.

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 Ihren in Schritt 1 eingerichteten MX-Einträgen übereinstimmen.

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 Eingangsadresse zu senden. Sie werden verarbeitet und auf Ihrem Webhost 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 überprüfen, indem Sie:

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

4. Interna: DKIM-Überprüfung, Zertifikatsvalidierung

Die App überprüft, ob empfangene E-Mails ein gültiges DKIM haben, und prüft, ob die Zertifikate selbst gültig sind, wie hier beschrieben. Dort gibt es auch Implementierungshinweise und Ideen für weitere Arbeiten.

Zusammenfassend…

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

Das war’s für jetzt! Viel Spaß beim Senden.

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