S/MIME Parte 4: Raccolta delle Chiavi Pubbliche dei Destinatari nel Modo Semplice – con gli Webhook del Relay Inbound di SparkPost
Uccello
1 feb 2019
1 min read

Punti Chiave
Premessa: Inviare email S/MIME crittografate non è difficile una volta che puoi raccogliere automaticamente la chiave pubblica di ogni destinatario. Questo post colma quella lacuna utilizzando SparkPost Inbound Relay Webhooks per ricevere email firmate, estrarre certificati e conservarli per la crittografia successiva.
Obiettivo: Costruire un servizio webhook basato su Flask che ascolta i messaggi firmati in arrivo, li valuta (verifiche DKIM + certificato) e scrive in modo sicuro ciascuna chiave pubblica su disco per l'uso nell'email sicura in uscita.
Caratteristiche:
Problema: Lo scambio manuale di chiavi non scala per le email generate dall'app.
Soluzione: Invitare gli utenti a inviare un'email firmata; il webhook in entrata analizza automaticamente e memorizza il loro certificato PEM.
Passi di configurazione:
Configura un Dominio Inbound e record MX (ad esempio, inbound.tuodominio.com).
Crea un Webhook Inbound Relay tramite l'API di SparkPost che punta al tuo endpoint dell'app.
Installa una piccola app Flask (webapp.py) utilizzando la configurazione di webapp.ini.
Registrati ampiamente per trasparenza; integra Pytest + Travis CI per la validazione automatizzata.
Misure di sicurezza:
Verifica le firme DKIM e l'autenticità dei messaggi.
Valida la catena di fiducia del certificato prima di memorizzarlo.
Usa un token di autenticazione segreto negli header del webhook.
Output:
Ogni messaggio in entrata valido crea un file di certificato come bob.lumreeker@gmail.com.crt.
Una volta memorizzate, queste chiavi abilitano risposte crittografate utilizzando script precedenti delle parti 2 e 3.
Punti salienti del Q&A
Perché è così fondamentale raccogliere le chiavi dei destinatari per S/MIME?
Poiché la crittografia richiede la chiave pubblica di ciascun destinatario; automatizzare questo passaggio consente a qualsiasi app di inviare email sicure senza scambio manuale.
In che modo il webhook Inbound Relay di SparkPost semplifica la raccolta delle chiavi?
Converte qualsiasi email in entrata firmata in un payload JSON strutturato, consentendo alla tua app di analizzare e conservare i certificati programmaticamente.
Quali misure di protezione prevengono la falsificazione o invii indesiderati?
Il servizio convalida le firme DKIM, applica i token di autenticazione e rifiuta i messaggi malformati o non firmati.
Dove sono memorizzati i certificati e in quale formato?
Sono scritti su disco in PEM formato (
.crtfile), pronti per essere utilizzati dagli strumenti di firma/crittografia costruiti nelle parti precedenti.Qual è il flusso di lavoro dello sviluppatore?
Esegui l'app Flask, verifica con Postman utilizzando il payload di esempio fornito, quindi collegala al webhook live di SparkPost per un'operazione continua.
Conclusione generale?
La gestione delle chiavi S/MIME può essere completamente automatizzata con alcune righe di Python e delle API di SparkPost, portando la crittografia scalabile a qualsiasi flusso di lavoro email generato dall'app.
Nella parte 1, abbiamo fatto un rapido tour di S/MIME, esaminando la firma e la crittografia dei nostri flussi di messaggi attraverso una serie di client di posta. La parte 2 ci ha portato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, per poi inviarle tramite SparkPost. La parte 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme on-premises come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare email crittografate S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per esseri umani come Thunderbird – ma come può funzionare con flussi di email generati da app? Le email generate da app, come quelle utilizzate dalle piattaforme di incontri, richiedono una strategia attenta per massimizzare il coinvolgimento. Vedi come le app di incontri creano esperienze email attivate compulsive.
Ma aspetta – c'è un altro modo per entrare a Mordor e ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, ovviamente) a inviarti indietro un'email firmata a un indirizzo di assistenza clienti noto. Usando i poteri magici dei webhook di SparkPost Inbound Relay, estrarremo e conserveremo quella chiave pubblica per te da utilizzare.
Possiamo riassumere questo in un semplice caso d'uso:
Come destinatario di messaggi, fornisco al tuo servizio la mia firma email personale tramite email, in modo che in futuro, le email possano essere inviate a me in forma crittografata S/MIME.
Da questo, deriviamo alcuni requisiti più dettagliati:
Abbiamo bisogno di un servizio email in entrata sempre attivo e affidabile per ricevere quelle email firmate.
Non ci dovrebbero essere requisiti speciali sul formato della posta, oltre al fatto che dovrebbe contenere una firma S/MIME.
Poiché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per rifiutare messaggi
Nella parte 1, abbiamo fatto un rapido tour di S/MIME, esaminando la firma e la crittografia dei nostri flussi di messaggi attraverso una serie di client di posta. La parte 2 ci ha portato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, per poi inviarle tramite SparkPost. La parte 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme on-premises come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare email crittografate S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per esseri umani come Thunderbird – ma come può funzionare con flussi di email generati da app? Le email generate da app, come quelle utilizzate dalle piattaforme di incontri, richiedono una strategia attenta per massimizzare il coinvolgimento. Vedi come le app di incontri creano esperienze email attivate compulsive.
Ma aspetta – c'è un altro modo per entrare a Mordor e ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, ovviamente) a inviarti indietro un'email firmata a un indirizzo di assistenza clienti noto. Usando i poteri magici dei webhook di SparkPost Inbound Relay, estrarremo e conserveremo quella chiave pubblica per te da utilizzare.
Possiamo riassumere questo in un semplice caso d'uso:
Come destinatario di messaggi, fornisco al tuo servizio la mia firma email personale tramite email, in modo che in futuro, le email possano essere inviate a me in forma crittografata S/MIME.
Da questo, deriviamo alcuni requisiti più dettagliati:
Abbiamo bisogno di un servizio email in entrata sempre attivo e affidabile per ricevere quelle email firmate.
Non ci dovrebbero essere requisiti speciali sul formato della posta, oltre al fatto che dovrebbe contenere una firma S/MIME.
Poiché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per rifiutare messaggi
Nella parte 1, abbiamo fatto un rapido tour di S/MIME, esaminando la firma e la crittografia dei nostri flussi di messaggi attraverso una serie di client di posta. La parte 2 ci ha portato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, per poi inviarle tramite SparkPost. La parte 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme on-premises come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare email crittografate S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per esseri umani come Thunderbird – ma come può funzionare con flussi di email generati da app? Le email generate da app, come quelle utilizzate dalle piattaforme di incontri, richiedono una strategia attenta per massimizzare il coinvolgimento. Vedi come le app di incontri creano esperienze email attivate compulsive.
Ma aspetta – c'è un altro modo per entrare a Mordor e ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, ovviamente) a inviarti indietro un'email firmata a un indirizzo di assistenza clienti noto. Usando i poteri magici dei webhook di SparkPost Inbound Relay, estrarremo e conserveremo quella chiave pubblica per te da utilizzare.
Possiamo riassumere questo in un semplice caso d'uso:
Come destinatario di messaggi, fornisco al tuo servizio la mia firma email personale tramite email, in modo che in futuro, le email possano essere inviate a me in forma crittografata S/MIME.
Da questo, deriviamo alcuni requisiti più dettagliati:
Abbiamo bisogno di un servizio email in entrata sempre attivo e affidabile per ricevere quelle email firmate.
Non ci dovrebbero essere requisiti speciali sul formato della posta, oltre al fatto che dovrebbe contenere una firma S/MIME.
Poiché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per rifiutare messaggi
1. Panoramica della soluzione
Ecco come apparirà la soluzione complessiva.

