¿Por qué necesito un servidor SMTP?

¿Por qué necesito un servidor SMTP intermedio para enviar correo? ¿Por qué mi cliente (Outlook, Thunderbird) no puede enviar mensajes directamente al dominio SMTP del destinatario?

Por ejemplo, si tengo que enviar un correo electrónico a address@example.commi cuenta de Gmail, lo envío al smtp.gmail.comservidor; y luego este servidor enviará mi mensaje al servidor MX de example.com.

Es técnicamente posible enviar un correo electrónico directamente al servidor SMTP del destinatario desde su computadora.

Mirándolo desde una base histórica, si el servidor SMTP remoto está inactivo, desea que un sistema lo maneje automáticamente y vuelva a intentarlo, por lo tanto, tiene un servidor SMTP. Del mismo modo, en los viejos tiempos, no todos los servidores de correo estaban conectados todo el tiempo: los enlaces de larga distancia eran caros, por lo que el correo se pondría en cola y se enviaría cuando se estableciera un enlace.

Pasando a donde Internet es barato, sigue siendo útil tener mecanismos para volver a intentar enviar correo electrónico si un servidor no está disponible, y no es ideal que esta funcionalidad se escriba en el MUA (agente de usuario de correo / programa de correo de usuario final). Estas funciones se ajustan a un MTA (servidor de correo / servidor SMTP).

Pero empeora: los spammers . La mayoría de los correos electrónicos (más del 80%) son spam. Por lo tanto, los proveedores de correo hacen todo lo posible para reducir este problema, y ​​una gran cantidad de técnicas hacen suposiciones sobre la forma en que se entrega el correo electrónico. Las siguientes son consideraciones importantes:

1. Lista gris: algunos proveedores desconectarán automáticamente una conexión de correo si el remitente y el destinatario no se han comunicado antes, y esperan que lo intenten por segunda vez, porque los spammers a menudo no lo hacen, mientras que se supone que un servidor SMTP siempre lo hace. Esto reduce los volúmenes de spam en aproximadamente un 80%. Aunque apesta tener que hacer esto.

2. Reputación: es mucho más probable que alguien que envía un correo electrónico a través de un servidor SMTP conocido y legítimo sea legítimo que un servidor de vuelo nocturno. Para tener una idea de la reputación, los proveedores hacen una serie de cosas:

   1. Bloquee direcciones dinámicas / de clientes (no 100%, pero se han asignado grandes porciones de Internet).

   2. Mire que el DNS inverso coincide con el DNS directo: no es muy difícil de hacer, pero muestra cierto nivel de responsabilidad y conocimiento de las mejores prácticas, y algo que muchos bloques de direcciones de clientes no tienen.

   3. Reputación: al comunicarse con otros servidores SMTP, muchos proveedores realizan un seguimiento de la cantidad de correo no deseado y los volúmenes de correo electrónico enviados y pueden reducir la cantidad de correo no deseado al limitar las conexiones y vigilar estos parámetros. (Hay muchas formas de hacerlo, no todas obvias, pero que requieren un remitente conocido).

   4. SPF y DKIM: estos mecanismos vinculan los recursos de DNS con el nombre de dominio para dificultar la falsificación de correo, y sería difícil (pero no necesariamente imposible de implementar si el programa de correo (MUA) es responsable del correo saliente. completo ya que ha sido aceptado. El crédito para ello debe ir a los carteles a continuación, ya que se me olvidó, pero es, sin embargo, muy válido)

Probablemente haya otras preocupaciones menores, pero estas serían las principales.

¿Por qué necesito un servidor SMTP intermedio para enviar correo? ¿Por qué mi cliente (Outlook, Thunderbird) no puede enviar mensajes directamente al dominio SMTP del destinatario?

En 1991, y la mayoría de principios de la década de 1990 e incluso antes, es posible que pueda hacer lo que describe. Pero la realidad en 2015 es que, aunque técnicamente se puede enviar un correo electrónico a cualquier persona desde cualquier máquina que tenga un servicio de correo instalado, el mundo de SPAM ha hecho que ese método sea efectivamente inútil.

