Agente de envío de mensajes

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Message submission agent" – news · newspapers · books · scholar · JSTOR (March 2017) (Learn how and when to remove this message)

Un agente de envío de mensajes ( MSA ), o agente de envío de correo , es un programa informático o agente de software que recibe mensajes de correo electrónico de un agente de usuario de correo (MUA) y coopera con un agente de transferencia de correo (MTA) para la entrega del correo. Utiliza ESMTP, una variante del Protocolo simple de transferencia de correo (SMTP), como se especifica en RFC 6409. ^[1]

Muchos MTA también realizan la función de un MSA, pero también hay programas que están especialmente diseñados como MSA sin la funcionalidad completa de MTA. ^[2] Históricamente, en el correo de Internet , tanto las funciones MTA como MSA utilizan el puerto número 25, pero el puerto oficial para MSA es 587. ^[1] El MTA acepta el correo entrante de un usuario, mientras que el MSA acepta el correo saliente de un usuario.

La separación de las funciones de MTA y MSA produce varios beneficios.

Una ventaja es que un MSA, al interactuar directamente con el MUA del autor, puede corregir errores menores en el formato de un mensaje (como la falta de campos Date , Message-ID , To o una dirección con un nombre de dominio faltante) y/o informar inmediatamente un error al autor para que pueda corregirse antes de enviarlo a cualquiera de los destinatarios. Un MTA que acepta un mensaje de otro sitio no puede realizar ese tipo de correcciones de manera confiable, y cualquier informe de error generado por dicho MTA llegará al autor (si es que llega a hacerlo) solo después de que el mensaje ya se haya enviado.

Otro beneficio es que con un número de puerto dedicado, 587, los usuarios siempre pueden conectarse a su dominio para enviar correo nuevo. Para combatir el correo no deseado (incluido el correo no deseado enviado sin saberlo por una víctima de una botnet ), muchos ISP y redes institucionales restringen la capacidad de conectarse a MTA remotos en el puerto 25. La accesibilidad de un MSA en el puerto 587 ^[3] permite a los usuarios nómadas (por ejemplo, aquellos que trabajan en una computadora portátil) continuar enviando correo a través de sus servidores de envío preferidos incluso desde dentro de las redes de otros. El uso de un servidor de envío específico es un requisito cuando se aplican políticas de remitente o prácticas de firma .

Otro beneficio es que separar las funciones de MTA y MSA hace que sea más fácil para un MTA denegar la retransmisión, es decir, rechazar cualquier correo que no esté dirigido a un destinatario en un dominio que se sirve localmente. Esta es una estrategia utilizada por los ISP para evitar el envío de correo basura desde equipos cliente infectados con virus. Por el contrario, un MSA debe aceptar generalmente correo para cualquier destinatario en Internet, aunque sólo acepta dicho correo de autores que estén autorizados a utilizar ese MSA y que hayan establecido su identidad ante el MSA mediante autenticación. En tiempos en los que tanto el envío de correo como la aceptación del correo entrante se realizaban habitualmente utilizando el mismo protocolo y el mismo servidor, la capacidad de enviar correo a destinos arbitrarios sin autenticación permitía a los spammers utilizar los MTA como un medio para distribuir correo basura (ya que una única transacción de mensaje puede solicitar que un MTA retransmita un mensaje a un gran número de destinatarios), y también hacía más difícil rastrear un mensaje hasta su origen.

Además, los MSA y los MTA pueden tener diferentes políticas para filtrar el correo no deseado. La mayoría de los MSA requieren autenticación en forma de un nombre de usuario y una contraseña proporcionados por el autor. Por lo tanto, cualquier mensaje recibido por un MSA de este tipo se puede rastrear hasta un autor que tiene una relación directa con el MSA y que puede ser considerado responsable de sus acciones. Esto permite que el MSA no tenga filtrado de correo no deseado o que tenga un filtrado de correo no deseado más permisivo que un MTA que existe con el propósito de aceptar correo electrónico entrante de otros dominios. Es difícil establecer confianza en el correo enviado entre dominios arbitrarios, porque generalmente no existe una relación directa entre esos dominios a través de la cual se pueda establecer la confianza, o incluso la identidad. En ausencia de dicha confianza, un MTA generalmente debe confiar en la heurística y en servicios de reputación de terceros para distinguir el correo no deseado del tráfico legítimo, y ambos mecanismos tienen un historial de ser propensos a errores. ^{[4] [5]} Por lo tanto, la separación de MSA y MTA evita el uso de mecanismos de reconocimiento de correo no deseado poco confiables durante el envío de correo y aumenta la probabilidad de que el correo legítimo se entregue correctamente.

Si bien los clientes de correo electrónico más recientes utilizan el puerto 587 de manera predeterminada, los más antiguos aún proponen el puerto 25. En este último caso, los usuarios deben cambiar el número de puerto manualmente. También es posible que el MUA descubra automáticamente qué servidor proporciona el MSA para un dominio determinado, buscando los registros SRV para ese dominio. El dominio example.com puede publicar su registro de la siguiente manera: ^[6]

 _envío._tcp.ejemplo.com. SRV 0 1 587 correo.ejemplo.com.

RFC 6409 requiere que los clientes estén autorizados y autenticados para utilizar el servicio de envío de correo, por ejemplo, como se describe en SMTP-AUTH (ESMTPA), o por otros medios como RADIUS , certificados de clave pública o (el mayormente obsoleto) POP antes de SMTP .

El MSA debe comprobar que el correo enviado sea sintácticamente válido y cumpla con las políticas del sitio correspondiente. El RFC 6409 contiene algunas características opcionales:

• La aplicación de los derechos de envío garantiza que la dirección del remitente del sobre sea válida y esté autorizada con la autenticación utilizada. Esto, en esencia, cumple con el modelo SPF especificado en RFC 7208.
• Se pueden agregar permisos de remitente para agregar un campo de encabezado de dirección de remitente si la dirección del remitente del sobre no coincide con ninguna dirección del autor en el campo de encabezado "De". Esto cumple aproximadamente con el modelo de ID de remitente especificado en RFC 4406, ignorando el caso complicado de los campos de encabezado Resent-From que no se cubren en RFC 6409.

• Autenticación de correo electrónico
• Lista de servidores de correo
• Comparación de servidores de correo
• Anfitrión inteligente
• Agente de correo electrónico (infraestructura) (MxA)
• Agente de entrega de correo (MDA)
• Agente de usuario de correo (MUA)

• Klensin, J. (abril de 2001). Protocolo simple de transferencia de correo. IETF . doi : 10.17487/RFC2821 . RFC 2821 . Consultado el 14 de noviembre de 2013 .
• "SMTP no es seguro". Kasoft Central . Consultado el 14 de junio de 2008 .