Historia del Protocolo SMTP

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

Predecesores de SMTP

Encabezados del protocolo de transferencia SMTP
Encabezados del protocolo de transferencia SMTP

En la década de 1960 se utilizaron varias formas de mensajería electrónica uno a uno. Los usuarios se comunicaban usando sistemas desarrollados para computadoras centrales específicas. A medida que se interconectaron más computadoras, especialmente en ARPANET del gobierno de los EE. UU., se desarrollaron estándares para permitir el intercambio de mensajes entre diferentes sistemas operativos. SMTP surgió de estos estándares desarrollados durante la década de 1970.

El correo en ARPANET tiene sus raíces en 1971: el Protocolo de buzón de correo, que no se implementó, pero se analiza en RFC 196; y el programa SNDMSG, que Ray Tomlinson de BBN adaptó ese año para enviar mensajes a través de dos computadoras en ARPANET. En el RFC 524 de junio de 1973 se hizo una propuesta adicional para un Protocolo de correo, que no se implementó.

El uso del Protocolo de transferencia de archivos (FTP) para el "correo de red" en ARPANET se propuso en RFC 469 en marzo de 1973. A través de RFC 561, RFC 680, RFC 724 y finalmente RFC 733 en noviembre de 1977, un marco estandarizado para " correo electrónico" utilizando servidores de correo FTP.

SMTP original

En 1980, Jon Postel y Suzanne Sluizer publicaron el RFC 772 que proponía el Protocolo de transferencia de correo como reemplazo del uso de FTP para el correo. RFC 780 de mayo de 1981 eliminó todas las referencias a FTP y asignó el puerto 57 para TCP y UDP, una asignación que IANA eliminó desde entonces. En noviembre de 1981, Postel publicó RFC 788 "Protocolo simple de transferencia de correo".

El estándar SMTP se desarrolló casi al mismo tiempo que Usenet, una red de comunicación de uno a muchos con algunas similitudes.

SMTP se volvió ampliamente utilizado a principios de la década de 1980. En ese momento, era un complemento del Programa de copia de Unix a Unix (UUCP), que era más adecuado para manejar transferencias de correo electrónico entre máquinas que estaban conectadas de forma intermitente. SMTP, por otro lado, funciona mejor cuando las máquinas de envío y recepción están conectadas a la red todo el tiempo. Ambos utilizaron un mecanismo de almacenamiento y reenvío y son ejemplos de tecnología push. Aunque los grupos de noticias de Usenet todavía se propagaban con UUCP entre servidores, UUCP como transporte de correo virtualmente ha desaparecido junto con las "rutas explosivas" que usaba como encabezados de enrutamiento de mensajes.

Sendmail, lanzado con 4.1cBSD en 1983, fue uno de los primeros agentes de transferencia de correo en implementar SMTP. Con el tiempo, a medida que BSD Unix se convirtió en el sistema operativo más popular en Internet, Sendmail se convirtió en el MTA (agente de transferencia de correo) más común.

El protocolo SMTP original solo admitía comunicaciones de texto ASCII de 7 bits no autenticadas y no cifradas, susceptibles de ataques triviales de intermediarios, suplantación de identidad y correo no deseado, y requería que los datos binarios se codificaran en texto legible antes de la transmisión. Debido a la ausencia de un mecanismo de autenticación adecuado, por diseño, cada servidor SMTP era una retransmisión de correo abierta. El Consorcio de correo de Internet (IMC) informó que el 55 % de los servidores de correo eran repetidores abiertos en 1998, pero menos del 1 % en 2002. Debido a las preocupaciones sobre el spam, la mayoría de los proveedores de correo electrónico bloquean los repetidores abiertos, lo que hace que el SMTP original sea esencialmente poco práctico para el uso general en Internet..

SMTP moderno

Trazabilidad emisor-receptor de una transferencia SMTP

