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 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 los 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 MTA y MSA produce varios beneficios.

Un beneficio es que un MSA, dado que interactúa directamente con el MUA del autor, puede corregir errores menores en un formato de mensaje (como la falta de campos Fecha , ID de mensaje , Para o una dirección a la que le falta un nombre de dominio) y/ o informar inmediatamente de un error al autor para que pueda corregirlo 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) solo después de que el mensaje ya haya sido enviado.

Un beneficio más es que con un número de puerto dedicado, 587, siempre es posible que los usuarios se conecten a su dominio para enviar correo nuevo. Para combatir el spam (incluido el spam enviado involuntariamente 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 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 facilita que un MTA niegue la retransmisión, es decir, rechace cualquier correo que no esté dirigido a un destinatario en un dominio que se sirva localmente. Esta es una estrategia utilizada por los ISP para evitar el envío de spam desde computadoras cliente infectadas con virus. Por el contrario, una MSA generalmente debe aceptar correo de cualquier destinatario en Internet, aunque sólo acepta dicho correo de autores que estén autorizados a utilizar esa MSA y que hayan establecido su identidad ante la MSA mediante autenticación. En tiempos en los que tanto el envío como la aceptación del correo entrante se realizaban normalmente 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 MTA como medio para distribuir spam (ya que una transacción de un solo mensaje puede solicitar que un MTA transmita un mensaje a un gran número de destinatarios), y también hizo más difícil rastrear un mensaje hasta su origen.

Además, los MSA y los MTA pueden tener políticas diferentes para el filtrado de spam. La mayoría de los MSA requieren autenticación en forma de nombre de usuario y contraseña proporcionados por el autor. Por lo tanto, cualquier mensaje recibido por dicha MSA se puede rastrear hasta un autor que tiene una relación directa con la MSA y a quien se le puede considerar responsable de sus acciones. Esto permite que el MSA no tenga filtrado de spam o que tenga un filtrado de spam más permisivo que un MTA que existe con el fin 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 confianza, o incluso identidad. En ausencia de dicha confianza, un MTA generalmente debe confiar en heurísticas y servicios de reputación de terceros para distinguir el spam 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 spam poco confiables durante el envío de correo y aumenta la probabilidad de que el correo legítimo se entregue exitosamente.

Protocolo

Configuración

Mientras que los clientes de correo electrónico recientes utilizan el puerto 587 de forma predeterminada, los más antiguos todavía proponen el puerto 25. En este último caso, los usuarios deben cambiar el número de puerto manualmente. También es posible que MUA descubra automáticamente qué servidor proporciona MSA para un dominio determinado y busque los registros SRV de ese dominio. El dominio ejemplo.com puede publicar su registro así: [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 más obsoleto) POP antes de SMTP .

Politica de ACCION

La MSA debe verificar que el correo enviado sea sintácticamente válido y se ajuste a las políticas pertinentes del sitio. RFC 6409 contiene algunas características opcionales:

Ver también

Referencias

  1. ^ ab Gellens, R.; Klensin, J. (noviembre de 2011). "Identificación del envío". Envío de mensajes por correo. IETF . segundo. 3.1. doi : 10.17487/RFC6409 . ETS 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: compila y administra 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 del remitente de correo electrónico basados ​​en DNS: una revisión crítica". Computadoras y seguridad . 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 por correo electrónico". Uso de registros SRV para localizar servicios de acceso/envío de correo electrónico. IETF . segundo. 3.1. doi : 10.17487/RFC6186 . RFC 6186 . Consultado el 17 de abril de 2013 .