S/MIME Parte 4: Raccolta di chiavi pubbliche del destinatario in modo semplice – con le webhook di SparkPost Inbound Relay
Uccello
1 feb 2019
1 min read
Conclusioni principali
Premessa: Inviare email crittografate S/MIME non è difficile una volta che si può raccogliere automaticamente la chiave pubblica di ciascun destinatario. Questo post chiude quella lacuna utilizzando i SparkPost Inbound Relay Webhooks per ricevere email firmate, estrarre i certificati e conservarli per una crittografia successiva.
Obiettivo: Costruire un servizio webhook basato su Flask che ascolta i messaggi firmati in arrivo, li convalida (controlli DKIM + certificato), e scrive ogni chiave pubblica su disco in modo sicuro per l'uso nella posta sicura in uscita.
Punti salienti:
Problema: Lo scambio manuale di chiavi non è scalabile per email generate da app.
Soluzione: Invitare gli utenti a inviare un'email firmata; il webhook in entrata analizza e archivia automaticamente il loro certificato PEM.
Passi di configurazione:
Configurare un Inbound Domain e i record MX (ad esempio, inbound.yourdomain.com).
Creare un Inbound Relay Webhook tramite API SparkPost puntando al tuo endpoint dell'app.
Distribuire una piccola app Flask (webapp.py) utilizzando la configurazione da webapp.ini.
Registrare ampiamente per trasparenza; integrare Pytest + Travis CI per la convalida automatica.
Misure di sicurezza:
Verificare le firme DKIM e l'autenticità dei messaggi.
Convalidare la catena di fiducia del certificato prima della memorizzazione.
Utilizzare un token di autenticazione segreto nell'intestazione del webhook.
Risultato:
Ogni messaggio in entrata valido crea un file di certificato come bob.lumreeker@gmail.com.crt.
Una volta memorizzate, queste chiavi consentono risposte crittografate utilizzando gli script precedenti dalle parti 2 e 3.
Q&A Highlights
Perché è così fondamentale raccogliere le chiavi del destinatario per S/MIME?
Poiché la crittografia richiede la chiave pubblica di ciascun destinatario, automatizzare questo passaggio consente a qualsiasi app di inviare posta sicura senza scambio manuale.
Come semplifica la raccolta delle chiavi il webhook Inbound Relay di SparkPost?
Converte qualsiasi email in entrata firmata in un payload JSON strutturato, consentendo alla tua app di analizzare e memorizzare i certificati in modo programmato.
Quali misure di sicurezza prevengono lo spoofing o le invii di spam?
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 formato PEM (
.crtfile), pronti per l'uso dalla catena di strumenti di firma/crittografia costruita nelle parti precedenti.Qual è il flusso di lavoro del developer?
Esegui l'app Flask, verifica con Postman utilizzando il payload di esempio fornito, quindi collegalo al webhook live di SparkPost per un funzionamento continuo.
Considerazioni generali?
La gestione delle chiavi S/MIME può essere completamente automatizzata con poche righe di Python e le API di SparkPost—portando la crittografia scalabile a qualsiasi flusso di lavoro email generato da app.
In part 1, abbiamo fatto un breve tour di S/MIME, osservando la firma e la crittografia dei nostri flussi di messaggi attraverso una gamma di client di posta. Part 2 ci ha guidato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, quindi inviarle tramite SparkPost. Part 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme locali come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare posta crittografata S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per gli 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 strategie attente per massimizzare il coinvolgimento. Scopri come le app di incontri creano esperienze di email generate automaticamente irresistibili.
Ma aspetta – c'è un altro modo per entrare in Mordor per ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, naturalmente) a rimandare una mail firmata a un indirizzo di servizio clienti noto. Usando i poteri magici dei webhooks SparkPost Inbound Relay, estrarremo e memorizzeremo 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 via 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, a parte il fatto che dovrebbe avere una firma S/MIME.
Perché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per respingere messaggi "spoof" da attori malevoli. Ci saranno diversi livelli di controllo.
Se tutto risulta in ordine, il servizio memorizzerà il certificato in un file, utilizzando il conosciuto formato testuale Privacy-Enhanced Mail (PEM).
Ci sono alcuni requisiti non funzionali:
I servizi webhook macchina-to-macchina possono essere difficili da vedere solo dalle risposte a ciò che sta accadendo all'interno. Il servizio dovrebbe fornire ampi log dell'applicazione leggibili dall'uomo. In particolare, l'analisi e il controllo del certificato dovrebbero essere loggati.
Aggiungiamo casi di test per gli interni dell'app, utilizzando il bel framework Pytest, e eseguiamo automaticamente questi test in fase di check-in tramite l'integrazione Travis CI con GitHub.
OK – iniziamo!
In part 1, abbiamo fatto un breve tour di S/MIME, osservando la firma e la crittografia dei nostri flussi di messaggi attraverso una gamma di client di posta. Part 2 ci ha guidato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, quindi inviarle tramite SparkPost. Part 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme locali come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare posta crittografata S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per gli 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 strategie attente per massimizzare il coinvolgimento. Scopri come le app di incontri creano esperienze di email generate automaticamente irresistibili.
Ma aspetta – c'è un altro modo per entrare in Mordor per ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, naturalmente) a rimandare una mail firmata a un indirizzo di servizio clienti noto. Usando i poteri magici dei webhooks SparkPost Inbound Relay, estrarremo e memorizzeremo 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 via 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, a parte il fatto che dovrebbe avere una firma S/MIME.
Perché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per respingere messaggi "spoof" da attori malevoli. Ci saranno diversi livelli di controllo.
Se tutto risulta in ordine, il servizio memorizzerà il certificato in un file, utilizzando il conosciuto formato testuale Privacy-Enhanced Mail (PEM).
Ci sono alcuni requisiti non funzionali:
I servizi webhook macchina-to-macchina possono essere difficili da vedere solo dalle risposte a ciò che sta accadendo all'interno. Il servizio dovrebbe fornire ampi log dell'applicazione leggibili dall'uomo. In particolare, l'analisi e il controllo del certificato dovrebbero essere loggati.
Aggiungiamo casi di test per gli interni dell'app, utilizzando il bel framework Pytest, e eseguiamo automaticamente questi test in fase di check-in tramite l'integrazione Travis CI con GitHub.
OK – iniziamo!
In part 1, abbiamo fatto un breve tour di S/MIME, osservando la firma e la crittografia dei nostri flussi di messaggi attraverso una gamma di client di posta. Part 2 ci ha guidato attraverso un semplice strumento da riga di comando per firmare e crittografare le email, quindi inviarle tramite SparkPost. Part 3 ha mostrato come iniettare flussi di posta sicuri in piattaforme locali come Port25 PowerMTA e Momentum.
In questa serie, abbiamo visto come includere una firma S/MIME sia abbastanza semplice. Inviare posta crittografata S/MIME è più complesso perché è necessario ottenere le chiavi pubbliche dei destinatari. È una cosa quando si utilizza un client di posta per gli 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 strategie attente per massimizzare il coinvolgimento. Scopri come le app di incontri creano esperienze di email generate automaticamente irresistibili.
Ma aspetta – c'è un altro modo per entrare in Mordor per ottenere quelle chiavi. Il tuo servizio può invitare i tuoi clienti (via email, naturalmente) a rimandare una mail firmata a un indirizzo di servizio clienti noto. Usando i poteri magici dei webhooks SparkPost Inbound Relay, estrarremo e memorizzeremo 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 via 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, a parte il fatto che dovrebbe avere una firma S/MIME.
Perché chiunque può provare a inviare una mail a questo servizio, dovrebbe essere progettato in modo difensivo, ad esempio, per respingere messaggi "spoof" da attori malevoli. Ci saranno diversi livelli di controllo.
Se tutto risulta in ordine, il servizio memorizzerà il certificato in un file, utilizzando il conosciuto formato testuale Privacy-Enhanced Mail (PEM).
Ci sono alcuni requisiti non funzionali:
I servizi webhook macchina-to-macchina possono essere difficili da vedere solo dalle risposte a ciò che sta accadendo all'interno. Il servizio dovrebbe fornire ampi log dell'applicazione leggibili dall'uomo. In particolare, l'analisi e il controllo del certificato dovrebbero essere loggati.
Aggiungiamo casi di test per gli interni dell'app, utilizzando il bel framework Pytest, e eseguiamo automaticamente questi test in fase di check-in tramite l'integrazione Travis CI con GitHub.
OK – iniziamo!
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.
L'app web è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, l'hai già. Ecco le novità:
Programma readSMIMEsig.py – legge un'email e analizza i certificati intermedi e utente.
Programma webapp.py – semplice applicazione web compatibile con Flask per l'uso con SparkPost Inbound Relay Webhooks.
webapp.ini – file di configurazione per il sopra. Un file di configurazione permette di passare facilmente gli stessi valori a entrambe le applicazioni a riga di comando e web.
Devi assicurarti che il tuo host abbia il numero di porta TCP corretto aperto alle richieste in entrata dal mondo esterno affinché SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Security Group della tua istanza.
Le istruzioni per configurare e avviare l'app web sono fornite nella nostra guida di configurazione – è abbastanza semplice. Per verificare che la tua app sia attiva e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host usando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
Questo è un buon segno – la tua app è attiva!
In webapp.log sul 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 giocare con dati reali nella tua app subito, puoi importare questa specifica richiesta Postman dal repository del progetto. Questa simula ciò che farà il tuo account SparkPost, cioè invia un https POST contenente un'email con un certificato specifico e valido (appartenente a un mio account di prova) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nella casella grigia sopra) per adattarlo alla tua installazione. Se hai cambiato il valore del token in webapp.ini, modifica il valore del header in Postman per abbinare.
Se la tua app funziona, vedrai una risposta “200 OK” indietro in Postman. Il file registro webapp.log del tuo host conterrà un output come 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 mentale, cerca l'ultima riga – se dice “written file”, allora stai andando bene. Il resto mostra il processo di verifica DKIM e validazione certificato.
Inizieremo con questa parte, in modo da averla completamente testata prima di collegare i webhook di relay in entrata.
L'app web è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, l'hai già. Ecco le novità:
Programma readSMIMEsig.py – legge un'email e analizza i certificati intermedi e utente.
Programma webapp.py – semplice applicazione web compatibile con Flask per l'uso con SparkPost Inbound Relay Webhooks.
webapp.ini – file di configurazione per il sopra. Un file di configurazione permette di passare facilmente gli stessi valori a entrambe le applicazioni a riga di comando e web.
Devi assicurarti che il tuo host abbia il numero di porta TCP corretto aperto alle richieste in entrata dal mondo esterno affinché SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Security Group della tua istanza.
Le istruzioni per configurare e avviare l'app web sono fornite nella nostra guida di configurazione – è abbastanza semplice. Per verificare che la tua app sia attiva e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host usando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
Questo è un buon segno – la tua app è attiva!
In webapp.log sul 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 giocare con dati reali nella tua app subito, puoi importare questa specifica richiesta Postman dal repository del progetto. Questa simula ciò che farà il tuo account SparkPost, cioè invia un https POST contenente un'email con un certificato specifico e valido (appartenente a un mio account di prova) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nella casella grigia sopra) per adattarlo alla tua installazione. Se hai cambiato il valore del token in webapp.ini, modifica il valore del header in Postman per abbinare.
Se la tua app funziona, vedrai una risposta “200 OK” indietro in Postman. Il file registro webapp.log del tuo host conterrà un output come 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 mentale, cerca l'ultima riga – se dice “written file”, allora stai andando bene. Il resto mostra il processo di verifica DKIM e validazione certificato.
Inizieremo con questa parte, in modo da averla completamente testata prima di collegare i webhook di relay in entrata.
L'app web è inclusa nello stesso progetto GitHub delle parti 1 – 3, quindi se hai seguito quelle parti, l'hai già. Ecco le novità:
Programma readSMIMEsig.py – legge un'email e analizza i certificati intermedi e utente.
Programma webapp.py – semplice applicazione web compatibile con Flask per l'uso con SparkPost Inbound Relay Webhooks.
webapp.ini – file di configurazione per il sopra. Un file di configurazione permette di passare facilmente gli stessi valori a entrambe le applicazioni a riga di comando e web.
Devi assicurarti che il tuo host abbia il numero di porta TCP corretto aperto alle richieste in entrata dal mondo esterno affinché SparkPost possa inviare messaggi alla tua app. Se sei ospitato su AWS EC2, ad esempio, dovrai configurare il Security Group della tua istanza.
Le istruzioni per configurare e avviare l'app web sono fornite nella nostra guida di configurazione – è abbastanza semplice. Per verificare che la tua app sia attiva e accessibile dal mondo esterno, puoi inviare richieste (vuote) da un altro host usando curl, ad esempio:
curl -X POST https://app.trymsys.net:8855/
Dovresti vedere una risposta come:
{"message":"Unknown Content-Type in request headers"}
Questo è un buon segno – la tua app è attiva!
In webapp.log sul 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 giocare con dati reali nella tua app subito, puoi importare questa specifica richiesta Postman dal repository del progetto. Questa simula ciò che farà il tuo account SparkPost, cioè invia un https POST contenente un'email con un certificato specifico e valido (appartenente a un mio account di prova) alla tua app.
Devi solo cambiare l'indirizzo di destinazione nella richiesta (nella casella grigia sopra) per adattarlo alla tua installazione. Se hai cambiato il valore del token in webapp.ini, modifica il valore del header in Postman per abbinare.
Se la tua app funziona, vedrai una risposta “200 OK” indietro in Postman. Il file registro webapp.log del tuo host conterrà un output come 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 mentale, cerca l'ultima riga – se dice “written file”, allora stai andando bene. Il resto mostra il processo di verifica DKIM e validazione certificato.
3. Configurazione dei webhook di inoltro inbound di SparkPost
Innanzitutto, selezioniamo un dominio da utilizzare come il nostro indirizzo di messaggio in entrata – qui, sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passi che ho usato in dettaglio:
3.1 Aggiungi Record MX
Avrai bisogno di accesso al tuo specifico account del provider di servizi Internet. Quando hai finito, puoi verificarli 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
Usa la SparkPost Postman API collection, selezionando Inbound Domains / Create .. call. Il corpo della richiesta POST contiene il tuo dominio, per esempio:
{ "domain": "inbound.thetucks.com" }
3.3 Crea un Relay Webhook
Crea un inbound relay webhook usando la chiamata 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à menzionato, consiglio di impostare un auth_token a un valore segreto personale, come impostato nel file webapp.ini sul tuo host.
Il tuo valore "target" deve corrispondere all'indirizzo host e alla porta TCP dove ospiterai l'app web.
Il tuo valore "domain" deve corrispondere ai record MX configurati nel passaggio 1.
Questo è tutto! Il sistema è configurato. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in entrata, che verranno elaborati e appariranno sull'host della tua applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, usando gli strumenti descritti nelle parti 2 & 3 di questa serie.
Puoi esaminare i contenuti di un certificato usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Innanzitutto, selezioniamo un dominio da utilizzare come il nostro indirizzo di messaggio in entrata – qui, sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passi che ho usato in dettaglio:
3.1 Aggiungi Record MX
Avrai bisogno di accesso al tuo specifico account del provider di servizi Internet. Quando hai finito, puoi verificarli 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
Usa la SparkPost Postman API collection, selezionando Inbound Domains / Create .. call. Il corpo della richiesta POST contiene il tuo dominio, per esempio:
{ "domain": "inbound.thetucks.com" }
3.3 Crea un Relay Webhook
Crea un inbound relay webhook usando la chiamata 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à menzionato, consiglio di impostare un auth_token a un valore segreto personale, come impostato nel file webapp.ini sul tuo host.
Il tuo valore "target" deve corrispondere all'indirizzo host e alla porta TCP dove ospiterai l'app web.
Il tuo valore "domain" deve corrispondere ai record MX configurati nel passaggio 1.
Questo è tutto! Il sistema è configurato. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in entrata, che verranno elaborati e appariranno sull'host della tua applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, usando gli strumenti descritti nelle parti 2 & 3 di questa serie.
Puoi esaminare i contenuti di un certificato usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Innanzitutto, selezioniamo un dominio da utilizzare come il nostro indirizzo di messaggio in entrata – qui, sarà inbound.thetucks.com. Configura il tuo dominio seguendo questa guida. Ecco i passi che ho usato in dettaglio:
3.1 Aggiungi Record MX
Avrai bisogno di accesso al tuo specifico account del provider di servizi Internet. Quando hai finito, puoi verificarli 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
Usa la SparkPost Postman API collection, selezionando Inbound Domains / Create .. call. Il corpo della richiesta POST contiene il tuo dominio, per esempio:
{ "domain": "inbound.thetucks.com" }
3.3 Crea un Relay Webhook
Crea un inbound relay webhook usando la chiamata 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à menzionato, consiglio di impostare un auth_token a un valore segreto personale, come impostato nel file webapp.ini sul tuo host.
Il tuo valore "target" deve corrispondere all'indirizzo host e alla porta TCP dove ospiterai l'app web.
Il tuo valore "domain" deve corrispondere ai record MX configurati nel passaggio 1.
Questo è tutto! Il sistema è configurato. Dovresti ora essere in grado di inviare certificati al tuo indirizzo in entrata, che verranno elaborati e appariranno sull'host della tua applicazione web – in questo caso, un file chiamato bob.lumreeker@gmail.com.crt.
Ora puoi inviare email crittografate a Bob, usando gli strumenti descritti nelle parti 2 & 3 di questa serie.
Puoi esaminare i contenuti di un certificato usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internals: controllo DKIM, validazione 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 là dentro 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 là dentro 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 là dentro e idee per ulteriori lavori.
Riassumendo…
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere facilmente raccolte utilizzando un'email verso un indirizzo webhook in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buona spedizione.
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere facilmente raccolte utilizzando un'email verso un indirizzo webhook in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buona spedizione.
Abbiamo visto come le chiavi pubbliche dei destinatari possano essere facilmente raccolte utilizzando un'email verso un indirizzo webhook in entrata. Una volta fatto, quei destinatari possono ricevere i loro messaggi in forma crittografata S/MIME.
Questo è tutto per ora! Buona spedizione.
