S/MIME Parte 4: Recopilación de Claves Públicas de Destinatarios de la Manera Fácil – con los Webhooks de Relé Entrante de SparkPost

Pájaro

1 feb 2019

Correo electrónico

1 min read

S/MIME Parte 4: Recopilación de Claves Públicas de Destinatarios de la Manera Fácil – con los Webhooks de Relé Entrante de SparkPost

Puntos clave

    • Premisa: Enviar correos electrónicos cifrados con S/MIME no es difícil una vez que puedes recopilar automáticamente la clave pública de cada destinatario. Esta publicación cierra esa brecha utilizando SparkPost Inbound Relay Webhooks para recibir correos firmados, extraer certificados y almacenarlos para cifrado posterior.

    • Objetivo: Construir un servicio webhook basado en Flask que escuche mensajes firmados entrantes, los valide (DKIM + verificaciones de certificado) y escriba de manera segura cada clave pública en el disco para su uso en correos seguros salientes.

    • Puntos destacados:

      1. Problema: El intercambio manual de claves no escala para correos electrónicos generados por aplicaciones.

      2. Solución: Invitar a los usuarios a enviar un correo electrónico firmado; el webhook entrante analiza y almacena automáticamente su certificado PEM.

      3. Pasos de configuración:

        • Configurar un Dominio Entrante y registros MX (por ejemplo, inbound.yourdomain.com).

        • Crear un Inbound Relay Webhook vía la API de SparkPost apuntando a tu endpoint de aplicación.

        • Implementar una pequeña aplicación Flask (webapp.py) utilizando la configuración de webapp.ini.

        • Registrar de manera extensa para transparencia; integrar Pytest + Travis CI para validación automatizada.

      4. Medidas de seguridad:

        • Verificar firmas DKIM y autenticidad de mensajes.

        • Validar la cadena de confianza del certificado antes de almacenarlo.

        • Usar un token de autenticación secreto en los encabezados del webhook.

      5. Salida:

        • Cada mensaje entrante válido crea un archivo de certificado como bob.lumreeker@gmail.com.crt.

        • Una vez almacenadas, estas claves permiten respuestas cifradas usando scripts anteriores de las partes 2 y 3.

Destacados de Q&A

  • ¿Por qué es tan crítico recopilar las claves de los destinatarios para S/MIME?

    Debido a que el cifrado requiere la clave pública de cada destinatario; automatizar este paso permite que cualquier aplicación envíe correo seguro sin intercambio manual.

  • ¿Cómo simplifica SparkPost Inbound Relay Webhook la colección clave?

    Convierte cualquier correo electrónico entrante firmado en una carga útil JSON estructurada, lo que permite que tu aplicación analice y mantenga los certificados de manera programática.

  • ¿Qué medidas de seguridad previenen el spoofing o envíos basura?

    El servicio valida las firmas DKIM, aplica tokens de autenticación y rechaza mensajes mal formados o no firmados.

  • ¿Dónde se almacenan los certificados y en qué formato?

    Se escriben en disco en formato PEM (.crt archivos), listos para su uso por la cadena de herramientas de firma/cifrado construida en las partes anteriores.

  • ¿Cuál es el flujo de trabajo del desarrollador?

    Ejecute la aplicación Flask, verifique con Postman utilizando la carga útil de muestra proporcionada, luego conéctelo al webhook en vivo de SparkPost para una operación continua.

  • ¿Conclusión general?

    La gestión de claves S/MIME se puede automatizar completamente con unas pocas líneas de Python y SparkPost APIs—llevando cifrado escalable a cualquier flujo de trabajo de correo electrónico generado por aplicaciones.

En la parte 1, hicimos un breve recorrido por S/MIME, observando la firma y el cifrado de nuestros flujos de mensajes a través de una variedad de clientes de correo. Parte 2 nos llevó a través de una sencilla herramienta de línea de comandos para firmar y cifrar correos electrónicos, luego enviarlos a través de SparkPost. Parte 3 mostró cómo inyectar flujos de correo seguros en plataformas locales como Port25 PowerMTA y Momentum.

En esta serie, hemos visto cómo incluir una firma S/MIME es bastante sencillo. Enviar correo cifrado con S/MIME es más complejo porque necesitas obtener las claves públicas de los destinatarios. Es una cosa cuando usas un cliente de correo para humanos como Thunderbird, pero ¿cómo puede funcionar eso con flujos de correo generados por aplicaciones? Los correos electrónicos generados por aplicaciones, como los utilizados por plataformas de citas, requieren una estrategia cuidadosa para maximizar la participación. Vea cómo las aplicaciones de citas crean experiencias de correo electrónico provocativas.

