Network Working Group J. Klensin, Presidente del Grupo de Trabajo Request For Comments: 1869 MCI STD: 10 N. Freed, Editor Obsoleta: 1651 Innosoft International, Inc. Categoría: Seguimiento de Estándar M. Rose Dover Beach Consulting, Inc. E. Stefferud Network Management Associates, Inc. D. Crocker Brandenburg Consulting Noviembre 1995 Traducción: Rubén Afonso Francos Extensiones del Servicio SMTP Estado de este memorándum Este documento especifica un seguimiento de protocolo estándar de Internet para la comunidad Internet y requiere del debate y las sugerencias para su perfeccionamiento. Por favor remítase a la edición actual de "Protocolos Estándares Oficiales de Internet" (STD 1) para conocer el nivel de estandarización y estado de este protocolo. La distribución de este memorándum es ilimitada. 1. Resumen Este memorándum define un método de ampliación del servicio proporcionado por SMTP mediante el cual un servidor SMTP puede informar a un cliente SMTP de las extensiones de servicio que soporta. Las extensiones de los servicios SMTP están registradas por la IANA. Este método no requiere de la modificación de los clientes o servidores SMTP existentes, a menos que éstos soliciten o proporcionen extensiones de servicio. 2. Introducción El Protocolo Simple de Transferencia de Correo (SMTP) [1] ha venido proporcionando una base estable y efectiva para las transferencias realizadas por los agentes de correo. A pesar de que tiene más de una década, SMTP ha demostrado una fortaleza notable. Sin embargo se ha hecho patente la necesidad de varias extensiones del protocolo. En lugar de describir estas extensiones como entes separados y desordenados, este documento realza de forma clara SMTP como la base sobre la que se pueden construir de forma sencilla y consistente futuras extensiones. Klensin, et al Seguimiento de Estándar [Pág. 1] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 3. Estructura para las Extensiones SMTP Para las extensiones de los servicios SMTP, el mensaje SMTP es una unidad de correo formada por envoltura y contenido. (1) La envoltura SMTP es clara, y se transmite como una serie de unidades del protocolo SMTP: está formada por una dirección de origen (a donde se deberían remitir los errores); un modo de entrega (por ejemplo, entregar a las cuentas de correo del receptor); y una o más direcciones de recepción. (2) El contenido SMTP se envía dentro de la unidad de DATOS del protocolo SMTP, y consta de dos partes: las cabeceras y el cuerpo. Las cabeceras forman un conjunto de pares campo/valor estructurados de acuerdo con el RFC 822 [2], mientras que el cuerpo, si se encuentra estructurado, está definido de acuerdo con MIME [3]. El contenido es textual por naturaleza, representado utilizando el repertorio US ASCII (ANSI X3.4-1986). A pesar de que las extensiones (como MIME) pueden suavizar esta restricción referente al cuerpo, las cabeceras siempre se codifican utilizando el repertorio US ASCII. El algoritmo definido en [4] se utiliza para representar valores de la cabecera que no están en el repertorio US ASCII, mientras se sigue usando dicho repertorio para codificarlos. A pesar de que SMTP se encuentra amplia y sólidamente extendido, algunos sectores de la comunidad Internet desean ampliar los servicios que proporciona. Este memorándum define un método que permite que un cliente y un servidor extendidos puedan reconocerse como tal y en el que un servidor pueda informar al cliente de las extensiones que soporta. Debe resaltarse que ninguna extensión del servicio SMTP debe ser considerada a la ligera. La robustez de SMTP proviene principalmente de su sencillez. Las experiencias con otros protocolos han demostrado que: los protocolos con pocas opciones tienden a la ubicuidad, mientras que los que tienen muchas opciones tienden a la oscuridad. Esto significa que cada extensión, sin importar las ventajas que aporte, debe ser cuidadosamente analizada a lo que su implementación, desarrollo, y costes de interoperabilidad se refiere. En muchos casos, el coste derivado de la extensión del servicio SMTP superará a los beneficios. Klensin, et al Seguimiento de Estándar [Pág. 2] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 Dada esta situación, las extensiones descritas en este memorándum consisten en: (1) un nuevo comando SMTP (sección 4) (2) un registro de las extensiones del servicio SMTP (sección 5) (3) parámetros adicionales para los comandos MAIL FROM y RCPT TO del protocolo SMTP (sección 6). 4. El comando EHLO Un cliente SMTP que soporte las extensiones del servicio SMTP debería comenzar una sesión SMTP enviando el comando EHLO en lugar del comando HELO. Si el servidor SMTP también las soporta devolverá una respuesta satisfactoria (ver sección 4.3), una respuesta de fallo (ver sección 4.4), o bien una respuesta de error (4.5). Si el servidor SMTP no soporta ninguna extensión del servicio SMTP generará una respuesta de error (ver sección 4.5). 4.1 Modificaciones al STD 10, RFC 821 Esta especificación está destinada a extender el STD 10, RFC 821 sin influir de ninguna manera en los servicios ya existentes. Los cambios menores requeridos se enumeran debajo. 4.1.1 Primer comando El RFC 821 establece que el primer comando en una sesión SMTP debe ser HELO. Por la presente se modifica este requisito de forma que se permite iniciar una sesión con HELO o con EHLO. 4.1.2 Longitud máxima de la linea de comandos Esta especificación amplía los comandos MAIL FROM y RCPT TO del protocolo SMTP para permitir parámetros y valores de parámetro adicionales. Es posible que las líneas MAIL FROM y RCPT TO resultantes excedan el límite de 512 caracteres impuesto por el RFC 821. Por la presente se modifica dicho límite para que se aplique únicamente a las líneas de comandos que no contengan ningún parámetro. Las especificaciones que definan nuevos parámetros para MAIL FROM o RCPT TO deben además especificar la longitud máxima de los mismos para que los implementadores de las extensiones conozcan el tamaño del bloque de memoria que deben reservar. La longitud máxima de comando que una implementación SMTP con extensiones debe soportar es 512 más la suma de la longitud máxima de todos los parámetros de cada una de las extensiones soportadas. Klensin, et al Seguimiento de Estándar [Pág. 3] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 4.2. Sintaxis del comando La sintaxis de este comando, usando la notación ABNF de [2], es: ehlo-cmd ::= "EHLO" SP dominio CR LF Si hay éxito, el servidor SMTP responde con el código 250. En caso de fallo, el servidor responde con el código 550. Si hay un error, responde con el código 500, 501, 502, ó 421. Este comando es enviado en lugar del comando HELO, y puede ser transmitido en cualquier momento en el que fuese apropiado enviar el comando HELO. Es decir, si se envía el comando EHLO, y se devuelve una respuesta de éxito, otro comando HELO o EHLO posterior hará que el servidor SMTP responda con el código 503. El cliente SMTP no debe almacenar ninguna información que se haya devuelto si el comando EHLO se responde con éxito. Esto es, el cliente SMTP debe enviar el comando EHLO al inicio de cada sesión SMTP si se necesita información sobre los recursos extendidos. 4.3. Respuesta Satisfactoria Si el servidor SMTP implementa y es capaz de utilizar el comando EHLO, devolverá el código 250. Esto indica que tanto el cliente como el servidor SMTP se encuentran en el estado inicial, es decir, no existe transacción en curso y todas las tablas de estado y buffers se encuentran vacías. Normalmente, esta respuesta ocupará varias líneas. Cada línea de la respuesta contendrá un comando y, opcionalmente, uno o más parámetros. La sintaxis para una respuesta positiva, utilizando la notación ABNF de [2], es: respuesta-ehlo-ok ::= "250" dominio [ SP saludo ] CR LF / ( "250-" dominio [ SP saludo ] CR LF *( "250-" linea-ehlo CR LF ) "250" SP linea-ehlo CR LF ) ; la conversación EHLO usual saludo ::= 1* linea-ehlo ::= clave-ehlo *( SP parámetro-ehlo ) clave-ehlo ::= (LETRA / DÍGITO) *(LETRA / DÍGITO / "-") Klensin, et al Seguimiento de Estándar [Pág. 4] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 ; la sintaxis y los valores dependen de la ; clave-ehlo parámetro-ehlo ::= 1* LETRA ::= DÍGITO ::= CR ::= LF ::= SP ::= Aunque los comandos EHLO estén escritos en mayúsculas, minúsculas, o una mezcla de ambas, siempre deben ser reconocidos y procesados de forma insensible a las mayúsculas o minúsculas. Esto sólo es una extensión de las prácticas empezadas en el RFC 821. La IANA mantiene un registro de las extensiones del servicio SMTP. Asociado con cada extensión existe un valor clave EHLO. Cada extensión de servicio registrada por la IANA debe estar definida en un RFC. Dichos RFC deben ser un seguimiento de estándar o definir un protocolo experimental aprobado por el IESG. La definición debe incluir: (1) el nombre textual de la extensión del servicio SMTP; (2) el valor de la clave EHLO asociada con la extensión; (3) la sintaxis y los posibles valores de los parámetros asociados con el valor de la clave EHLO. (4) cualquier palabra SMTP adicional asociada con la extensión (las palabras adicionales generalmente, aunque no necesariamente, coinciden con el valor de la clave EHLO); (5) cualquier parámetro nuevo que la extensión asocie con las claves MAIL FROM o RCPT TO; (6) la forma en que el hecho de soportar la extensión afecta al comportamiento del cliente y del servidor SMTP; y, Klensin, et al Seguimiento de Estándar [Pág. 5] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 (7) el incremento que produce la extensión en la longitud máxima de los comandos MAIL FROM, RCPT TO, o ambos, por encima de lo especificado en el RFC 821. Adicionalmente, cualquier valor de la clave EHLO que comience con "X", ya sea mayúscula o minúscula, hará referencia a una extensión SMTP local, la cual será utilizada a través de un acuerdo bilateral en lugar de uno estandarizado. No se utilizarán claves que comiencen con "X" en una extensión de servicio registrada. Cualquier valor de clave presentado en la respuesta EHLO que no comience con "X" debe corresponder con un estándar, seguimiento de estándar, o extensión de servicio SMTP experimental aprobada por el IESG y registrada por la IANA. Un servidor conforme con esto no debe ofrecer claves que no comiencen por "X" que no estén descritas en una extensión registrada. Las claves adicionales están sometidas a las mismas normas que las claves EHLO; en concreto, las palabras que comiencen con "X" son extensiones locales que pueden no estar registradas o estandarizadas y las palabras que no comiencen con "X" siempre deben estar registradas. 4.4. Respuesta de Fallo Si por alguna razón el servidor SMTP es incapaz de mostrar las extensiones de servicio que soporta, devolverá el código 554. En el caso de una respuesta de fallo, el cliente SMTP debería enviar el comando HELO o QUIT. 4.5. Respuestas de Error generadas por servidores extendidos Si el servidor SMTP reconoce el comando EHLO, pero no acepta los argumentos que lo acompañan, devolverá el código 501. Si el servidor SMTP lo reconoce, pero no lo implementa, devolverá el código 502. Si el servidor SMTP determina que no es posible seguir proporcionando el servicio SMTP (por ejemplo, debido a un apagado inmediato), devolverá el código 421. El cliente SMTP debería enviar el comando HELO o QUIT en el caso de que reciba cualquier respuesta de error. 4.6. Respuestas de servidores sin extensiones Klensin, et al Seguimiento de Estándar [Pág. 6] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 Un servidor SMTP que es conforme con el RFC 821 pero no soporta las extensiones especificadas aquí, no reconocerá el comando EHLO y consecuentemente devolverá el código 500, tal y como se especifica en el RFC 821. El servidor SMTP debería permanecer en el mismo estado después de devolver este código (ver sección 4.1.1 del RFC 821). El cliente SMTP puede entonces enviar el comando HELO o QUIT. 4.7. Respuestas de servidores mal implementados Se sabe que algunos servidores SMTP cortan la transmisión SMTP al recibir el comando EHLO. La desconexión puede ocurrir inmediatamente o después de devolver una respuesta. Este comportamiento infringe la sección 4.1.1 del RFC 821, que establece claramente que la desconexión sólo debe producirse después de que se envíe el comando QUIT. Para conseguir una mejor interoperabilidad, en ningún caso se sugiere que los clientes SMTP extendidos utilizando EHLO sean implementados para comprobar si el servidor ha desconectado después de enviar el comando EHLO, ya sea antes o después de haber devuelto una respuesta. Si esto ocurre el cliente debe decidir si la operación puede ser realizada sin utilizar ninguna extensión SMTP. Si es así, se puede abrir una nueva conexión y utilizar el comando HELO. Otros servidores mal implementados no aceptarán un comando HELO después de que haya sido enviado el comando EHLO y se haya rechazado. En algunos casos, este problema puede ser evitado enviando un RSET después de devolver la respuesta fallida al EHLO, y enviar posteriormente HELO. Los clientes que hagan esto deberían ser advertidos de que muchas implementaciones devolverán un código de fallo (por ejemplo, 503 secuencia errónea de comandos) en respuesta al RSET. Este código puede ser ignorado con tranquilidad. 5. Registro inicial de la IANA El registro inicial de la IANA sobre las extensiones del servicio SMTP consiste en estas entradas: Extensión Comando EHLO Parámetros Comando Conducta añadida ------------- ------------ ---------- --------- ------------------ Envío SEND ninguno SEND definida en RFC 821 Envío o Correo SOML ninguno SOML definida en RFC 821 Envío y Correo SAML ninguno SAML definida en RFC 821 Expandir EXPN ninguno EXPN definida en RFC 821 Ayuda HELP ninguno HELP definida en RFC 821 Devolución TURN ninguno TURN definida en RFC 821 Klensin, et al Seguimiento de Estándar [Pág. 7] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 que corresponden con los comandos SMTP definidos como opcionales en [5]. (Los comandos SMTP obligatorios, conformes con [5], son HELO, MAIL, RCPT, DATA, RSET, VRFY, NOOP, y QUIT). 6. Parámetros MAIL FROM y RCPT TO Se sabe que muchas de las extensiones planeadas para SMTP harán uso de parámetros adicionales asociados con los comandos MAIL FROM y RCPT TO. La sintaxis de estos comandos, de nuevo haciendo uso de la notación ABNF de [2], y bajo las definiciones de [1], es: comando-esmtp ::= cmd-esmtp-interior [SP parámetros-esmtp] CR LF parámetros-esmtp ::= parámetro-esmtp *(SP parámetro-esmtp) parámetro-esmptp ::= clave-esmtp ["=" valor-esmtp] clave-esmtp ::= (LETRA / DÍGITO) *(LETRA / DÍGITO / "-") ; la sintaxis y los valores dependen de ; la clave-esmtp valor-esmtp ::= 1* C: S: 220 dbc.mtview.ca.us servicio SMTP preparado C: EHLO ymir.claremont.edu S: 250 dbc.mtview.ca.us saluda ... indica que el servidor SMTP implementa únicamente aquellos comandos SMTP que están definidos como obligatorios en [5]. (2) En cambio, una interacción de la forma: S: C: S: 220-dbc.mtview.ca.us servicio SMTP preparado C: EHLO ymir.claremount.edu S: 250-dbc.mtview.ca.us saluda S: 250-EXPN S: 250-HELP S: 250-8BITMIME S: 250-XONE S: 250-XVRB ... indica que el servidor SMTP además implementa los comandos EXPN y HELP, una extensión de servicio estándar (8BITMIME), y dos extensiones de servicio no estándares sin registrar (XONE y XVRB). (3) Finalmente, un servidor que no soporte extensiones del servicio SMTP, debería actuar de la siguiente manera: S: C: S: 220 dbc.mtview.ca.us servicio SMTP preparado C: EHLO ymir.claremont.edu Klensin, et al Seguimiento de Estándar [Pág. 9] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 S: 500 Comando no reconocido: EHLO ... La respuesta 500 indica que el servido SMTP no implementa las extensiones aquí especificadas. Normalmente, el cliente debería entonces enviar un comando HELO y continuar como se especifica en el RFC 821. Ver la sección 4.7 para un análisis adicional. 9. Consideraciones de Seguridad Este RFC no discute aspectos relacionados con la seguridad y no se cree que origine temas relativos a la misma que no existan ya de forma endémica en el correo electrónico y en las implementaciones totalmente conformes con el RFC 821. Proporciona información sobre las características de los servidores de correo atendiendo a sus respuestas al comando EHLO. Sin embargo, toda la información proporcionada por el conjunto de extensiones de servicio definidas en este RFC puede ser deducida probando selectivamente los comandos requeridos para enviar y recibir correo. Las consecuencias concernientes a la seguridad de las extensiones de servicio descritas en otros RFC deberían ser debatidas en dichos documentos. 10. Agradecimientos Este documento representa una síntesis de las ideas de muchas personas y reacciones a las ideas y proposiciones de muchas otras. Randall Atkinson, Craig Everhart, Risto Kankkunen, y Greg Vaudreuil contribuyeron lo suficiente con sus ideas y textos para ser considerados coautores. Otras sugerencias importantes, escritos, o ánimos provinieron de Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan Zachariassen, y de las contribuciones de todo el Grupo de Trabajo sobre SMTP perteneciente al IETF. Por supuesto, ninguno de los individuos es necesariamente responsable de la combinación de ideas representadas aquí. En realidad, en algunos casos, la respuesta a alguna crítica en particular fue aceptar la identificación del problema e incluir una solución completamente distinta de la que se había propuesto inicialmente. 11. Referencias [1] Postel, J., "Protocolo Simple de Transferencia de Correo", STD 10, RFC 821, USC/Information Sciences Institute, Agosto 1982. [2] Crocker, D., "Estándar para el formato de los mensajes de texto de la Internet ARPA", STD 11, RFC 822, UDEL, Agosto 1982. Klensin, et al Seguimiento de Estándar [Pág. 10] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 [3] Borestein, N., y N. Freed, "Extensiones Multipropósito del Correo de Internet", RFC 1521, Bellcore, Innosoft, Septiembre 1993. [4] Moore, K., "Representación del Texto No-ASCII en las cabeceras de los Mensajes de Internet", RFC 1522, Universidad de Tennessee, Septiembre 1993. [5] Braden, R., "Requisitos de los Anfitriones de Internet - Aplicación y Apoyo", STD 3, RFC 1123, USC/Instituto de Ciencias de la Información, Octubre 1989. 12. Direcciones del Director, Editor y Autor. John Klensin, Director del Grupo de Trabajo. MCI 2100 Reston Parkway Reston, VA 22091 Teléfono: +1 703 715-7361 Fax: +1 703 715-7436 Correo electrónico: klensin@mci.net Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Teléfono: +1 818 919 3600 Fax: +1 818 919 3614 Correo Electrónico: ned@innosoft.com Marshal T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 USA Teléfono: +1 415 968 1052 Fax: +1 415 968 2510 Correo Electrónico: mrose@dbc.mtview.ca.us Einar A. Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA, 92647-5615 USA Klensin, et al Seguimiento de Estándar [Pág. 11] RFC 1869 Extensiones del Servicio SMTP Noviembre 1995 Teléfono: +1 714 842 3711 Fax: +1 714 848 2091 Correo Electrónico: stef@nma.com Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA USA Teléfono: +1 408 246 8253 Fax: +1 408 249 6205 Correo Electrónico: dcrocker@mordor.stanford.edu Klensin, et al Seguimiento de Estándar [Pág. 12]