Página principal » cómo » ¿Por qué se necesita un servidor SMTP intermedio para enviar correo?

    ¿Por qué se necesita un servidor SMTP intermedio para enviar correo?

    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, pueden tener curiosidad acerca de por qué incluso se necesita un servidor SMTP intermedio. Con eso en mente, la publicación de preguntas y respuestas de SuperUser 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 de SuperUser, una subdivisión de Stack Exchange, un grupo de sitios web de preguntas y respuestas impulsado por la comunidad..

    Foto cortesía de David Schroeder (Flickr)..

    La pregunta

    Lector superusuario 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 a direcció[email protected] con mi cuenta de Gmail, lo envío a la smtp.gmail.com servidor; entonces este servidor envía mi mensaje al servidor MX de example.com.

    ¿Por qué se necesita un servidor SMTP intermedio para enviar correo??

    La respuesta

    El contribuidor de Superusuario davidgo tiene la respuesta para nosotros:

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

    Mirándolo desde una base histórica, si el servidor SMTP remoto está inactivo, quiere que un sistema lo maneje automáticamente y vuelva a intentarlo, por lo tanto, tiene un servidor SMTP. De manera similar, en el pasado, no todos los servidores de correo estaban conectados todo el tiempo (los enlaces de larga distancia eran costosos), por lo que el correo se colocaba en la cola y se enviaba cuando se establecía un enlace.

    Pasando a donde los servicios de Internet son baratos, todavía es útil tener mecanismos para reintentar el envío de correo si un servidor no está disponible. No es ideal que esta funcionalidad se escriba en el MUA (agente de usuario de correo / programa de correo de usuario final). Estas funciones encajan en un MTA (servidor de correo / servidor SMTP).

    Pero se pone peor, los spammers. La mayoría del correo (más del 80 por ciento) es spam. 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. Las siguientes son consideraciones importantes:

    1. Greylisting: 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 debe hacerlo. Esto reduce el volumen de spam en alrededor del 80 por ciento, pero apesta tener que hacer esto aunque.

    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 nocturno. Para tener una idea de la reputación, los proveedores hacen varias cosas:

    • Bloquee las direcciones dinámicas / de clientes (no el 100 por ciento, pero se han mapeado grandes porciones de Internet).
    • Compruebe si el DNS inverso coincide con el DNS hacia adelante. 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).
    • Compruebe la reputación. Al comunicarse con otros servidores SMTP, muchos proveedores realizan un seguimiento de la cantidad de correo no deseado y el volumen de correo enviado. Pueden reducir la cantidad de spam al limitar las conexiones y vigilar estos parámetros. Hay muchas formas de hacerlo, no todas obvias, pero que requieren un remitente conocido.
    • SPF y DKIM. Estos mecanismos vinculan los recursos de DNS con el 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.

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


    ¿Tienes algo que agregar a la explicación? Apaga el sonido en los comentarios. ¿Quieres leer más respuestas de otros usuarios de Stack Exchange con experiencia en tecnología? Echa un vistazo a la discusión completa aquí.