Ecco come apparirà la soluzione complessiva.

Ecco come apparirà la soluzione complessiva.

2. Installazione, configurazione e avvio dell'app web
Inizieremo con questa parte, in modo da averla completamente testata prima di collegare i webhook di relay in entrata.
La web app è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, ce l'hai già. Ecco le nuove funzioni:
Programma readSMIMEsig.py – leggi un'email e analizza i certificati intermedi e utente.
Programma webapp.py – applicazione web semplice compatibile con Flask da utilizzare con i Webhook di Relay Inbound di SparkPost.
webapp.ini – file di configurazione per quanto sopra. Un file di configurazione consente di passare gli stessi valori facilmente sia alle applicazioni da riga di comando che a quelle web.
Devi assicurarti che il tuo host abbia aperto il numero di porta TCP corretto per le richieste in entrata dal mondo esterno in modo che SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Gruppo di Sicurezza della tua istanza.
Le istruzioni per configurare e avviare la web app sono fornite nella nostra guida all'installazione – è piuttosto facile. Per controllare che la tua app sia in esecuzione e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host utilizzando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
È una cosa positiva – la tua app è in esecuzione!
Nel webapp.log del tuo host, vedrai un output simile a questo:
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
Per aiutarti a lavorare con dati reali nella tua app immediatamente, puoi importare questa specifica richiesta di Postman dal repository del progetto. Questo simula ciò che il tuo account SparkPost farà, ovvero invia un'email con un certificato specifico e valido (appartenente a un mio account di test) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nel riquadro grigio sopra) per farlo corrispondere alla tua installazione. Se hai cambiato il valore del token in webapp.ini, regola il valore dell'intestazione in Postman per farlo corrispondere.
Se la tua app funziona, vedrai una risposta “200 OK” di ritorno in Postman. Il file webapp.log del tuo host conterrà un output simile a questo:
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
Per un rapido controllo della correttezza, cerca l'ultima riga – se dice “file scritto”, sei a posto. Il resto di questo mostra il processo di controllo DKIM e validazione del certificato.
Inizieremo con questa parte, in modo da averla completamente testata prima di collegare i webhook di relay in entrata.
La web app è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, ce l'hai già. Ecco le nuove funzioni:
Programma readSMIMEsig.py – leggi un'email e analizza i certificati intermedi e utente.
Programma webapp.py – applicazione web semplice compatibile con Flask da utilizzare con i Webhook di Relay Inbound di SparkPost.
webapp.ini – file di configurazione per quanto sopra. Un file di configurazione consente di passare gli stessi valori facilmente sia alle applicazioni da riga di comando che a quelle web.
Devi assicurarti che il tuo host abbia aperto il numero di porta TCP corretto per le richieste in entrata dal mondo esterno in modo che SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Gruppo di Sicurezza della tua istanza.
Le istruzioni per configurare e avviare la web app sono fornite nella nostra guida all'installazione – è piuttosto facile. Per controllare che la tua app sia in esecuzione e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host utilizzando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
È una cosa positiva – la tua app è in esecuzione!
Nel webapp.log del tuo host, vedrai un output simile a questo:
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
Per aiutarti a lavorare con dati reali nella tua app immediatamente, puoi importare questa specifica richiesta di Postman dal repository del progetto. Questo simula ciò che il tuo account SparkPost farà, ovvero invia un'email con un certificato specifico e valido (appartenente a un mio account di test) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nel riquadro grigio sopra) per farlo corrispondere alla tua installazione. Se hai cambiato il valore del token in webapp.ini, regola il valore dell'intestazione in Postman per farlo corrispondere.
Se la tua app funziona, vedrai una risposta “200 OK” di ritorno in Postman. Il file webapp.log del tuo host conterrà un output simile a questo:
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
Per un rapido controllo della correttezza, cerca l'ultima riga – se dice “file scritto”, sei a posto. Il resto di questo mostra il processo di controllo DKIM e validazione del certificato.
Inizieremo con questa parte, in modo da averla completamente testata prima di collegare i webhook di relay in entrata.
La web app è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, ce l'hai già. Ecco le nuove funzioni:
Programma readSMIMEsig.py – leggi un'email e analizza i certificati intermedi e utente.
Programma webapp.py – applicazione web semplice compatibile con Flask da utilizzare con i Webhook di Relay Inbound di SparkPost.
webapp.ini – file di configurazione per quanto sopra. Un file di configurazione consente di passare gli stessi valori facilmente sia alle applicazioni da riga di comando che a quelle web.
Devi assicurarti che il tuo host abbia aperto il numero di porta TCP corretto per le richieste in entrata dal mondo esterno in modo che SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Gruppo di Sicurezza della tua istanza.
Le istruzioni per configurare e avviare la web app sono fornite nella nostra guida all'installazione – è piuttosto facile. Per controllare che la tua app sia in esecuzione e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host utilizzando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
È una cosa positiva – la tua app è in esecuzione!
Nel webapp.log del tuo host, vedrai un output simile a questo:
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
Per aiutarti a lavorare con dati reali nella tua app immediatamente, puoi importare questa specifica richiesta di Postman dal repository del progetto. Questo simula ciò che il tuo account SparkPost farà, ovvero invia un'email con un certificato specifico e valido (appartenente a un mio account di test) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nel riquadro grigio sopra) per farlo corrispondere alla tua installazione. Se hai cambiato il valore del token in webapp.ini, regola il valore dell'intestazione in Postman per farlo corrispondere.
Se la tua app funziona, vedrai una risposta “200 OK” di ritorno in Postman. Il file webapp.log del tuo host conterrà un output simile a questo:
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
Per un rapido controllo della correttezza, cerca l'ultima riga – se dice “file scritto”, sei a posto. Il resto di questo mostra il processo di controllo DKIM e validazione del certificato.
3. Configurazione dei webhook di relay in arrivo di SparkPost
In primo luogo, selezioniamo un dominio da utilizzare come nostro indirizzo per i messaggi in arrivo – qui sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passaggi che ho utilizzato in dettaglio:
3.1 Aggiungi record MX
Avrai bisogno di accesso al tuo specifico account del fornitore di servizi Internet. Una volta fatto, puoi controllarli con dig – ecco il comando per il mio dominio.
dig +short MX inbound.thetucks.com
Dovresti vedere:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Crea un Dominio Inbound
Utilizza la collezione API Postman di SparkPost, selezionando il richiamo Inbound Domains / Create .. Il corpo della richiesta POST contiene il tuo dominio, ad esempio:
{ "domain": "inbound.thetucks.com" }

