Diferencia entre revisiones de «Correo electronico»
m (→Recetario) |
mSin resumen de edición |
||
(No se muestran 11 ediciones intermedias del mismo usuario) | |||
Línea 6: | Línea 6: | ||
==== Mecanismos principales ==== |
==== Mecanismos principales ==== |
||
===== SPF ===== |
===== SPF (Sender Policy Framework) ===== |
||
SPF es una normativa que permite establecer y comprobar qué máquinas están autorizadas para enviar correos electrónicos para un dominio de Internet. |
|||
La normativa exige que se defina un registro en el DNS del dominio con una estructura flexible que pueda ser consultado por aquellos servidores que reciben el correo para dar por válido el origen. |
|||
Un registro SPF tiene el siguiente aspecto: |
Un registro SPF tiene el siguiente aspecto: |
||
<code>bovalo.org. 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"</code> |
<code>bovalo.org. 10800 IN TXT "v=spf1 a include:_mailcust.gandi.net ?all"</code> |
||
El registro contiene lo siguiente: |
|||
Y para implementar SPF en un servidor de correo como ''exim4'' es necesario actuar en dos sitios: |
|||
* Indicador de versión del SPF: v=spf1 |
|||
* Cero o más mecanismos que declaran direcciones IP y máquinas que pueden enviar el correo. Los mecanismos pueden estar prefijados con un calificador que altera su significado en caso de fallo. Los principales los detallo a continuación. Hay algunos más pero no los estoy contemplando. |
|||
** '''a''' define un servidor de correo |
|||
** '''mx''' los servidores de correo del dominio |
|||
** '''ipv4''' dirección IP (versión 4) o rango CIDR |
|||
** '''ipv6''' dirección IP (versión 6) o rango |
|||
** '''include''' evalúa el registro SPF de los servidores incluídos (no expande a su contenido, los evalúa) |
|||
* Los calificadores indican cómo considerar el que la IP de origen del mensaje coincida con un mecanismo: |
|||
** '''+''' pass |
|||
** '''-''' fail |
|||
** '''~''' softfail |
|||
** '''?''' neutral |
|||
La evaluación de un registro SPF, que se lleva a cabo mecanismo tras mecanismo, puede resultar en alguno de los siguientes resultados: |
|||
{| class="wikitable" |
|||
|+ |
|||
!Resultado |
|||
!Explicación |
|||
!Acción prevista |
|||
|- |
|||
|Pass |
|||
|El registro designa al servidor como autorizado para enviar correo |
|||
|Mensaje aceptado |
|||
|- |
|||
|Fail |
|||
|El registro designa al servidor como '''no''' autorizado |
|||
|Mensaje rechazado |
|||
|- |
|||
|SoftFail |
|||
|El registro designa al servidor como '''no''' autorizado para enviar pero considera que está en tránsito |
|||
|Mensaje aceptado pero marcado |
|||
|- |
|||
|Neutral |
|||
|El registro especifica que no puede decir nada sobre la validación |
|||
|Mensaje aceptado |
|||
|- |
|||
|None |
|||
|El dominio no tiene un registro SPF o lo tiene pero no evalúa a ningún resultado |
|||
|Mensaje aceptado |
|||
|- |
|||
|PermError |
|||
|Hay un error permanente (como un registro SPF mal formado) |
|||
|No se especifica |
|||
|- |
|||
|TempError |
|||
|Hay un error transitorio |
|||
|Mensaje aceptado o rechazado |
|||
|} |
|||
Así pues para implementar SPF en un servidor de correo como ''exim4'' es necesario actuar en dos sitios: |
|||
# Configurar el registro DNS del dominio para indicar al exterior que está autorizado para enviar mensajes en su nombre. |
# Configurar el registro DNS del dominio para indicar al exterior que está autorizado para enviar mensajes en su nombre. |
||
# Configurar el servidor para que valide los correos entrantes consultando los registros DNS de los que proceden. |
# Configurar el servidor para que valide los correos entrantes consultando los registros DNS de los que proceden. |
||
====== Referencias ====== |
|||
El formato de un registro SPF en el DNS tiene las siguientes partes: |
|||
* <code>v=spf1</code>versión empleada del mecanismo SPF. |
|||
* |
|||
* https://www.netmeister.org/blog/spf.html |
|||
Para crear el registro DNS se pueden emplear herramientas como SPF Wizard y obtener así el formato correcto que luego se deberá incluir en el registro DNS. Es útil echarle un vistazo antes a la documentación oficial porque aclara conceptos básicos y proporciona más enlaces interesantes. |
|||
* http://www.open-spf.org/SPF_Record_Syntax/ |
|||
====== Herramientas ====== |
|||
La validación del registro DNS (una vez que exista y se ha propagado) puede realizarse por varios medios: |
La validación del registro DNS (una vez que exista y se ha propagado) puede realizarse por varios medios: |
||
Línea 27: | Línea 80: | ||
* Enviar un correo a [mailto://check-auth@verifier.port25.com check-auth@verifier.port25.com] y leer el correo devuelto para comprobar si lo hemos configurado bien. |
* Enviar un correo a [mailto://check-auth@verifier.port25.com check-auth@verifier.port25.com] y leer el correo devuelto para comprobar si lo hemos configurado bien. |
||
===== DKIM ===== |
===== DKIM (DomainKeys Identified Mail) ===== |
||
DKIM es el acrónimo de ''Domain Keys Identified Mail'' y es un mecanismo que también consta, como el '''SPF''', de dos partes; ambas deben comenzar con la creación de un par de claves pública/privada que se utilizarán en: |
DKIM es el acrónimo de ''Domain Keys Identified Mail'' y es un mecanismo que también consta, como el '''SPF''', de dos partes; ambas deben comenzar con la creación de un par de claves pública/privada que se utilizarán en: |
||
Línea 35: | Línea 88: | ||
De esta manera aquél servidor que reciba nuestro correo firmado podrá descargar la clave pública de los registros del DNS y efectuar la verificación sobre los mensajes. |
De esta manera aquél servidor que reciba nuestro correo firmado podrá descargar la clave pública de los registros del DNS y efectuar la verificación sobre los mensajes. |
||
Los pasos a seguir |
Los pasos a seguir son: |
||
# Elegir un texto breve como ''selector'' que se utilizará en ambos lados: DNS y |
# Elegir un texto breve como ''selector'' que se utilizará en ambos lados: DNS y servidor de correo. Vale cualquier cosa pero emplear algo ''estándar'' como ''exim'' o ''default'' es buena idea para no tener que recordar nombres extraños cuando verificamos lo que hemos hecho. |
||
# Crear un par de claves pública/privada con openssl teniendo en cuenta las limitaciones de espacio del registrador (gandi.net por ejemplo sólo admite 1024 bytes de longitud). |
# Crear un par de claves pública/privada con [[openssl]] teniendo en cuenta las limitaciones de espacio del registrador (gandi.net por ejemplo sólo admite 1024 bytes de longitud). |
||
# Configurar |
# Configurar el servidor de correo para que emplee la clave privada para firmar los mensajes salientes. |
||
# Crear y publicar un registro TXT en el DNS con la parte pública. |
# Crear y publicar un registro TXT en el DNS con la parte pública. |
||
# Verificar (una vez todo se ha actualizado) que los mensajes están correctamente firmados: |
# Verificar (una vez todo se ha actualizado) que los mensajes están correctamente firmados: |
||
## Emplear un servicio en línea como DKIM Key Checker |
## Emplear un servicio en línea como [https://easydmarc.com/tools/dkim-lookup DKIM Key Checker] |
||
## Enviar un correo a check-auth@verifier.port25.com o similar para obtener resultados desde el punto de vista del receptor. |
## Enviar un correo a [mailto://check-auth@verifier.port25.com check-auth@verifier.port25.com] o similar para obtener resultados desde el punto de vista del receptor. |
||
Esta configuración para el servidor exim está explicada [[Exim4|en su página]]. |
|||
La configuración de exim es sencilla. Una vez hemos guardado a salvo la clave cambiamos la configuración (el archivo ''/etc/exim4/conf.d/transport/10_exim4-config_transport-macros'' por ejemplo) para indicar que lo emplee cada vez que transporte un correo. |
|||
<nowiki>DKIM_DOMAIN = ${lc:${domain:$h_from:}} |
|||
DKIM_FILE = /etc/exim4/dkim/dominio.com.private.key |
|||
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} |
|||
DKIM_SELECTOR = exim</nowiki> |
|||
Podemos revisar la configuración de exim con: |
|||
# exim4 -bV | grep DKIM |
|||
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning '''DKIM''' |
|||
====== Registro DNS para DKIM ====== |
====== Registro DNS para DKIM ====== |
||
Se emplea un registro tipo '''TXT''' cuyo valor es un nombre DNS ficticio formado por el selector de clave definido |
Se emplea un registro tipo '''TXT''' cuyo valor es un nombre DNS ficticio formado por el selector de clave definido antes, el literal ''_domainkey'' y el nombre del dominio completo (''empresa.net'' por ejemplo). |
||
Así pues quedaría de la siguiente forma: |
Así pues quedaría de la siguiente forma: |
||
Línea 72: | Línea 117: | ||
* https://www.mailhardener.com/kb/how-to-create-a-dkim-record-with-openssl |
* https://www.mailhardener.com/kb/how-to-create-a-dkim-record-with-openssl |
||
===== DMARC ===== |
===== DMARC (Domain-based Message Authentication, Reporting and Conformance) ===== |
||
DMARC es un protocolo creado para intentar paliar las debilidades de los otros dos mecanismos (SPF y DKIM) de autentificación del correo electrónico, especialmente cuando hay discrepancias entre la cabecera ''From'' del mensaje y lo que se muestra como campo ''From''. Su operativa es algo más compleja que los anteriores porque es parte de un proceso activo que está siempre basado en los dos anteriores. |
|||
La forma de proceder '''debería ser''' la siguiente: |
|||
# Publicar un registro DMARC para el dominio |
|||
# Monitorizar los informes DMARC para comprobar qué emisores de correo legítimos han fallado y por qué |
|||
# Modificar SPF, DKIM y DMARC para asegurarse de que esos emisores de correo tengan vía libre |
|||
# Ajustar las restricciones DMARC |
|||
# Volver a monitorizar los informes DMARC para legitimar los emisores que fallan y descubrir los emisores maliciosos que intentan suplantar tu identidad. |
|||
====== Registro DMARC ====== |
|||
El registro DNS para DMARC es de tipo TXT y su estructura es la siguiente: |
|||
# Nombre del registro: _dmarc.empresa.net o _dmarc.smtp.empresa.net dependiendo de si es un dominio o un subdominio. |
|||
# En el contenido hay campos separados por un punto y coma: |
|||
## Literal "'''v=DMARC1'''" |
|||
## Campo "'''p=normativa'''" siendo normativa alguna de las siguientes: |
|||
### '''p=none''' indica que el servidor no llevará a cabo ninguna acción contra correos no cualificados. |
|||
### '''p=quarantine''' indica que el servidor debe aislar estos correos, generalmente enviándolos a una carpeta de spam. |
|||
### '''p=reject''' indica que el servidor receptor de correo debe rechazar todos los mensajes no cualificados por el dominio; sólo los mensajes firmados por tu dominio pueden intentar alcanzar los buzones de entrada de los receptores y todos los demás serán descartados. |
|||
## Campo "'''rua='''" define la dirección de correo a la que enviar informes de fallos DMARC que se han recibido y que afectan a tu dominio. La síntaxis es '''"rua=[mailto:dmar@empresa.net mailto:dmarc@empresa.net]'''". La dirección, obviamente, puede ser cualquiera. |
|||
## Campo "'''ruf='''" define la dirección de correo a la que enviar informes forenses de fallos DMARC. La síntaxis es similar a la de ''rua'': "'''ruf=mailto:dmarc@empresa.net'''". |
|||
## Campo "'''aspf=TAG'''" determina la alineación de DMARC con SPF en el caso de las cabeceras ''From''. Más abajo puede verse una tabla con los posibles valores y resultados, pero los valores de ''TAG'' pueden ser '''r''' para modo relajado y '''s''' para modo estricto. |
|||
## Campo "'''adkim=TAG'''" hace lo mismo pero para la firma DKIM. Los valores pueden ser '''s''' para modo estricto y '''r''' para modo relajado. El modo estricto se asegura que el test de firma DKIM se dará por válido sólo si el campo '''d=''' en la firma coincide con el dominio en ''from''. El modo relajado, en cambio, hará que el test DKIM se dé por válido en todos los casos donde el campo ''d='' coindica con el dominio raíz de la dirección ''from''. |
|||
## Campo "'''fo=LEVEL'''" que determina cuándo enviar un informe sobre la validación DMARC. El valor predeterminado es '''0''' y se puede elegir entre: |
|||
##* '''0''' Se envía un informe si el correo falla los alineamientos SPF y DKIM |
|||
##* '''1''' Se envía un informe si el correo falla alguno de los dos test de alineación |
|||
##* '''2''' Se envía el informe si falla el test de alineación DKIM |
|||
##* '''3''' Se envía el informe si falla el test de alineación SPF |
|||
El registro típico para DMARC en un dominio sencillo sería el siguiente:<syntaxhighlight lang="text"> |
|||
v=DMARC1;p=none;rua=mailto:dmarc@exampledomain.com;ruf=mailto:dmarc@exampledomain.com;apsf=r;adkim=r; |
|||
</syntaxhighlight> |
|||
====== Alineación SPF en DMARC ====== |
|||
{| class="wikitable" |
|||
|+ |
|||
!Dominio en campo From |
|||
!Dominio SPF |
|||
!Chequeo relajado |
|||
!Chequeo estricto |
|||
|- |
|||
|example.org |
|||
|example.org |
|||
|Aceptado |
|||
|Aceptado |
|||
|- |
|||
|example.org |
|||
|mail.example.org |
|||
|Aceptado |
|||
|Rechazado |
|||
|- |
|||
|mail.example.org |
|||
|mail.example.org |
|||
|Aceptado |
|||
|Aceptado |
|||
|- |
|||
|mail.example.org |
|||
|example.org |
|||
|Aceptado |
|||
|Rechazado |
|||
|- |
|||
|example.mail.org |
|||
|example.org |
|||
|Rechazado |
|||
|Rechazado |
|||
|} |
|||
===== ARC - Authenticated Received Chain ===== |
|||
==== Resumen de registros DNS para un servidor de correo ==== |
==== Resumen de registros DNS para un servidor de correo ==== |
||
Línea 109: | Línea 223: | ||
===== Referencias ===== |
===== Referencias ===== |
||
* DMARC: |
|||
* https://www.esecurityplanet.com/networks/what-is-dmarc/ |
|||
* https://www.esecurityplanet.com/networks/ |
** [https://www.esecurityplanet.com/networks/what-is-dmarc/ What is DMARC] |
||
** [https://www.esecurityplanet.com/networks/how-to-set-up-and-implement-dmarc-email-security/ How to setup DMARC] |
|||
* https://www.rfc-editor.org/rfc/rfc6186.html |
|||
** [https://powerdmarc.com/dmarc-alignment/ DMARC Alignment] |
|||
* RFC: |
|||
** [https://www.rfc-editor.org/rfc/rfc1113.html RFC 1113: Privacy enhancement for Internet electronic mail: Part I] |
|||
** [https://www.rfc-editor.org/rfc/rfc6186.html RFC 6186 (Use of SRV Records for Locating Email Submission/Access Services]) |
|||
==== Recetario ==== |
==== Recetario ==== |
||
===== Herramientas de validación en línea ===== |
|||
* [https://www.kitterman.com/spf/validate.html Validación de SPF] |
|||
===== SPF para dominios sin correo ===== |
|||
Si se tiene un dominio de Internet que no envía correo electrónico alguno es conveniente protegerlo para que pueda ser usado por terceros definiendo el SPF como sigue: <syntaxhighlight lang="text"> |
|||
empresa.net. 10800 IN TXT "v=spf1 -all" |
|||
</syntaxhighlight> |
|||
===== Reescribiendo el asunto del mensaje ===== |
===== Reescribiendo el asunto del mensaje ===== |
Revisión actual - 17:43 26 dic 2023
Correo electrónico
Guía de ayuda para configurar un servidor de correo electrónico en un servidor Linux.
Mecanismos principales
SPF (Sender Policy Framework)
SPF es una normativa que permite establecer y comprobar qué máquinas están autorizadas para enviar correos electrónicos para un dominio de Internet.
La normativa exige que se defina un registro en el DNS del dominio con una estructura flexible que pueda ser consultado por aquellos servidores que reciben el correo para dar por válido el origen.
Un registro SPF tiene el siguiente aspecto:
bovalo.org. 10800 IN TXT "v=spf1 a include:_mailcust.gandi.net ?all"
El registro contiene lo siguiente:
- Indicador de versión del SPF: v=spf1
- Cero o más mecanismos que declaran direcciones IP y máquinas que pueden enviar el correo. Los mecanismos pueden estar prefijados con un calificador que altera su significado en caso de fallo. Los principales los detallo a continuación. Hay algunos más pero no los estoy contemplando.
- a define un servidor de correo
- mx los servidores de correo del dominio
- ipv4 dirección IP (versión 4) o rango CIDR
- ipv6 dirección IP (versión 6) o rango
- include evalúa el registro SPF de los servidores incluídos (no expande a su contenido, los evalúa)
- Los calificadores indican cómo considerar el que la IP de origen del mensaje coincida con un mecanismo:
- + pass
- - fail
- ~ softfail
- ? neutral
La evaluación de un registro SPF, que se lleva a cabo mecanismo tras mecanismo, puede resultar en alguno de los siguientes resultados:
Resultado | Explicación | Acción prevista |
---|---|---|
Pass | El registro designa al servidor como autorizado para enviar correo | Mensaje aceptado |
Fail | El registro designa al servidor como no autorizado | Mensaje rechazado |
SoftFail | El registro designa al servidor como no autorizado para enviar pero considera que está en tránsito | Mensaje aceptado pero marcado |
Neutral | El registro especifica que no puede decir nada sobre la validación | Mensaje aceptado |
None | El dominio no tiene un registro SPF o lo tiene pero no evalúa a ningún resultado | Mensaje aceptado |
PermError | Hay un error permanente (como un registro SPF mal formado) | No se especifica |
TempError | Hay un error transitorio | Mensaje aceptado o rechazado |
Así pues para implementar SPF en un servidor de correo como exim4 es necesario actuar en dos sitios:
- Configurar el registro DNS del dominio para indicar al exterior que está autorizado para enviar mensajes en su nombre.
- Configurar el servidor para que valide los correos entrantes consultando los registros DNS de los que proceden.
Referencias
Herramientas
La validación del registro DNS (una vez que exista y se ha propagado) puede realizarse por varios medios:
- Emplear SPF Query Tool para verificar en línea nuestros registros DNS.
- Enviar un correo a check-auth@verifier.port25.com y leer el correo devuelto para comprobar si lo hemos configurado bien.
DKIM (DomainKeys Identified Mail)
DKIM es el acrónimo de Domain Keys Identified Mail y es un mecanismo que también consta, como el SPF, de dos partes; ambas deben comenzar con la creación de un par de claves pública/privada que se utilizarán en:
- La parte pública en un registro del DNS con formato especial.
- La parte privada en el servidor que envía el correo y con la que firmará todos los que emita.
De esta manera aquél servidor que reciba nuestro correo firmado podrá descargar la clave pública de los registros del DNS y efectuar la verificación sobre los mensajes.
Los pasos a seguir son:
- Elegir un texto breve como selector que se utilizará en ambos lados: DNS y servidor de correo. Vale cualquier cosa pero emplear algo estándar como exim o default es buena idea para no tener que recordar nombres extraños cuando verificamos lo que hemos hecho.
- Crear un par de claves pública/privada con openssl teniendo en cuenta las limitaciones de espacio del registrador (gandi.net por ejemplo sólo admite 1024 bytes de longitud).
- Configurar el servidor de correo para que emplee la clave privada para firmar los mensajes salientes.
- Crear y publicar un registro TXT en el DNS con la parte pública.
- Verificar (una vez todo se ha actualizado) que los mensajes están correctamente firmados:
- Emplear un servicio en línea como DKIM Key Checker
- Enviar un correo a check-auth@verifier.port25.com o similar para obtener resultados desde el punto de vista del receptor.
Esta configuración para el servidor exim está explicada en su página.
Registro DNS para DKIM
Se emplea un registro tipo TXT cuyo valor es un nombre DNS ficticio formado por el selector de clave definido antes, el literal _domainkey y el nombre del dominio completo (empresa.net por ejemplo).
Así pues quedaría de la siguiente forma:
default._domainkey.empresa.net 10799 IN TXT "v=DKIM1;p=..."
donde el valor númerico es el TTL del registro y la clave pública va como valor del parámetro p, toda junta sin saltos de línea ni espacios.
Creación del par de claves DKIM
Empleando el programa opensll se crea primero la clave RSA:
$ openssl genrsa -out clave.pem 2048
Y se extrae de ella la clave pública:
$ openssl rsa -in clave.pem -pubout -outform der 2>/dev/null | openssl base64 -A
El resultado es el que debe almacenarse en el registro DNS bajo el selector elegido.
Referencias:
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC es un protocolo creado para intentar paliar las debilidades de los otros dos mecanismos (SPF y DKIM) de autentificación del correo electrónico, especialmente cuando hay discrepancias entre la cabecera From del mensaje y lo que se muestra como campo From. Su operativa es algo más compleja que los anteriores porque es parte de un proceso activo que está siempre basado en los dos anteriores.
La forma de proceder debería ser la siguiente:
- Publicar un registro DMARC para el dominio
- Monitorizar los informes DMARC para comprobar qué emisores de correo legítimos han fallado y por qué
- Modificar SPF, DKIM y DMARC para asegurarse de que esos emisores de correo tengan vía libre
- Ajustar las restricciones DMARC
- Volver a monitorizar los informes DMARC para legitimar los emisores que fallan y descubrir los emisores maliciosos que intentan suplantar tu identidad.
Registro DMARC
El registro DNS para DMARC es de tipo TXT y su estructura es la siguiente:
- Nombre del registro: _dmarc.empresa.net o _dmarc.smtp.empresa.net dependiendo de si es un dominio o un subdominio.
- En el contenido hay campos separados por un punto y coma:
- Literal "v=DMARC1"
- Campo "p=normativa" siendo normativa alguna de las siguientes:
- p=none indica que el servidor no llevará a cabo ninguna acción contra correos no cualificados.
- p=quarantine indica que el servidor debe aislar estos correos, generalmente enviándolos a una carpeta de spam.
- p=reject indica que el servidor receptor de correo debe rechazar todos los mensajes no cualificados por el dominio; sólo los mensajes firmados por tu dominio pueden intentar alcanzar los buzones de entrada de los receptores y todos los demás serán descartados.
- Campo "rua=" define la dirección de correo a la que enviar informes de fallos DMARC que se han recibido y que afectan a tu dominio. La síntaxis es "rua=mailto:dmarc@empresa.net". La dirección, obviamente, puede ser cualquiera.
- Campo "ruf=" define la dirección de correo a la que enviar informes forenses de fallos DMARC. La síntaxis es similar a la de rua: "ruf=mailto:dmarc@empresa.net".
- Campo "aspf=TAG" determina la alineación de DMARC con SPF en el caso de las cabeceras From. Más abajo puede verse una tabla con los posibles valores y resultados, pero los valores de TAG pueden ser r para modo relajado y s para modo estricto.
- Campo "adkim=TAG" hace lo mismo pero para la firma DKIM. Los valores pueden ser s para modo estricto y r para modo relajado. El modo estricto se asegura que el test de firma DKIM se dará por válido sólo si el campo d= en la firma coincide con el dominio en from. El modo relajado, en cambio, hará que el test DKIM se dé por válido en todos los casos donde el campo d= coindica con el dominio raíz de la dirección from.
- Campo "fo=LEVEL" que determina cuándo enviar un informe sobre la validación DMARC. El valor predeterminado es 0 y se puede elegir entre:
- 0 Se envía un informe si el correo falla los alineamientos SPF y DKIM
- 1 Se envía un informe si el correo falla alguno de los dos test de alineación
- 2 Se envía el informe si falla el test de alineación DKIM
- 3 Se envía el informe si falla el test de alineación SPF
El registro típico para DMARC en un dominio sencillo sería el siguiente:
v=DMARC1;p=none;rua=mailto:dmarc@exampledomain.com;ruf=mailto:dmarc@exampledomain.com;apsf=r;adkim=r;
Alineación SPF en DMARC
Dominio en campo From | Dominio SPF | Chequeo relajado | Chequeo estricto |
---|---|---|---|
example.org | example.org | Aceptado | Aceptado |
example.org | mail.example.org | Aceptado | Rechazado |
mail.example.org | mail.example.org | Aceptado | Aceptado |
mail.example.org | example.org | Aceptado | Rechazado |
example.mail.org | example.org | Rechazado | Rechazado |
ARC - Authenticated Received Chain
Resumen de registros DNS para un servidor de correo
No todos los registros son obligados pero para un servidor más o menos completo lo que hay que definir en el DNS es lo siguiente:
- Información general:
- Registro A: con la IP del servidor de correo
- Registro MX: para indicar qué servidor gestiona el correo del dominio.
- Registro PTR: para comprobar que el servidor de correo resuelve efectivamente a esa IP. Difícil de conseguir a menos que se tenga un servidor DNS propio o el proveedor del servidor lo permita.
- Medidas de seguridad:
- Registro SPF: para indicar qué máquinas (nombre o IP) pueden enviar correo para el dominio y qué hacer en caso de que no se cumpla.
- Registro DKIM: conteniendo la clave pública para comprobar si los mensajes están cifrados con la clave privada del dominio.
- Registro DMARC: indica qué hacer con el correo si fallan los mecanismos SPF y DKIM y proporciona una dirección de correo a la que enviar informes de fallos.
- Descubrimiento de servicios:
- Envío de correo: registro de tipo SRV (_submission._tcp.) indicando donde encontrar el servidor SMTP.
- Acceso al correo IMAP: registro de tipo SRV (_imap._tcp o _imaps._tcp) donde encontrar el servidor IMAP.
- Acceso al correo POP3: registro de tipo SRV (_pop3._tcp o _pop3s._tcp) donde encontrar acceso POP3 a los mensajes.
Ejemplos
Para un dominio llamado empresa.net que disponga de servidor de correo completo sus registros DNS quedarían de la siguiente manera:
# Registros generales
@ 10800 IN A ###.###.###.###
@ 10800 IN MX 10 smtp.empresa.net.
# Seguridad del correo: SPF, DKIM, DMARC
@ 10800 IN TXT "v=spf1 a:smtp.empresa.net -all"
default._domainkey 10800 IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3....."
_dmarc.empresa.net 10800 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; sp=none"
# Descubrimiento de servicios
_imap.tcp 10800 IN SRV 10 10 143 imap.empresa.net.
_imaps._tcp 10800 IN SRV 10 10 995 imap.empresa.net.
_submission._tcp 10800 IN SRV 0 1 25 smtp.empresa.net.
Referencias
- RFC:
Recetario
Herramientas de validación en línea
SPF para dominios sin correo
Si se tiene un dominio de Internet que no envía correo electrónico alguno es conveniente protegerlo para que pueda ser usado por terceros definiendo el SPF como sigue:
empresa.net. 10800 IN TXT "v=spf1 -all"
Reescribiendo el asunto del mensaje
Cuando necesitamos reescribir el campo asunto de un mensaje de correo podemos utilizar una mezcla de herramientas que trabajan bien entre sí:
- reformail (en el paquete maildrop) para quitar y poner cabeceras al mensaje.
- Perl y el módulo Encode por si es necesario manipular textos codificados.
- maildrop o algo similar para filtrar el correo justo antes de su entrega.
Todo ello envuelto en un programa como el siguiente ...
#!/bin/sh
# Como ayuda para depurar fijamos un valor
# predeterminado para la etiqueta
LABEL=${1:-LABEL}
# Tenemos que salvar todo el mensaje entrante en un archivo temporal
# porque las operaciones posteriores se llevan en dos fases
TMPMSG=/tmp/$(basename $0).$$
cat > $TMPMSG
# La primera fase es leer el campo 'Subject' y almacenarlo en una
# variable,
SUBJECT=$(reformail -x Subject: < $TMPMSG)
# a la que añadimos el etiquetado entre corchetes,
NEWSUBJECTPARAM="Subject: [${LABEL}] ${SUBJECT}"
# y la segunda fase consiste en sustituir el campo 'subject' por el que hemos
# formado y renombrar el anterior con el prefijo 'old-' para no perder
# contenido.
reformail -i "${NEWSUBJECTPARAM}" < $TMPMSG
... y situado en el filtro de correo de la cuenta o cuentas de correo que necesitamos; lo siguiente es un ejemplo de cómo añadir una etiqueta especial a aquellos mensajes que contengan notificaciones de Correos y Telégrafos y está situado dentro del archivo $HOME/.mailfilter
:
#
# Notificaciones e correos.es
#
if (/^From:.*correos.es/)
{
xfilter "/usr/local/bin/add2subject CORREOS"
}
Testear autentificación IMAP
- Ref: How to test an IMAP server by using telnet
Si utilizamos una conexión plana con un servidor IMAP lo podremos hacer así:
$ telnet taquiones.net imap Trying 80.68.92.119... Connected to taquiones.net. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 ... AUTH=PLAIN] Dovecot ready. a1 LOGIN victor PASSWORD a1 OK [CAPABILITY IMAP4rev1 ... SPECIAL-USE] Logged in a2 LOGOUT a3 LOGOUT * BYE Logging out a3 OK Logout completed. Connection closed by foreign host.
Y si necesitamos una conexión segura tendremos que utilizar openssh en lugar de telnet variando el puerto según el servidor esté configurado:
$ openssl s_client -connect taquiones.net:995 -quiet depth=1 C = ES, ST = Madrid, O = Taquiones, OU = CA, CN = taquiones.net, emailAddress = postmaster@taquiones.net verify error:num=19:self signed certificate in certificate chain verify return:0