Pero espera, hay otra manera de entrar a Mordor para obtener esas claves. Tu servicio puede invitar a tus clientes (por correo electrónico, por supuesto) a enviarte de vuelta un correo firmado a una dirección de servicio al cliente conocida. Usando los poderes mágicos de los webhooks de SparkPost Inbound Relay, extraeremos y guardaremos esa clave pública para que puedas usarla.

Podemos resumir esto en un caso de uso simple:

  • Como destinatario de mensajes, proporciono a tu servicio mi firma de correo electrónico personal a través del correo electrónico, para que en el futuro, los correos electrónicos puedan ser enviados a mí en forma cifrada S/MIME.

De esto, derivemos algunos requisitos más detallados:

  • Necesitamos un servicio de correo electrónico entrante siempre activo y confiable para recibir esos correos firmados.

  • No debe haber requisitos especiales sobre el formato del correo, aparte de que debe llevar una firma S/MIME.

  • Debido a que cualquiera puede intentar enviar un correo a este servicio, debe diseñarse de manera defensiva, por ejemplo, para rechazar mensajes "falsos" de actores malintencionados. Habrá la necesidad de varias capas de verificación.

  • Si todo está bien, el servicio almacenará el certificado en un archivo, usando el conocido formato de texto plano Privacy-Enhanced Mail (PEM).

Hay algunos requisitos no funcionales:

  • Los servicios de webhook de máquina a máquina pueden ser difíciles de ver solo desde las respuestas para lo que está sucediendo dentro. El servicio debe proporcionar registros a nivel de aplicación extensibles y legibles por humanos. En particular, se debería registrar el análisis y la verificación de certificados.

  • Añadimos casos de prueba para el interior de la aplicación, usando el agradable marco Pytest, y ejecutamos esas pruebas automáticamente al hacer check-in usando la integración de Travis CI con GitHub.

¡Bien, comencemos!

En la parte 1, hicimos un breve recorrido por S/MIME, observando la firma y el cifrado de nuestros flujos de mensajes a través de una variedad de clientes de correo. Parte 2 nos llevó a través de una sencilla herramienta de línea de comandos para firmar y cifrar correos electrónicos, luego enviarlos a través de SparkPost. Parte 3 mostró cómo inyectar flujos de correo seguros en plataformas locales como Port25 PowerMTA y Momentum.

En esta serie, hemos visto cómo incluir una firma S/MIME es bastante sencillo. Enviar correo cifrado con S/MIME es más complejo porque necesitas obtener las claves públicas de los destinatarios. Es una cosa cuando usas un cliente de correo para humanos como Thunderbird, pero ¿cómo puede funcionar eso con flujos de correo generados por aplicaciones? Los correos electrónicos generados por aplicaciones, como los utilizados por plataformas de citas, requieren una estrategia cuidadosa para maximizar la participación. Vea cómo las aplicaciones de citas crean experiencias de correo electrónico provocativas.

Pero espera, hay otra manera de entrar a Mordor para obtener esas claves. Tu servicio puede invitar a tus clientes (por correo electrónico, por supuesto) a enviarte de vuelta un correo firmado a una dirección de servicio al cliente conocida. Usando los poderes mágicos de los webhooks de SparkPost Inbound Relay, extraeremos y guardaremos esa clave pública para que puedas usarla.

Podemos resumir esto en un caso de uso simple:

  • Como destinatario de mensajes, proporciono a tu servicio mi firma de correo electrónico personal a través del correo electrónico, para que en el futuro, los correos electrónicos puedan ser enviados a mí en forma cifrada S/MIME.

De esto, derivemos algunos requisitos más detallados:

  • Necesitamos un servicio de correo electrónico entrante siempre activo y confiable para recibir esos correos firmados.

  • No debe haber requisitos especiales sobre el formato del correo, aparte de que debe llevar una firma S/MIME.

  • Debido a que cualquiera puede intentar enviar un correo a este servicio, debe diseñarse de manera defensiva, por ejemplo, para rechazar mensajes "falsos" de actores malintencionados. Habrá la necesidad de varias capas de verificación.

  • Si todo está bien, el servicio almacenará el certificado en un archivo, usando el conocido formato de texto plano Privacy-Enhanced Mail (PEM).