3.3 Crea un Webhook Relay
Crea un webhook relay in ingresso utilizzando il richiamo Postman pertinente. Il corpo del messaggio nel mio caso contiene:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Come già accennato, ti consiglio di impostare un auth_token sul tuo valore segreto, come impostato nel file webapp.ini sul tuo host.
Il tuo valore “target” deve corrispondere all'indirizzo del tuo host e alla porta TCP in cui ospiterai l'app web.
Il tuo valore “domain” deve corrispondere ai tuoi record MX impostati nel passaggio 1.

Questo è tutto! La parte tecnica è fatta. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in arrivo; verranno elaborati e appariranno sul tuo host dell'applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, utilizzando gli strumenti descritti nelle parti 2 e 3 di questa serie.
Puoi esaminare il contenuto di un certificato utilizzando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
In primo luogo, selezioniamo un dominio da utilizzare come nostro indirizzo per i messaggi in arrivo – qui sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passaggi che ho utilizzato in dettaglio:
3.1 Aggiungi record MX
Avrai bisogno di accesso al tuo specifico account del fornitore di servizi Internet. Una volta fatto, puoi controllarli con dig – ecco il comando per il mio dominio.
dig +short MX inbound.thetucks.com
Dovresti vedere:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Crea un Dominio Inbound
Utilizza la collezione API Postman di SparkPost, selezionando il richiamo Inbound Domains / Create .. Il corpo della richiesta POST contiene il tuo dominio, ad esempio:
{ "domain": "inbound.thetucks.com" }