Cuando utiliza un servicio SMTP "real", las cosas se configuran como registros PTR, registros SPF e incluso DomainKeys, todos establecidos para un propósito y un solo propósito: garantizar que el SMTP que envía el mensaje es legítimo. ¿Y si no es así? Filtre el mensaje en una carpeta de SPAM o el "gran abismo" de eliminación. Aquí hay un desglose de cada uno de esos elementos:

• PTR (registro de puntero / registro DNS inverso): verificación a nivel del servidor. Como se explica aquí , se utiliza un registro PTR para asignar una interfaz de red (IP) a un nombre de host. Lo que significa que si tiene una dirección 123.456.789.0en su servidor SMTP que envía correos electrónicos para smtp.example.comentonces sería un registro PTR apropiado para eso smtp.example.com. Parece demasiado simple, pero funciona ya que el único que realmente puede establecer un registro PTR es el propietario de la dirección IP y solo se puede configurar en su hardware. Por lo tanto, actúa como un punto de verificación hacia quién posee / ejecuta / administra esa dirección IP.

• SPF (Sender Policy Framework): verificación del nivel de entrada DNS del nombre de host. Un registro SPF, como se explica aquí, es básicamente un registro DNS establecido por el titular del nombre de dominio que proporciona una lista de direcciones IP y nombres de host de servidores que pueden enviar correos electrónicos para ese nombre de dominio. De nuevo, ese es otro paso de verificación que garantiza que solo el verdadero propietario del nombre de dominio para un servidor SMTP pueda enviar correos. Entonces, digamos que un servidor con la dirección IP de 123.456.789.9envía correos electrónicos example.com. Ya sabemos que smtp.example.comutiliza 123.456.789.0, pero una entrada de registro SPF para example.compuede decir: "¡Hey! 123.456.789.9es un buen servidor! Él es de fiar! ¡Respeta sus correos electrónicos!

• DKIM (DomainKeys Identified Mail): verificación de nivel de mensaje de correo electrónico. Como se explica aquí y en Wikipedia , “DKIM es un sistema de validación de correo electrónico diseñado para detectar la suplantación de identidad del correo electrónico al proporcionar un mecanismo para permitir que los intercambiadores de correo verifiquen que el correo entrante de un dominio esté autorizado por los administradores de ese dominio y que el correo electrónico (incluidos los archivos adjuntos) no ha sido modificado durante el transporte. ”Al usar hashes criptográficos, DKIM verifica que el correo en sí no haya sido filtrado o manipulado durante el tránsito. Esto también sirve como otro punto de verificación en la cadena "¿Eres legítimo o eres SPAM?".

Por lo tanto, al final, un servidor SMTP público que valga la pena tendrá al menos dos de estos elementos (PTR y SPF) configurados para verificar que el servidor SMTP y el correo electrónico relacionado sean legítimos. No todos usan DKIM, pero es otra capa de validación que se está volviendo cada vez más popular hoy en día a medida que los SPAMmers se vuelven más tenaces en sus esfuerzos por enviar SPAM.

La mayoría de los ISP residenciales bloquean el puerto TCP 25 (SMTP) para evitar que participe en una red de spam. Si su PC se infecta, su PC puede comenzar a arrojar spam a instancias de otra persona.

Las otras respuestas son excelentes, y el spam tiene mucho que ver con eso.

Pero en realidad hay una respuesta más simple, más genérica: características. Enviar correos electrónicos a través de SMTP es en realidad una tarea muy compleja. Incluso sin spam, no querría implementar todo el conjunto de características del protocolo SMTP en cada cliente de correo electrónico; está mejor con un software dedicado (sendmail, postfix, etc. son los más importantes en el mundo * nix, Exchange en el mundo Windows).

Por ejemplo, incluso en la forma más básica, un servidor SMTP "real" tiene que poder al menos poder resolver los registros MX. Luego tiene que negociar características (principalmente TLS, pero también hay otras características). Tiene que gestionar colas para volver a intentar, generar informes de no entrega, etc.

