Hispanopedia WikiUn 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), tal como se especifica en la RFC 6409. [ 1 ]
Muchos MTA también realizan la función de un MSA, pero también hay programas diseñados específicamente como MSA sin la funcionalidad completa de un MTA. [ 2 ] Históricamente, en el correo de Internet , tanto las funciones de MTA como de MSA usan el puerto número 25, pero el puerto oficial para los MSA es el 587. [ 1 ] El MTA acepta el correo entrante de un usuario, mientras que el MSA acepta el correo saliente de un usuario.
Beneficios
La separación de las funciones de la MTA y la MSA genera varios beneficios.
Una ventaja es que un MSA, al interactuar directamente con el MUA del autor, puede corregir errores menores en el formato del mensaje (como campos como Fecha , ID del mensaje o Para faltantes, o una dirección sin nombre de dominio) y/o informar inmediatamente del error al autor para que lo corrija antes de enviarlo a cualquier destinatario. Un MTA que recibe un mensaje de otro sitio no puede realizar este tipo de correcciones de forma fiable, y cualquier informe de error generado por dicho MTA llegará al autor (si es que llega) solo después de que el mensaje ya se haya enviado.
Otra ventaja es que, con un número de puerto dedicado, el 587, los usuarios siempre pueden conectarse a su dominio para enviar nuevos correos. 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, los que trabajan en un portátil) seguir 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 .
Otra ventaja es que separar las funciones de MTA y MSA facilita que un MTA rechace el reenvío, es decir, que deniegue cualquier correo que no esté dirigido a un destinatario en un dominio que se sirva localmente. Esta es una estrategia que utilizan los ISP para evitar el envío de spam desde ordenadores cliente infectados con virus. Por el contrario, un MSA generalmente debe aceptar correo para cualquier destinatario en Internet, aunque solo acepta correo de autores autorizados a usar ese MSA y que hayan establecido su identidad ante el MSA mediante autenticación. En épocas en las que tanto el envío como la recepción de correo entrante se realizaban generalmente mediante el mismo protocolo y el mismo servidor, la posibilidad de enviar correo a destinos arbitrarios sin autenticación permitía a los spammers utilizar los MTA como medio para distribuir spam (ya que una sola transacción de mensaje puede solicitar que un MTA reenvíe un mensaje a un gran número de destinatarios), y también dificultaba el rastreo de 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 mediante un nombre de usuario y una contraseña proporcionados por el autor. Por lo tanto, cualquier mensaje recibido por un MSA de este tipo es rastreable 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 spam o que este sea más permisivo que el de un MTA que existe para aceptar correo electrónico entrante de otros dominios. Es difícil establecer confianza en el correo enviado entre dominios arbitrarios, ya que 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 recurrir a 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 errores. [ 4 ] [ 5 ] Por lo tanto, la separación de MSA y MTA evita el uso de mecanismos de reconocimiento de spam poco fiables 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 recientes usan el puerto 587 por defecto, 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 el MUA descubra automáticamente qué servidor proporciona el MSA para un dominio determinado, consultando los registros SRV de ese dominio. El dominio example.com puede publicar su registro de la siguiente manera: [ 6 ]
_submission._tcp.example.com. SRV 0 1 587 mail.example.com.
Autenticación obligatoria
RFC 6409 requiere que los clientes estén autorizados y autenticados para usar 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 .
Aplicación de políticas
El MSA debe verificar que el correo enviado sea sintácticamente válido y cumpla con las políticas del sitio correspondientes. 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 mediante la autenticación utilizada. Esto, en esencia, cumple con el modelo SPF especificado en la RFC 7208.
- Se permite agregar un campo de encabezado de dirección del 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, sin tener en cuenta el caso particular de los campos de encabezado Resent-From, que no están contemplados en RFC 6409.
Véase también
Referencias
- Klensin, J. (abril de 2001). Protocolo simple de transferencia de correo . IETF . doi : 10.17487/RFC2821 . RFC 2821. Recuperado el 14 de noviembre de 2013 .
- "SMTP no es seguro" . Kasoft Central . Consultado el 14 de junio de 2008 .
- 1 2 Gellens, R.; Klensin, J. (noviembre de 2011). "Identificación de envío" . Envío de mensajes para correo . IETF . sec. 3.1. doi : 10.17487/RFC6409 . STD 72. RFC 6409. Recuperado el 14 de noviembre de 2013 .
- ↑ Costales, Bryan; Assmann, Claus; Jansen, George; Shapiro, Gregory Neil (26 de octubre de 2007). sendmail: Creación y administración de sendmail . O'Reilly Media, Inc. ISBN 978-0-596-55534-4.
- ↑ 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 rendición de cuentas . IETF . doi : 10.17487/RFC5068 . RFC 5068. Recuperado 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.
- ↑ 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". Computers & Security . 28 (8): 731– 742. doi : 10.1016/j.cose.2009.05.002 .
- ↑ Jeremy Blosser y David Josephsen (noviembre de 2004). "Mitigación de spam bayesiana centralizada y escalable con Bogofilter" . Actas de LISA '04: Decimoctava Conferencia de Administración de Sistemas . USENIX . Consultado el 24 de junio de 2010 .
- ↑ Cyrus Daboo (marzo de 2011). "Envío de correo electrónico" . Uso de registros SRV para localizar servicios de envío/acceso de correo electrónico . IETF . sec. 3.1. doi : 10.17487/RFC6186 . RFC 6186. Consultado el 17 de abril de 2013 .
- Agentes de correo electrónico
- Autenticación de correo electrónico
- protocolos de correo de Internet