
In deze serie hebben we gezien hoe het toevoegen van een S/MIME-handtekening vrij eenvoudig is. Het verzenden van S/MIME-versleutelde e-mails is complexer omdat je openbare sleutels van de ontvanger moet verkrijgen. Het is één ding wanneer je een mailclient gebruikt voor mensen zoals Thunderbird – maar hoe werkt dat met app-gegeneerde e-mailstromen?
Business in a box.
Ontdek onze oplossingen.
Praat met ons verkoopteam
In deel 1 hadden we een snelle rondleiding van S/MIME, waarbij we keken naar het ondertekenen en versleutelen van onze berichtstromen over een reeks mailclients. Deel 2 nam ons mee door een eenvoudige opdrachtregeltool om e-mails te ondertekenen en versleutelen, en deze vervolgens via SparkPost te verzenden. Deel 3 liet zien hoe je veilige mailstromen in on-premise platformen zoals Port25 PowerMTA en Momentum kunt injecteren.
In deze serie hebben we gezien hoe het opnemen van een S/MIME-handtekening vrij eenvoudig is. Het verzenden van S/MIME-versleutelde mail is ingewikkelder omdat je openbare sleutels van de ontvanger moet verkrijgen. Het is één ding wanneer je een mailclient voor mensen zoals Thunderbird gebruikt – maar hoe kan dat werken met app-gegenereerde e-mailstromen?
Maar wacht – er is een andere manier om die sleutels in Mordor te verkrijgen. Uw service kan uw klanten uitnodigen (uiteraard via e-mail) om een ondertekende mail terug te sturen naar een bekend klantenserviceadres. Met behulp van de magische krachten van SparkPost Inbound Relay webhooks, zullen we die openbare sleutel voor u extraheren en opslaan.
We kunnen dit samenvatten in een eenvoudig gebruiksscenario:
Als ontvanger van berichten geef ik uw service mijn persoonlijke e-mailhandtekening via e-mail, zodat in de toekomst e-mails aan mij kunnen worden verzonden in S/MIME-versleutelde vorm.
Hieruit kunnen we enkele meer gedetailleerde vereisten afleiden:
We hebben een altijd actieve, betrouwbare inkomende e-mailservice nodig om die ondertekende e-mails te ontvangen.
Er mogen geen speciale vereisten zijn voor het mailformaat, anders dan dat het een S/MIME-handtekening moet dragen.
Aangezien iedereen kan proberen om een mail naar deze service te sturen, moet het defensief worden ontworpen, bijvoorbeeld om 'spoof'-berichten van kwaadwillenden te weigeren. Er moeten verschillende lagen van controle zijn.
Als alles goedgekeurd is, zal de service het certificaat in een bestand opslaan, in het bekende tekstformaat Privacy-Enhanced Mail (PEM).
Er zijn enkele niet-functionele vereisten:
Machine-to-machine webhookdiensten kunnen moeilijk te zien zijn alleen aan de hand van reacties op wat er binnen gebeurt. De service moet uitgebreide mensleesbare applicatieniveau logboeken bieden. In het bijzonder moeten het certificaat parseren en controleren worden gelogd.
We voegen testcases toe voor de interne werking van de app, met behulp van het leuke Pytest framework, en voeren die tests automatisch uit bij het inchecken met Travis CI integratie met GitHub.
OK – laten we beginnen!
1. Oplossingsoverzicht
Dit is hoe de totale oplossing eruit zal zien.

2. Installeren, configureren en starten van de web app
3. SparkPost inbound relay webhooks instellen
Allereerst selecteren we een domein dat we gaan gebruiken als ons inkomend berichtadres – hier zal het zijn inbound.thetucks.com. Stel je domein in volgens deze gids. Hier zijn de stappen die ik in detail heb gebruikt:
3.1 Voeg MX Records toe
Je hebt toegang nodig tot je specifieke Internet Service Provider-account. Wanneer je klaar bent, kun je ze controleren met dig – hier is het commando voor mijn domein.
dig +short MX inbound.thetucks.com
Je zou het volgende moeten zien:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com.
3.2 Maak een Inkomend Domein
Gebruik de SparkPost Postman API collectie, door de Inkomende Domeinen / Creëer .. oproep te selecteren. Het lichaam van het POST-verzoek bevat je domein, bijvoorbeeld:
{ "domain": "inbound.thetucks.com" }

3.3 Creëer een Relay Webhook
Maak een inkomende relay webhook met behulp van de relevante Postman oproep. In mijn geval bevat het berichtlichaam:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Zoals eerder vermeld, raad ik aan om een auth_token in te stellen naar je eigen geheime waarde, zoals ingesteld in het webapp.ini bestand op je host.
Je “target” waarde moet overeenkomen met je hostadres en TCP-poort waar je de webapplicatie zult hosten.
Je “domein” waarde moet overeenkomen met je in stap 1 ingestelde MX records.

Dat is het! Het leidingwerk is klaar. Je zou nu certificaten naar je inkomend adres moeten kunnen sturen, ze zullen worden verwerkt en verschijnen op je webapplicatie-host – in dit geval, een bestand genaamd bob.lumreeker@gmail.com.crt.
Nu kun je versleutelde e-mails naar Bob sturen, met behulp van de tools die in delen 2 & 3 van deze serie worden beschreven.
Je kunt de inhoud van een certificaat onderzoeken met:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internals: DKIM-controle, certificaatvalidatie
De app controleert of ontvangen e-mails geldige DKIM hebben en controleert of de certificaten zelf geldig zijn, zoals hier beschreven. Er zijn daar ook implementatieopmerkingen en ideeën voor verder werk.
Samenvattend…
We hebben gezien hoe openbare sleutels van ontvangers eenvoudig kunnen worden verzameld met een e-mail naar een inkomend relay-webhookadres. Zodra dit is gedaan, kunnen die ontvangers hun berichten in S/MIME versleutelde vorm ontvangen.
Dat is het voor nu! Vrolijk verzenden.