Hay algunos requisitos no funcionales:

  • Los servicios de webhook de máquina a máquina pueden ser difíciles de ver solo desde las respuestas para lo que está sucediendo dentro. El servicio debe proporcionar registros a nivel de aplicación extensibles y legibles por humanos. En particular, se debería registrar el análisis y la verificación de certificados.

  • Añadimos casos de prueba para el interior de la aplicación, usando el agradable marco Pytest, y ejecutamos esas pruebas automáticamente al hacer check-in usando la integración de Travis CI con GitHub.

¡Bien, comencemos!

En la parte 1, hicimos un breve recorrido por S/MIME, observando la firma y el cifrado de nuestros flujos de mensajes a través de una variedad de clientes de correo. Parte 2 nos llevó a través de una sencilla herramienta de línea de comandos para firmar y cifrar correos electrónicos, luego enviarlos a través de SparkPost. Parte 3 mostró cómo inyectar flujos de correo seguros en plataformas locales como Port25 PowerMTA y Momentum.

En esta serie, hemos visto cómo incluir una firma S/MIME es bastante sencillo. Enviar correo cifrado con S/MIME es más complejo porque necesitas obtener las claves públicas de los destinatarios. Es una cosa cuando usas un cliente de correo para humanos como Thunderbird, pero ¿cómo puede funcionar eso con flujos de correo generados por aplicaciones? Los correos electrónicos generados por aplicaciones, como los utilizados por plataformas de citas, requieren una estrategia cuidadosa para maximizar la participación. Vea cómo las aplicaciones de citas crean experiencias de correo electrónico provocativas.

Pero espera, hay otra manera de entrar a Mordor para obtener esas claves. Tu servicio puede invitar a tus clientes (por correo electrónico, por supuesto) a enviarte de vuelta un correo firmado a una dirección de servicio al cliente conocida. Usando los poderes mágicos de los webhooks de SparkPost Inbound Relay, extraeremos y guardaremos esa clave pública para que puedas usarla.

Podemos resumir esto en un caso de uso simple:

  • Como destinatario de mensajes, proporciono a tu servicio mi firma de correo electrónico personal a través del correo electrónico, para que en el futuro, los correos electrónicos puedan ser enviados a mí en forma cifrada S/MIME.

De esto, derivemos algunos requisitos más detallados:

  • Necesitamos un servicio de correo electrónico entrante siempre activo y confiable para recibir esos correos firmados.

  • No debe haber requisitos especiales sobre el formato del correo, aparte de que debe llevar una firma S/MIME.

  • Debido a que cualquiera puede intentar enviar un correo a este servicio, debe diseñarse de manera defensiva, por ejemplo, para rechazar mensajes "falsos" de actores malintencionados. Habrá la necesidad de varias capas de verificación.

  • Si todo está bien, el servicio almacenará el certificado en un archivo, usando el conocido formato de texto plano Privacy-Enhanced Mail (PEM).

Hay algunos requisitos no funcionales:

  • Los servicios de webhook de máquina a máquina pueden ser difíciles de ver solo desde las respuestas para lo que está sucediendo dentro. El servicio debe proporcionar registros a nivel de aplicación extensibles y legibles por humanos. En particular, se debería registrar el análisis y la verificación de certificados.

  • Añadimos casos de prueba para el interior de la aplicación, usando el agradable marco Pytest, y ejecutamos esas pruebas automáticamente al hacer check-in usando la integración de Travis CI con GitHub.

¡Bien, comencemos!

1. Resumen de la solución

Así es como se verá la solución general.

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

Así es como se verá la solución general.

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

Así es como se verá la solución general.

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

2. Instalación, configuración y inicio de la aplicación web

Empezaremos con esta parte, así que la tendremos completamente probada antes de conectar los webhooks de retransmisión entrante.

La aplicación web está incluida en el mismo proyecto de GitHub que las partes 1 a 3, por lo que si has seguido esas partes, ya la tienes. Aquí están las nuevas partes:

  • Programa readSMIMEsig.py – lee un correo electrónico y extrae certificados intermedios y de usuario.

  • Programa webapp.py – aplicación web simple compatible con Flask para usar con SparkPost Inbound Relay Webhooks.

  • webapp.ini – archivo de configuración para lo anterior. Un archivo de configuración permite que los mismos valores se pasen fácilmente tanto a aplicaciones de línea de comandos como a aplicaciones web.

