====== Buenas prácticas para el servicio de correo electrónico ======

En este artículo expondremos brevemente algunas reglas para asegurarnos de que nuestro servicio de correo electrónico funcione correctamente. Se asume que se posee un nivel intermedio de familiaridad con la administración de redes, por lo que algunas cosas básicas no se explicarán aquí.

===== Introducción =====

En el mundo de las comunicaciones, hay una regla no escrita: la red de destino no tiene obligación alguna de aceptar un mensaje si no cumple las normas que considera aceptables. Es su potestad, y le toca a los administradores de los sistemas que intentan entregar mensajes a esa red realizar los ajustes necesarios para que se cumplan esas normas.

Obviamente que no deben usarse normas tan estrictas y complejas que se vuelva prácticamente imposible cumplirlas, pero lamentablemente, con la creciente avalancha de spams, intentos de suplantación de identidad y otros ataques con métodos de ingeniería social, se hace necesario utilizar normas de verificación un poco más estrictas a las inicialmente necesarias hace unas décadas cuando comenzó a popularizarse el servicio de correo electrónico. A muchos aqui les consta que la OSRI((Oficina para la Seguridad de las Redes Informáticas.)) comprueba regularmente la vulnerabilidad de los servicios, y las reglas que mencionaremos aquí no son particularmente difíciles de implementar, y ayudan a prevenir parte de estas vulnerabilidades.