En noviembre de 1995, RFC 1869 definió el Protocolo de transferencia de correo simple extendido (ESMTP), que estableció una estructura general para todas las extensiones existentes y futuras que tenían como objetivo agregar las funciones que faltaban en el SMTP original. ESMTP define medios consistentes y manejables por los cuales los clientes y servidores de ESMTP pueden identificarse y los servidores pueden indicar extensiones admitidas.

El envío de mensajes (RFC 2476) y SMTP-AUTH (RFC 2554) se introdujeron en 1998 y 1999 y ambos describen nuevas tendencias en la entrega de correo electrónico. Originalmente, los servidores SMTP solían ser internos de una organización, recibían correo para la organización desde el exterior y retransmitían mensajes de la organización al exterior. Pero a medida que pasó el tiempo, los servidores SMTP (agentes de transferencia de correo), en la práctica, ampliaron sus funciones para convertirse en agentes de envío de mensajes para los agentes de usuario de correo, algunos de los cuales ahora retransmitían correo desde el exterior.de una organización (por ejemplo, un ejecutivo de la empresa desea enviar correo electrónico durante un viaje utilizando el servidor SMTP corporativo). Este problema, una consecuencia de la rápida expansión y popularidad de la World Wide Web, significó que SMTP tenía que incluir reglas y métodos específicos para la retransmisión de correo. y autenticar a los usuarios para evitar abusos, como la retransmisión de correo electrónico no solicitado (spam). Trabajar en el envío de mensajes (RFC 2476) se inició originalmente porque los servidores de correo populares a menudo reescribían el correo en un intento de solucionar los problemas, por ejemplo, agregando un nombre de dominio a una dirección no calificada. Este comportamiento es útil cuando el mensaje que se está reparando es un envío inicial, pero peligroso y dañino cuando el mensaje se originó en otro lugar y se está retransmitiendo. La separación limpia del correo en envío y retransmisión se consideró una forma de permitir y fomentar la reescritura de envíos y prohibir la reescritura de retransmisión. A medida que el spam se volvió más frecuente, también se lo vio como una forma de proporcionar autorización para el envío de correo desde una organización, así como la trazabilidad. Esta separación entre retransmisión y envío se convirtió rápidamente en la base de las prácticas modernas de seguridad del correo electrónico.

Como este protocolo comenzó puramente basado en texto ASCII, no funcionó bien con archivos binarios o caracteres en muchos idiomas distintos del inglés. Se desarrollaron estándares como Multipurpose Internet Mail Extensions (MIME) para codificar archivos binarios para transferirlos a través de SMTP. Los agentes de transferencia de correo (MTA) desarrollados después de Sendmail también tendían a implementarse con limpieza de 8 bits, de modo que la estrategia alternativa "solo enviar ocho" podría usarse para transmitir datos de texto arbitrarios (en cualquier codificación de caracteres similar a ASCII de 8 bits) a través de SMTP. Mojibake seguía siendo un problema debido a las diferentes asignaciones de conjuntos de caracteres entre los proveedores, aunque las direcciones de correo electrónico solo permitían ASCII. Actualmente, los MTA limpios de 8 bits tienden a admitir la extensión 8BITMIME, permitiendo que algunos archivos binarios se transmitan casi tan fácilmente como el texto sin formato (aún se aplican los límites en la longitud de línea y los valores de octetos permitidos, por lo que se necesita la codificación MIME para la mayoría de los datos que no son de texto y algunos formatos de texto). En 2012, elSMTPUTF8La extensión se creó para admitir texto UTF-8, lo que permite contenido y direcciones internacionales en alfabetos no latinos como el cirílico o el chino.

Muchas personas contribuyeron a las especificaciones básicas de SMTP, entre ellas Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin y Keith Moore.

Contenido relacionado

IPv4

El Protocolo de Internet versión 4 o IPv4 es la cuarta versión del Protocolo de Internet su...

Servidor multimedia

Un servidor multimedia es un dispositivo informático o un software de aplicación que almacena medios digitales y los pone a disposición a través de una...

Capa de transporte

En redes informáticas, la capa de transporte, nivel de transporte o transport layer es una división conceptual de métodos en la arquitectura en capas de...
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save