Necesitas asegurarte de que tu host tiene el número de puerto TCP correcto abierto a las solicitudes entrantes desde el mundo exterior para que SparkPost pueda enviar mensajes POST a tu aplicación. Si estás alojado en AWS EC2, por ejemplo, necesitarás configurar el Grupo de Seguridad de tu instancia.

Se proporcionan instrucciones para configurar y comenzar la aplicación web en nuestra guía de configuración – es bastante fácil. Para comprobar que tu aplicación está funcionando y es accesible desde el exterior, puedes enviar solicitudes (en blanco) desde otro host usando curl, por ejemplo:

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

Deberías ver una respuesta como:

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

Esto es una buena señal: ¡tu aplicación está en funcionamiento!

En webapp.log en tu host, verás una salida similar a esta:

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

Para ayudarte a jugar con datos reales en tu aplicación de inmediato, puedes importar esta solicitud de Postman específica del repositorio del proyecto. Esto simula lo que hará tu cuenta de SparkPost, es decir, envía un POST https que contiene un correo electrónico con un certificado específico y válido (perteneciente a una cuenta de prueba mía) a tu aplicación.

Solo necesitas cambiar la dirección de destino en la solicitud (en el cuadro gris arriba) para que coincida con tu instalación. Si cambiaste el valor del token en webapp.ini, ajusta el valor del encabezado en Postman para que coincida.

Si tu aplicación está funcionando, verás una respuesta “200 OK” de vuelta en Postman. Tu archivo webapp.log del host contendrá una salida como esta:

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

Para una verificación rápida, busca la última línea: si dice “written file”, entonces estás bien. El resto de esto muestra el proceso de verificación DKIM y validación de certificados.

Empezaremos con esta parte, así que la tendremos completamente probada antes de conectar los webhooks de retransmisión entrante.

La aplicación web está incluida en el mismo proyecto de GitHub que las partes 1 a 3, por lo que si has seguido esas partes, ya la tienes. Aquí están las nuevas partes:

  • Programa readSMIMEsig.py – lee un correo electrónico y extrae certificados intermedios y de usuario.

  • Programa webapp.py – aplicación web simple compatible con Flask para usar con SparkPost Inbound Relay Webhooks.

  • webapp.ini – archivo de configuración para lo anterior. Un archivo de configuración permite que los mismos valores se pasen fácilmente tanto a aplicaciones de línea de comandos como a aplicaciones web.

Necesitas asegurarte de que tu host tiene el número de puerto TCP correcto abierto a las solicitudes entrantes desde el mundo exterior para que SparkPost pueda enviar mensajes POST a tu aplicación. Si estás alojado en AWS EC2, por ejemplo, necesitarás configurar el Grupo de Seguridad de tu instancia.

Se proporcionan instrucciones para configurar y comenzar la aplicación web en nuestra guía de configuración – es bastante fácil. Para comprobar que tu aplicación está funcionando y es accesible desde el exterior, puedes enviar solicitudes (en blanco) desde otro host usando curl, por ejemplo:

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

Deberías ver una respuesta como:

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

Esto es una buena señal: ¡tu aplicación está en funcionamiento!

En webapp.log en tu host, verás una salida similar a esta:

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

Para ayudarte a jugar con datos reales en tu aplicación de inmediato, puedes importar esta solicitud de Postman específica del repositorio del proyecto. Esto simula lo que hará tu cuenta de SparkPost, es decir, envía un POST https que contiene un correo electrónico con un certificado específico y válido (perteneciente a una cuenta de prueba mía) a tu aplicación.

Solo necesitas cambiar la dirección de destino en la solicitud (en el cuadro gris arriba) para que coincida con tu instalación. Si cambiaste el valor del token en webapp.ini, ajusta el valor del encabezado en Postman para que coincida.

Si tu aplicación está funcionando, verás una respuesta “200 OK” de vuelta en Postman. Tu archivo webapp.log del host contendrá una salida como esta:

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

Para una verificación rápida, busca la última línea: si dice “written file”, entonces estás bien. El resto de esto muestra el proceso de verificación DKIM y validación de certificados.

Empezaremos con esta parte, así que la tendremos completamente probada antes de conectar los webhooks de retransmisión entrante.

La aplicación web está incluida en el mismo proyecto de GitHub que las partes 1 a 3, por lo que si has seguido esas partes, ya la tienes. Aquí están las nuevas partes:

  • Programa readSMIMEsig.py – lee un correo electrónico y extrae certificados intermedios y de usuario.

  • Programa webapp.py – aplicación web simple compatible con Flask para usar con SparkPost Inbound Relay Webhooks.

  • webapp.ini – archivo de configuración para lo anterior. Un archivo de configuración permite que los mismos valores se pasen fácilmente tanto a aplicaciones de línea de comandos como a aplicaciones web.