===== Reglas a implementar =====

  * El equipo que pretenda enviar un mensaje de correo mediante SMTP/SMTPS, primeramente debería identificarse correctamente con su FQDN((//Fully-Qualified Domain Name//, nombre de dominio plenamente calificado.)) en la instrucción HELO/EHLO, por ejemplo: ''ehlo nombredelequipo.subdominio.dominio.tld'' y no usando un nombre sin calificar como ''helo PC-SECRETARIA'' o una dirección IP literal como ''helo [192.2.0.39]''.((Nótese que aunque los estándares de correo recomiendan que se acepten direcciones IP literales, en la práctica esto se pinta de perlas para el //spam// (envío masivo de correo no solicitado), de modo que muchas redes lo prohiben.))
  * El FQDN utilizado durante la identificación debería existir en el DNS del remitente, y lo normal es que coincida con el FQDN del registro MX,((//Mail Exchange//, intercambiador de correos.)) o al menos con el FQDN de un equipo que realmente esté autorizado a entregar mensajes a nombre de ese dominio.
  * Cada dominio que pretenda utilizar el servicio de correo electrónico debería tener al menos un registro MX, incluso aunque se tenga en el DNS un registro TXT con una entrada SPF,((//Sender Policy Framework//, marco de políticas de envío.)) pues no todos los MTA((//Mail Transfer Agent//, agente para transferencia de correo)) tienen implementada esta verificación.((Si no se desea que un MX reciba mensajes desde el exterior, basta con ponerle una prioridad inferior y ademas impedir en el cortafuegos las conexiones entrantes a dicho equipo desde el exterior.))
  * El registro MX debe contener un FQDN y nunca una dirección IP. Obviamente también debe tener asociado un registro A que resuelva ese FQDN a su IP correspondiente. Hay quienes en su lugar utilizan un registro CNAME, pero esto es menos eficiente porque podría obligar al equipo remoto a hacer dos consultas en lugar de una.
  * Jamás debería hacerse una entrada SPF que permita entregar mensajes desde todo un dominio (o subdominio), ni desde todas las direcciones de una subred, a menos que realmente sea una subred exclusivamente de MXs o equipos autorizados a intercambiar mensajes de correo en ese dominio. El valor más seguro es sencillamente ''v=spf1 mx -all'' (es decir, solo el MX puede entregar mensajes de correo a nombre del dominio, ningún otro equipo puede hacerlo).
  * Todo dominio debería imlementar la resolución inversa con un registro PTR para resolver el FQDN correspondiente a la IP del equipo que hace de MX, y en el caso específico de equipos que están autorizados a enviar aunque no sean MXs (cosa en si un poco dudosa), es una medida de verificación prácticamente obligatoria, pues en caso contrario muchos MTA sencillamente rechazarán los mensajes, ya que al no poder identificar el equipo lo confundirán con un //spammer//.((Enviador masivo de correo no solicitado.))
  * Idealmente cada registro PTR debería coincidir con un único FQDN (obviamente, el FQDN del equipo en cuestión al cual debe apuntar).
  * El registro SOA del dominio debe contener una dirección de contacto real en caso de problemas. Si se pretende dejar el valor genérico de ''hostmaster.eldominio.tld'',((Esto es en realidad una dirección de correo, pues el primer punto siempre se interpreta como una arroba.)) al menos debería hacerse un alias de hostmaster a la dirección de correo del responsable de gestionar el DNS.
  * Cada dominio debería implementar la dirección abuse@subdominio.eldominio.tld para el caso de que algún destinatario desee reportar un uso abusivo del servicio de correo electrónico. El uso de esta dirección está suficientemente extendido como para considerarla un estándar, y bien podría simplemente hacerse un alias de dicha dirección a la del postmaster o la persona encargada de velar por el funcionamiento apropiado del servicio, ya que a veces el postmaster está ocupado con otro tipo de tareas.
  * Se considera una buena práctica habilitar la dirección genérica info@subdominio.eldominio.tld para permitir la solicitud de información general a quienes necesiten contactarnos, pero desconozcan a quien dirigirse. Similarmente, esta dirección puede ser un alias a la dirección real de la persona encargada de esta función.

===== Otras reglas útiles =====

  * El MTA jamás debería ser un //Open Relay// (repetidor abierto). Esto puede parecer obvio e innecesario puesto que los programas utilizados como MTA genralmente vienen con una configuración razonablemente segura por defecto, pero a veces una simple modificación en dicha configuración sin saber exactamente lo que se está haciendo, podría cambiar el comportamiento por defecto, de modo que antes de modificar una preferencia, hay que estudiar a fondo la documentación disponible al respecto y siempre debe realizarse una salva antes de cualquier modificación y con posterioridad a dicha modificación deben realizarse todas las comprobaciones de seguridad pertinentes.
  * El MTA debería tener deshabilitados comandos como EXPN o VRFY, y debería tener habilitada la autenticación e idealmente también permitir (pero no necesariamente de manera estricta) la conexión por protocolos seguros.
  * Conviene realizar en nuestro MTA verificaciones que impidan enviar un mensaje con el asunto vacío o solo con espacios. En caso contrario uno prácticamente queda obligado a ir abriendo correo por correo para saber de qué trata, por lo que hay redes que rechazan tales mensajes.
  * En una entidad laboral, es preferible crear las cuentas de correo con la identificación de la función que deben atender, o al menos crear un alias de la función a la dirección real del responsable. Por ejemplo, supongamos que el especialista comercial se llama Juan Valdés y su dirección de correo es ''jvaldes@midominio.tld''. Si Juan se traslada, enferma o fallece, podría ser necesario notificarlo a todos los contactos a quienes se entregó dicha dirección, pues no siempre se dispone de un sitio web para notificarlo, e incluso de tenerse, una cantidad considerable de personas jamás actualiza sus contactos. En cambio, de haberse utilizado por ejemplo la dirección ''espcomercial@midominio.tld'' no habría afectacción alguna.
  * Para combatir el spam actualmente no basta con adoptar medidas tecnológicas, conviene educar a los usuarios contra los posibles intentos de ingeniería social, y así se convertirán en poderoros aliados. Algunas buenas recomendaciones para los usuarios pueden ser: evitar abrir adjuntos que no se han solicitado aunque supuestamente provengan de contactos confiables, desconfiar de cualquier mensaje que solicite enviar información personal por correo (especialmente datos de autenticación), no hacer clic en enlaces a supuestas páginas de bancos, no reenviar cadenas de ningún tipo, no reenviar cualquier mensaje alarmista sobre supuestos virus o amenazas informáticas a nadie más que el administrador de sistemas para que pueda confirmarlo, y en general informarle sobre cualquier actividad sospechosa. Podrá parecer que a corto plazo esto genera más trabajo, pero a mediano y largo plazo esta colaboración ahorrará muchos problemas, especialmente si se agradece a los usuarios por su ayuda.

===== Porciones relacionadas de configuración =====
(Pendiente. Aquí podrían enlazarse otros artículos de la Wiki donde se detalla cómo implementar concretamente estas reglas.)

===== Atribuciones =====

  * **Autor:** Hugo Florentino