3.3 Crea un Webhook Relay
Crea un webhook relay in ingresso utilizzando il richiamo Postman pertinente. Il corpo del messaggio nel mio caso contiene:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Come già accennato, ti consiglio di impostare un auth_token sul tuo valore segreto, come impostato nel file webapp.ini sul tuo host.
Il tuo valore “target” deve corrispondere all'indirizzo del tuo host e alla porta TCP in cui ospiterai l'app web.
Il tuo valore “domain” deve corrispondere ai tuoi record MX impostati nel passaggio 1.

Questo è tutto! La parte tecnica è fatta. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in arrivo; verranno elaborati e appariranno sul tuo host dell'applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, utilizzando gli strumenti descritti nelle parti 2 e 3 di questa serie.
Puoi esaminare il contenuto di un certificato utilizzando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
In primo luogo, selezioniamo un dominio da utilizzare come nostro indirizzo per i messaggi in arrivo – qui sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passaggi che ho utilizzato in dettaglio:
3.1 Aggiungi record MX
Avrai bisogno di accesso al tuo specifico account del fornitore di servizi Internet. Una volta fatto, puoi controllarli con dig – ecco il comando per il mio dominio.
dig +short MX inbound.thetucks.com
Dovresti vedere:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Crea un Dominio Inbound
Utilizza la collezione API Postman di SparkPost, selezionando il richiamo Inbound Domains / Create .. Il corpo della richiesta POST contiene il tuo dominio, ad esempio:
{ "domain": "inbound.thetucks.com" }

3.3 Crea un Webhook Relay
Crea un webhook relay in ingresso utilizzando il richiamo Postman pertinente. Il corpo del messaggio nel mio caso contiene:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Come già accennato, ti consiglio di impostare un auth_token sul tuo valore segreto, come impostato nel file webapp.ini sul tuo host.
Il tuo valore “target” deve corrispondere all'indirizzo del tuo host e alla porta TCP in cui ospiterai l'app web.
Il tuo valore “domain” deve corrispondere ai tuoi record MX impostati nel passaggio 1.

Questo è tutto! La parte tecnica è fatta. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in arrivo; verranno elaborati e appariranno sul tuo host dell'applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, utilizzando gli strumenti descritti nelle parti 2 e 3 di questa serie.
Puoi esaminare il contenuto di un certificato utilizzando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Interni: Controllo DKIM, convalida del certificato
L'app verifica che le email ricevute abbiano un DKIM valido e controlla che i certificati stessi siano validi, come descritto qui. Ci sono anche note di implementazione e idee per ulteriori lavori.
L'app verifica che le email ricevute abbiano un DKIM valido e controlla che i certificati stessi siano validi, come descritto qui. Ci sono anche note di implementazione e idee per ulteriori lavori.
L'app verifica che le email ricevute abbiano un DKIM valido e controlla che i certificati stessi siano validi, come descritto qui. Ci sono anche note di implementazione e idee per ulteriori lavori.
In sintesi...
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere raccolte facilmente utilizzando un'email a un indirizzo webhook di relay in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buon invio.
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere raccolte facilmente utilizzando un'email a un indirizzo webhook di relay in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buon invio.
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere raccolte facilmente utilizzando un'email a un indirizzo webhook di relay in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buon invio.