Necesitas asegurarte de que tu host tiene el número de puerto TCP correcto abierto a las solicitudes entrantes desde el mundo exterior para que SparkPost pueda enviar mensajes POST a tu aplicación. Si estás alojado en AWS EC2, por ejemplo, necesitarás configurar el Grupo de Seguridad de tu instancia.

Se proporcionan instrucciones para configurar y comenzar la aplicación web en nuestra guía de configuración – es bastante fácil. Para comprobar que tu aplicación está funcionando y es accesible desde el exterior, puedes enviar solicitudes (en blanco) desde otro host usando curl, por ejemplo:

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

Deberías ver una respuesta como:

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

Esto es una buena señal: ¡tu aplicación está en funcionamiento!

En webapp.log en tu host, verás una salida similar a esta:

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

Para ayudarte a jugar con datos reales en tu aplicación de inmediato, puedes importar esta solicitud de Postman específica del repositorio del proyecto. Esto simula lo que hará tu cuenta de SparkPost, es decir, envía un POST https que contiene un correo electrónico con un certificado específico y válido (perteneciente a una cuenta de prueba mía) a tu aplicación.

Solo necesitas cambiar la dirección de destino en la solicitud (en el cuadro gris arriba) para que coincida con tu instalación. Si cambiaste el valor del token en webapp.ini, ajusta el valor del encabezado en Postman para que coincida.

Si tu aplicación está funcionando, verás una respuesta “200 OK” de vuelta en Postman. Tu archivo webapp.log del host contendrá una salida como esta:

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

Para una verificación rápida, busca la última línea: si dice “written file”, entonces estás bien. El resto de esto muestra el proceso de verificación DKIM y validación de certificados.

3. Configuración de SparkPost inbound relay webhooks

En primer lugar, seleccionamos un dominio para usar como nuestra dirección de mensajes entrantes – aquí, será inbound.thetucks.com. Configure su dominio siguiendo esta guía. Aquí están los pasos que utilicé en detalle:

3.1 Añadir registros MX

Necesitarás acceso a la cuenta específica de tu proveedor de servicios de Internet. Cuando hayas terminado, puedes verificarlos con dig – aquí está el comando para mi dominio.

dig +short MX inbound.thetucks.com

Deberías ver:

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

3.2 Crear un dominio entrante

Utiliza la colección de API de SparkPost Postman, seleccionando la llamada Inbound Domains / Create. El cuerpo de la solicitud POST contiene tu dominio, por ejemplo:

