A medida que una persona aprende más sobre cómo funcionan los clientes de correo, los servidores SMTP y todo el sistema de correo en línea, puede sentir curiosidad por saber por qué se necesita un servidor SMTP intermedio. Con eso en mente, el post de preguntas y respuestas de los SuperUsuarios de hoy tiene las respuestas a las preguntas de un lector curioso.
La sesión de preguntas y respuestas de hoy nos llega por cortesía del SuperUsuario, una subdivisión de Stack Exchange, una agrupación de sitios web de preguntas y respuestas impulsada por la comunidad.
Foto cortesía de David Schroeder (Flickr).
El lector de SuperUser Tobia quiere saber por qué se necesita un servidor SMTP intermedio para enviar correo:
¿Por qué necesito un servidor SMTP intermedio para enviar correo? ¿Por qué mi cliente de correo (Outlook o Thunderbird) no puede enviar mensajes directamente al dominio SMTP del destinatario?
Por ejemplo, si tengo que enviar correo aaddress@example.com con mi cuenta de Gmail, lo envío al servidorsmtp.gmail.com; entonces este servidor envía mi mensaje al servidor MX deexample.com.
¿Por qué se necesita un servidor SMTP intermedio para enviar correo?
La respuesta
El colaborador de SuperUser davidgo tiene la respuesta para nosotros:
Es técnicamente posible enviar correo directamente al servidor SMTP del destinatario desde su ordenador.
Mirándolo desde una perspectiva histórica, si el servidor SMTP remoto está caído, usted quiere que un sistema lo maneje automáticamente y siga reintentando, de ahí que tenga 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 ponía en cola y se enviaba cuando se establecía un enlace.
Pasando a donde los servicios de Internet son baratos, sigue siendo útil disponer de mecanismos para volver a intentar enviar correo si un servidor no está disponible. No es ideal que esta funcionalidad se escriba en el MUA (Mail user agent/end user mail program). Estas funciones encajan en un MTA (Servidor de correo/Servidor SMTP).
Pero se pone peor: spammers. La mayor parte del correo (más del 80 por ciento) es spam. Los proveedores de correo hacen todo lo que pueden para reducir este problema y un gran número de técnicas hacen suposiciones sobre la forma en que se distribuye el correo. Las siguientes son consideraciones importantes:
1. Lista gris:Algunos proveedores eliminará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. Los spammers a menudo no vuelven a intentarlo mientras que un servidor SMTP siempre lo hace. Esto reduce el volumen de spam en un 80 por ciento, pero es una lástima tener que hacer esto.
2. Reputación:Es mucho más probable que alguien que envía correo a través de un servidor SMTP conocido y de buena reputación sea legítimo en comparación con un servidor “fly-by-night”. Para tener una idea de la reputación, los proveedores hacen una serie de cosas:
- Bloquear direcciones dinámicas/clientes (no al 100 por ciento, pero se han trazado grandes porciones de Internet).
- Compruebe si el DNS inverso coincide con el DNS de reenvío. No es muy difícil de hacer, pero muestra cierto nivel de responsabilidad y conocimiento de las mejores prácticas (algo que muchos bloques de direcciones de clientes no tienen).
- Comprueba la reputación. Cuando se comunica con otros servidores SMTP, muchos proveedores llevan un registro de la cantidad de spam y el volumen de correo enviado. Pueden reducir la cantidad de spam limitando las conexiones y vigilando estos parámetros. Hay muchas maneras de hacerlo, no todas obvias, pero que requieren un remitente conocido.
- SPF y DKIM. Estos mecanismos vinculan los recursos DNS al nombre de dominio para dificultar la falsificación del correo y sería difícil, pero no necesariamente imposible de implementar si el programa de correo (MUA) es responsable del correo saliente.
<...