stringtranslate.com

Agente de envío de mensajes

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 computadora que ejecuta un MSA también se conoce como servidor de correo saliente .

Beneficios

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.

Protocolo

Configuración

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.

Autenticación obligatoria

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 .

Cumplimiento de políticas

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:

Véase también

Referencias

  1. ^ ab Gellens, R.; Klensin, J. (noviembre de 2011). "Identificación de envío". Envío de mensajes por correo. IETF . sec. 3.1. doi : 10.17487/RFC6409 . STD 72. RFC 6409 . Consultado el 14 de noviembre de 2013 .
  2. ^ Costales, Bryan; Assmann, Claus; Jansen, George; Shapiro, Gregory Neil (26 de octubre de 2007). sendmail: Crear y administrar sendmail. "O'Reilly Media, Inc." ISBN 978-0-596-55534-4.
  3. ^ C. Hutzler; D. Crocker; P. Resnick; E. Allman ; T. Finch (noviembre de 2007). Operaciones de envío de correo electrónico: requisitos de acceso y responsabilidad. IETF . doi : 10.17487/RFC5068 . RFC 5068. Consultado el 13 de febrero de 2013. Los proveedores de acceso NO DEBEN bloquear el acceso de los usuarios a Internet externo mediante el puerto de ENVÍO 587.
  4. ^ Amir Herzberg (19 de mayo de 2009). "Mecanismos de autenticación de remitentes de correo electrónico basados ​​en DNS: una revisión crítica". Computers & Security . 28 (8): 731–742. doi :10.1016/j.cose.2009.05.002.
  5. ^ Jeremy Blosser y David Josephsen (noviembre de 2004). "Mitigación de spam bayesiano centralizada y escalable con Bogofilter". Actas de LISA '04: Decimoctava Conferencia de Administración de Sistemas . USENIX . Consultado el 24 de junio de 2010 .
  6. ^ Cyrus Daboo (marzo de 2011). "Envío de correo electrónico". Uso de registros SRV para localizar servicios de acceso/envío de correo electrónico. IETF . sec. 3.1. doi : 10.17487/RFC6186 . RFC 6186 . Consultado el 17 de abril de 2013 .