{ "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 Crear un Webhook de retransmisión

Crea un webhook de retransmisión entrante utilizando la llamada relevante de Postman. El cuerpo del mensaje en mi caso contiene:

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

Como se mencionó antes, recomiendo configurar un auth_token con tu propio valor secreto, tal como está en el archivo webapp.ini en tu host.

Tu valor "target" necesita coincidir con la dirección de tu host y el puerto TCP donde alojarás la aplicación web.

Tu valor "domain" necesita coincidir con los registros MX configurados en el paso 1.

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


¡Eso es todo! La instalación está hecha. Ahora deberías poder enviar certificados a tu dirección entrante, serán procesados y aparecerán en el host de tu aplicación web – en este caso, un archivo llamado bob.lumreeker@gmail.com.crt.

Ahora puedes enviar correos electrónicos cifrados a Bob, utilizando las herramientas descritas en las partes 2 y 3 de esta serie.

Puedes examinar el contenido de un certificado utilizando:

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

En primer lugar, seleccionamos un dominio para usar como nuestra dirección de mensajes entrantes – aquí, será inbound.thetucks.com. Configure su dominio siguiendo esta guía. Aquí están los pasos que utilicé en detalle:

3.1 Añadir registros MX

Necesitarás acceso a la cuenta específica de tu proveedor de servicios de Internet. Cuando hayas terminado, puedes verificarlos con dig – aquí está el comando para mi dominio.

dig +short MX inbound.thetucks.com

Deberías ver:

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

3.2 Crear un dominio entrante

Utiliza la colección de API de SparkPost Postman, seleccionando la llamada Inbound Domains / Create. El cuerpo de la solicitud POST contiene tu dominio, por ejemplo:

{ "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 Crear un Webhook de retransmisión

Crea un webhook de retransmisión entrante utilizando la llamada relevante de Postman. El cuerpo del mensaje en mi caso contiene:

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

Como se mencionó antes, recomiendo configurar un auth_token con tu propio valor secreto, tal como está en el archivo webapp.ini en tu host.

Tu valor "target" necesita coincidir con la dirección de tu host y el puerto TCP donde alojarás la aplicación web.

Tu valor "domain" necesita coincidir con los registros MX configurados en el paso 1.

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


¡Eso es todo! La instalación está hecha. Ahora deberías poder enviar certificados a tu dirección entrante, serán procesados y aparecerán en el host de tu aplicación web – en este caso, un archivo llamado bob.lumreeker@gmail.com.crt.

Ahora puedes enviar correos electrónicos cifrados a Bob, utilizando las herramientas descritas en las partes 2 y 3 de esta serie.

Puedes examinar el contenido de un certificado utilizando:

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

En primer lugar, seleccionamos un dominio para usar como nuestra dirección de mensajes entrantes – aquí, será inbound.thetucks.com. Configure su dominio siguiendo esta guía. Aquí están los pasos que utilicé en detalle:

3.1 Añadir registros MX

Necesitarás acceso a la cuenta específica de tu proveedor de servicios de Internet. Cuando hayas terminado, puedes verificarlos con dig – aquí está el comando para mi dominio.

dig +short MX inbound.thetucks.com

Deberías ver:

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

3.2 Crear un dominio entrante

Utiliza la colección de API de SparkPost Postman, seleccionando la llamada Inbound Domains / Create. El cuerpo de la solicitud POST contiene tu dominio, por ejemplo:

{ "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 Crear un Webhook de retransmisión

Crea un webhook de retransmisión entrante utilizando la llamada relevante de Postman. El cuerpo del mensaje en mi caso contiene:

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

Como se mencionó antes, recomiendo configurar un auth_token con tu propio valor secreto, tal como está en el archivo webapp.ini en tu host.

Tu valor "target" necesita coincidir con la dirección de tu host y el puerto TCP donde alojarás la aplicación web.

Tu valor "domain" necesita coincidir con los registros MX configurados en el paso 1.

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


¡Eso es todo! La instalación está hecha. Ahora deberías poder enviar certificados a tu dirección entrante, serán procesados y aparecerán en el host de tu aplicación web – en este caso, un archivo llamado bob.lumreeker@gmail.com.crt.

Ahora puedes enviar correos electrónicos cifrados a Bob, utilizando las herramientas descritas en las partes 2 y 3 de esta serie.

Puedes examinar el contenido de un certificado utilizando:

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

4. Internals: Verificación de DKIM, validación de certificados

La aplicación verifica que los correos electrónicos recibidos tengan DKIM válido y confirma que los propios certificados sean válidos, como se describe aquí. También hay notas de implementación allí, y ideas para trabajo adicional.

La aplicación verifica que los correos electrónicos recibidos tengan DKIM válido y confirma que los propios certificados sean válidos, como se describe aquí. También hay notas de implementación allí, y ideas para trabajo adicional.

La aplicación verifica que los correos electrónicos recibidos tengan DKIM válido y confirma que los propios certificados sean válidos, como se describe aquí. También hay notas de implementación allí, y ideas para trabajo adicional.

Resumiendo…

Hemos visto cómo las claves públicas de los destinatarios se pueden recopilar fácilmente utilizando un correo electrónico a una dirección de webhooks de retransmisión entrante. Una vez hecho esto, esos destinatarios pueden recibir sus mensajes en forma cifrada de S/MIME.

¡Eso es todo por ahora! Felices envíos.

Hemos visto cómo las claves públicas de los destinatarios se pueden recopilar fácilmente utilizando un correo electrónico a una dirección de webhooks de retransmisión entrante. Una vez hecho esto, esos destinatarios pueden recibir sus mensajes en forma cifrada de S/MIME.

¡Eso es todo por ahora! Felices envíos.

Hemos visto cómo las claves públicas de los destinatarios se pueden recopilar fácilmente utilizando un correo electrónico a una dirección de webhooks de retransmisión entrante. Una vez hecho esto, esos destinatarios pueden recibir sus mensajes en forma cifrada de S/MIME.

¡Eso es todo por ahora! Felices envíos.

Otras noticias

Leer más de esta categoría

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

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

© 2025 Bird

Contactar Soporte

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

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

© 2025 Bird

Contactar Soporte

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

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

© 2025 Bird

Contactar Soporte