Y esa es solo la funcionalidad básica, imprescindible, sin la cual el servidor ni siquiera funcionaría. Ni siquiera incluye cosas como la reescritura de direcciones, las listas de correo. Sin mencionar la docena de otros protocolos que son compatibles con sendmail y otros, como UUCP.

La implementación de SMTP en Outlook, Thunderbird, etc. es muy mínima, en el mejor de los casos, aproximadamente el equivalente a usar un host inteligente en sendmail, si eso es así.

Relacionado, pero un tema separado: el correo electrónico es un tema muy sensible a la seguridad, y desearía tener uno o muy pocos servidores administrados centralmente para manejarlo, en lugar de potencialmente cientos o miles de servidores individuales en cada escritorio.

¿Por qué necesito un servidor SMTP intermedio para enviar correo? ¿Por qué mi cliente (Outlook, Thunderbird) no puede enviar mensajes directamente al dominio SMTP del destinatario?

Podrías crear un programa de correo electrónico que hiciera esto, y no dudo que otros lo hayan hecho (o intentado) también antes.

Esencialmente, estaría escribiendo una herramienta que sea tanto MUA (agente de usuario de correo) como MTA (agente de transferencia de correo) en una.

La razón de que esto se separe tradicionalmente en diferentes herramientas, con el MTA que reside en el "lado del servidor", es que un MTA que envía correo a través de Internet abierto es considerablemente más complejo de escribir y configurar, y también se beneficia de residir en un servidor confiable "siempre encendido".

Una MTA tiene que:

• Busque y conéctese a servidores en los que no confía, o que pueden comportarse mal, y trate las condiciones de error de una manera sensata que no pierda el correo.

• Trate con los servidores que están inactivos y diríjase a servidores alternativos o ponga en cola el correo para volver a intentarlo más tarde. Esto funciona mejor en un proceso de servidor que está "siempre conectado" a Internet. También implica que el agente de transferencia de correo necesita sus propias áreas de almacenamiento para el correo que está en cola.

• Maneje una variedad de capacidades diferentes del servidor, ajustando el comportamiento de acuerdo con las capacidades del servidor receptor.

• Informe al usuario sobre las condiciones de error o cuando el correo no se pueda entregar, para que el correo no solo se pierda.

• Tenga excelentes prácticas de seguridad y sea muy consciente de la seguridad.

• Idealmente, resida en un servidor confiable y siempre conectado con una dirección IP estable y una entrada de DNS inversa, es decir, una conexión a Internet adecuada para servidores públicos. Esto ayuda a otros sistemas a no detectar el correo enviado como spam.

Teniendo en cuenta estos requisitos, tiene sentido alojar el servidor SMTP en un servidor público siempre activo en algún lugar, y tratar de usar una herramienta adecuada para hacer ese trabajo en particular.

Otra cosa a considerar es recibir correos electrónicos devueltos . Como mínimo, todos los correos electrónicos salientes tienen una dirección DESDE donde se puede enviar una respuesta (usuario desconocido, respuesta de vacaciones, etc.). Para que se resuelva la dirección de devolución, debe existir un registro MX que apunte a la ubicación de la bandeja de entrada de devolución. A menos que envíe un correo electrónico desde una computadora con una dirección IP estática que siempre está encendida, necesitará un servidor para manejar estos mensajes entrantes. Esto es típicamente (pero no siempre) manejado por el mismo servicio.

GMail, Outlook 365 y Yahoo Mail son ejemplos de servicios de correo electrónico que utilizan las personas que envían correos electrónicos. Para el envío comercial de correo electrónico, existen servicios como MailChimp, Marketo y Eloqua que son muy buenos para enviar correos electrónicos masivos para una empresa y manejar cosas como rebotes, estrangulamiento y capacidad de entrega.

Ver: https://en.m.wikipedia.org/wiki/Bounce_address