Protocolo Simple de Transferencia de Correo

Protocolo simple de transferencia de correo
Grupo de Trabajo de la Red de J. Klensin

Peticin de Comentarios: 5321 de octubre de 2008
Obsoletes: 2821
Actualizaciones: 1123
Categora: Normas pista
Protocolo simple de transferencia de correo

Condicin de este memo
Este documento especifica un protocolo de seguimiento de normas de Internet

para la
comunidad de Internet, y solicita debate y sugerencias para
mejoras. Por favor refirase a la edicin actual del "Internet
Normas Oficiales de Protocolo "(STD 1) para la normalizacin
y la situacin de este protocolo. La distribucin de este memo es ilimitada.
Abstracto
Este documento es una especificacin del protocolo bsico de Internet

transporte de correo electrnico. Se consolida, actualizaciones, y aclara
varios documentos anteriores, por lo que la totalidad o parte de la mayora de
ellos
obsoleto. Cubre los mecanismos de extensin SMTP y las mejores prcticas
para Internet contempornea, pero no proporciona detalles acerca
extensiones en particular. Aunque SMTP fue diseado como un correo
el transporte y el protocolo de entrega, esta especificacin contiene tambin
informacin que es importante para su uso como un "envo de correo"
protocolo para "split-UA" (Agente de Usuario) y los sistemas de lectura de
correo mvil
ambientes.
Klensin Normas Track [Page 1]
RFC 5321 SMTP de octubre de 2008
Tabla de contenido
1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transporte de Correo Electrnico. . . . . . . . . . . . . . . 5
1.2. Historia y contexto de este documento. . . . . . . . . . 5
1.3. Convenciones del documento. . . . . . . . . . . . . . . . . . . 6
2. El Modelo SMTP. . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Estructura basica . . . . . . . . . . . . . . . . . . . . . 7
2.2. El modelo de extensin. . . . . . . . . . . . . . . . . . . 9
2.2.1. Fondo . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definicin y registro de las extensiones. . . . . . 10
2.2.3. Problemas especiales con extensiones. . . . . . . . . . . . 11
2.3. Terminologa SMTP. . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Objetos electrnico. . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Remitentes y receptores. . . . . . . . . . . . . . . . 12
2.3.3. Agentes electrnico y almacenes de mensajes. . . . . . . . . . . .
12
2.3.4. Host. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Nombres de dominio . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Tampn y tabla de estado. . . . . . . . . . . . . . . . 14
2.3.7. Los comandos y respuestas. . . . . . . . . . . . . . . . . 14
2.3.8. Lneas . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. El contenido del mensaje y datos de correo. . . . . . . . . . . .
15
2.3.10. Originales, Entrega, rel y Sistemas de puerta de enlace. . . 15
2.3.11. Buzn y Direccin. . . . . . . . . . . . . . . . . 15
2.4. Principios generales de sintaxis y modelo de transacciones. . . . .
diecisis
3. Los procedimientos SMTP: una visin general. . . . . . . . . . . . . . . 17
3.1. Iniciacin de Sesin. . . . . . . . . . . . . . . . . . . . 18
3.2. Iniciacin de cliente. . . . . . . . . . . . . . . . . . . . 18
3.3. Transacciones electrnico. . . . . . . . . . . . . . . . . . . . 19
3.4. El reenvo de correccin de direccin o la actualizacin. . . . . . 21
3.5. Comandos para la depuracin de direcciones. . . . . . . . . . . . . 22
3.5.1. Visin de conjunto . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Respuesta normal. . . . . . . . . . . . . . . . . 24
3.5.3. Significado del VRFY o EXPN xito de respuesta. . . . . . . 25
3.5.4. Semntica y Aplicaciones de EXPN. . . . . . . . . . 26
3.6. Reinstalacin y el enrutamiento de
correo. . . . . . . . . . . . . . . . 26
3.6.1. Las rutas de origen y de reinstalacin. . . . . . . . . . . . . .
26
3.6.2. Los registros de correo Exchange y reinstalacin. . . . . . . . . .
26
3.6.3. Mensaje Servidores sumisin como rels. . . . . . . . . 27
3.7. Gatewaying electrnico. . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Campos de la cabecera gatewaying. . . . . . . . . . . . . 28
3.7.2. Lneas recibidas en gatewaying. . . . . . . . . . . . . 29
3.7.3. Las direcciones de gatewaying. . . . . . . . . . . . . . . 29
3.7.4. Otros campos de cabecera en gatewaying. . . . . . . . . . 29
3.7.5. Sobres en gatewaying. . . . . . . . . . . . . . . 30
3.8. Terminar las sesiones y conexiones. . . . . . . . . . . 30
3.9. Listas de correo y alias. . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31

3.9.2. Lista. . . . . . . . . . . . . . . . . . . . . . . . . 31
4. Las especificaciones SMTP. . . . . . . . . . . . . . . . . . . 32
4.1. Los comandos SMTP. . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Semntica y la sintaxis de comandos. . . . . . . . . . . . . 32
4.1.2. Comando Argumento de sintaxis. . . . . . . . . . . . . . . 41
4.1.3. Los literales de direcciones. . . . . . . . . . . . . . . . . . .
43
4.1.4. Orden de Comandos. . . . . . . . . . . . . . . . . . 44
4.1.5. Privadas-Use comandos. . . . . . . . . . . . . . . . . 46
4.2. Respuestas SMTP. . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Cdigo de respuesta Niveles de gravedad y la
teora. . . . . . . . . . . 48
4.2.2. Cdigos de respuesta por grupos de funciones. . . . . . . . . . . .
50
4.2.3. Cdigos de respuesta en Orden numrico. . . . . . . . . . . . . 52
4.2.4. Cdigo de respuesta 502. . . . . . . . . . . . . . . . . . . . 53
4.2.5. Cdigos de respuesta luego de que datos y la posterior
<CRLF>. <CRLF>. . . . . . . . . . . . . . . . . . . . 53
4.3. La secuenciacin de los comandos y las
respuestas. . . . . . . . . . . . 54
4.3.1. Descripcin general de secuenciacin. . . . . . . . . . . . . . . .
. 54
4.3.2. Las secuencias de comandos de
respuesta. . . . . . . . . . . . . . . 55
4.4. La informacin de rastreo. . . . . . . . . . . . . . . . . . . . 57
4.5. Cuestiones de implementacin adicionales. . . . . . . . . . . . . 61
4.5.1. Implementacin mnimo. . . . . . . . . . . . . . . . 61
4.5.2. Transparencia. . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Tamaos y tiempos de espera. . . . . . . . . . . . . . . . . . 62
4.5.3.1. Lmites de tamao y mnimos. . . . . . . . . . . . . 62
4.5.3.1.1. Parte-local. . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Dominio. . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Camino . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Lnea de comando . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Responder Lnea. . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Lnea de texto. . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Contenido del mensaje . . . . . . . . . . . . . . . 63
4.5.3.1.8. Los destinatarios de bfer. . . . . . . . . . . . . . 64
4.5.3.1.9. Tratamiento Cuando se superan los lmites. . . . . . . . 64
4.5.3.1.10. Demasiados destinatarios cdigo. . . . . . . . . . . 64
4.5.3.2. Tiempos de espera. . . . . . . . . . . . . . . . . . . . .
sesenta y cinco
4.5.3.2.1. 220 Mensaje inicial: 5 minutos. . . . . . . . sesenta y
cinco
4.5.3.2.2. CORREO Comando: 5 minutos. . . . . . . . . . . sesenta y
cinco
4.5.3.2.3. RCPT comandos: 5 minutos. . . . . . . . . . . sesenta y
cinco
4.5.3.2.4. DATOS Iniciacin: 2 Minutos. . . . . . . . . . 66
4.5.3.2.5. Bloque de datos: 3 Minutos. . . . . . . . . . . . 66
4.5.3.2.6. Terminacin DATOS: 10 Minutos. . . . . . . . . 66
4.5.3.2.7. Tiempo de espera del servidor: 5 minutos. . . . . . . . . .
. 66
4.5.4. Estrategias vuelva a intentar. . . . . . . . . . . . . . . . . . .
66
4.5.5. Los mensajes con un nulo Reverse-Path. . . . . . . . . . 68
5. Resolucin de Direccin y Gestin de correo. . . . . . . . . . . . . 69
5.1. Localizar el host de destino. . . . . . . . . . . . . . . . . 69
5.2. IPv6 y los registros MX. . . . . . . . . . . . . . . . . . . 71
6. Deteccin de problemas y manejo. . . . . . . . . . . . . . . . 71

6.1. Entrega fiable y respuestas por correo electrnico. . . . . . . . . .

71
6.2. No deseados, no solicitadas, y mensajes de "ataque". . . . . . . 72
6.3. Deteccin de bucle. . . . . . . . . . . . . . . . . . . . . . 73
6.4. La compensacin de las irregularidades. . . . . . . . . . . . . 73
7. Consideraciones de Seguridad. . . . . . . . . . . . . . . . . . . 75
7.1. Seguridad de correo y de suplantacin. . . . . . . . . . . . . . . . 75
7.2. Copias "a ciegas". . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, y Seguridad. . . . . . . . . . . . . . . . . 76
7.4. El redireccionamiento de correo Sobre la base de los cdigos de
respuesta 251 y 551. . 77
7.5. La divulgacin de informacin en Anuncios. . . . . . . . . 77
7.6. La divulgacin de informacin en los campos de seguimiento. . . . . . .
. . . 78
7.7. Divulgacin de la Informacin en el reenvo de mensajes. . . . . . . 78
7.8. La resistencia a los ataques. . . . . . . . . . . . . . . . . . 78
7.9. Alcance de funcionamiento de los servidores SMTP. . . . . . . . . . . .
78
8. Consideraciones IANA. . . . . . . . . . . . . . . . . . . . . 79
9. Agradecimientos. . . . . . . . . . . . . . . . . . . . . . . 80
10. Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Referencias normativas . . . . . . . . . . . . . . . . . . . 81
10.2. Referencias informativas. . . . . . . . . . . . . . . . . . 82
Apndice A. Servicio de transporte TCP. . . . . . . . . . . . . . . . 85
Apndice B. Creacin de comandos SMTP de RFC 822 Cabecera
Campos . . . . . . . . . . . . . . . . . . . . . . . 85
Rutas Apndice C. Fuente. . . . . . . . . . . . . . . . . . . . 86
Apndice D. Escenarios. . . . . . . . . . . . . . . . . . . . . . 87
D.1. Un Escenario SMTP transaccin tpica. . . . . . . . . . . 88
D.2. Escenario abortado SMTP Transaccin. . . . . . . . . . . . 89
D.3. Escenario correo retransmitido. . . . . . . . . . . . . . . . . . 90
D.4. Verificacin y envo de Escenario. . . . . . . . . . . . . . 92
Apndice E. Otras cuestiones previas. . . . . . . . . . . . . . . . 92
Apndice F. Desaprobados Caractersticas de la RFC 821. . . . . . . . . . . 93
F.1. GIRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Fuente de enrutamiento. . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO. . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. # -literals. . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Fechas y aos. . . . . . . . . . . . . . . . . . . . . 94
F.6. El envo de correo frente. . . . . . . . . . . . . . . . . . 94
1. Introduccin
1.1. Transporte de Correo Electrnico
El objetivo del Protocolo de transferencia de correo simple (SMTP) es de

transferir correo fiable y eficiente.
SMTP es independiente del subsistema de transmisin particular y

slo requiere un canal de flujo de datos ordenada fiable. Mientras esto
documento trata especficamente de transporte a travs de TCP, otros
transportes
es posible. Apndices con el RFC 821 [1] describen algunos de ellos.
Una caracterstica importante de SMTP es su capacidad para transportar correo

a travs de mltiples redes, normalmente se conoce como "la retransmisin de
correo SMTP"
(Ver seccin 3.6). Una red consiste en el acceso mutuo-TCP-
Mquinas de la Internet pblica, los anfitriones mutuamente-TCP-accesible en
una
firewall aislado TCP / IP Intranet, o anfitriones de alguna otra LAN o WAN
medio ambiente utilizando un protocolo de nivel de transporte no TCP.
Utilizando
SMTP, un proceso puede transferir correo a otro proceso en el mismo
red o a alguna otra red a travs de un proceso de retransmisin o puerta de
enlace
acceder a ambas redes.
De esta manera, un mensaje de correo electrnico puede pasar a travs de un

nmero de compuesto intermedio
rel o puertas de enlace en su camino desde el emisor al receptor final.
Los mecanismos de intercambio de correo del sistema de nombres de dominio (RFC
1035
[2], RFC 974 [12], y en la seccin 5 de este documento) se utilizan para
identificar el destino del siguiente salto apropiado para que un mensaje sea
transportado.
1.2. Historia y contexto de este documento
Este documento es una especificacin del protocolo bsico para el

Internet de transporte de correo electrnico. Se consolida, y actualizaciones
aclara, pero no aade nuevas o cambiar la funcionalidad existente de
el seguimiento:
o el original SMTP (Simple Mail Transfer Protocol) especificacin de

RFC 821 [1],
o Los requisitos del sistema de nombres de dominio y las implicaciones para el

correo
transporte desde el RFC 1035 [2] y RFC 974 [12],
o las aclaraciones y declaraciones de aplicacin en el RFC 1123 [3],

y
o material extrado de los mecanismos de extensin SMTP en el RFC 1869

[13].
Klensin Normas Track [Pgina 5]
o editorial y la clarificacin Los cambios en el RFC 2821 [14] para que ese
especificacin del proyecto de norma.
Se deja obsoleto el RFC 821, RFC 974, RFC 1869, y RFC 2821 y RFC
actualizaciones
1123 (sustituyendo los materiales de transporte de correo de RFC 1123). Sin
embargo,
RFC 821 especifica algunas caractersticas que no estaban en uso significativo
de
Internet a mediados de la dcada de 1990 y (en los apndices) adicional alguna
los modelos de transporte. Esas secciones se omiten aqu en inters de
claridad y brevedad; lectores que necesitan ellos deben referirse al RFC 821.
Tambin incluye material adicional de RFC 1123 que requiere

amplificacin. Este material ha sido identificado en mltiples formas,
sobre todo mediante el seguimiento en llamas en varias listas y grupos de
noticias y
problemas de lecturas o interpretaciones inusuales que han aparecido como
las extensiones SMTP se han desplegado. Cuando esta especificacin
mueve ms all de la consolidacin y la realidad se diferencia de las
anteriores
documentos, se les reemplaza tcnicamente as como textualmente.
Aunque SMTP fue diseado como un transporte de correo y protocolo de entrega,

esta especificacin tambin contiene informacin que es importante para su
utilizar como un protocolo de "correo de presentacin", segn lo recomendado
por la oficina de correos
Protocolo (POP) (RFC 937 [15], RFC 1939 [16]) e IMAP (RFC 3501
[17]). En general, el protocolo de envo de correo especificada por separado
en el RFC 4409 [18] Actualmente se prefiere al uso directo de SMTP; Ms
discusin de ese tema aparece en dicho documento.
Seccin 2.3 proporciona definiciones de trminos especficos de este

documento.
Excepto cuando es necesario la terminologa histrica para mayor claridad,
esta
documento se utiliza la corriente "cliente" y la terminologa "servidor" de
identificar los procesos de envo y recepcin SMTP, respectivamente.
Un documento adicional, RFC 5322 [4], analiza las secciones de encabezado del
mensaje
y los rganos y especifica los formatos y estructuras para ellos.
1.3. Convenciones del documento
Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBER", "NO DEBER",
"DEBE", "NO", "recomendada", "MAYO", y "OPCIONAL" en este
documento se han de interpretar como se describe en el RFC 2119 [5]. Como cada
de estos trminos fue intencional y cuidadosamente seleccionados para mejorar
la
interoperabilidad de correo electrnico, cada uso de estos trminos se va a
tratar
como un requisito de conformidad.
Debido a que este documento tiene una larga historia y para evitar el riesgo
de
varios errores y de confundir a los lectores y documentos que apuntan a
ste, la mayora de los ejemplos y de los nombres de dominio que contienen son
preservado de la RFC 2821. Los lectores estn advertidos de que estos son

ejemplos ilustrativos que no debera realmente ser utilizados en cualquiera de

cdigo
o archivos de configuracin.
2. El Modelo SMTP
2.1. Estructura basica
El diseo SMTP se puede representar como:
+ ---------- + + ---------- +
+ ------ + | | | |
| Usuario | <-> | | SMTP | |
+ ------ + | Client- | Comandos / Respuestas | Servidor- |
+ ------ + | SMTP | <--------------> | SMTP | + ------ +
| Archivo | <-> | | y Correo | | <-> | Archivo |
| Sistema | | | | | | Sistema |
+ ------ + + + + ---------- ---------- + + + ------
servidor SMTP cliente SMTP
Cuando un cliente SMTP tiene un mensaje que transmitir, se establece un

perodo de dos
canal de transmisin manera de un servidor SMTP. La responsabilidad de una
cliente SMTP es transferir mensajes de correo a uno o ms servidores SMTP,
o informar sobre su incapacidad para hacerlo.
El medio por el cual un mensaje de correo electrnico se presenta a un cliente

SMTP, y
cmo ese cliente determina el identificador (s) ( "nombres") de la
dominio (s) a la que se pueden transferir a los mensajes de correo, es un
local de
la materia, y no se aborda en este documento. En algunos casos, la
dominio designado (s), o aquellos determinados por un cliente SMTP, lo har
identificar el destino final (s) del mensaje de correo. En otra
casos, comunes con los clientes SMTP asociados con las implementaciones de
la POP (RFC 937 [15], RFC 1939 [16]) o IMAP (RFC 3501 [17])
protocolos, o cuando el cliente SMTP est dentro de un transporte aislado
entorno de servicio, el dominio determinado identificar una
destino intermedio a travs del cual todos los mensajes de correo estn siendo
retransmitida. clientes SMTP que transfieren todo el trfico con independencia
de la
dominios de destino asociados con los mensajes individuales, o que hacen
no mantener colas para transmisiones de mensajes de volver a intentar que
inicialmente
no se puede completar, de lo contrario pueden adecuarse a esta especificacin,
pero
no se consideran totalmente capaz. Totalmente capaz de SMTP
implementaciones, incluyendo los rels utilizados por estos menos capaces
nios, y sus destinos, se espera que para apoyar la totalidad de la
colas, reintentar, y las funciones de direccin alternativa discutidos en este
especificacin. En muchas situaciones y configuraciones, el menos-
clientes capaces discutidos anteriormente deberan estar utilizando el mensaje
presentacin de protocolo (RFC 4409 [18]) en lugar de SMTP.

Los medios por los cuales un cliente de SMTP, una vez que se ha determinado un
objetivo
dominio, determina la identidad de un servidor SMTP para que la copia del
un mensaje se va a transferir, y despus realiza que la transferencia, se
contemplado en el presente documento. Para efectuar una transferencia de
correo a un SMTP
servidor, un cliente de SMTP establece un canal de transmisin de dos vas
para
dicho servidor SMTP. Un cliente SMTP determina la direccin de una
host adecuado funcionamiento de un servidor SMTP mediante la resolucin de un
destino
nombre de dominio que sea un intermedio de acogida de intercambio de correo o
una final
orientar host.
Un servidor SMTP puede ser el destino final o una

intermedia "relay" (es decir, que puede asumir el papel de un servidor SMTP
cliente despus de recibir el mensaje) o "puerta de entrada" (es decir, puede
transportar el mensaje an ms el uso de algn protocolo que no sea SMTP).
comandos SMTP se generan por el cliente SMTP y se envan al SMTP
servidor. SMTP respuestas se envan desde el servidor SMTP para el SMTP
cliente en respuesta a los comandos.
En otras palabras, la transferencia de mensajes puede ocurrir en una sola

conexin
entre el original SMTP-emisor y la final SMTP-receptor, o lata
ocurrir en una serie de saltos a travs de sistemas de intermediacin. En
cualquiera
caso, una vez que el servidor ha emitido una respuesta xito al final de la
datos de correo, un traspaso formal de la responsabilidad del mensaje se
produce:
el protocolo requiere que un servidor deber aceptar la responsabilidad de
o bien entregar el mensaje o informar adecuadamente el hecho de no hacer
as (vanse las Secciones 6.1, 6.2 y 7.8, a continuacin).
Una vez establecido el canal de transmisin y protocolo de enlace inicial

se ha completado, el cliente SMTP normalmente se inicia una transaccin de
correo.
Este tipo de acciones se compone de una serie de comandos para especificar el
iniciador y destino del correo y la transmisin de la
el contenido del mensaje (incluyendo todas las lneas en la seccin de
cabecera u otro
estructura) en s. Cuando el mismo mensaje se enva a mltiples
destinatarios, este protocolo fomenta la transmisin de una sola
copia de los datos para todos los receptores en el mismo destino (o
rel intermedio) de acogida.
El servidor responde a cada comando con una respuesta; respuestas pueden

indican que el comando fue aceptado, que los comandos adicionales son
esperado, o que existe una condicin de error temporal o permanente.
Comandos de especificar el remitente o los destinatarios pueden incluir
servidor-
permitida solicitudes de extensin de servicio SMTP, como se discute en
Seccin 2.2. El dilogo es a propsito de paso a paso, de una en una sola vez,
aunque esto puede ser modificado por acuerdo mutuo de extensin
peticiones como lnea de comando (RFC 2920 [19]).
Una vez que un mensaje de correo dada ha sido transmitida, el cliente, o son
susceptibles
solicitar que se cierre la conexin o puede iniciar otro tipo de correo

actas. Adems, un cliente de SMTP puede usar una conexin a una

servidor SMTP para los servicios auxiliares tales como la verificacin de
correo electrnico
direcciones o recuperacin de direcciones de los suscriptores lista de correo.
Como se sugiri anteriormente, este protocolo proporciona mecanismos para la

transmisin de correo. Histricamente, esta transmisin normalmente
producido directamente desde el host del usuario que enva a la recepcin
host del usuario cuando los dos hosts estn conectados a la misma transporte
Servicio. Cuando no estn conectados al mismo servicio de transporte,
la transmisin se produce a travs de uno o ms servidores de retransmisin
SMTP. Una muy
caso comn en la actualidad de Internet implica la presentacin del original
mensaje a un servidor intermedio, "envo de mensajes", la cual es
similar a un rel pero tiene algunas propiedades adicionales; dichos
servidores
se discuten en la Seccin 2.3.10 y con cierto detalle en el RFC 4409 [18].
Un husped intermediario que acta ya sea como una retransmisin SMTP o como
una
puerta de entrada a algn otro medio de transmisin, generalmente se
selecciona
a travs del uso del servicio de nombres de dominio (DNS) de intercambio de
correo
mecanismo.
Por lo general, los huspedes intermediarios son determinados a travs del

registro DNS MX, no
por explcita de enrutamiento "fuente" (vase la Seccin 5 y el Apndice C y
F.2 Apndice).
2.2. El modelo de extensin
2.2.1. Fondo
En un esfuerzo que comenz en el ao 1990, aproximadamente una dcada despus

de RFC
821 se complet, el protocolo se modific con un "servicio
modelo de extensiones "que permite que el cliente y el servidor para aceptar
utilizar la funcionalidad compartida ms all de los requisitos SMTP
originales.
El mecanismo de extensin SMTP define un medio por el que un SMTP extendido
cliente y el servidor pueden reconocerse entre s, y el servidor pueden
informar
el cliente en cuanto a las extensiones de servicio que soporta.
SMTP implementaciones contempornea debe apoyar la extensin bsica
mecanismos. Por ejemplo, los servidores deben apoyar el comando EHLO incluso
si no implementan ninguna extensin y clientes especfico debe
preferentemente utilizar EHLO en lugar de HELO. (Sin embargo, para
compatibilidad con ms edad, las implementaciones conformes clientes SMTP y
servidores DEBE apoyar los mecanismos HELO originales como punto de retorno.)
A menos que las diferentes caractersticas de HELO deben ser identificados
para
fines de interoperabilidad, este documento trata solamente EHLO.
SMTP es ampliamente desplegado y las implementaciones de alta calidad han

demostrado
a ser muy robusto. Sin embargo, la comunidad de Internet considera ahora
algunos servicios que son importantes que no fueron detectados cuando el
protocolo fue diseado por primera vez. Si el apoyo a esos servicios es estar

aadido, debe hacerse de una manera que permite que las implementaciones de
edad a la
seguir trabajando de manera aceptable. El marco de extensin consiste en:
o El comando SMTP EHLO, dejando sin efecto la anterior HELO,
Registro OA de las extensiones del servicio SMTP,
o Los parmetros adicionales al correo SMTP RCPT y comandos, y
o reemplazos opcionales para los comandos definidos en este protocolo, tales

que para los datos en las transmisiones que no son ASCII (RFC 3030 [20]).
La fuerza de SMTP proviene principalmente de su simplicidad. Experiencia con

muchos protocolos han demostrado que los protocolos con pocas opciones tienden
hacia
ubicuidad, mientras que los protocolos con muchas opciones tienden hacia la
oscuridad.
Todos y cada extensin, independientemente de sus beneficios, deben estar

examinaron minuciosamente con respecto a su implementacin,
y los costes de interoperabilidad. En muchos casos, el coste de la ampliacin
de la
servicio SMTP probable que superan a los beneficios.
2.2.2. Definicin y registro de las extensiones
La IANA mantiene un registro de las extensiones del servicio SMTP. UN

correspondiente valor de palabra clave EHLO se asocia con cada extensin.
Cada extensin de servicio registrada en la IANA debe definirse en una
formal de normas de va o protocolo experimental aprobado por IESG
documento. La definicin debe incluir:
o el nombre textual de la extensin del servicio SMTP;
o la palabra clave EHLO valor asociada a la extensin;
o los valores de sintaxis y posibles de parmetros asociados con el

palabra clave EHLO valor;
o cualquier SMTP verbos asociados con la extensin
(Verbos adicionales sern normalmente, pero no se requiere que sea, el
mismo que el valor de palabra clave EHLO);
o Los nuevos parmetros de los asociados de extensin con el correo o RCPT

verbos;
Descripcin OA de cmo el apoyo a la extensin afecta a la

comportamiento de un servidor SMTP y el cliente; y

o el incremento que la extensin est aumentando al mximo

longitud de la CORREO comandos y / o RCPT, sobre la especificada en el
esta Norma.
Adems, cualquier valor de palabra clave EHLO de partida con un superior o

inferior
caso "X" se refiere a una extensin de servicio SMTP local de uso exclusivo
a travs de un acuerdo bilateral. Palabras clave que comienzan con "X" no debe
utilizado en una extensin de servicio registrada. A la inversa, los valores
de palabras clave
presentado en la respuesta EHLO que no comienzan con DEBE "X"
corresponde a un estndar, normas de va, o IESG aprobados
Experimental extensin del servicio SMTP registrada en la IANA. UN
conforme servidor no debe ofrecer "X" no -prefixed valores de palabras clave
que
no se describen en una extensin registrada.
verbos y nombres de parmetros adicionales estn sujetos a las mismas reglas

que
palabras clave EHLO; En concreto, los verbos que comienzan con "X" en la hora
local
extensiones que no pueden estar registradas o estandarizado. A la inversa,
No verbos que comienzan con "X" siempre deben estar registrados.
2.2.3. Problemas especiales con extensiones
Las extensiones que puedan modificar las propiedades bastante bsicas de

funcionamiento son SMTP
permitido. El texto en otras secciones de este documento debe ser
entenderse en este contexto. En particular, las extensiones pueden cambiar el
lmites mnimos especificados en la Seccin 4.5.3, pueden cambiar el ASCII
requisito de juego de caracteres como se ha mencionado anteriormente, o puede
introducir un poco
modos opcionales de tratamiento de mensajes.
En particular, si una extensin implica que la trayectoria de suministro

normalmente soporta caractersticas especiales de esa extensin, y una
sistema de SMTP intermedio encuentra un siguiente salto que no admite la
la extensin requerida, puede optar, en base a la extensin especfica
y las circunstancias, que el mensaje de reposicin y tratan ms adelante y / o
tratar una
alternativo de tipo MX. Si se emplea esta estrategia, el tiempo de espera para
caer
de nuevo a un formato no extendido (si est disponible) debe ser menor
que el tiempo de espera normal para rebotar por imposibilidad de entrega (por
ejemplo, si
tiempo de espera normal es de tres das, el tiempo de espera de reposicin
antes de intentar
para transmitir el correo sin la extensin podra ser un da).
2.3. SMTP Terminologa
2.3.1. Objetos de correo
SMTP transporta un objeto electrnico. Un objeto de correo contiene un sobre

y el contenido.
En el sobre SMTP se enva como una serie de unidades de protocolo SMTP

(Descrito en la Seccin 3). Consiste en una direccin del originador (a

los informes de errores, que deben ser dirigidas), uno o ms destinatarios

las direcciones y los materiales de extensin de protocolo facultativo.
Histricamente,
variaciones sobre el camino inverso-especificacin de direccin (originador)
comando (MAIL) podra utilizarse para especificar modos de entrega
alternativas,
tales como visualizacin inmediata; esas variaciones ahora estn en desuso
(Vase el Apndice F y el Anexo F.6).
El contenido SMTP se enva en la unidad de protocolo SMTP DATA y tiene dos

partes: la seccin de encabezado y el cuerpo. Si el contenido se ajusta a
otros estndares contemporneos, la seccin de cabecera consiste en una
coleccin de campos de cabecera, cada uno compuesto de un nombre de
encabezado, una
colon, y los datos, estructurados como en la especificacin de formato de
mensaje
(RFC 5322 [4]); el cuerpo, si se estructura, se define de acuerdo con MIME
(RFC 2045 [21]). El contenido es textual en la naturaleza, expresada usando
el repertorio US-ASCII [6]. Aunque las extensiones SMTP (como
"8BITMIME", RFC 1652 [22]) puede relajar esta restriccin por el contenido
cuerpo, los campos de cabecera de contenido estn siempre codificados
utilizando los EE.UU.-ASCII
repertorio. Dos extensiones MIME (RFC 2047 [23] y RFC 2231 [24])
definir un algoritmo para la representacin de valores de cabecera fuera de la
US-
ASCII repertorio, al tiempo que las codifican utilizando los EE.UU.-ASCII
repertorio.
2.3.2. Emisores y receptores
En el RFC 821, los dos anfitriones que participan en una transaccin SMTP eran
descrito como el "SMTP-emisor" y "receptor-SMTP". Este documento
se ha cambiado para reflejar la terminologa actual de la industria y por lo
tanto
se refiere a ellos como el "cliente SMTP" (o, a veces simplemente "el
cliente")
y "servidor SMTP" (o simplemente "servidor"), respectivamente. Desde un
host determinado puede actuar tanto como servidor y el cliente en una
situacin de rel,
"Receptor" y la terminologa "emisor" todava se utiliza cuando sea necesario
para
claridad.
2.3.3. Agentes electrnico y almacenes de mensajes
terminologa adicional del sistema electrnico se convirti en comn despus

de RFC 821 era
publicado y, donde sea conveniente, se utiliza en esta especificacin. En
en particular, los servidores SMTP y clientes proporcionar un servicio de
transporte de correo
y por lo tanto actuar como "Agentes de Transferencia de Correo (MTA)".
"Usuario de Correo
Agentes "(MUA o UAS) son normalmente considerados como las fuentes y
blanco de correo electrnico. En el origen, un MUA se acumulan durante el mail
que se va
transmitida desde un usuario y fuera de la mano a un MTA; el final
( "Entrega") MTA puede pensar en como repartir el correo fuera a una
MUA (o al menos la transferencia de responsabilidad a la misma, por ejemplo,
por
depositar el mensaje en un "almacn de mensajes"). Sin embargo, aunque estos
trminos se utilizan con por lo menos la apariencia de una gran precisin en
otros entornos, los lmites implcitos entre MUA y MTA
a menudo no coinciden con exactitud comn, y que se ajuste, con prcticas

correo de Internet. Por lo tanto, el lector debe tener cuidado de no inferir

las relaciones y responsabilidades fuertes que podran estar implicadas
si se utilizaran en otro lugar estos trminos.
2.3.4. Anfitrin
Para los fines de esta memoria, un host es un sistema informtico

unido a la Internet (o, en algunos casos, a una red TCP / IP privados
de red) y que soporta el protocolo SMTP. Los anfitriones son conocidos por los
nombres
(Ver la siguiente seccin); No deben ser identificados por numrica
direcciones, es decir, por los literales de direcciones como se describe en la
Seccin 4.1.2.
2.3.5. Nombres de dominio
Un nombre de dominio (o con frecuencia slo un "dominio") consiste en uno o

ms
componentes, separados por puntos, si aparece ms de uno. En el caso
de un dominio de nivel superior utilizado por s mismo en una direccin de
correo electrnico, una sola
cadena se utiliza sin puntos. Esto hace que el requisito,
se describe con ms detalle a continuacin, que slo dominio totalmente
calificado
nombres aparecen en las transacciones SMTP en la Internet pblica,
particularmente importante cuando se trata de dominios de nivel superior.
Estas
Componentes ( "etiquetas" en la terminologa de DNS, RFC 1035 [2]) estn
restringidas
para los propsitos de SMTP consisten en una secuencia de letras, dgitos, y
guiones extradas del conjunto de caracteres ASCII [6]. Los nombres de dominio
son
utilizado como nombres de hosts y de otras entidades en el nombre de dominio
jerarqua. Por ejemplo, un dominio puede referirse a un alias (etiqueta de una
RR CNAME) o la etiqueta de los registros de intercambio de correo que se
utilizarn para
entregar el correo en vez de representar un nombre de host. Ver RFC 1035 [2]
y la Seccin 5 de esta memoria.
El nombre de dominio, tal como se describe en este documento y en el RFC 1035

[2],
es el nombre completo, totalmente calificado (a menudo referido como un
"nombre completo").
Un nombre de dominio que no est en forma FQDN no es ms que un alias local.
alias locales no deben aparecer en cualquier transaccin SMTP.
Slo se permiten, nombres de dominio completos (FQDN) resolubles

cuando los nombres de dominio se utilizan en SMTP. En otras palabras, nombres
que pueden
ser resuelto RR RR MX o la direccin (es decir, A o AAAA) (como se discuti
en la Seccin 5) estn permitidos, como lo son los RR CNAME cuyos objetivos se
pueden
resuelto, a su vez, a los RR MX o direccin. apodos o locales
los nombres no cualificados no debern ser utilizados. Hay dos excepciones a
la
norma que obliga a los FQDN:
o El nombre de dominio dado en el comando EHLO debe ser una primaria

nombre de host (un nombre de dominio que se resuelve en una direccin de
RR) o, si
el anfitrin no tiene un nombre, una direccin literal, como se describe en
Seccin 4.1.3 y se analiza en la discusin de EHLO
Seccin 4.1.4.

o El nombre de buzn reservado "postmaster" puede ser utilizado en un RCPT

comando sin la calificacin de dominio (vase la Seccin 4.1.1.3) y
Debe ser aceptada si se utiliza de modo.
2.3.6. Tampn y Tabla de Estado
Las sesiones SMTP son con estado, con ambas partes mantener cuidadosamente una
visin comn de la situacin actual. En este documento, se modela
estado por un "tapn" virtual y una "tabla de estado" en el servidor que
puede ser utilizado por el cliente para, por ejemplo, "borrar el bfer" o
"Restablecer la tabla de estado", haciendo que la informacin en la memoria
intermedia para ser
desech y el estado para ser devuelto a un estado anterior.
2.3.7. Comandos y Respuestas
comandos SMTP y, a no ser alterada por una extensin de servicio, mensajes

de datos, se transmiten desde el emisor al receptor a travs de la
canal de transmisin en "lneas".
Una respuesta SMTP es un acuse de recibo (positivo o negativo) enviado en

"lneas" del receptor al emisor a travs del canal de transmisin en
respuesta a un comando. La forma general de una respuesta es un valor numrico
cdigo de finalizacin (que indica el xito o el fracaso) generalmente seguido
por una
cadena de texto. Los cdigos son para uso de los programas y el texto es
generalmente destinado a los usuarios humanos. RFC 3463 [25], especifica
adems
estructuracin de las cadenas de respuesta del, incluyendo el uso de
suplementos
y cdigos de terminacin ms especficas (vase tambin el RFC 5248 [26]).
2.3.8. Lneas
Lneas constan de cero o ms caracteres de datos terminados por la

secuencia de caracteres ASCII "CR" (valor hexadecimal 0D) seguido
inmediatamente por
de caracteres ASCII "LF" (valor hexadecimal 0A). Esta secuencia de terminacin
es
denotado como <CRLF> en este documento. Conforme implementaciones DEBE
NO reconocer o generar cualquier otra secuencia de caracteres o carcter
como un terminador de lnea. Los lmites pueden ser impuestas a longitudes de
lnea por
servidores (vase la Seccin 4).
Adems, la aparicin de "desnudo" "CR" o "LF" en caracteres de texto

(Es decir, ya sea sin la otra) tiene una larga historia de causar
problemas en las implementaciones de correo electrnico y las aplicaciones que
utilizan el correo
sistema como una herramienta. implementaciones de cliente SMTP no debe
transmitir
estos caracteres excepto cuando estn destinados como terminadores de lnea
y luego debe, como se ha indicado anteriormente, transmitirlas slo como un
<CRLF>
secuencia.

2.3.9. El contenido del mensaje y datos de correo
Los trminos "contenido del mensaje" y "datos de correo" se utilizan

indistintamente
en este documento para describir el material transmitido despus de los datos
comando es aceptado y antes del final de la indicacin de datos es
transmitida. El contenido del mensaje incluye la seccin de encabezado del
mensaje y
el cuerpo del mensaje, posiblemente estructurada. La especificacin MIME (RFC
2045 [21]) proporciona los mecanismos estndar de mensaje estructurado
cuerpos.
2.3.10. Originales, Entrega, rel y Sistemas de puerta de enlace
Esta especificacin se hace una distincin entre cuatro tipos de SMTP

sistemas, basado en el papel esos sistemas desempean en la transmisin de
correo electrnico. Un sistema "originario" (tambin conocido como SMTP
originador) introduce correo en Internet o, ms generalmente,
en un entorno de servicio de transporte. Un sistema de SMTP "entrega" es
uno que recibe el correo de un entorno de servicio de transporte y
la pasa a un agente de usuario de correo o lo deposita en un almacn de
mensajes
Se espera que un agente de usuario de correo para posteriormente acceso. Un
"rel" SMTP
sistema (normalmente se conoce simplemente como "relay") recibe un correo de
una
cliente SMTP y lo transmite, sin modificacin al mensaje
datos que no sean la adicin de informacin de rastreo, a otro servidor SMTP
para
reinstalacin o ms para la entrega.
Un sistema de SMTP "puerta de entrada" (por lo general se refiere simplemente

como "puerta de entrada")
recibe el correo de un sistema cliente en un entorno de transporte y
la transmite a un sistema de servidor en otro ambiente de transporte.
Las diferencias en los protocolos o la semntica de mensajes entre el
transporte
ambientes a ambos lados de una puerta de enlace pueden requerir que la puerta
de enlace
sistema de realizar transformaciones para el mensaje de que no estn
permitidos
a sistemas de retransmisin SMTP. Para los fines de esta memoria,
servidores de seguridad que reescriben direcciones deben ser considerados como
vas de acceso,
incluso si SMTP se utiliza a ambos lados de ellos (ver RFC 2979 [27]).
2.3.11. Buzn y Direccin
Tal como se utiliza en esta memoria, una "direccin" es una cadena de

caracteres
que identifica a un usuario al que se enviar el correo o en una ubicacin
que el correo ser depositado. El trmino "buzn" se refiere a aquella
depositario. Los dos trminos se utilizan indistintamente tpicamente menos
la distincin entre la ubicacin en la que se coloca mail (la
buzn) y una referencia a l (la direccin) es importante. Un
Direccin consiste normalmente en las especificaciones del usuario y de
dominio. los
convencin buzn de nomenclatura estndar se define para ser
"@ Dominio local-parte"; el uso contemporneo permite un conjunto mucho ms
amplio de
aplicaciones que "los nombres de usuario" simples. En consecuencia, y debido a
una
larga historia de problemas cuando los huspedes intermediarios han intentado

optimizar el transporte mediante la modificacin de ellos, la parte local DEBE

estar
interpretado y asignada la semntica slo por el host especificado en el
parte del dominio de la direccin.
2.4. Principios generales de sintaxis y modelo de transacciones
comandos SMTP y las respuestas tienen una sintaxis rgida. Todos los comandos
comienzan
con un verbo de comando. Todas las respuestas comienzan con un valor numrico
de tres dgitos
cdigo. En algunos comandos y respuestas, se requieren argumentos siguiente
el verbo o la respuesta de cdigo. Algunos comandos no aceptan argumentos
(despus de
el verbo), y algunos cdigos de respuesta son seguidas, a veces,
opcionalmente,
por la forma de texto libre. En ambos casos, en los que aparece el texto, es
separado del verbo o cdigo de respuesta por un carcter de espacio. Completar
las definiciones de los comandos y respuestas aparecen en la Seccin 4.
Verbos y los valores de los argumentos (por ejemplo, "A:" o "a:" en el comando
RCPT
y las palabras clave de nombres de extensin) no son sensibles, con el nico
excepcin en esta especificacin de un buzn local-parte (SMTP
Las extensiones pueden especificar explcitamente los elementos de maysculas
y minsculas). Es decir,
un verbo de comando, un valor de argumento que no sea un buzn local-parte,
y el texto de forma libre puede ser codificado en maysculas, minsculas, o
cualquier
mezcla de letras maysculas y minsculas, sin impacto en su significado. los
Local-parte de un buzn de correo debe ser tratada como maysculas y
minsculas.
Por lo tanto, las implementaciones de SMTP debe tener cuidado para preservar
el caso
de buzn local-partes. En particular, para algunos hosts, el usuario
"Smith" es diferente del usuario "Smith". Sin embargo, la explotacin de la
maysculas y minsculas de los buzones de correo locales de partes impide la
interoperabilidad y
no se recomienda. dominios de buzones siguen las reglas normales de DNS y son
por lo tanto, no es sensible a maysculas.
Unos servidores SMTP, en violacin de esta especificacin (y RFC 821)

requieren que los verbos de comando ser codificados por los clientes en
maysculas.
Implementaciones MAYO considerar la contratacin de esta codificacin para dar
cabida a aquellos
servidores.
La clusula argumento consiste en una cadena de caracteres de longitud

variable
terminando con el final de la lnea, es decir, con la secuencia de caracteres
<CRLF>. El receptor no tomar ninguna accin hasta que esta secuencia es
recibido.
La sintaxis para cada comando se muestra con la discusin de ese

mando. elementos y parmetros comunes se muestran en la Seccin 4.1.2.
Los comandos y las respuestas se componen de caracteres del ASCII

conjunto de caracteres [6]. Cuando el servicio de transporte proporciona un
byte de 8 bits
(Octeto) canal de transmisin, cada caracteres de 7 bits se transmite,
justificado a la derecha, en un octeto con el bit de orden limpiado a cero.
Ms especficamente, el servicio SMTP no extendido ofrece 7 bits

el transporte solamente. Un cliente SMTP originario que no tiene xito

negociado una extensin apropiada con un servidor determinado (vase la
el prrafo siguiente) NO DEBE transmitir mensajes con informacin de la
bit de orden de octetos. Si dichos mensajes se transmiten en
violacin de esta regla, la recepcin de los servidores SMTP pueda solucionar
el alto
bit de orden o rechazar el mensaje como no vlido. En general, un rel SMTP
Debe asumir que el contenido del mensaje que ha recibido es vlido y,
suponiendo que los permisos de envolvente hacerlo, sin retransmitirla
observa su contenido. Por supuesto, si el contenido est mal etiquetado y
la ruta de datos no puede aceptar el contenido real, esto puede dar lugar a
la entrega final de un mensaje severamente distorsionado para el receptor.
sistemas de entrega SMTP puede rechazar estos mensajes, o las devolver lo
no se puede entregar, en lugar de entregarlos. En ausencia de un server-
extensin ofrecidos permitiendo explcitamente, un sistema de envo SMTP es
no permitido para enviar comandos del sobre en cualquier otro juego de
caracteres
de US-ASCII. sistemas de recepcin debe rechazar estos comandos,
Normalmente el uso de "error de sintaxis 500 - carcter no vlido", responde.
la transmisin de contenido de mensaje de 8 bits puede ser solicitada por el

servidor de
un cliente que utiliza instalaciones SMTP extendidos, en particular el
"8BITMIME"
extensin, RFC 1652 [22]. 8BITMIME debe ser apoyado por SMTP
servidores. Sin embargo, no debe interpretarse como autorizacin para
transmitir material sin restricciones de 8 bits, ni tampoco 8BITMIME Autorizar
transmisin de cualquier material de la envoltura en que no sea ASCII.
8BITMIME
NO debe ser solicitada por los remitentes para el material con el bit alto de
que no est en formato MIME con un contenido de transferencia apropiada
codificacin; Los servidores pueden rechazar estos mensajes.
La notacin metalingstica utiliza en este documento corresponde a la

"BNF aumentada" que se utiliza en otros documentos del sistema de correo de
Internet. los
lector que no est familiarizado con la sintaxis que debe consultar el ABNF
especificacin en RFC 5234 [7]. metalenguaje trminos utilizados en la gestin
texto estn rodeados por parntesis angulares (por ejemplo, <CRLF>) para mayor
claridad.
Se advierte al lector que la gramtica se expresa en el
metalenguaje no es exhaustiva. Hay muchos casos en los que
disposiciones en el texto restringen o modifican la sintaxis o de otro modo
la semntica implcita por la gramtica.
3. Los procedimientos SMTP: Una visin general
Esta seccin contiene una descripcin de los procedimientos utilizados en

SMTP:
de inicio de sesin, transaccin de correo, reenvo de correo, verificando
buzn nombres y la expansin de listas de correo, y apertura y cierre
intercambios. Los comentarios sobre la retransmisin, una nota sobre los
dominios de correo, y una
discusin de los roles cambiantes se incluye al final de esta seccin.
Varios escenarios completos se presentan en el Apndice D.

3.1. Iniciacin de sesin

Una sesin SMTP se inicia cuando un cliente abre una conexin a una
servidor y el servidor responde con un mensaje de apertura.
implementaciones del servidor SMTP puede incluir la identificacin de su

versin de software y la informacin en la respuesta de felicitacin de
conexin
despus de que el cdigo 220, una prctica que permite el aislamiento ms
eficiente
y la reparacin de cualquier problema. Implementaciones podr prever una
Los servidores SMTP para desactivar el anuncio de software y la versin donde
que causa problemas de seguridad. Mientras que algunos sistemas tambin
identifican su
punto de contacto para problemas de correo, esto no es un sustituto de
el mantenimiento de la direccin de "administrador de correo" requerido (vase
la Seccin 4).
El protocolo SMTP permite a un servidor para rechazar formalmente una sesin

de correo
al tiempo que permite la conexin inicial de la siguiente manera: a 554
La respuesta puede ser dada en el mensaje inicial abertura de conexin
en lugar del 220. Un servidor de adoptar este enfoque an debe esperar
para que el cliente enve un QUIT (vase la Seccin 4.1.1.10) antes del cierre
la conexin y debe responder a los comandos que intervienen con
"503 mala secuencia de comandos". Desde un intento de hacer un servidor SMTP
la conexin a un sistema de este tipo es, probablemente, por error, un
servidor de volver
una respuesta 554 de abertura de conexin debe proporcionar suficiente
la informacin en el texto de respuesta para facilitar la depuracin del envo
sistema.
3.2. Iniciacin cliente
Una vez que el servidor ha enviado el mensaje de saludo (bienvenida) y la

cliente ha recibido, el cliente normalmente enva el comando EHLO para
el servidor, lo que indica la identidad del cliente. Adems de la apertura
la sesin, el uso de EHLO indica que el cliente es capaz de procesar
extensiones de servicio y solicitudes que el servidor proporcionan una lista
de las
extensiones que soporta. SMTP sistemas ms antiguos que son incapaces de
extensiones de servicios de apoyo, y los clientes actuales que no lo hacen
requieren extensiones de servicio en la sesin de correo estn iniciando, MAYO
utilizar HELO en lugar de EHLO. Los servidores NO DEBEN devolver el EHLO-
extendida
respuesta al estilo de un comando HELO. Para una conexin particular
intentar, si el servidor devuelve un "comando no reconocido" respuesta a
EHLO, el cliente debe ser capaz de caer de nuevo y enviar HELO.
En el comando EHLO, el envo del comando de host identifica a s mismo;

el comando puede ser interpretado como diciendo "Hola, soy <dominio>" (y,
en el caso de EHLO, "y yo apoyo las solicitudes de extensin de servicio").

3.3. Las transacciones de correo
Hay tres pasos para las transacciones de correo SMTP. La transaccin

comienza con un comando electrnico que proporciona la identificacin del
remitente. (En
general, el comando MAIL se puede enviar slo cuando no hay transaccin de
correo
Est en proceso; vase la Seccin 4.1.4.) Una serie de uno o ms RCPT
comandos sigue, dando la informacin del receptor. Entonces, un Data
comando inicia la transferencia de los datos de correo y se termina mediante
la
"Fin de correo" indicador de datos, lo que tambin confirma la transaccin.
La primera etapa en el procedimiento es el comando MAIL.
MAIL FROM: <reverse-path> [SP <parmetros-mail>] <CRLF>
Esta orden le dice al SMTP-receptor que una transaccin es nuevo correo

puesta en marcha y para restablecer todas sus tablas y tampones del estado,
incluyendo cualquier
destinatarios o datos de correo. El <reverse-path> parte de la primera o
nico argumento contiene el buzn de origen (entre "<" y ">"
entre corchetes), que se pueden utilizar para informar de errores (ver seccin
4.2 para una
discusin de los informes de errores). Si se acepta, el servidor SMTP
rendimientos
una respuesta "250 OK". Si la especificacin de buzn no es aceptable para
alguna razn, el servidor debe devolver una respuesta que indica si el
el fracaso es permanente (es decir, ocurrir de nuevo si el cliente intenta
enviar la misma direccin otra vez) o temporal (es decir, la direccin podra
ser
aceptado si el cliente intenta de nuevo ms tarde). A pesar de la aparente
mbito de aplicacin de este requisito, hay circunstancias en las que el
aceptabilidad de la ruta inversa no puede determinarse hasta que uno o
ms visin de caminos (en los comandos RCPT) pueden ser examinados. En esos
casos, el servidor puede aceptar razonablemente el camino inverso (con un 250
respuesta) y luego reportar problemas despus de que se reciban los forward-
trayectorias
y examinado. Normalmente, los fallos producen 550 o 553 respuestas.
Histricamente, el <reverse-path> se le permiti contener ms de

slo un buzn de correo; Sin embargo, los sistemas contemporneos no debe usar
la fuente
enrutamiento (ver Apndice C).
La <parmetros-mail> se asocian con negociada SMTP

extensiones de servicio (vase la seccin 2.2).
El segundo paso en el procedimiento es el comando RCPT. Este paso de

el procedimiento se puede repetir cualquier nmero de veces.
RCPT TO: <forward-path> [SP-RCPT <parmetros>] <CRLF>
El primer o nico argumento de este comando incluye un camino a seguir

(Normalmente un buzn de correo y de dominio, siempre rodeado de "<" y ">"
parntesis) la identificacin de un destinatario. Si se acepta, el servidor
SMTP
devuelve una respuesta "250 OK" y almacena el de la trayectoria directa. Si el

destinatario se sabe que no es una direccin de entrega, el servidor SMTP

devuelve una respuesta 550, tpicamente con una cadena como "Este usuario no
existe -
"Y el nombre del buzn (otras circunstancias y cdigos de respuesta son
posible).
El <forward-path> puede contener ms que un buzn de correo.

Histricamente, el <forward-path> se le permiti contener una fuente
Lista de los ejrcitos y el buzn de destino de enrutamiento; sin embargo,
clientes SMTP contempornea no deben utilizar las rutas de origen (vase
Apndice C). Los servidores deben estar preparados para encontrar una lista de
fuente
rutas en el de la trayectoria directa, sino que debe pasar por alto las rutas
o mayo
disminucin de apoyo a la retransmisin que implican. Del mismo modo, los
servidores MAYO
negarse a aceptar el correo destinado para otros huspedes o sistemas.
Estas restricciones hacen un servidor intil como un rel para que los
clientes
no son compatibles con la funcionalidad SMTP completa. En consecuencia,
restricted-
clientes capacidad no debe asumir que cualquier servidor SMTP en el
Internet puede ser utilizado como su sitio de procesamiento de correo
(retransmisin). Si una
comando RCPT aparece sin una orden previa de correo, el servidor DEBE
devolver una "secuencia de comandos errnea" 503 respuesta. el opcional
<RCPT parmetros> estn asociados con el servicio SMTP negociado
extensiones (vase la seccin 2.2).
Ya que ha sido una fuente comn de errores, vale la pena sealar que
espacios no estn permitidos en cada lado de los dos puntos que se derivan de
en el comando electrnico o en el comando RCPT. La sintaxis es exactamente
como se da arriba.
El tercer paso en el procedimiento es el comando de datos (o algn

alternativo establecido en una extensin de servicio).
DATOS <CRLF>
Si se acepta, el servidor SMTP devuelve una respuesta intermedia 354 y

considera todas las lneas subsiguientes hasta, pero no incluyendo el fin de
Indicador de datos de correo a ser el texto del mensaje. Cuando el extremo de
texto es
recibido y almacenado correctamente, el SMTP-receptor enva un "250 OK"
respuesta.
Dado que los datos de correo se enva en el canal de transmisin, al final de

datos de correo deben indicarse de forma que el cuadro de dilogo de comando y
respuesta puede
reanudarse. SMTP indica el final de los datos de correo mediante el envo de
una
lnea que contiene slo un "." (Punto o punto final). Una transparencia
procedimiento se utiliza para evitar que esto interfiera con el usuario de
texto (vase la Seccin 4.5.2).
El indicador de fin de datos de correo tambin confirma la transaccin de

correo y
Indica al servidor SMTP para procesar ahora los destinatarios almacenados y
correo
datos. Si se acepta, el servidor SMTP devuelve una respuesta "250 OK". los
comando de datos puede fallar en slo dos puntos en el intercambio de
protocolo:
Si no haba MAIL, RCPT o ninguna, el comando o comandos eran todas esas

rechazada, el servidor puede devolver un "comando fuera de secuencia" (503) o
"no hay destinatarios vlidos" (554) Respuesta en respuesta al comando DATA.
Si una de estas respuestas (o cualquier otra respuesta 5yz) es recibida, el
cliente no debera enviar el mensaje de datos; ms en general, los datos de
mensaje
NO DEBE ser enviado a menos que se reciba una respuesta 354.
Si el verbo es un principio aceptado y la respuesta emitida 354, los datos

comando debe fallar slo si la transaccin de correo era incompleta (por
ejemplo, no hay receptores), si los recursos no estaban disponibles
(incluyendo,
Por supuesto, el servidor no est disponible de forma inesperada), o si el
servidor determina que el mensaje debe ser rechazada por la poltica o
otras razones.
Sin embargo, en la prctica, algunos servidores no realizan destinatario

la verificacin hasta despus de que se reciba el mensaje de texto. estos
servidores
Debe tratar a un fallo de uno o ms destinatarios como "subsecuente
fracaso "y devolver un mensaje de correo electrnico como se discute en la
Seccin 6 y, en
en particular, en la Seccin 6.1. El uso de un "buzn 550 no encontrado" (o
equivalente) cdigo de respuesta despus se aceptan los datos dificulta
o imposible para el cliente para determinar qu destinatarios fallaron.
Cuando el formato de RFC 822 ([28], [4]) se est utilizando, los datos de
correo
incluir los campos de cabecera, tales como los nombrados Fecha, Asunto, Para,
Cc,
y de. sistemas de SMTP servidor no debe rechazar los mensajes basados en
defectos percibidos en el RFC 822 o MIME (RFC 2045 [21]) mensaje
seccin de encabezado o cuerpo del mensaje. En particular, no deben rechazar
mensajes en los que el nmero de campos de cabecera de Resent no coinciden o
Resienten-a-aparece sin Reenviar desde y / o Reenviar actualizada.
comandos de transaccin por correo deben ser utilizados en el orden mencionado

anteriormente.
3.4. El reenvo de correccin de direccin o la actualizacin
Reenvo de apoyo ms a menudo se requiere para consolidar y simplificar

direcciones dentro de, o en relacin con, alguna empresa y con menor
frecuencia
para establecer direcciones para enlazar la direccin previa de una persona
con una
el actual. reenvo de mensajes en silencio (sin servidor
notificacin al remitente), por motivos de seguridad o de no divulgacin,
es comn en la Internet contempornea.
En tanto la empresa como la "nueva direccin" de los casos, la informacin
oculta (y en ocasiones de seguridad) consideraciones argumentar en contra de
la exposicin
de la direccin "final" a travs del protocolo SMTP como un efecto secundario
de
la actividad de reenvo. Esto puede ser especialmente importante cuando el

discurso final puede incluso no ser alcanzable por el remitente. Por

consiguiente,
los mecanismos de "reenvo" descritos en la seccin 3.2 del RFC 821, y
especialmente los 251 (destino corregido) y 551 cdigos de respuesta de
RCPT debe ser evaluada cuidadosamente por los ejecutores y, cuando estn
disponible, por aquellos configuracin de sistemas (vase tambin la seccin
7.4).
En particular:
o servidores podr transmitir mensajes cuando tengan conocimiento de una

direccin
cambio. Cuando lo hacen, ellos pueden bien disponer de direcciones-
actualizacin
informacin con un cdigo 251, o puede reenviar "silencio" y la de regreso
un cdigo 250. Sin embargo, si se utiliza un cdigo 251, no deben asumir
que el cliente realmente actualizar informacin de direccin o incluso
volver que la informacin para el usuario.
Alternativamente,
o Los servidores pueden rechazar mensajes o devolverlos como no entregable

cuando
que no se pueden entregar con precisin como dirigida. Cuando lo hacen,
O bien puede proporcionar informacin de la direccin-actualizar con un 551
cdigo, o puede rechazar el mensaje como no entregado con un cdigo 550
y no hay informacin-direccin especfica. Sin embargo, si un cdigo 551 es
utilizado, no deben asumir que el cliente realmente actualizar
informacin de direccin o incluso volver que la informacin para el
usuario.
implementaciones del servidor SMTP que soportan el 251 y / o 551 respuesta

cdigos DEBE proporcionar mecanismos de configuracin para que los sitios que
concluyen que iban a divulgar informacin no deseada puede desactivar
o restringir su uso.
3.5. Comandos para la depuracin de direcciones
3.5.1. Visin de conjunto
SMTP proporciona comandos para verificar un nombre de usuario u obtener el

contenido de
una lista de correo. Esto se hace con el VRFY y comandos EXPN, que
tener argumentos de cadena de caracteres. Implementaciones DEBE apoyo VRFY
y EXPN (sin embargo, vase la Seccin 3.5.2 y la Seccin 7.3).
Para el comando VRFY, la cadena es un nombre de usuario o un nombre de usuario

y
dominio (vase ms adelante). Si una normal (es decir, 250) se devuelve la
respuesta,
La respuesta puede incluir el nombre completo del usuario y debe incluir
el buzn de correo del usuario. Debe estar en alguna de las siguientes
formas:
Nombre de usuario <parte-local @ dominio>

@ dominio local de partes

Cuando un nombre que es el argumento de VRFY podra identificar ms de una

buzn, el servidor puede observar bien la ambigedad o identificar la
alternativas. En otras palabras, cualquiera de los siguientes son legtimos
respuestas a VRFY:
553 Usuario ambigua
553- ambiguo; Las posibilidades son

553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>
553-ambiguo; posibilidades
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>
En circunstancias normales, un cliente que recibe una respuesta 553 sera

esperado para exponer el resultado al usuario. El uso de exactamente las
formas
dado, y los "usuarios" ambiguas o palabras clave "ambigua", posiblemente
complementado con cdigos de respuesta prolongados, tales como los descritos
en RFC
3463 [25], facilitar la traduccin automtica a otros idiomas
segn sea necesario. Por supuesto, un cliente que fue altamente automatizado o
que era
que opera en otro idioma que no sea Ingls podra optar por tratar de
traducir la respuesta a volver alguna otra indicacin al usuario
que el texto literal de la respuesta, o tomar alguna accin automatizada
tales como la consulta de un servicio de directorio para obtener informacin
adicional
antes de informar al usuario.
Para el comando EXPN, la cadena identifica una lista de correo, y el

xito (es decir, 250) de respuesta multilnea puede incluir el nombre completo
de los usuarios y debe dar a los buzones en la lista de correo.
En algunos ordenadores, la distincin entre una lista de correo y un alias

para un nico buzn es un poco difusa, ya que una estructura de datos comn
puede contener ambos tipos de entradas, y que es posible tener correo
listas que contienen slo un buzn de correo. Si se hace una solicitud de
aplicacin
VRFY a una lista de correo, una respuesta positiva se puede dar si un mensaje
dirigida as sera entregado a todos en la lista, de lo contrario una
error DEBE ser informado (por ejemplo, "550 Eso es una lista de correo, no una
usuario "o" 252 No es posible verificar los miembros de la lista de correo ").
Si un
solicitud se hace para expandir un nombre de usuario, el servidor puede
devolver una

respuesta positiva que consiste en una lista que contiene un nombre, o un

de error se puede informar (por ejemplo, "550 Ese es un nombre de usuario, no
un correo
lista").
En el caso de una respuesta de varias lneas xito (normal para EXPN),

exactamente un buzn de correo se va a especificar en cada lnea de la
respuesta.
El caso de una solicitud ambigua se discute anteriormente.
"Nombre de usuario" es un trmino difuso y se ha utilizado de forma

deliberada. Un
implementacin de los comandos EXPN o VRFY DEBE incluir al menos
reconocimiento de los buzones locales como "nombres de usuario". Sin embargo,
puesto
la prctica actual de Internet a menudo resulta en una nica unidad de
traslado de acogida
correo para varios dominios, hosts, especialmente los anfitriones que
proporcionan este
funcionalidad, debe aceptar la "@ dominio local-parte" forma como un "usuario
nombrar "; anfitriones pueden tambin optar por reconocer a otras cadenas
como" usuario
nombres ".
El caso de la ampliacin de una lista de buzones requiere una respuesta

multilnea, tales
como:
C: EXPN ejemplo- personas

S: 250-Jon Postel <Postel@isi.edu>
S: 250 Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam P. Smith <SQSmith@specific.generic.com>
C: EXPN Ejecutivo-Lavadero-Lista
S: 550 Acceso denegado a Ti.
Los argumentos de cadena de caracteres de los comandos EXPN VRFY y no puede

restringirse an ms debido a la variedad de implementaciones de la
Lista de nombres de usuario y buzn de conceptos. En algunos sistemas, puede
ser
apropiado para el argumento del comando EXPN sea un nombre de archivo
para un archivo que contiene una lista de correo, pero de nuevo hay una gran
variedad
de archivo convenciones de nombres en Internet. Del mismo modo, histrico
variaciones en lo que se devuelve por estos comandos son tales que la
la respuesta debe ser interpretado con mucho cuidado, en todo caso, y debe
en general, slo se utilizar para fines de diagnstico.
3.5.2. VRFY normal de las respuestas
Cuando normal (551) 2yz o respuestas son devueltas de un VRFY o EXPN

solicitud, la respuesta debe incluir la <Buzn> nombre utilizando una
"<@ Dominio local partes>" de la construccin, donde "dominio" es una por
integracin global
Nombre de dominio completo. En circunstancias excepcionales suficiente para
justificar la violacin de la intencin de esta especificacin, de forma libre
de texto
Pueden ser devueltos. A fin de facilitar el anlisis por ambos equipos

y la gente, las direcciones deben aparecer entre parntesis angulares. Cuando

direcciones, en lugar de informacin de depuracin de forma libre, se
devuelven,
EXPN y VRFY DEBEN volver direcciones de dominio vlidas slo que son
utilizables
en comandos SMTP RCPT. En consecuencia, si una direccin implica la entrega
a un programa u otro sistema, el nombre del buzn utiliza para llegar a ese
destino debe ser dada. Caminos (fuente rutas explcitas) no debe ser
devuelto por VRFY o EXPN.
Las implementaciones de servidor DEBE apoyo tanto VRFY y EXPN. por

razones de seguridad, las implementaciones MAYO proporcionar instalaciones
locales a
manera de desactivar uno o ambos de estos comandos a travs de la
configuracin
opciones o el equivalente (ver seccin 7.3). Cuando estos comandos estn
compatible, que no estn obligados a trabajar a travs de los rels cuando
transmiten
esta apoyado. Puesto que eran ambos opcionales en el RFC 821, pero fue VRFY
carcter obligatorio en el RFC 1123 [3], si se admite EXPN, debe ser
aparece como una extensin de servicio en una respuesta EHLO. PUEDE ser VRFY
que aparece como una conveniencia, pero, puesto que se requiere apoyo a la
misma, SMTP
Los clientes no estn obligados a comprobar su presencia en la prolongacin
la lista antes de usarlo.
3.5.3. Significado del VRFY o EXPN xito de respuesta
Un servidor NO DEBE devolver un cdigo 250 en respuesta a una VRFY o EXPN

comando a menos que realmente se ha verificado la direccin. En particular,
un servidor no debe retornar 250 si todo lo que ha hecho es para verificar que
la
sintaxis dada es vlida. En ese caso, 502 (Comando no implementado)
o 500 (error de sintaxis, comando no reconocido) DEBE ser devueltos. Como
dicho en otro lugar, la aplicacin (en el sentido de la realidad validacin
direcciones y el retorno de informacin) de VRFY y EXPN son fuertemente
recomendado. Por lo tanto, las implementaciones que regresan 500 o 502 para
VRFY
no estn en plena conformidad con esta especificacin.
Puede haber circunstancias en las que una direccin parece ser vlida, pero
no puede razonablemente ser verificada en tiempo real, sobre todo cuando una
servidor est actuando como un proveedor de correo para otro servidor o
dominio.
"Validez aparente", en este caso, habitualmente comportan al menos
comprobacin de sintaxis y podra implicar la verificacin de que todos los
dominios
especificados son aquellos a los que el husped espera de ser capaz de
transmitir
correo. En estas situaciones, Cdigo de respuesta 252 DEBE ser devueltos.
Estas
paralelas casos la discusin de la verificacin RCPT en la Seccin 2.1.
Del mismo modo, el anlisis de la seccin 3.4 se aplica a la utilizacin de
respuesta
cdigos 251 y 551 con VRFY (y EXPN) para indicar las direcciones que estn
pero reconocieron que se remitira o rechazados se recibieron electrnico
para ellos. Implementaciones en general, debe ser ms agresivo en cuanto a
Verificacin de la direccin en el caso de VRFY que en el caso de RCPT,
incluso si se necesita un poco ms de tiempo para hacerlo.

3.5.4. Semntica y Aplicaciones de EXPN
EXPN es a menudo muy til en problemas de depuracin y comprensin

con listas de correo y alias-meta-direcciones mltiples. Algunos sistemas
han tratado de utilizar la expansin fuente de listas de correo como medio de
eliminar duplicados. La propagacin de los sistemas de solapamiento con
enviar por correo en Internet para anfitriones (normalmente con MX y CNAME DNS
registros), para los buzones de correo (varios tipos de alias de host local),
y en
diversas disposiciones de proxies ha hecho casi imposible que estos
estrategias para trabajar constantemente, y los sistemas de correo no deben
intentar
ellos.
3.6. Reinstalacin y el enrutamiento de correo
3.6.1. Las rutas de origen y de reinstalacin
En general, la disponibilidad de registros de intercambio de correo en el

dominio
sistema de nombres (RFC 1035 [2], RFC 974 [12]) hace que el uso de explcita
rutas de origen en el sistema de correo de Internet innecesarios. Muchos
problemas histricos con la interpretacin de las rutas de origen explcitas
han hecho su uso indeseable. clientes SMTP no debe generar
fuente rutas explcitas, excepto bajo circunstancias inusuales. SMTP
Los servidores pueden negarse a actuar como retransmisiones de correo o para
aceptar las direcciones que
especificar las rutas de origen. Cuando la informacin de ruta se encuentra,
SMTP
Los servidores pueden ignorar la informacin de ruta y slo tiene que enviar a
la final
destino especificado como el ltimo elemento de la ruta y debe hacer
asi que. No ha sido una prctica vlida de utilizar nombres que no lo hacen
aparecer en el DNS como nombres de destino, con los remitentes de contar con
los huspedes intermedios especificados en el enrutamiento de origen para
resolver cualquier
problemas. Si las rutas de origen son despojados, esta prctica causar
fracasos. Esta es una de las varias razones por las que los clientes SMTP NO
DEBE
generar rutas de origen no vlidos o depender de la resolucin de la serie
nombres.
Cuando no se utilizan rutas de la fuente, el proceso se describe en RFC 821

para
la construccin de un camino inverso del de la trayectoria no es aplicable
y la inversa de la ruta en el momento de la entrega ser simplemente la
direccin que apareci en el comando MAIL.
3.6.2. Los registros de correo Exchange y retransmisin
Un servidor de retransmisin SMTP suele ser el blanco de un registro DNS MX

que
designa, en lugar de el sistema de suministro final. el rel
servidor puede aceptar o rechazar la tarea de transmisin de correo
electrnico de la misma
forma en que se acepta o rechaza el correo de un usuario local. Si se acepta
la
tarea, entonces se convierte en un cliente SMTP, establece una transmisin
canal al siguiente servidor SMTP especificado en el DNS (de acuerdo con
las reglas de la Seccin 5), y la enva por correo. Si se niega a

retransmitir correo a una direccin particular, por razones de poltica, una

respuesta 550
Debe ser devuelto.
Esta especificacin no se ocupa de la verificacin de retorno

caminos para su uso en las notificaciones de entrega. Un trabajo reciente,
como la que se
SPF en [29] y DKIM [30] [31], se ha hecho para proporcionar formas de
determinar que una direccin es vlida o pertenece a la persona que
en realidad enviado el mensaje. Un servidor puede intentar verificar el
retorno
ruta antes de usar su direccin para notificaciones de entrega, pero los
mtodos
de este modo no se definen aqu ni es ningn mtodo particular
recomendada en este momento.
3.6.3. Los servidores de envo de mensajes como rels
Existen muchos clientes de correo que envan, especialmente en conjuncin con

instalaciones que reciben a travs de correo electrnico POP3 o IMAP, que han
limitado
capacidad de soportar algunos de los requisitos de esta norma,
tales como la capacidad de la cola de mensajes para su posterior entrega
intentos. Para estos clientes, es una prctica comn para hacer privada
arreglos para enviar todos los mensajes a un solo servidor para su
procesamiento
y la distribucin posterior. SMTP, tal como se especifica aqu, no es lo ideal
adecuado para este papel. Un protocolo de envo de correo normalizado tiene
ha desarrollado que est reemplazando gradualmente las prcticas basadas en
SMTP
(Ver RFC 4409 [18]). En cualquier caso, al ser de carcter
privado y caen fuera del alcance de esta especificacin, que son
no se describe aqu.
Es importante sealar que los registros MX pueden sealar a SMTP servidores

que actan como puertas de acceso a otros entornos, no slo los rels SMTP
y sistemas de distribucin final; vanse las secciones 3.7 y 5.
Si un servidor SMTP ha aceptado la tarea de transmisin de correo electrnico

y
descubre posteriormente que el destino es incorrecto o que el correo no puede
ser entregado por alguna otra razn, entonces se deber construir una
"Correo no entregado" mensaje de notificacin y enviarlo a la
remitente de correo no se puede entregar (como se indica por la inversa
camino). Formatos especificados para los informes de no entrega por otras
normas
(Vase, por ejemplo, RFC 3461 [32] y RFC 3464 [33]) se debe utilizar si
posible.
Este mensaje de notificacin debe ser desde el servidor SMTP en el rel

host o el host que primero determina que la entrega no puede ser
consumado. Por supuesto, los servidores SMTP no debe enviar la notificacin
Mensajes acerca de los problemas que transportan mensajes de notificacin. De
una sola mano
para evitar bucles en el informe de errores es especificar una ruta inversa
nula
en el comando MAIL de un mensaje de notificacin. Cuando un mensaje de este
tipo
se transmite, el camino inverso deber ser fijado a nulo (ver

Seccin 4.5.5 para una discusin adicional). Un comando MAIL con un nulo
reverse-path aparece como sigue:
MAIL FROM: <>
Como se discuti en la seccin 6.4, un rel SMTP no tiene necesidad de

inspeccionar o
actuar sobre la seccin de cabecera o el cuerpo de los datos del mensaje y no
debe
hacerlo sino para aadir su propio "Recibido:" campo de cabecera (Seccin 4.4)
y, opcionalmente, para intentar detectar un bucle en el sistema de correo (ver
Seccin 6.3). Por supuesto, esta prohibicin tambin se aplica a cualquier
modificaciones de estos campos de cabecera o el texto (vase tambin la
seccin 7.9).
3.7. gatewaying electrnico
Mientras que la funcin de rel se discuti anteriormente opera dentro de la

Internet
entorno de servicio de transporte SMTP, los registros MX o diversas formas de
encaminamiento explcito puede requerir que un servidor intermedio realice
una funcin de traduccin entre uno y otro servicio de transporte. Como
discute en la Seccin 2.3.10, cuando un sistema de este tipo est en el lmite
entre dos entornos de servicio de transporte, nos referimos a ella como una
"Puerta de entrada" o "gateway SMTP".
Gatewaying correo entre diferentes entornos de correo, tales como

diferentes formatos y protocolos de correo, es complejo y no lo hace fcil
ceder a la normalizacin. Sin embargo, algunos requisitos generales pueden ser
dado para una pasarela entre Internet y otro electrnico
ambiente.
3.7.1. Campos de la cabecera gatewaying
campos de cabecera se puede reescribir necesario, dado que los mensajes son
por puerta de enlace a travs de lmites de entorno electrnico. Esto puede
implicar
inspeccionar el cuerpo del mensaje o la interpretacin de la parte local de la
direccin de destino, a pesar de las prohibiciones establecidas en la Seccin
6.4.
Otros sistemas de correo gatewayed a Internet utilizan a menudo un subconjunto

de
la cabecera RFC 822 seccin o proporcionar una funcionalidad similar con una
sintaxis diferente, pero algunos de estos sistemas de correo no dispone de una
equivalente a la envoltura SMTP. Por lo tanto, cuando se deja un mensaje
el entorno de Internet, puede ser necesario plegar el SMTP
informacin sobre en la seccin de cabecera del mensaje. Un posible
solucin sera la creacin de nuevos campos de cabecera para llevar a la
envolvente
informacin (por ejemplo, "X-SMTP-MAIL:" y "X-SMTP RCPT-:"); sin embargo, esta
requerira cambios en los programas de correo electrnico en entornos
exteriores y
podra correr el riesgo de divulgacin de informacin privada (vase la
seccin 7.2).

3.7.2. Lneas recibidas en gatewaying
Al reenviar un mensaje dentro o fuera del entorno de Internet,

puerta de acceso deber anteponer un Recibido: lnea, pero no debe alterar en
cualquier
una forma Recibido: lnea que ya est en la seccin de encabezado.
"Recibido:" campos de cabecera de los mensajes procedentes de otro

ambientes pueden no ajustarse exactamente a esta especificacin. Sin embargo,
el uso ms importante de lneas Received: es para el correo de depuracin
fallas, y esta depuracin puede verse obstaculizada por bien intencionados
pasarelas que tratan de "arreglar" un Recibido: lnea. Como otra consecuencia
de campos de cabecera traza generados en entornos que no son SMTP, recibiendo
Los sistemas no deben rechazar el correo basado en el formato de una cabecera
traza
campo y debe ser extremadamente robusto, a la luz de la inesperada
informacin o formatos en los campos de cabecera.
La puerta de enlace es conveniente indicar el medio ambiente y protocolo en la

"va"
clusulas del campo de cabecera recibido (s) que se suministra.
3.7.3. Las direcciones de gatewaying
Desde el lado de Internet, la puerta de entrada debe aceptar toda la direccin

vlida
formatos de los comandos SMTP y en la seccin de encabezado RFC 822, y todos
RFC vlida 822 mensajes. Las direcciones y los campos de cabecera generada por
Gateways deben ajustarse a las normas aplicables (incluyendo ste y
RFC 5322 [4]). Gateways son, por supuesto, sujetos a las mismas reglas
para el manejo de rutas de la fuente que los descritos para otros sistemas de
SMTP
en la Seccin 3.3.
3.7.4. Otros campos de cabecera en gatewaying
La puerta de acceso deber asegurar que todos los campos de la cabecera de un

mensaje que se
hacia delante en el entorno de correo de Internet cumplen con los requisitos
para
correo de Internet. En particular, todas las direcciones en "De:", "To:",
"Cc:", etc., campos de cabecera debe ser transformada (si es necesario) para
satisfacer la sintaxis de cabecera estndar de la RFC 5322 [4], debe hacer
referencia a
Slo los nombres de dominio totalmente calificados, y debe ser eficaz y til
para el envo de las respuestas. El algoritmo de conversin utilizado para
convertir el correo
a partir de los protocolos de Internet con el protocolo del otro al medio
ambiente deben
asegurar que los mensajes de error desde el entorno de correo externo son
entregada a la trayectoria inversa del sobre SMTP, no a una
direccin en el campo "De:", "Remitente:" o encabezado similar campos de la
mensaje.

3.7.5. Sobres en gatewaying
Del mismo modo, cuando la transmisin de un mensaje de otro medio ambiente en

Internet, la pasarela debe establecer la ruta de retorno sobre en
de acuerdo con una direccin de retorno mensaje de error, si lo suministra el
ambiente extranjero. Si el ambiente exterior no tiene equivalente
concepto, la puerta de enlace debe seleccionar y utilizar una mejor
aproximacin, con
la direccin del remitente del mensaje como el defecto de ltimo recurso.
3.8. Terminar las sesiones y conexiones
Una conexin SMTP se termina cuando el cliente enva un QUIT

mando. El servidor responde con un cdigo de respuesta positiva, despus de lo
cual
se cierra la conexin.
Un servidor SMTP NO DEBE cerrar la conexin intencional con arreglo
circunstancias operativas normales (ver seccin 7.8), excepto:
o Despus de recibir un comando QUIT y responder con una respuesta 221.
o Despus de la deteccin de la necesidad de cerrar el servicio SMTP y

devolver un cdigo 421 de respuesta. Este cdigo de respuesta puede ser
emitido
despus de que el servidor recibe cualquier comando o, si es necesario,
de forma asncrona, desde la recepcin de comandos (en el supuesto de que
la
cliente recibir despus de que se emite el siguiente orden).
o Despus de un tiempo de espera, tal como se especifica en la Seccin

4.5.3.2, se produce de espera
para que el cliente enve un comando o datos.
En particular, un servidor que cierra las conexiones en respuesta a

los comandos que no se entienden es en violacin de esta
especificacin. Se espera que los servidores a ser tolerantes con desconocidos
comandos, la emisin de una respuesta 500 y en espera de nuevas instrucciones
de
el cliente.
Un servidor SMTP que se cerr por la fuerza hacia abajo a travs de medios
externos deberan
intentar enviar una lnea que contiene un cdigo de 421 respuesta a la SMTP
cliente antes de salir. El cliente SMTP normalmente leer el 421
cdigo de respuesta despus de enviar su siguiente comando.
clientes SMTP que experimentan una estrecha conexin, reset, u otro

comunicaciones fallo debido a circunstancias que no estn bajo su control
(En violacin de la intencin de esta especificacin, pero a veces
inevitable) debe, para mantener la robustez del sistema electrnico,
tratamiento de la transaccin de correo, como si una respuesta 451 haba sido
recibida y
actuar en consecuencia.

3.9. Listas de correo y alias
Un host SMTP con capacidad conveniente apoyar tanto el alias y la lista

modelos de expansin direccin para la entrega mltiple. Cuando un mensaje es
entregada o remitida a cada direccin de una forma lista ampliada, la
la direccin del remitente en el sobre ( "MAIL FROM:") se debe cambiar para
ser
la direccin de una persona u otra entidad que administra la lista.
Sin embargo, en este caso, la seccin de cabecera del mensaje (RFC 5322 [4])
MUST
ser dejado sin cambios; En particular, el campo "De" de la cabecera
seccin no se ve afectada.
Una instalacin de correo importante es un mecanismo para multi-destino

la entrega de un mensaje individual, mediante la transformacin (o "expansin"
o
"Explosin") una direccin de pseudo-buzn de correo en una lista de destino
direcciones de buzn. Cuando se enva un mensaje a un pseudo-buzn tales
(A veces llamado un "detonador"), las copias se envan o
redistribuido a cada buzn en la lista ampliada. Los servidores deben
simplemente utilizar las direcciones de la lista; aplicacin de la heurstica
u otras reglas de coincidencia para eliminar algunas direcciones, como la de
el creador, est totalmente desaconsejado. Clasificamos un pseudo tales
buzn como un "alias" o una "lista", dependiendo de la expansin
reglas.
3.9.1. Alias
Para expandir un alias, el gestor de correo receptor simplemente reemplaza el

pseudo
direccin de buzn de correo en el sobre con cada una de las direcciones
ampliadas
en turno; el resto de la envoltura y el cuerpo del mensaje se dejan
sin alterar. El mensaje se entrega a continuacin, o remitir a cada uno
Direccin ampliado.
3.9.2. Lista
Una lista de correo puede decirse que operar por la "redistribucin" en lugar
de
por "expedicin". Para expandir una lista, el gestor de correo destinatario
sustituye al
direccin de pseudo-buzn de correo en el sobre con cada uno de los ampliado
direcciones a su vez. La direccin de retorno (backward-apuntando) en el
se cambia sobre para que todos los mensajes de error generados por la final
entregas sern devueltos a un administrador de la lista, no a la
autor del mensaje, que por lo general no tiene control sobre los contenidos de
la lista y por lo general encontrarn mensajes de error molestos. Tenga en
cuenta que
la diferencia clave entre los alias de manejo (Seccin 3.9.1) y
reenviando (este inciso) es el cambio en el retroceso que apunta
abordar en este caso. Cuando una lista limita su procesamiento a la
conjunto muy limitado de modificaciones y acciones descritas aqu, es
tratar de emular a un MTA; dichas listas pueden ser tratados como una
continuacin en trnsito de correo electrnico.

Existen listas de distribucin que realizan adicional, a veces

extensas, modificaciones a un mensaje y su envolvente. Dicho correo
listas deben ser vistos como MUAs completos, que aceptan una entrega y
enviar un nuevo mensaje.
4. Las especificaciones SMTP
4.1. Los comandos SMTP
4.1.1. Comando semntica y la sintaxis
Los comandos SMTP definen la transferencia de correo o el sistema de correo

funcin solicitada por el usuario. comandos SMTP son cadenas de caracteres
terminados por <CRLF>. Los comandos propios son alfabticos
personajes terminados por <SP> si los parmetros siguen y <CRLF>
de otra manera. (Con el fin de mejorar la interoperabilidad, SMTP
receptores debe tolerar espacios en blanco antes de la terminacin
<CRLF>.) La sintaxis de la parte local de un buzn DEBE cumplir con los
convenciones sitio receptor y la sintaxis especificada en la Seccin 4.1.2.
Los comandos SMTP se discuten a continuacin. Las respuestas son SMTP
discuti en la Seccin 4.2.
Una transaccin de correo implica varios objetos de datos que son

comunicado como argumentos a diferentes comandos. El camino inverso-es
el argumento del comando MAIL, la de la trayectoria directa es el argumento de
el comando RCPT, y los datos de correo es el argumento de los datos
mando. Estos argumentos u objetos de datos deben ser transmitidos y
retenida, en espera de la confirmacin comunicada por el final de los datos de
correo
indicacin de que finalice la transaccin. El modelo para esto es
que tampones distintos se proporcionan para mantener los tipos de objetos de
datos;
es decir, no es un tampn de trayectoria inversa, un tampn de la trayectoria,
y una
tampn de datos de correo. comandos especficos hacen que la informacin que
se aadirn
a un bfer especfico, o hacer que uno o ms tampones que se borren.
Varios comandos (RSET, DATOS, QUIT) se especifican como no lo permite

parmetros. En ausencia de extensiones especficas que ofrece el
servidor y aceptado por el cliente, el cliente no debe enviar tales
parmetros y servidores debe rechazar los comandos que contiene como
que tiene una sintaxis no vlida.
4.1.1.1. HOLA extendido (EHLO) o HOLA (HELO)
Estos comandos se utilizan para identificar el cliente SMTP para el SMTP

servidor. La clusula argumento contiene el nombre de dominio completo
del cliente SMTP, si hay alguno disponible. En situaciones en las que la
sistema cliente SMTP no tiene un nombre de dominio significativa (por ejemplo,
cuando
su direccin se le asigna de forma dinmica y no hay registro de asignacin
inversa es

disponible), el cliente debe enviar una direccin literal (ver

Seccin 4.1.3).
RFC 2821, y algunas prcticas informales anteriores, alentado siguiente

lo literal por informacin que ayude a identificar al cliente
sistema. Esa convencin no fue muy bien acogida, y muchos SMTP
servidores consideraron que era un error. En aras de la interoperabilidad,
es probable que sea prudente para los servidores que estn preparados para
esta cadena de
se producen, pero los clientes SMTP no deben enviar la misma.
El servidor SMTP se identifica ante el cliente SMTP en el

respuesta saludo de conexin y en la respuesta a este comando.
Un cliente SMTP debera dar inicio a una sesin SMTP mediante la emisin de la
EHLO
mando. Si el servidor SMTP es compatible con las extensiones de servicio SMTP,
se
dar una respuesta correcta, una respuesta de fallo o un error
respuesta. Si el servidor SMTP, en violacin de esta especificacin,
no soporta las extensiones de servicio SMTP, se generar una
respuesta de error. sistemas cliente SMTP mayores pueden, como se mencion
anteriormente,
utilizar HELO (como se especifica en el RFC 821) en lugar de EHLO, y los
servidores deben
apoyar el comando HELO y responder adecuadamente a ella. En cualquier caso,
una
cliente deber emitir HELO o EHLO antes de iniciar una transaccin de correo.
Estos comandos, y una respuesta "250 OK" para uno de ellos, confirman que
tanto el cliente SMTP y el servidor SMTP estn en el estado inicial,
es decir, no hay una transaccin en curso y todas las tablas de estado y
tampones se borran.
Sintaxis:
ehlo = SP "EHLO" (dominio / direccin-literal) CRLF
helo = "HELO" Dominio CRLF SP
Normalmente, la respuesta a EHLO ser una respuesta de varias lneas. Cada

lnea
de la respuesta contiene una palabra clave y, opcionalmente, uno o ms
parmetros. Tras la sintaxis normal para respuestas de varias lneas, stas
palabras clave siguen el cdigo (250) y un guin para todos excepto el ltimo
la lnea, y el cdigo y un espacio para la ltima lnea. La sintaxis de una
respuesta positiva, usando la notacin ABNF y smbolos terminales de
RFC 5234 [7], es:
ehlo-ok-RSP = ( "250" SP Dominio [SP ehlo saludar] CRLF)

/ ( "250" de dominio [SP ehlo saludar] CRLF
* ( "250" lnea ehlo CRLF)
"250" SP ehlo lnea CRLF)

ehlo saludar = 1 * (% d0-9 / d11-12% /% d14-127)

; cadena de caracteres que no sean CR o LF
ehlo lnea = ehlo-clave * (SP ehlo-param)
ehlo-palabra clave = (ALPHA / DIGIT) * (ALPHA / DIGIT / "-")

; sintaxis adicional de ehlo-params depende
; ehlo en palabras clave
ehlo-param = 1 * (% d33-126)
; cualquier CHAR excluyendo <SP> y todos
; los caracteres de control (US-ASCII 0-31 y 127
; inclusivo)
Aunque las palabras clave EHLO se pueden especificar en maysculas,

minsculas, o mixto
caso, siempre deben ser reconocidos y tratados en un caso-
de manera insensible. Esto es simplemente una extensin de prcticas
se especifica en el RFC 821 y la Seccin 2.4.
La respuesta EHLO deber contener las palabras clave (y los parmetros

asociados si
required) para todos los comandos que se sealan como "necesarios" en la
Seccin 4.5.1
la nica excepcin de los comandos de uso privado como se describe en la
Seccin 4.1.5.
comandos de uso privado pueden estar sealados.
4.1.1.2. MAIL (CORREO)
Este comando se utiliza para iniciar una transaccin de correo electrnico en

la que el
los datos se entregan a un servidor SMTP que pueden, a su vez, entregarlo a
uno o ms buzones o pasarlo a otro sistema (posiblemente usando
SMTP). La clusula argumento contiene un camino inverso y puede contener
parmetros opcionales. En general, el comando MAIL se puede enviar solamente
cuando no hay transaccin de correo est en curso, consulte la Seccin 4.1.4.
El camino inverso-consiste en el buzn de correo del remitente.

Histricamente, que
buzn podra eventualmente haber sido precedida de una lista de hosts, pero
que el comportamiento se considera obsoleto (ver Apndice C). En algunos tipos
de
informes mensajes para los que es probable que una respuesta a causar un bucle
de correo
(Por ejemplo notificaciones, enviar correo y no entrega), la
reverse-path puede ser nula (ver seccin 3.6).
Este comando borra el buffer de trayectoria inversa, el bfer de la

trayectoria directa,
y la memoria de datos de correo, e inserta la informacin de la ruta inversa
de su clusula de argumento en el bfer de la ruta inversa.
Si se negociaron las extensiones del servicio, el comando de correo tambin

llevar a parmetros asociados con una extensin de servicio particular.

Sintaxis:
mail = "MAIL FROM:" reverse-path

[SP-correo parmetros] CRLF
4.1.1.3. RECEPTOR (RCPT)
Este comando se utiliza para identificar a un individuo receptor del correo

datos; varios destinatarios son especificados por mltiples usos de este
mando. La clusula argumento contiene una ruta de avance y puede contener
parmetros opcionales.
El camino a seguir consiste normalmente en el destino deseado

buzn. sistemas de envo no debe generar la lista opcional de
hosts conocidos como ruta de origen. sistemas de recepcin debe reconocer
la sintaxis de ruta de origen sino que debe quitarse la ruta de origen
especificacin y utilizar el nombre de dominio asociado con el buzn
como si no se hubiera proporcionado la ruta de origen.
Del mismo modo, el rel de mquinas dar tiras o ignorar las rutas de origen, y
nombres, no debern ser copiados en el camino inverso. Cuando alcances de
correo
su destino final (la de la trayectoria directa contiene slo una
buzn de destino), el servidor SMTP lo inserta en el destino
buzn de conformidad con las convenciones de correo de acogida.
Este comando aade su argumento de la trayectoria directa a la de la

trayectoria directa
buffer; no cambia el tampn de trayectoria inversa ni los datos de correo
buffer.
Por ejemplo, el correo recibido en el rel xyz.com anfitrin con el sobre

comandos
MAIL FROM: <userx@y.foo.org>

RCPT TO: <@ hosta.int, @ jkl.org: userc@d.bar.org>
normalmente ser enviado directamente a la sede de d.bar.org con el sobre

comandos

RCPT TO: <userc@d.bar.org>
Tal como se establece en el Apndice C, xyz.com tambin pueden optar por

transmitir la
mensaje a hosta.int, utilizando los comandos del sobre

RCPT TO: <@ hosta.int, @ jkl.org: userc@d.bar.org>

o para jkl.org, utilizando los comandos del sobre

RCPT TO: <@ jkl.org:userc@d.bar.org>
El intento de utilizar la retransmisin de esta manera est totalmente

desaconsejado.
Dado que los anfitriones no estn obligados a retransmitir correo en absoluto,
xyz.com MAYO tambin
rechazar el mensaje por completo cuando se recibe el comando RCPT, utilizando
un cdigo 550 (ya que se trata de una "razn poltica").
Si se negociaron las extensiones del servicio, el comando RCPT tambin puede

llevar a parmetros asociados con una extensin de servicio particular,
ofrecido por el servidor. El cliente no debe transmitir a otros parmetros
que los asociados con una extensin de servicio ofrecido por el servidor
en su respuesta EHLO.
Sintaxis:
RCPT = "RCPT TO:" ( "<Administrador @" dominio ">" / "<administrador de

correo>" /
Hacia el camino) [SP-RCPT parmetros] CRLF
Tenga en cuenta que, en una desviacin de las normas habituales

para
-partes locales, la cadena "Administrador de correo" se muestra
ms arriba es
tratados como maysculas y minsculas.
4.1.1.4. DATOS (DATA)
El receptor normalmente enva una respuesta 354 a los datos, y luego golosinas
las lneas (cuerdas que termina en <CRLF> secuencias, como se describe en
Seccin 2.3.7) que sigue al comando como datos de correo del remitente.
Este comando hace que los datos de correo que se aadirn a los datos de
correo
buffer. Los datos de correo pueden contener cualquiera de los caracteres ASCII
128
cdigos, aunque la experiencia ha indicado que el uso del control
caracteres que no sean SP, HT, CR, LF y pueden causar problemas y
Debe evitarse siempre que sea posible.
Los datos de correo se terminan por una lnea que contiene slo un perodo,
que
es decir, la secuencia de caracteres "<CRLF>. <CRLF>", donde el primer <CRLF>
es
en realidad el terminador de la lnea anterior (vase la Seccin 4.5.2).
Esta es la indicacin de final de datos de correo. El primer <CRLF> de este
terminacin de la secuencia es tambin el <CRLF> que termina la lnea final de
los datos (texto del mensaje) o, si no hay datos de correo, termina la DATOS
propio comando (el caso "sin datos electrnico" no se ajusta a esta
especificacin ya que requerira que ni la cabecera traza
los campos requeridos por esta especificacin ni la seccin de cabecera del
mensaje
requerido por la RFC 5322 [4] ser transmitida). Un extra <CRLF> NO DEBE
se aade, pues eso causara una lnea vaca que se aade a la
mensaje. La nica excepcin a esta regla se planteara si el mensaje

el cuerpo se pasa al originario SMTP-emisor con una "lnea" definitiva

que no termin en <CRLF>; en ese caso, el sistema de SMTP originario
O bien debe rechazar el mensaje como no vlido o aadir <CRLF> con el fin de
tiene el servidor SMTP receptor reconoce el "fin de los datos" condicin.
La costumbre de lneas que terminan aceptando slo en <LF>, como una concesin
a
comportamiento no conforme por parte de algunos sistemas UNIX, se ha
demostrado
para causar ms problemas de los que resuelve interoperabilidad y SMTP
sistemas de servidor no debe hacer esto, incluso en el nombre de mejora
robustez. En particular, la secuencia "<LF>. <LF>" (lnea desnuda
se alimenta, sin retornos de carro) no deben ser considerados como
equivalentes a
<CRLF>. <CRLF> como la indicacin de final de datos de correo.
La recepcin de la indicacin de final de datos de correo requiere que el
servidor
procesar la informacin de la transaccin correo almacenado. Este
procesamiento
consume la informacin en la memoria intermedia de la ruta inversa, la de la
trayectoria directa
tampn, y la memoria intermedia de datos de correo, y en la realizacin de
este
comandar estos tampones se borran. Si el tratamiento es exitoso,
El receptor debe enviar una respuesta OK. Si el procesamiento falla, el
receptor deber enviar una respuesta al fracaso. El modelo SMTP no permite
por fallos parciales en este punto: o bien el mensaje es aceptado por
el servidor para la entrega y una respuesta positiva se devuelve o se
No se acepta y se devuelve una respuesta al fracaso. En el envo de un
positivo
"250 OK" finalizacin respuesta a la indicacin de final de datos, el receptor
asume plena responsabilidad del mensaje (vase la Seccin 6.1). errores
que se diagnostican posteriormente deben ser reportados en un mensaje de
correo,
como se discute en la Seccin 4.4.
Cuando el servidor SMTP acepta un mensaje, ya sea para transmitir o para

la entrega final, se inserta un registro de seguimiento (tambin denominado
indistintamente como "lnea de marca de tiempo" o lnea de "Recibido") en la
parte superior
de los datos de correo. Este registro de rastreo indica la identidad de la
servidor que envi el mensaje, la identidad de la mquina que recibi
el mensaje (y se la insercin de este sello de tiempo), y la fecha y hora
se recibi el mensaje. Los mensajes retransmitidos tendrn tiempo mltiple
lneas de sello. Los detalles de la formacin de estas lneas, incluyendo su
sintaxis, se especifica en la Seccin 4.4.
aparece discusin adicional sobre el funcionamiento del comando DATA

en la Seccin 3.3.
Sintaxis:
datos = "data" CRLF

4.1.1.5. RESET (RSET)
Este comando especifica que la transaccin de correo actual ser

abortado. Cualquier remitente almacenado, receptores, y los datos de correo se
deben
descartados, y todos los tampones y tablas de estado borran. El receptor
Debe enviar una respuesta "250 OK" a un comando RSET sin argumentos. UN
orden de reposicin puede ser emitida por el cliente en cualquier momento. Es
con eficacia equivalente a un NOOP (es decir, no tiene ningn efecto) si se
emiti
inmediatamente despus de EHLO, antes de EHLO se emite en la sesin, despus
de
un indicador de fin de datos han sido enviados y reconocido, o
inmediatamente antes de una QUIT. Un servidor SMTP NO DEBE cerrar la
conexin como resultado de recibir un RSET; que la accin est reservado
para QUIT (vase la Seccin 4.1.1.10).
Desde EHLO implica algn tipo de procesamiento y la respuesta adicional por

parte del
servidor, RSET ser normalmente ms eficiente que la reemisin que
comando, a pesar de que la semntica formal son los mismos.
Hay circunstancias, en contra de la intencin de esta

memoria descriptiva, en la que un servidor SMTP puede recibir una indicacin
de que
la conexin TCP subyacente se ha cerrado o restablecer. Para preservar
la robustez del sistema de correo, servidores SMTP deben estar preparados
para esta enfermedad y debe tratar como si un QUIT se haban recibido
antes de la conexin desapareci.
Sintaxis:
RSET = "RSET" CRLF
4.1.1.6. VERIFICAR (VRFY)
Este comando solicita al receptor para confirmar que el argumento

identifica a un usuario o buzn. Si se trata de un nombre de usuario, la
informacin es
devuelto como se especifica en la Seccin 3.5.
Este comando no tiene efecto en la memoria intermedia de la ruta inversa, el

orientadas hacia el
tampn de ruta o bien el bfer de datos de correo.
Sintaxis:
vrfy = cadena de caracteres CRLF SP "VRFY"

4.1.1.7. EXPAND (EXPN)
Este comando solicita al receptor para confirmar que el argumento

identifica una lista de correo, y si es as, para devolver el nmero de
miembros del
esa lista. Si el comando se ejecuta correctamente, se devuelve una respuesta
que contiene informacin tal como se describe en la Seccin 3.5. Esta
respuesta se
tener mltiples lneas excepto en el caso trivial de una lista de un solo
miembro.
orientadas hacia el
tampn de ruta o bien el bfer de datos de correo, y puede ser emitida en
cualquier
hora.
Sintaxis:
expn = cadena de caracteres CRLF SP "EXPN"
4.1.1.8. AYUDA AYUDA)
Este comando hace que el servidor para enviar informacin til para el
cliente. El comando puede tomar un argumento (por ejemplo, cualquier nombre de
comando)
y devolver informacin ms especfica como respuesta.

orientadas hacia el
cualquier
hora.
Los servidores SMTP DEBE apoyo AYUDA sin argumentos y mayo apoyarlo
con argumentos.
Sintaxis:
help = "AYUDA" [SP String] CRLF

4.1.1.9. NOOP (NOOP)
Este comando no afecta a los parmetros previamente introducidos o

comandos. En l se especifica ninguna accin aparte de que el receptor enva
una
respuesta "250 OK".

orientadas hacia el
cualquier
hora. Si se especifica una cadena de parmetros, los servidores deben
ignorarlo.
Sintaxis:
NOOP = "NOOP" [SP String] CRLF
4.1.1.10. QUIT (QUIT)
Este comando especifica que el receptor debe enviar un "221 OK" respuesta,
y luego cerrar el canal de transmisin.
El receptor no debe cerrar el canal de transmisin intencionada

hasta que recibe y responde a un comando QUIT (incluso si haba una
error). El remitente NO DEBE cerrar la transmisin intencional
canal hasta que se enva un comando QUIT, y debe esperar hasta que se
recibe la respuesta (incluso si hubo un error de respuesta a una anterior
mando). Si la conexin se cierra prematuramente debido a violacines
del fallo por encima o sistema o red, el servidor deber cancelar cualquier
en espera de la transaccin, pero no deshacer cualquier completado previamente
transaccin, y por lo general tiene que actuar como si el comando o
transaccin
en curso haba recibido un error temporal (es decir, una respuesta 4yz).
El comando QUIT se puede emitir en cualquier momento. Cualquier corriente

incompleto
transaccin de correo ser abortado.
Sintaxis:
dejar de fumar = "QUIT" CRLF
4.1.1.11. Correo de parmetros y RCPT-Parmetro respuestas de errores
Si el servidor SMTP no reconoce o no se puede realizar una o varias

de los parmetros asociados a un determinado CORREO FROM o RCPT TO
de comandos, devolver el cdigo 555.
Si, por alguna razn, el servidor es temporalmente incapaz de acomodar

uno o ms de los parmetros asociados con un MAIL FROM o RCPT TO
del sistema y, si la definicin del parmetro especfico no lo hace
mandato para hacer uso de otro cdigo, se debe devolver el cdigo 455.

Errores especficos a los parmetros particulares y sus valores sern

se especifica en RFC definicin del parmetro.
4.1.2. Comando Argumento Sintaxis
La sintaxis de las clusulas de los argumentos de los comandos anteriores

(utilizando el
sintaxis especificada en el RFC 5234 [7] en su caso) es la siguiente.
Algunas de las producciones que figuran a continuacin se utilizan slo en
combinacin con
rutas de origen tal como se describe en el Apndice C. Las terminales no se
define en el
este documento, tales como ALFA, dgito, SP, CR, LF, CRLF, son como se definen
en la sintaxis "ncleo" en la Seccin 6 de la RFC 5234 [7] o en el mensaje
sintaxis de formato en el RFC 5322 [4].
Reverse-path = Ruta / "<>"
Hacia el camino = Ruta
Path = "<" [Adl ":"] Buzn ">"
Adl = A-dominio * ( "," A-dominio)

; Tenga en cuenta que esta forma, el llamado "fuente
; ruta ", debe ser aceptado, no debe ser
; generado, y debera ser ignorado.
Al-domain = "@" dominio
Mail-parmetros = esmtp-param * (SP esmtp-param)
RCPT parmetros = esmtp-param * (SP esmtp-param)
esmtp-param = esmtp-palabra clave [ "=" esmtp valor]
esmtp-palabra clave = (ALPHA / DIGIT) * (ALPHA / DIGIT / "-")
esmtp-valor = 1 * (% d33-60 / d62-126%)

; cualquier CHAR excluyendo "=", SP, y el control
; caracteres. Si esta cadena es una direccin de correo
electrnico,
; es decir, un buzn, entonces el "xtext" sintaxis [32]
; Debera ser usado.
Palabra clave = LDH-str
Argumento = Atom
Domain = subdominio * ( "." Sub-dominio)

subdominio = Let-cavar [LDH-str]
Let-dig = ALPHA / DIGIT
LDH-str = * (ALPHA / DIGIT / "-") Let-dig
abordar literal = "[" (IPv4-address-literal /

IPv6-direccin-literal /
General-direccin-literal) "]"
; Ver la Seccin 4.1.3
Buzn = local-parte "@" (dominio / direccin-literal)

Parte-local = Dot-string / cita de cadena
; PUEDEN entre maysculas y minsculas
Dot-string = Atom * ( "." Atom)
Atom = 1 * atext
Cita de cadena = DQUOTE * QcontentSMTP DQUOTE
QcontentSMTP = qtextSMTP / quoted-pairSMTP
quoted-pairSMTP =% d92% d32-126

; es decir, la barra invertida seguida por cualquier ASCII
; grfica (incluida ella misma) o en el espacio
qtextSMTP =% d32-33 /% d35-91 /% d93-126

; es decir, dentro de una cadena entre comillas, cualquier
; se permite grfico ASCII o espacio
; sin blackslash-citando a excepcin
; De comillas dobles y la propia barra invertida.
String = Atom / cita de cadena
Mientras que la definicin anterior para Local-parte es relativamente

permisiva,
para la mxima interoperabilidad, un anfitrin que espera recibir correo
Buena idea intentar crear buzones donde la parte local requiere (o
usos) el formulario de cita de cadena o cuando la parte local es caso-
sensible. Para cualquier propsito que requieren generacin o la comparacin
de
-partes locales (por ejemplo, a los nombres de buzn especficos), todas las
formas citadas MUST
ser entendido como equivalente, y el sistema de envo debe transmitir la
formulario que utiliza el mnimo posible citar.
Los sistemas no deben definir buzones de tal manera como para requerir el uso
en el SMTP de caracteres no ASCII (octetos con el conjunto de bits de alto
orden

a uno) o ASCII "caracteres de control" (valor decimal 0-31 y 127).

Estos caracteres no debern ser utilizados en los comandos de correo o RCPT u
otro
comandos que requieren nombres de buzn.
Tenga en cuenta que la barra invertida, "\", es un personaje cita, que se

utiliza para
indicar que el siguiente carcter se va a usar literalmente (en lugar de
su interpretacin normal). Por ejemplo, "Joe \, Smith" indica una
solo nueve caracteres cadena de nombre de usuario con la coma es el
cuarto carcter de esa cadena.
Para promover la interoperabilidad y consistente con larga data

orientacin sobre el uso prudente de los DNS en el nombramiento y aplicaciones
(Por ejemplo, vase la seccin 2.3.1 del documento DNS base, RFC 1035 [2]),
caracteres fuera del conjunto de caracteres alfabticos, dgitos, y
guin no debe aparecer en las etiquetas de nombre de dominio para los clientes
SMTP o
servidores. En particular, no se permite el carcter de subrayado.
servidores SMTP que reciben una orden en la que los cdigos de caracteres no
vlidos
Se han empleado, y para el que no hay otras razones para
rechazo, deber rechazar ese comando con una respuesta 501 (esta regla,
como otros, podra ser anulado por las extensiones SMTP adecuados).
4.1.3. Los literales de direcciones
A veces, un anfitrin no es conocido en el sistema de nombres de dominio y

la comunicacin (y, en particular, la comunicacin para informar y reparacin
el error) es bloqueado. Para evitar esta barrera, una especial literal
forma de la direccin se permite como alternativa a un nombre de dominio.
Para las direcciones IPv4, esta forma utiliza cuatro pequeas enteros
decimales
separados por puntos y encerrado por corchetes como [123.255.37.2],
lo que indica un (IPv4) Direccin de Internet en la secuencia de octetos
formar. Para IPv6 y otras formas de abordar que eventualmente podra
estandarizarse, la forma consiste en una "etiqueta" estandarizada que
identifica la sintaxis de la direccin, dos puntos y la direccin de s mismo,
en una
formato especificado como parte de las normas de aplicacin (es decir, RFC
4291
[8] para IPv6).
Especficamente:
IPv4-address-literal = SNUM 3 ( "." SNUM)
IPv6-direccin-literal = "IPv6:" IPv6-addr
General-direccin-literal = Estandarizado-tag ":" 1 * dcontent
Estandarizada-tag = LDH-str
; Estandarizada-etiqueta deber ser especificado en una
; Normas de va RFC y registrado en la IANA

dcontent =% d33-90 /; Para imprimir US-ASCII

D94-126%; excl. "[", "\", "]"
SNUM = 1 * 3digit
; que representa un entero decimal
; valor en el rango de 0 a 255
IPv6-dir = IPv6 completa / IPv6-comp / IPv6v4-completa / IPv6v4-comp
IPv6-hex = 1 * 4HEXDIG
IPv6 completa = IPv6-hexagonal 7 ( ":" IPv6-hex)
IPv6-comp = [IPv6-hexagonal * 5 ( ":" IPv6-hex)] "::"

[IPv6-hexagonal * 5 ( ":" IPv6-hex)]
; El "::" representa al menos 2 grupos de 16 bits de
; ceros. No ms de 6 grupos, adems de la
; "::" puede estar presente.
IPv6v4 completo = IPv6-hexagonal de 5 ( ":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hexagonal * 3 ( ":" IPv6-hex)] "::"

[IPv6-hexagonal * 3 ( ":" IPv6-hex) ":"]
IPv4-address-literal
; El "::" representa al menos 2 grupos de 16 bits de
; ceros. No ms de 4 grupos, adems de la
; "::" E IPv4-address-literal pueda estar presente.
4.1.4. Orden de Comandos
Hay restricciones en el orden en que estos comandos pueden ser

usado.
Una sesin que contendr las transacciones de correo, primero deber estar
inicializado por el uso del comando EHLO. Un servidor SMTP DEBE
aceptar comandos para las transacciones no son de correo (por ejemplo, VRFY o
EXPN)
sin esta inicializacin.
Un comando EHLO puede ser emitida por un cliente ms adelante en la sesin. Si

que se emite despus de que comience la sesin y el comando EHLO es
aceptable para el servidor SMTP, el servidor SMTP debe borrar todas las
memorias intermedias
y restablecer el estado exactamente como si un comando RSET haba sido
emitida. En
otras palabras, la secuencia de RSET seguidas inmediatamente por EHLO es
redundante, pero no perjudicial que otra en el costo de rendimiento de
la ejecucin de comandos innecesarios.
Si el comando EHLO no es aceptable para el servidor SMTP, 501, 500,

502, o 550 respuestas de falla deben ser devueltos en su caso. los

servidor SMTP debe permanecer en el mismo estado despus de transmitir estos

responde que se encontraba antes de que se recibi la EHLO.
El cliente debe SMTP, si es posible, asegrese de que el parmetro de dominio

al comando EHLO es un nombre de host de nivel superior como se especifica para
este
comando en la Seccin 2.3.5. Si esto no es posible (por ejemplo, cuando el
la direccin del cliente se le asigna de forma dinmica y el cliente no tiene
un nombre obvio), un literal direccin debe ser sustituido por el
nombre de dominio.
Un servidor SMTP puede verificar que el argumento de nombre de dominio en el

EHLO
comando corresponde efectivamente a la direccin IP del cliente.
Sin embargo, si falla la verificacin, el servidor DEBE NO negarse a
aceptar un mensaje sobre esa base. La informacin capturada en el
intento de verificacin es para el registro y propsitos de rastreo. Tenga en
cuenta que
esta prohibicin se aplica a la coincidencia del parmetro a su IP
abordar solamente; vase la Seccin 7.9 para una discusin ms extensa de
rechazo de las conexiones entrantes o mensajes de correo.
El NOOP, AYUDA, EXPN, VRFY, y los comandos RSET se puede utilizar en cualquier
momento
durante una sesin, o sin inicializar una sesin previamente. SMTP
Los servidores deben procesar stas de manera normal (es decir, no devolver un
503
cdigo), aunque todava no se ha recibido ningn comando EHLO; Los clientes
deben
abrir una sesin con EHLO antes de enviar estos comandos.
Si se siguen estas reglas, el ejemplo en el RFC 821 que muestra "550

Acceso denegado a que "en respuesta a un comando EXPN es incorrecta
a menos que un comando EHLO precede a la EXPN o la denegacin de acceso es
basndose en la direccin IP del cliente o de otro tipo de autenticacin o
autorizacin de determinacin de los mecanismos.
El comando MAIL (o SEND obsoleta, SOML o comandos SAML)

comienza una transaccin de correo. Una vez iniciado, una transaccin de
correo consiste
de una transaccin de comandos, uno o ms comandos RCPT, y un comienzo
comando de datos, en ese orden. Una transaccin de correo puede ser abortado
la RSET, un nuevo EHLO, o el comando QUIT. Puede haber cero o ms
transacciones en una sesin. CORREO (o SEND, SOML, o SAML) no se deben
enviado si una transaccin de correo ya est abierto, es decir, debe ser
enviada
slo si no hay transaccin de correo se haba iniciado en la sesin, o si
el anterior concluy con xito con un xito DATOS
de comandos, o si el anterior fue abortado, por ejemplo, con un RSET o una
nueva
EHLO.
Si la transaccin de comienzo argumento de comando no es aceptable, una

501 respuesta fallo deber ser devuelto y el servidor SMTP debe permanecer en
el mismo estado. Si los comandos en una transaccin estn fuera de fin de
el grado de que no pueden ser procesados por el servidor, un fallo 503

la respuesta deber ser devuelto y el servidor SMTP debe permanecer en la

misma
estado.
El ltimo comando en una sesin debe ser el comando QUIT. el QUIT

comando debe ser utilizado por el cliente SMTP para solicitar la conexin
cierre, incluso cuando fue enviado y aceptado ningn comando de apertura de la
sesin.
4.1.5. Privadas-Utilizan Comandos
Tal como se especifica en la Seccin 2.2.2, los comandos a partir de "X" puede
ser utilizado
Mediante un acuerdo bilateral entre el cliente (envo) y el servidor
(Recepcin) agentes SMTP. Un servidor SMTP que no reconoce tales
Se espera una orden para responder con "500 Comando no reconocido". Un
servidor SMTP ampliada puede incluir los nombres de caractersticas asociadas
con stos
comandos privadas en la respuesta al comando EHLO.
Los comandos enviados o aceptados por los sistemas de SMTP que no comienzan
con "X"
Debe ajustarse a los requisitos de la Seccin 2.2.2.
4.2. Respuestas SMTP
Las respuestas a los comandos SMTP sirven para asegurar la sincronizacin de

peticiones y acciones en el proceso de transferencia de correo y para
garantizar
que el cliente SMTP siempre conoce el estado del servidor SMTP.
Cada comando debe generar exactamente una respuesta.
Los detalles de la secuencia de comando de respuesta se describen en

Seccin 4.3.
Una respuesta SMTP consiste en un nmero de tres dgitos (transmitida como

tres
caracteres numricos) seguido de texto a menos que se especifique lo contrario
en este documento. El nmero es para el uso de autmatas para determinar
qu estado para entrar en la prxima; el texto es para el usuario humano. El
tres
los dgitos contienen suficiente informacin codificada que la necesidad del
cliente SMTP
no examinar el texto y puede o bien descartarlo o pasarlo a la
del usuario, segn sea apropiado. Las excepciones son como se indica en el
presente
documento. En particular, los 220, 221, 251, 421, y 551 cdigos de respuesta
estn asociadas con el texto del mensaje que debe ser analizada e interpretada
por las mquinas. En el caso general, el texto puede ser receptor dependiente
y dependiente del contexto, por lo que es probable que se variando textos para
cada respuesta de cdigo. Se presenta una discusin de la teora de los
cdigos de respuesta
en la Seccin 4.2.1. Formalmente, la respuesta se define para ser la
secuencia: una
cdigo de tres dgitos, <SP>, una lnea de texto, y <CRLF>, o una de varias
lneas
responder (como se define en la misma seccin). Dado que, en violacin de esta
especificacin, el texto se enva a veces no, los clientes que no lo hacen
recibirlo deben estar preparados para procesar el cdigo sola (con o
y sin un carcter de espacio al final). Slo el EHLO, EXPN, y AYUDA
Se espera que los comandos para dar lugar a respuestas de varias lneas en la
normalidad

circunstancias; Sin embargo, las respuestas de varias lneas estn permitidos

para cualquier
mando.
En ABNF, las respuestas del servidor son:
Saludo = ( "220" (dominio / direccin-literal)

[Textstring SP] CRLF) /
( "220-" (dominio / direccin-literal)
[Textstring SP] CRLF
* ( "220-" [textstring] CRLF)
"220" [SP textstring] CRLF)
textstring = 1 * (% d09 / d32-126%); HT, SP, para imprimir US-ASCII
Responder-line = * (respuesta de cdigo "-" [textstring] CRLF)

Responder cdigo [SP textstring] CRLF
Responder-cdigo =% x32-35% x30-35% x30-39
donde "felicitacin" slo aparece en la respuesta 220 que anuncia que

el servidor est abriendo su parte de la conexin. (Otros posibles
las respuestas del servidor al conectarse seguir la sintaxis de la respuesta
de lnea.)
Un servidor SMTP DEBE enviar slo los cdigos de respuesta que figuran en este
documento. Un servidor SMTP es conveniente utilizar el texto mostrado en los
ejemplos
siempre que sea apropiado.
Un cliente SMTP debe determinar sus acciones slo por el cdigo de respuesta,
no
por el texto (excepto para el "cambio de direccin" 251 y 551 y, si
necesarios, 220, 221, y 421 respuestas); en el caso general, cualquier texto,
incluyendo ningn texto en absoluto (aunque remitentes no deben enviar al
descubierto
cdigos), debern ser aceptables. El espacio (en blanco) despus de la
respuesta
cdigo se considera parte del texto. Siempre que sea posible, un receptor-
SMTP debe probar el primer dgito (indicacin de la gravedad) de la respuesta
cdigo.
La lista de cdigos que aparece a continuacin no deben ser interpretadas como

permanente. Mientras que la adicin de nuevos cdigos debe ser una rara y
una actividad significativa, con informacin complementaria en el texto
prefirindose parte de la respuesta, los nuevos cdigos se puede aadir como
el
consecuencia de las nuevas normas o especificaciones normas de va.
En consecuencia, un emisor-SMTP debe estar preparado para manejar cdigos no
especifica en este documento y debe hacerlo mediante la interpretacin de la
primera
dgitos solamente.
En ausencia de extensiones negociado con el cliente, servidores SMTP

No debe enviar cdigos de respuesta cuyos primeros dgitos son distinto de 2,
3, 4,

o 5. Los clientes que reciben este tipo de cdigos fuera del rea de
distribucin deben normalmente
tratarlos como errores fatales y terminar la transaccin de correo.
4.2.1. Respuesta Cdigo de Niveles de gravedad y Teora
Los tres dgitos de la respuesta cada uno tiene un significado especial. los
primer dgito indica si la respuesta es buena, mala o incompleta.
Un cliente SMTP poco sofisticado, o uno que recibe un inesperado
cdigo, ser capaz de determinar su siguiente accin (proceder como estaba
previsto,
rehacer, replegarse, etc.) mediante el examen de este primer dgito. Un
cliente SMTP
que quiere saber aproximadamente qu ocurri tipo de error (por ejemplo,
error del sistema electrnico, error de sintaxis de comandos) puede examinar
la segunda
dgito. El tercer dgito y cualquier informacin adicional que puede ser
presente est reservada para el mejor gradacin de informacin.
Hay cuatro valores para el primer dgito del cdigo de respuesta:
2yz positiva respuesta Finalizacin

La accin solicitada se ha completado con xito. Un nuevo
solicitud puede ser iniciado.
3yz respuesta positiva Intermedio

El comando ha sido aceptado, pero est siendo la accin solicitada
dejando en suspenso, a la espera de recibir ms informacin. los
cliente SMTP debe enviar otro comando especificando este
informacin. Esta respuesta se utiliza en grupos de secuencias de comandos
(es decir,
en DATA).
4yz Transitoria respuesta negativa de Terminacin

El comando no fue aceptado, y la accin solicitada no lo hizo
ocurrir. Sin embargo, la condicin de error es temporal, y la accin
se podr solicitar de nuevo. El remitente debe volver al principio
de la secuencia de comandos (si existe). Es difcil asignar una
que significa "transitorio" cuando dos sitios diferentes (del receptor y
del
agentes remitente-SMTP) debe estar de acuerdo en la interpretacin. cada
respuesta
en esta categora podra tener un valor de tiempo diferente, pero el SMTP
cliente es conveniente volver a intentarlo. Una regla de oro para
determinar si una
respuesta encaja en el 4yz o la categora 5yz (ver ms abajo) es que
respuestas se 4yz si pueden tener xito si se repite sin ningn
cambio en la forma de comandos o en propiedades del emisor o receptor
(Es decir, el comando se repite de forma idntica y el receptor
no poner una nueva aplicacin).
5yz respuesta negativa de Terminacin Permanente

El comando no fue aceptado y la accin solicitada no lo hizo
ocurrir. El cliente SMTP no debe repetir la solicitud exacta (en
la misma secuencia). Incluso algunas condiciones de error "permanentes"
pueden ser
corregido, por lo que el usuario humano puede querer dirigir al cliente
SMTP para

reiniciar la secuencia de comandos mediante la accin directa en algn

momento de
el futuro (por ejemplo, despus de la ortografa se ha cambiado, o el
usuario
ha alterado el estado de la cuenta).
Vale la pena sealar que el protocolo de transferencia de archivos (FTP) [34]
utiliza una
arquitectura cdigo muy similar y que los cdigos de SMTP se basan en
el modelo de FTP. Sin embargo, SMTP utiliza una sola orden, modelo de una
respuesta
(Mientras que FTP es asncrona) y los cdigos 1yz de FTP no son parte de la
modelo de SMTP.
El segundo dgito codifica las respuestas en categoras especficas:
x0z Sintaxis: Estas respuestas se refieren a errores de sintaxis,

sintcticamente
comandos correctos que no encajan en ninguna categora funcional, y
comandos no implementados o superfluos.
x1z Informacin: Estas son las respuestas a las solicitudes de informacin,

tales
como el estado o ayuda.
Conexiones x2z: Estas son las respuestas que se refieren a la transmisin

canal.
x3z no especificado.
x4z no especificado.
x5z sistema de correo: Estas respuestas indican el estado del receptor

sistema de correo vis-a-vis la transferencia solicitada u otro sistema de
correo
accin.
El tercer dgito da una gradacin ms fina de significado en cada categora

especificado por el segundo dgito. La lista de respuestas ilustra esto.
Cada texto de respuesta se recomienda ms que obligatorio, e incluso puede
cambiar de acuerdo con el mandato con el que est asociado. Sobre el
Por otro lado, los cdigos de respuesta deben seguir estrictamente las
especificaciones
en esta seccin. implementaciones de receptor no deben inventar nuevas
cdigos para situaciones ligeramente diferentes de las descritas aqu,
sino ms bien adaptar los cdigos ya definidos.
Por ejemplo, un comando como NOOP, cuya ejecucin exitosa hace

No ofrecer al cliente SMTP ninguna informacin nueva, devolver un 250
respuesta. La respuesta es 502 cuando el comando solicita una sin aplicarse
no especficos del sitio de accin. Un refinamiento de que es la respuesta 504
para
un comando que se ejecuta, sino que solicita una sin aplicarse
parmetro.

El texto de respuesta puede ser ms largo que una sola lnea; en estos casos
el
texto completo debe estar marcado por lo que el cliente SMTP sabe cuando puede
deje de leer la respuesta. Esto requiere un formato especial para indicar una
respuesta de varias lneas.
El formato de las respuestas de varias lneas requiere que todas las lneas,
excepto la
ltima, comenzar con el cdigo de respuesta, seguido inmediatamente por un
guin,
"-" (Tambin conocida como menos), seguido de un texto. La ltima lnea
comenzar con el cdigo de respuesta, seguido inmediatamente por <SP>,
opcionalmente
un poco de texto, y <CRLF>. Como se seal anteriormente, los servidores deben
enviar el <SP>
si el texto subsiguiente no se enva, pero los clientes deben estar preparados
para ello
a ser omitido.
Por ejemplo:
250-Primera lnea
250-Segunda lnea
250-234 texto que comienza con los nmeros
250 La ltima lnea
En una respuesta multilnea, el cdigo de respuesta en cada una de las lneas

debe ser el
mismo. Es razonable que el cliente se basan en esto, por lo que puedo
tomar decisiones de tratamiento basadas en el cdigo en cualquier lnea,
asumiendo
que todos los dems sern los mismos. En algunos casos, no es importante
los datos para el cliente en el "texto" respuesta. El cliente podr
identificar estos casos desde el contexto actual.
4.2.2. Cdigos de respuesta por grupos de las funciones
500 Error de sintaxis, Comando no reconocido (Esto puede incluir errores

como lnea de comandos demasiado larga)
501 Error de sintaxis en los parmetros o argumentos
502 Comando no implementado (vase la Seccin 4.2.4)
503 secuencia de comandos errnea
504 parmetro Comando no implementado
211 El estado del sistema, o sistema de ayuda respuesta
214 mensajes de ayuda (La informacin sobre cmo utilizar el receptor o el

significado de un comando en particular no estndar; esta respuesta es til
slo para el usuario humano)

220 <dominio> Servicio listo
221 <dominio> canal de transmisin de cierre Servicio

421 <dominio> servicio no est disponible, el cierre de canal de transmisin
(Esto puede ser una respuesta a cualquier comando si el servicio sabe que
debe
apagar)
250 Accin requerida bien, completado
251 Usuario no local; reenviar a <forward-path> (Vase la Seccin 3.4)
252 No se puede VRFY usuario, pero aceptar el mensaje y el intento de entrega

(Vase la Seccin 3.5.3)
455 Servidor incapaces de acomodar los parmetros
555 DE CORREO / RCPT TO parmetros no reconoce o no se ha implementado
450 Accin de correo solicitada no realizada: buzn no disponible (por

ejemplo,
buzn ocupado o bloqueado temporalmente por razones de poltica)
550 Accin no realizada: buzn no disponible (por ejemplo, el buzn

No se ha encontrado, sin acceso, o el comando rechazada por razones de
poltica)
451 accin solicitada anulada: error en el procesamiento
551 Usuario no local; Por favor, intente <forward-path> (Vase la Seccin 3.4)
452 Accin no realizada: insuficiente sistema de almacenamiento
552 accin requerida interrumpida: la asignacin de almacenamiento superado
553 Pidi medidas no adoptadas: nombre de buzn no permitido (por ejemplo,

sintaxis incorrecta buzn de correo)
354 Inicio de entrada de correo; terminar con <CRLF>. <CRLF>
554 Transaccin no (o, en el caso de una abertura de conexin

respuesta, "No hay servicio SMTP aqu")

4.2.3. Cdigos de respuesta en Orden numrico
211 El estado del sistema, o sistema de ayuda respuesta
214 mensajes de ayuda (La informacin sobre cmo utilizar el receptor o el

significado de un comando en particular no estndar; esta respuesta es til
slo para el usuario humano)
220 <dominio> Servicio listo
221 <dominio> canal de transmisin de cierre Servicio
250 Accin requerida bien, completado
251 Usuario no local; reenviar a <forward-path> (Vase la Seccin 3.4)
252 No se puede VRFY usuario, pero aceptar el mensaje y el intento de entrega

(Vase la Seccin 3.5.3)
354 Inicio de entrada de correo; terminar con <CRLF>. <CRLF>
421 <dominio> servicio no est disponible, el cierre de canal de transmisin

(Esto puede ser una respuesta a cualquier comando si el servicio sabe que
debe
apagar)
450 Accin de correo solicitada no realizada: buzn no disponible (por

ejemplo,
buzn ocupado o bloqueado temporalmente por razones de poltica)
451 accin solicitada anulada: error local en el procesamiento
452 Accin no realizada: insuficiente sistema de almacenamiento
455 Servidor incapaces de acomodar los parmetros
500 Error de sintaxis, Comando no reconocido (Esto puede incluir errores

como lnea de comandos demasiado larga)
501 Error de sintaxis en los parmetros o argumentos
502 Comando no implementado (vase la Seccin 4.2.4)
503 secuencia de comandos errnea
504 parmetro Comando no implementado
550 Accin no realizada: buzn no disponible (por ejemplo, el buzn

No se ha encontrado, sin acceso, o el comando rechazada por razones de
poltica)

551 Usuario no local; Por favor, intente <forward-path> (Vase la Seccin 3.4)
552 accin requerida interrumpida: la asignacin de almacenamiento superado
553 Pidi medidas no adoptadas: nombre de buzn no permitido (por ejemplo,

sintaxis incorrecta buzn de correo)
554 Transaccin no (o, en el caso de una abertura de conexin

respuesta, "No hay servicio SMTP aqu")
555 DE CORREO / RCPT TO parmetros no reconoce o no se ha implementado

4.2.4. Cdigo de respuesta 502
Se han planteado dudas acerca de cundo cdigo de respuesta 502 (Comando no

implementado) debe ser devuelto con preferencia a otros cdigos. 502
Se debe utilizar cuando el comando es en realidad reconocida por el SMTP
servidor, pero no se han aplicado. Si no se reconoce el comando, el cdigo de
500 deben ser devueltos. sistemas SMTP extendidos NO DEBEN lista
capacidades en respuesta a EHLO para los que van a regresar 502 (o
500) Respuestas.
4.2.5. Cdigos de respuesta luego de que datos y la posterior <CRLF>. <CRLF>
Cuando un servidor SMTP devuelve un estado de finalizacin positivo (cdigo

2yz)
despus de que el comando de datos se completa con <CRLF>. <CRLF>, se acepta
Responsabilidad para:
o la entrega del mensaje (si existe el buzn del destinatario), o
o si los intentos para entregar el mensaje fallan debido a transitorios

condiciones de volver a intentar la entrega, un nmero razonable de veces
en
intervalos que se especifican en la Seccin 4.5.4.
o si los intentos para entregar el mensaje fallan debido a la permanente

condiciones, o si intenta entregar el mensaje de falla repetidas
debido a las condiciones transitorias, volviendo a la notificacin
apropiada
el remitente del mensaje original (el uso de la direccin en el SMTP
comando MAIL).
Cuando un servidor SMTP devuelve un estado de error temporal (4yz) cdigo

despus
el comando de datos se completa con <CRLF>. <CRLF>, no se debe hacer una
subsecuente intento de entregar ese mensaje. El cliente SMTP conserva
responsabilidad por la entrega de dicho mensaje y tendr derecho a remitir
al usuario o requeue para un intento posterior (ver
Seccin 4.5.4.1).

El usuario que origin el mensaje debe ser capaz de interpretar la

devolucin de un estado de error transitorio (por mensaje de correo
electrnico o de otra manera)
como una indicacin de falta de entrega, al igual que un fallo permanente
sera
interpretado. Si el cliente SMTP maneja con xito estos
condiciones, el usuario no recibir una respuesta tan.
Cuando un servidor SMTP devuelve un estado de error permanente (5yz) cdigo

despus
el comando de datos se completa con <CRLF>. <CRLF>, no debe hacer
cualquier intento posterior de entregar el mensaje. Al igual que con temporal
cdigos de estado de error, el cliente SMTP siendo el responsable del
mensaje, pero no debera volver a intentar la entrega en el mismo servidor
sin revisin de usuario del mensaje y la respuesta y apropiado
intervencin.
4.3. La secuenciacin de Comandos y Respuestas
4.3.1. Descripcin general secuenciacin
La comunicacin entre el emisor y el receptor es una alterna

dilogo, controlado por el remitente. Como tal, emite un remitente
mando y el receptor responde con una respuesta. A menos que otra
acuerdos se negocian a travs de extensiones de servicio, el emisor
Debe esperar a que esta respuesta antes de enviar ms comandos. Uno
respuesta importante es el saludo de conexin. Normalmente, un receptor
enviar una "lista de servicio" respuesta 220 cuando la conexin es
terminado. El remitente es conveniente esperar a que este mensaje de saludo
antes
enviando los comandos.
Nota: todas las respuestas de tipo saludo tienen el nombre oficial (la
totalmente calificado nombre de dominio principal) de la mquina del servidor
como el primer
siguiente palabra del cdigo de respuesta. A veces, el anfitrin no tendr
nombre significativo. Vea la Seccin 4.1.3 para una discusin de alternativas
en estas situaciones.
Por ejemplo,
220 ISIF.USC.EDU Servicio listo
220 mail.example.com SuperSMTP v 6.1.2 Servicio listo
220 [10.0.0.1] servicio de alojamiento desorientado listo
La siguiente tabla muestra de xito y fracaso respuestas alternativas para

cada comando. Estos deben cumplirse estrictamente. Un receptor puede

texto sustituto en las respuestas, pero los significados y las acciones

implcitas
mediante los cdigos numricos y por la secuencia de comandos especfica
respuesta debe
ser preservado.
4.3.2. Las secuencias de comandos de respuesta
Cada comando est en la lista con sus respuestas habituales posibles. los
prefijos
utilizar antes de las posibles respuestas son "I" para el intermedio, "S" para
xito, y "E" para el error. Ya que algunos servidores pueden generar otra
respuestas en circunstancias especiales, y para permitir la futura
extensin, los clientes SMTP debe, siempre que sea posible, slo la
interpretacin de
primer dgito de la respuesta y deben estar preparados para hacer frente a
cdigos de respuesta no reconocidos por interpretar slo el primer dgito.
Menos que se extienda el uso de los mecanismos descritos en la seccin 2.2,
SMTP
servidores no debe transmitir cdigos de respuesta a un cliente de SMTP que se
aparte de tres dgitos o que no comienza por un dgito entre 2 y
5 inclusive.
Estas reglas de secuenciacin y, en principio, los cdigos en s mismos,

pueden
ser ampliada o modificada por las extensiones SMTP ofrecidos por el servidor y
aceptado (requerido) por el cliente. Sin embargo, si el objetivo es ms
granularidad precisa en los cdigos, en lugar de los cdigos para
completamente
nuevos propsitos, el sistema descrito en el RFC 3463 [25], debe ser
utilizados en
preferencia a la invencin de nuevos cdigos.
Adems de los cdigos que figuran a continuacin, cualquier comando SMTP puede
volver
cualquiera de los siguientes cdigos si las circunstancias inusuales que
corresponde
se encuentran:
500 Para la "lnea de comandos demasiado tiempo" caso o si el nombre del

comando era
no reconocido. Tenga en cuenta que la produccin de un "comando no
reconocido"
error en respuesta al subconjunto requerido de estos comandos es una
violacin de esta especificacin. Del mismo modo, la produccin de un
"comando
mensaje demasiado largo "para una lnea de comandos de menos de 512
caracteres
violara las disposiciones de la Seccin 4.5.3.1.4.
501 Error de sintaxis en comandos o argumentos. Con el fin de prever

futuras ampliaciones, los comandos que se especifican en este documento
como
argumentos que no aceptan (datos, RSET, QUIT) debe devolver un 501
mensaje si argumentos se suministran en la ausencia de EHLO-
extensiones anunciado.
421 Servicio de apagar y cerrar el canal de transmisin

secuencias especficas son:
establecimiento de la conexin
S: 220
E: 554
EHLO o HELO
S: 250
E: 504 (Una implantacin conforme podran devolver slo el cdigo
en los casos bastante oscuras), 550, 502 (permitido slo con un Antiguo-
servidor de estilo que no es compatible EHLO)
CORREO
S: 250
E: 552, 451, 452, 550, 553, 503, 455, 555
RCPT
S: 250, 251 (ver Seccin 3.4 para la discusin de los 251 y 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
DATOS
I: 354 -> Datos -> S: 250
E: 552, 554, 451, 452
E: 450, 550 (rechazos por razones de poltica)
E: 503, 554
RSET
S: 250
VRFY
S: 250, 251, 252

E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504

AYUDA
S: 211, 214
E: 502, 504
NOOP
S: 250
DEJAR
S: 221
4.4. Informacin de seguimiento

Cuando un servidor SMTP recibe un mensaje para entrega o ms
procesamiento, se debe insertar trace ( "marca de tiempo" o "Recibido")
informacin al principio del contenido del mensaje, como se discute en
Seccin 4.1.1.4.
Esta lnea debe estar estructurado de la siguiente manera:
o La clusula FROM, que debern presentarse en un entorno SMTP,

Debe contener tanto (1) el nombre del host de origen tal como se presenta
en el comando EHLO y (2) una direccin IP que contiene el literal
direccin de la fuente, determinado a partir de la conexin TCP.
o La clusula de ID puede contener un "@" como se sugiere en el RFC 822, pero

esto
no es requerido.
o Si aparece la clusula FOR, que deber contener exactamente un <ruta>

entrada, incluso cuando se han dado mltiples comandos RCPT. Mltiple
<Ruta> s plantean algunos problemas de seguridad y han quedado en desuso,
ver
Seccin 7.2.
Un programa de correo de Internet no debe cambiar o eliminar una lnea

Received:
que previamente se aadi a la seccin de encabezado del mensaje. SMTP
los servidores DEBEN Anteponer lneas a los mensajes recibidos; No deben
cambiar
el orden de las lneas existentes o lneas Recibido de insercin en cualquier
otra
ubicacin.
A medida que Internet crece, la comparabilidad de los campos de cabecera

recibida se
importante para detectar problemas, rels especialmente lentas. SMTP
servidores que crean Recibidos campos de cabecera DEBE uso explcito
compensaciones en las fechas (por ejemplo, -0800), en lugar de nombres de zona
horaria de
cualquier tipo. hora local (con un desplazamiento) se debe utilizar en lugar
de UT
cuando sea factible. Esta formulacin permite un poco ms informacin
circunstancias locales sobre el que se especifiquen. Si se necesita UT, la

receptor basta con hacer un poco de aritmtica simple para convertir los
valores.
El uso de UT pierde informacin sobre la zona horaria en la localizacin de la
servidor. Si se desea proporcionar un nombre de zona horaria, cabe
incluido en un comentario.
Cuando el servidor SMTP de entrega hace que la "entrega final" de una

mensaje, se inserta una lnea ruta de retorno al inicio del correo
datos. Se requiere este uso de la ruta de retorno; sistemas de correo debe ser
compatible
eso. La lnea de la ruta de retorno conserva la informacin en el <inversa
ruta> en el comando MAIL. En este caso, la entrega final significa el mensaje
ha dejado el entorno SMTP. Normalmente, esto significara que haba sido
entregado al usuario de destino o una gota de correo asociada, pero en
algunos casos puede ser procesada posteriormente y transmitidos por otro
sistema de correo.
Es posible que el buzn de correo en el camino de retorno sea diferente

de buzn de correo del remitente real, por ejemplo, si las respuestas de error
son
para ser entregado a un buzn especial el tratamiento de errores en lugar de
el remitente del mensaje. Cuando las listas de distribucin estn
involucrados, este
disposicin es comn y til como un medio de dirigir errores a
mantenedor de la lista en lugar del autor del mensaje.
El texto anterior implica que los datos de correo finales comenzarn con una
volver lnea de recorrido, seguido de una o ms lneas de indicacin de
tiempo. Estas
lneas sern seguidos por el resto de los datos de correo: la primera
equilibrio de la seccin de encabezado de correo y luego el cuerpo (RFC 5322
[4]).
A veces es difcil para un servidor SMTP para determinar si

No se est haciendo la entrega final desde reenvo u otras operaciones
puede ocurrir despus del mensaje es aceptado para la entrega. Por
consiguiente,
ms lejos (reenvo, puerta de enlace, o rel) Los sistemas pueden quitar el
va de retorno y reconstruir el comando MAIL segn sea necesario para asegurar
que
exactamente una tal lnea aparece en un mensaje entregado.
Un sistema SMTP mensaje originario no debe enviar un mensaje de que

ya contiene un campo de cabecera Return-path. Los servidores SMTP que realizan
una funcin de rel no deben inspeccionar los datos del mensaje, y
especialmente
no en la medida necesaria para determinar si los campos de cabecera ruta de
retorno
estn presentes. Los servidores SMTP haciendo entrega final podr eliminar
Regresar-
campos de cabecera camino antes de aadir su propio.
El propsito principal de la devolucin de la ruta es para designar la

direccin de
qu mensajes que indican la falta de entrega u otros fallos del sistema
electrnico
han de ser enviados. Para que esto sea inequvoca, exactamente un trayecto de
retorno
Deben estar presentes cuando se entrega el mensaje. Los sistemas que utilizan
RFC
822 de sintaxis con los medios de transporte que no son SMTP debe designar a
una inequvoca
direccin, asociado con el sobre de transporte, a la que error
informes (por ejemplo, mensajes de no entrega) deben ser enviados.

Nota histrica: El texto en el RFC 822 que parece contradecir el uso

del campo de cabecera de retorno de la ruta (o la ruta de la direccin inversa
envolvente
desde el comando MAIL) como el destino de los mensajes de error no es
aplicable en Internet. La direccin de la ruta inversa (como copia en
Return-path) DEBE ser utilizado como blanco de cualquier correo que contiene
mensajes de error de entrega.
En particular:
puerta de entrada de la OA SMTP -> otra parte debe insertar una ruta de
retorno
campo de encabezado, a menos que se sabe que el transporte "en otro lugar"
tambin utiliza direcciones de dominio de Internet y mantiene el sobre
direccin del remitente por separado.
pasarela de OA de otra parte -> SMTP debe eliminar cualquier ruta de retorno
campo de encabezado en el mensaje, y cualquiera de las copias que se
informacin para el sobre SMTP o combinarla con la informacin
presente en el sobre del otro sistema de transporte para construir
el argumento de la ruta inversa al comando de correo en el SMTP
sobre.
El servidor debe dar un trato especial a los casos en los que el

procesamiento despus de la indicacin de final de datos de correo es
solamente
un xito parcial. Esto podra ocurrir si, despus de aceptar varias
receptores y los datos de correo, el servidor SMTP determina que el correo
los datos se podran entregar con xito para algunos, pero no todos, de la
destinatarios. En tales casos, la respuesta a la orden de datos debe ser
una respuesta OK. Sin embargo, el servidor SMTP debe redactar y enviar una
mensaje de notificacin "correo no entregado" al autor de la
mensaje.
Una sola notificacin lista de todos los destinatarios que no o

mensajes de notificacin aisladas, debern ser enviados por cada fallido
recipiente. Para la economa de la transformacin por el remitente, el antiguo
Debe utilizarse cuando sea posible. Tenga en cuenta que la diferencia clave
entre
alias de manejo (Seccin 3.9.1) y expedicin (es) esta subseccin
el cambio en la direccin de retroceso que apunta en este caso. Todas
mensajes de notificacin sobre correo no entregado DEBEN ser enviado a travs
de la
comando MAIL (incluso si se obtiene del procesamiento SEND obsoleta,
SOML, o SAML comandos) y debe utilizar una va de retorno nulo como se ha
discutido
en la Seccin 3.6.
El registro de hora y la lnea de va de retorno se definen formalmente como

de la siguiente manera (las definiciones de "FWS" y "CFWS" aparecen en el RFC
5322
[4]):
Return-path-line = "Return-Path:" FWS Reverse-ruta <CRLF>
Sello de tiempo-line = "Recibido:" FWS sello <CRLF>

Sello = Desde el dominio de Al-dominio Opt-info [CFWS] ";"

FWS fecha-hora
; donde "fecha y hora" es como se define en el RFC 5322 [4]
; pero las formas "Obs-", especialmente de dos dgitos
; aos, estn prohibidos en SMTP y no debern ser utilizados.
De-domain = "FROM" FWS-extendido de dominio
Por-domain = CFWS "A" FWS-extendido de dominio
Extended-domain = Dominio /
(Dominio FWS "(" TCP-info ")") /
(Direccin-FWS literal "(" TCP-info ")")
TCP-info = direccin literal / (Dominio FWS direccin literal)

; La informacin derivada por el servidor de la conexin TCP
; No EHLO cliente.
Opt-info = [Va] [Con] [ID] [Para]

[Adicional-registrada-Clusulas]
Via = CFWS "VIA" FWS Enlace
Con CFWS = "por" Protocolo FWS
ID = "ID" CFWS FWS (Atom / msg-id)

; msg-id se define en el RFC 5322 [4]
Para CFWS = "FOR" FWS (el camino / Buzn)
-Clusulas adicionales registrados = CFWS Atom FWS Cadena

; clusulas adicionales pueden ser estndar
aadido en este
; ubicacin de las futuras normas y
la inscripcin en
; IANA. Los servidores SMTP no debe usar
no registrado
; nombres. Vase la Seccin 8.
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; nombres estndar adicionales para los enlaces son
; inscrito en la Internet Assigned Numbers
; (IANA). "Va" es principalmente valiosos
; con los medios de transporte que no utilizan Internet. Los
servidores SMTP
; No deben utilizar nombres no registrados.

Protocolo = "ESMTP" / "SMTP" / Attdl-Protocolo
Attdl-Protocolo = Atom
; nombres estndar adicionales para protocolos son
; inscrito en la Internet Assigned Numbers
; (IANA) en los "parmetros de correo"
; Registro [9]. Los servidores SMTP NO DEBE
; utilizar nombres no registrados.
4.5. Problemas adicionales de aplicacin

4.5.1. Implementacin mnimo
Con el fin de hacer viable SMTP, la siguiente implementacin mnimo

Debe ser proporcionada por todos los receptores. Los siguientes comandos deben
el apoyo para cumplir con esta especificacin:
EHLO
HELO
CORREO
RCPT
DATOS
RSET
NOOP
DEJAR
VRFY
Cualquier sistema que incluye un servidor SMTP apoyo o la retransmisin de

correo
entrega debe apoyar el buzn "postmaster" reservado como un caso-
nombre local insensibles. Esta direccin de administrador de correo no es
estrictamente
necesario si el servidor siempre devuelve 554 en la abertura de conexin (como
se
se describe en la Seccin 3.1). El requisito para aceptar correo
administrador de correo implica que RCPT comandos que especifican un buzn
para
postmaster en cualquiera de los dominios para los que el servidor SMTP ofrece
servicio de correo, as como el caso especial de "RCPT TO: <administrador de
correo>"
(Sin especificacin de dominio), debe ser apoyada.
Se espera que los sistemas de SMTP para hacer todos los esfuerzos razonables
para aceptar
correo dirigido a Postmaster de cualquier otro sistema en el Internet.
En casos extremos - como para contener un ataque de denegacin de servicio o
otra violacin de seguridad - un servidor SMTP puede bloquear el correo
dirigido a
Administrador de correos. Sin embargo, estas medidas deberan delimitar
estrictamente
a fin de evitar mensajes que no son parte de este tipo de ataques de bloqueo.

4.5.2. Transparencia
Sin alguna provisin para la transparencia de datos, la secuencia de

caracteres
"<CRLF>. <CRLF>" termina el texto electrnico y no puede ser enviado por el
usuario.
En general, los usuarios no son conscientes de tales secuencias "prohibidos".
A
permitir que todo el texto compuesta por el usuario que se transmiten de forma
transparente, la
Se utilizan procedimientos siguientes:
o Antes de enviar una lnea de texto electrnico, el cliente comprueba el SMTP

primer carcter de la lnea. Si se trata de un perodo, uno adicional
se inserta perodo al comienzo de la lnea.
o Cuando una lnea de texto electrnico es recibido por el servidor SMTP, se

comprueba
la lnea. Si la lnea se compone de un solo perodo, es
tratado como el final del indicador de correo. Si el primer carcter es una
perodo y hay otros caracteres de la lnea, la primera
Se suprime el carcter.
Los datos de correo pueden contener cualquiera de los 128 caracteres ASCII.
Todas
personajes han de ser entregadas al buzn del destinatario, incluyendo
espacios, tabulaciones verticales y horizontales, y otros caracteres de
control.
Si el canal de transmisin proporciona un byte de 8 bits (octetos) de datos
corriente, los cdigos ASCII de 7 bits se transmiten, justificado a la
derecha, en
los octetos, con los bits de orden borran a cero. Ver
Seccin 3.6 para obtener un tratamiento especial de estas enfermedades en los
sistemas de SMTP
cumpliendo una funcin de rel.
En algunos sistemas, puede ser necesario para transformar los datos, ya que es
recibido y almacenado. Esto puede ser necesario para aquellas mquinas que
utilizan una
diferente conjunto de caracteres ASCII que como su juego de caracteres local,
almacenar datos en los registros en lugar de cadenas, o que utilizan especial
secuencias de caracteres como delimitadores dentro de los buzones. Si tal
transformaciones son necesarias, que deben ser reversibles, especialmente si
que se aplicar al correo que es retransmitida.
4.5.3. Tamaos y tiempos de espera
4.5.3.1. Lmites de tamao y mnimos
Hay varios objetos que han requerido mnimos / mximos tamaos.

Cada aplicacin deber ser capaz de recibir objetos de al menos
estos tamaos. Los objetos ms grandes que estos tamaos se debe evitar cuando
posible. Sin embargo, algunos de correo de Internet construye como codificada
direcciones X.400 (RFC 2156 [35]) mayor a los mismos objetos de mayor tamao.
Los clientes pueden intentar transmitir estos, pero debe estar preparado para
una
servidor de rechazarlas si no pueden ser manejados por el mismo. Al
posibles tcnicas de mxima extensin, la aplicacin que imponen sin
lmites en la longitud de estos objetos deben ser utilizados.

Las extensiones a SMTP pueden implicar el uso de caracteres que ocupan ms

de un solo octeto cada uno. Por lo tanto, esta seccin se especifican las
longitudes
en octetos donde las longitudes absolutas, en lugar de caracteres que cuenta,
son
destinado a.
4.5.3.1.1. Parte-local
La longitud total mxima de un nombre de usuario u otra parte local es 64

octetos.
4.5.3.1.2. Dominio
La longitud total mxima de un nombre de dominio o el nmero es de 255

octetos.
4.5.3.1.3. Camino
La longitud total mxima de una ruta de retroceso o avance de la ruta es de

256
octetos (incluyendo los separadores y elementos de puntuacin).
4.5.3.1.4. Lnea de comando
La longitud total mxima de una lnea de comandos que incluye la palabra de

comando
y el <CRLF> es de 512 octetos. extensiones SMTP se pueden utilizar para
aumentar este lmite.
4.5.3.1.5. Responder Lnea
La longitud total mxima de una lnea de respuesta incluyendo el cdigo de

respuesta y
el <CRLF> es de 512 octetos. Ms informacin puede ser transmitida a travs de
-Line mltiples respuestas.
4.5.3.1.6. Lnea de texto
La longitud total mxima de una lnea de texto que incluye el <CRLF> es de

1000
octetos (sin contar el punto inicial para la transparencia duplicado).
Este nmero puede aumentarse por el uso de extensiones de servicio SMTP.
4.5.3.1.7. Contenido del mensaje
La longitud total mxima de un contenido del mensaje (incluyendo cualquier

mensaje
seccin de cabecera, as como el cuerpo del mensaje) debe ser al menos 64 K
octetos. Desde la introduccin de normas de Internet para aplicaciones
multimedia
electrnico (RFC 2045 [21]), longitudes de mensaje en Internet han crecido
de manera espectacular, y las restricciones de tamao de mensaje debe ser
evitado si al
todo posible. sistemas de servidor SMTP que debe imponer restricciones
Conveniente aplicar el "tamao" de extensin de servicio de la RFC 1870 [10],
y
sistemas cliente SMTP que enviarn mensajes de gran tamao se deben utilizar
cuando sea posible.

4.5.3.1.8. Los destinatarios de bfer

El nmero mnimo total de destinatarios que se tienen que guardar es 100
destinatarios. El rechazo de mensajes (para los receptores excesiva)
menos de 100 comandos RCPT es una violacin de esta especificacin.
El principio general de que la retransmisin del servidor SMTP NO DEBE, y
Los servidores SMTP de entrega no debe, realizar pruebas de validacin en el
mensaje
campos de cabecera sugiere que los mensajes no debern rechazarse basan en
el nmero total de receptores se muestran en los campos de cabecera. Un
servidor que
impone un lmite en el nmero de destinatarios deben comportarse de una manera
ordenada
moda, tales como el rechazo de direcciones adicionales encima de su lmite ms
de silencio descartar direcciones previamente aceptada. Un cliente
que tiene que entregar un mensaje que contiene ms de 100 comandos RCPT
Debe estar preparado para transmitir en 100 receptores de "trozos" si el
servidor se niega a aceptar ms de 100 destinatarios en una sola
mensaje.
4.5.3.1.9. Tratamiento Cuando se superan los lmites
Errores debidos a la superacin de estos lmites pueden ser reportados

mediante el uso de la
cdigos de respuesta. Algunos ejemplos de cdigos de respuesta son:
500 Lnea demasiado tiempo.
501 Camino demasiado largo
452 demasiados destinatarios (vase ms adelante)
552 datos de correo demasiado.
4.5.3.1.10. Demasiados destinatarios Cdigo
RFC 821 [1] de forma incorrecta aparece el error en un servidor SMTP

agota su lmite de aplicacin sobre el nmero de comandos RCPT
( "demasiados destinatarios") como que tiene cdigo de respuesta 552. La
respuesta correcta
cdigo para esta condicin es 452. Los clientes deben tratar a un cdigo 552
en
este caso como temporal, en lugar de permanente, insuficiencia de modo que la
lgica
a continuacin funciona.
Cuando un servidor SMTP conforme se encuentra con esta condicin, tiene por lo
Comandos menos 100 RCPT xito en su memoria intermedia destinatarios. Si el
servidor es capaz de aceptar el mensaje, entonces por lo menos estos 100

direcciones sern eliminados de la cola del cliente SMTP. Cuando el

cliente intenta la retransmisin de esas direcciones que recibieron 452
respuestas, al menos 100 de estos sern capaces de encajar en el SMTP
receptores de servidor de amortiguamiento. Cada intento de retransmisin que
es capaz
para entregar nada va a poder disponer de al menos 100 de ellas
destinatarios.
Si un servidor SMTP tiene un lmite de aplicacin sobre el nmero de RCPT

comandos y este lmite se ha agotado, se debe utilizar un cdigo de respuesta
452 (pero el cliente tambin debe estar preparado para un 552, como se ha
sealado
encima). Si el servidor tiene una limitacin en polticas sitio configurado en
el
nmero de comandos RCPT, en su lugar puede utilizar un cdigo de respuesta
5yz. En
en particular, si la intencin es prohibir mensajes con ms de una
El sitio especificado por el nmero de destinatarios, en lugar de simplemente
limitar el
nmero de destinatarios en una transaccin de correo en concreto, sera
razonable para devolver una respuesta 503 a cualquier comando de datos
recibidos
posterior al cdigo 452 (o 552) o simplemente para devolver el 503 despus de
Datos sin devolver cualquier respuesta negativa anterior.
4.5.3.2. Tiempos de espera
Un cliente SMTP debe proporcionar un mecanismo de tiempo de espera. Se deber

utilizar per-
comando tiempos de espera en lugar de alguna manera tratando de tiempo de todo
el correo
transaccin. Tiempos de espera debe ser fcilmente reconfigurable,
preferiblemente
sin recompilar el cdigo de SMTP. Para implementar esto, se ajusta un
temporizador
para cada comando SMTP y para cada uno de amortiguamiento de la transferencia
de datos. los
Esto ltimo significa que el tiempo de espera total es inherentemente
proporcional a
el tamao del mensaje.
Sobre la base de una amplia experiencia con los ejrcitos ocupados-rel

electrnico, el mnimo
por mando valores de tiempo de espera debe ser como sigue:
4.5.3.2.1. 220 Mensaje inicial: 5 Minutos
Un proceso de cliente SMTP necesita distinguir entre un TCP fallado

conexin y un retraso en la recepcin del mensaje 220 saludo inicial.
Muchos servidores SMTP aceptan una conexin TCP, pero retrasan la entrega de
la
220 mensajes hasta que su carga del sistema permite que ms correo para estar
procesada.
4.5.3.2.2. CORREO Comando: 5 Minutos
4.5.3.2.3. RCPT comandos: 5 Minutos
Se requiere un tiempo de espera mayor si el procesamiento de listas de correo

y
los alias no se pospone hasta despus de que el mensaje fue aceptado.
4.5.3.2.4. DATOS Iniciacin: 2 Minutos
Esta es la espera de la respuesta "354 La entrada de inicio" a un comando de

datos.
4.5.3.2.5. Bloque de datos: 3 Minutos
Esta es la espera de la finalizacin de cada llamada de envo de TCP

la transmisin de un bloque de datos.
4.5.3.2.6. Terminacin DATOS: 10 Minutos.
Esta es la espera de la respuesta "250 OK". Cuando el receptor recibe

el perodo final de conclusin los datos del mensaje, que por lo general lleva
a cabo
de proceso para entregar el mensaje a un buzn de usuario. Un espuria
tiempo de espera en este punto sera un gran desperdicio y lo hara
normalmente
provocar la administracin de mltiples copias del mensaje, ya que tiene
sido enviado con xito y el servidor ha aceptado la responsabilidad de
entrega. Vea la Seccin 6.1 para un anlisis adicional.
4.5.3.2.7. Tiempo de espera del servidor: 5 minutos.
Un servidor SMTP DEBE tener un tiempo de espera de al menos 5 minutos,

mientras que
se espera que el siguiente comando desde el emisor.
4.5.4. Estrategias reintentar
La estructura comn de una aplicacin host SMTP, incluidos los usuarios

buzones de correo, una o ms reas para poner en cola los mensajes en
trnsito, y una
o ms procesos demonio para enviar y recibir correo. El exacto
estructura variar en funcin de las necesidades de los usuarios en el host
y el nmero y tamao de las listas de distribucin soportados por el
anfitrin. Nosotros
describir varias optimizaciones que han demostrado ser tiles, en particular
para los anuncios publicitarios que apoyan altos niveles de trfico.
Cualquier estrategia de la cola DEBE incluir tiempos de espera en todas las

actividades en una
funcin de cada comando. Una estrategia de la cola no debera enviar mensajes
de error
en respuesta a mensajes de error en cualquier circunstancia.
4.5.4.1. Envo de Estrategia
El modelo general para un cliente SMTP es uno o ms procesos que

intentar peridicamente para transmitir el correo saliente. En un sistema
tpico,
el programa que compone un mensaje tiene algn mtodo para solicitar
atencin inmediata para una nueva pieza de correo saliente, mientras que el
correo que
no puede ser transmitida de inmediato deben estar en cola y peridicamente
juzgado por el remitente. Una entrada de cola de correo incluir no slo el
mensaje en s mismo sino tambin la informacin sobre.

El remitente deber volver a intentar retrasar un destino en particular

despus de una
intento ha fracasado. En general, el intervalo de reintento debe ser por lo
menos 30 minutos; estrategias sin embargo, ms sofisticados y variables
ser beneficioso cuando el cliente SMTP puede determinar la razn de
sin envio.
Reintentos continan hasta que se transmite el mensaje o el remitente da

arriba; el tiempo give-up por lo general tiene que ser por lo menos 4-5 das.
Puede
es conveniente establecer un nmero mximo de reintentos ms corto para no
notificaciones de entrega y mensajes de error que para los equivalentes
mensajes estndar. Los parmetros para el algoritmo de reintentos DEBE estar
configurable.
Un cliente es conveniente mantener una lista de hosts que no podra llegar y

los tiempos de espera de conexin correspondiente, en lugar de volver a
intentar la cola
elementos de correo.
La experiencia sugiere que las fallas son normalmente transitoria (el objetivo
sistema o su conexin se ha estrellado), favoreciendo una poltica de dos
los intentos de conexin en la primera hora del mensaje est en la cola,
y luego dar marcha atrs a una vez cada dos o tres horas.
El cliente SMTP puede acortar el retardo de cola en cooperacin con el

servidor SMTP. Por ejemplo, si el correo se recibe de un particular,
direccin, es probable que el correo en cola para que anfitrin ahora pueden
enviarse.
La aplicacin de este principio puede, en muchos casos, eliminar la
exigencia de una funcin explcita "enviar colas ahora" como ETRN,
RFC 1985 [36].
La estrategia puede ser modificado adicionalmente como resultado de mltiples

direcciones por host (vase ms adelante) para optimizar el tiempo de entrega
contra
el uso de recursos.
Un cliente SMTP puede tener una gran cola de mensajes para cada
host de destino no est disponible. Si todos estos mensajes fueron juzgados de
nuevo
en cada ciclo de reintento, no habra exceso de sobrecarga de Internet y
el sistema de envo sera bloqueado por un largo perodo. Tenga en cuenta que
una
cliente SMTP generalmente puede determinar que un intento de entrega tiene
no slo despus de un tiempo de espera de varios minutos, e incluso a un
minuto
tiempo de espera por conexin resultar en un muy gran retraso si reintentos
se repiten para docenas o incluso cientos, de los mensajes en cola en el
mismo host.
Al mismo tiempo, los clientes SMTP es conveniente utilizar gran cuidado en el

almacenamiento en cach
respuestas negativas de los servidores. En un caso extremo, si es EHLO
emitido varias veces durante la misma conexin SMTP, diferente
respuestas pueden ser devueltos por el servidor. Ms significativamente, 5yz
respuestas al comando MAIL NO DEBEN ser almacenados en cach.

Cuando un mensaje de correo se va a entregar a varios destinatarios, y

el servidor SMTP al que se va a enviar una copia del mensaje es el
mismo para varios destinatarios, a continuacin, slo una copia del mensaje
Debe transmitirse. Es decir, el cliente SMTP deben utilizar el
secuencia de comandos: MAIL, RCPT, RCPT, ..., RCPT, DATA en lugar de la
secuencia: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. Sin embargo, si hay
son muy muchas direcciones, un lmite en el nmero de comandos RCPT por
comando de correo imponerse. Esta caracterstica eficacia debera
implementado.
Del mismo modo, para lograr la entrega a tiempo, el cliente SMTP puede apoyar
mltiples transacciones de correo salientes simultneas. Sin embargo, un
lmite
puede ser apropiado para proteger al husped de dedicar toda su
recursos para enviar por correo.
4.5.4.2. Recepcin de Estrategia
El servidor SMTP DEBE intento de mantener una pendiente de escuchar en el SMTP

puerto (especificado por IANA como el puerto 25) en todo momento. Esto
requiere que el
soporte de mltiples conexiones TCP entrantes para SMTP. algunos limitan
Podr imponerse, pero los servidores que no pueden manejar ms de un SMTP
transaccin a la vez no estn en conformidad con la intencin de esta
especificacin.
Como se discuti anteriormente, cuando el servidor SMTP recibe el correo de

una
particular, direccin de host, podra activar su propia puesta en cola SMTP
mecanismos que vuelva a intentar cualquier correo en espera de que la
direccin del host.
4.5.5. Los mensajes con un nulo Reverse-Path
Hay varios tipos de mensajes de notificacin que son requeridos por

Normas existentes y propuestos que se enviar con un nulo ruta inversa,
a saber, las notificaciones de no entrega como se discute en la Seccin 3.7,
otros
tipos de notificaciones de estado de entrega (DSN, RFC 3461 [32]), y
Message Disposition Notifications (MDN, RFC 3798 [37]). Todo
este tipo de mensajes son notificaciones acerca de un mensaje anterior,
y que se envan a la trayectoria inversa del mensaje de correo anterior.
(Si la entrega de un mensaje de notificacin falla, que por lo general
indica un problema con el sistema de correo del host al cual
se dirige el mensaje de notificacin. Por esta razn, en algunos hosts
el MTA est configurado para reenviar dichos mensajes de notificacin a
fallidos
alguien que es capaz de solucionar los problemas con el sistema de correo, por
ejemplo, a travs de
el alias del administrador de correo.)
Todos los dems tipos de mensajes (es decir, cualquier mensaje que no se
requiere
por un RFC normas de va para tener un camino inverso-null) deben ser enviados
con una, no nulo inversa ruta vlida.

Los ejecutores de los procesadores de correo electrnico automatizados deben

tener cuidado de hacer
Asegrese de que los diversos tipos de mensajes con un inverso de la ruta nula
son
se maneja correctamente. En particular, dichos sistemas no deberan responder
a
mensajes con un nulo reverse-path, y no deberan aadir un no nulo
reverse-path, o cambiar una ruta inversa nula a uno que no sea nulo, a
ese tipo de mensajes para el reenvo.
5. Resolucin de Direccin y Gestin de correo
5.1. Localizar el host de destino
Una vez que un cliente SMTP identifica lxico un dominio para que el correo se
ser entregados a la transformacin (como se describe en las secciones 2.3.5 y
3.6),
una bsqueda de DNS se deben realizar para resolver el nombre de dominio (RFC
1035
[2]). Se espera que los nombres que los nombres de dominio totalmente
calificados
(FQDN): mecanismos para inferir FQDN de nombres parciales o locales
alias se encuentran fuera de esta especificacin. Debido a una historia de
problemas, los servidores SMTP utilizan para la presentacin inicial de los
mensajes deben
NO hacer tales inferencias (servidores de envo de mensajes [18] han
algo ms de flexibilidad) y SMTP intermedio (rel) Los servidores deben
NO hacerlos.
Las operaciones de bsqueda intenta localizar primero en un registro MX

asociado a la
nombre. Si se encuentra un registro CNAME, el nombre resultante se procesa
como
si fuera el nombre inicial. Si un error de dominio es inexistente
devuelto, esta situacin debe ser informado como un error. Si una
Se devuelve error temporal, el mensaje debe ser puesto en cola y vuelve a
intentar
ms tarde (vase la Seccin 4.5.4.1). Si se devuelve una lista vaca de MX,
la direccin se trata como si se asoci con un MX implcito
RR, con una preferencia de 0, sealando que host. Si los registros MX son
presentes, pero ninguno de ellos son utilizables, o el MX implcito es
inservible,
Esta situacin debe ser informado como un error.
Si se encuentran uno o ms registros de recursos MX para un nombre dado,

sistemas SMTP debe
NO utilizar cualquier registro de recursos de direcciones asociadas con ese
nombre a menos que sean
ubicada utilizando los RR MX; la regla "implcita MX" anterior slo se aplica
si no hay registros MX actuales. Si los registros MX estn presentes, pero
ninguno de ellos estn disponibles, esta situacin debe ser informado como un
error.
Cuando un nombre de dominio asociado a un MX RR se alz la vista y la

campo de datos asociado obtenido, el campo de datos de esa respuesta debe
contener un nombre de dominio. Ese nombre de dominio, cuando se les pregunta,
deber devolver
al menos un registro de direccin (por ejemplo, A o RR AAAA) que da la IP
direccin del servidor SMTP al que el mensaje debe ser dirigido.
Cualquier otra respuesta, incluyendo especficamente un valor que devolver
una
registro CNAME cuando se les pregunta, se encuentra fuera del alcance de esta
Norma.
La prohibicin de las etiquetas en los datos que se resuelve en CNAMEs es
discute con ms detalle en el documento RFC 2181, Seccin 10.3 [38].

Cuando la bsqueda tiene xito, el mapeo puede resultar en una lista de

direcciones de entrega alternativos en lugar de una sola direccin, ya
de mltiples registros MX, varios hosts, o ambas cosas. Para proporcionar
confiable
la transmisin de correo, el cliente SMTP debe ser capaz de tratar (y volver a
intentar)
cada una de las direcciones pertinentes en esta lista en orden, hasta que una
intento de entrega tiene xito. Sin embargo, tambin puede ser un configurable
limitar el nmero de direcciones alternativas que se pueden probar. En
cualquier
caso, el cliente SMTP debera probar al menos dos direcciones.
Dos tipos de informacin se utilizan para clasificar las direcciones de host:

varios registros MX y los hosts mltiples.
Los registros MX contienen una indicacin de la preferencia que debe

utilizarse en
clasificacin si aparece ms de uno de dichos registros (vase ms adelante).
Inferior
nmeros son ms preferidos que los superiores. Si hay mltiples
destinos con la misma preferencia y no hay una clara razn para
favorecer a uno (por ejemplo, mediante el reconocimiento de una direccin de
fcil acceso), a continuacin,
el remitente-SMTP debe cambiar aleatoriamente a difundir la carga a travs
varios intercambiadores de correo para una organizacin especfica.
El host de destino (tal vez tomada del registro MX preferido) puede

multiproveedor, en cuyo caso el nombre de dominio solucionador devolver un
lista de direcciones IP alternativas. Es responsabilidad de la
Interfaz de resolucin de nombres de dominio de haber ordenado esta lista
preferencia decreciente, si es necesario, y el remitente SMTP debe probarlos
en el orden indicado.
Aunque la capacidad de probar varias direcciones alternativas es

se requieren instalaciones especficas, pueden querer limitar o desactivar el
uso
direcciones de alternativas. La cuestin de si un remitente es conveniente
reintentos intento de utilizar las diferentes direcciones de un host mltiple
ha sido motivo de controversia. El argumento principal para usar el mltiplo
direcciones es que maximiza la probabilidad de entrega oportuna,
y de hecho a veces la probabilidad de cualquier entrega; el contador-
argumento es que puede resultar en el uso de recursos innecesarios. Nota
que el uso de recursos tambin est fuertemente determinada por la estrategia
de enviar
discuti en la Seccin 4.5.4.1.
Si un servidor SMTP recibe un mensaje con un destino para el que se

Es un intercambio de correo designado, se puede retransmitir el mensaje
(potencialmente
despus de haber reescrito MAIL FROM y / o RCPT TO direcciones), hacer
la entrega final del mensaje, o entregarlos fuera utilizando algn mecanismo
fuera del entorno de transporte SMTP-proporcionada. Por supuesto, ni
de este ltimo requiere que la lista de registros MX examinarse
promover.
Si se determina que debe retransmitir el mensaje sin reescribir

la direccin, que deber ordenar los registros MX para determinar los
candidatos a

entrega. Los registros estn clasificadas por primera preferencia, con el

registros de los nmeros ms bajos siendo los ms preferidos. El rel debe
alojar
luego inspeccione la lista para cualquiera de los nombres o direcciones por el
cual se
podra ser conocido en las transacciones de correo. Si se encuentra un
registro coincidente,
todos los registros en ese nivel de preferencia y los nmeros ms altos DEBEN
estar
desechado de la consideracin. Si no hay registros que quedan en ese
punto, es una condicin de error, y el mensaje debe volver como
no se puede entregar. Si los registros no se mantienen, deberan ser juzgados,
el mejor
preferencia primero, como se describe anteriormente.
5.2. IPv6 y los registros MX
En Internet contempornea, clientes y servidores SMTP pueden estar alojados

en los sistemas IPv4, IPv6, sistemas o sistemas de doble pila que son
compatible con ya sea la versin del Protocolo de Internet. El anfitrin
dominios a los que MX punto de registros pueden, por lo tanto, contener s "Un
RR"
(IPv4), "AAAA" RR s (IPv6), o cualquier combinacin de ellos. mientras RFC
3974 [39] discute alguna experiencia operativa en entornos mixtos
ambientes, no fue lo suficientemente amplio como para justificar
la normalizacin, y algunas de sus recomendaciones parecen ser
incompatibles con esta especificacin. Las medidas adecuadas que deban
tomada ya sea depender de las circunstancias locales, tales como el
rendimiento
de las redes pertinentes y las conversiones que pudieran ser necesarias,
o sern obvios (por ejemplo, un slo IPv6 cliente no necesita intentar
Busque un RR o intentar llegar a los servidores slo IPv4). Los diseadores de
SMTP implementaciones que puedan circular en IPv6 o de doble pila
ambientes deben estudiar los procedimientos anteriores, especialmente la
comentarios acerca de los hosts mltiples, y, preferiblemente, proporcionar
mecanismos
para facilitar la sintonizacin de funcionamiento y la interoperabilidad entre
correo
sistemas IPv4 e IPv6, mientras que teniendo en cuenta las circunstancias
locales.
6. Deteccin de problemas y Manipulacin
6.1. Entrega fiable y Respuestas de correo electrnico
Cuando el receptor-SMTP acepta una pieza de correo (mediante el envo de un

"250 OK"
mensaje en respuesta a datos), se est aceptando la responsabilidad de
entregar o retransmitir el mensaje. Se debe tomar esta responsabilidad
seriamente. Que no hay que perder el mensaje por razones frvolas, tales
como porque el host se bloquea despus o debido a una predecible
la escasez de recursos. Algunas de las razones que no son considerados
frvolos
se discuten en la siguiente subseccin y en la Seccin 7.8.
Si hay un fallo en la entrega despus de la aceptacin de un mensaje, el

Receptor-SMTP deben formular y enviar un mensaje de notificacin. Esta
Dicha notificacin deber enviarse utilizando un nulo ( "<>") reverse-path en
el
sobre. El destinatario de esta notificacin debe ser la direccin
de la va de retorno sobre (o el Return-Path: Lnea). Sin embargo,

si esta direccin es nula ( "<>"), el receptor-SMTP no debe enviar una

notificacin. Obviamente, nada en esta seccin puede o debe
prohibir decisiones locales (es decir, como parte del mismo sistema de
medio ambiente como el receptor-SMTP) para registrar o transmitir
informacin sobre los eventos de direcciones nulos nivel local, si as se
desea. Si
la direccin es una fuente ruta explcita, que deber ser despojado de
su salto final.
Por ejemplo, supongamos que una notificacin de error debe ser enviado para
una
mensaje que lleg con:
MAIL FROM: <@ a, b @: usuario @ d>
El mensaje de notificacin deber ser enviada usando:
RCPT TO: <usuario @ d>
Algunos errores en la entrega despus de que el mensaje es aceptado por SMTP

sern
inevitable. Por ejemplo, puede ser imposible que el receptor
servidor SMTP para validar todas las direcciones de entrega en comando RCPT
(s)
debido a un error en el sistema de dominio "blanda", ya que el objetivo es un
correo
lista (vase el anlisis anterior de RCPT), o porque el servidor est
que acta como un rel y no tiene acceso inmediato a la entrega
sistema.
Para evitar recibir mensajes duplicados como resultado de los tiempos de
espera, una
Receptor-SMTP debe procurar reducir al mnimo el tiempo necesario para
responder a
el <CRLF>. <CRLF> fin ltimo del indicador de datos. Ver el RFC 1047 [40] para
una discusin de este problema.
6.2. No deseados, no solicitadas, y mensajes de "ataque"
Utilidad y previsibilidad del sistema de correo de Internet requiere que las

mensajes que pueden ser entregados debe ser entregado, independientemente de
cualquier
sintaxis u otros fallos asociados a esos mensajes, y al margen
de su contenido. Si no pueden ser entregados, y no pueden ser
rechazado por el servidor SMTP durante la transaccin SMTP, que deberan
ser "rebotado" (devuelto con mensajes de notificacin de no entrega) como
descrito arriba. En el mundo actual, en el que muchos servidor SMTP
operadores han descubierto que la cantidad de correo electrnico masivo no
deseado
excede enormemente la cantidad de correo deseado y en el que la aceptacin de
una
mensaje puede desencadenar trfico no deseado adicional, proporcionando
verificacin de la direccin, estos principios puede no ser prctico.
Como se discuti en la seccin 7.8 y la seccin 7.9 ms adelante, dejando caer

electrnico
sin notificacin del remitente est permitido en la prctica.
Sin embargo, es extremadamente peligroso y viola una larga tradicin y
expectativas de la comunidad que el correo es o bien entregar o devolver. Si

silencio-que caen mensaje haya sido usurpada, que fcilmente podra socavar
la confianza en la fiabilidad de los sistemas de correo de Internet. Asi que
cada silenciosa de los mensajes debe ser considerada slo en aquellos casos
donde no es muy alta confianza en que los mensajes estn seriamente
fraudulenta o inapropiada.
Para estirar el principio de la entrega si es posible, an ms, puede

ser una poltica racional para no entregar el correo que tiene un retorno no
vlido
direccin, aunque la historia de la red es que los usuarios son
suele ser mejor servido mediante la entrega de cualquier mensaje que pueda ser
entregado. Fiable de determinar que la direccin del remitente es vlido puede
ser una tarea difcil y consume tiempo de proceso, especialmente si el
putativo
sistema de envo no es directamente accesible o no se completa y
apoyar con precisin y VRFY, incluso si una "gota mensajes con invlida
direcciones devolver "la poltica que se adopte, se debe aplicar slo cuando
hay cerca de la certeza de que las direcciones de retorno son, de hecho,
invlido.
Por el contrario, si se rechaza un mensaje, ya que se encontr que contena

contenido hostil (una decisin que est fuera del alcance de un servidor SMTP
servidor como se define en este documento), rechazo () Los mensajes de
"rebote"
No deben ser enviados a menos que el sitio de recepcin confa en que los
mensajes sern entregados de manera til. La preferencia por defecto y en
estos casos es evitar el envo de mensajes de no entrega cuando las
mensaje de entrada se determina con contenido hostil.
6.3. Deteccin de bucle
recuento simple del nmero de "Recibido:" campos de cabecera en una

mensaje ha demostrado ser una eficaz, aunque rara vez ptima,
Mtodo de deteccin de bucles en los sistemas de correo. Los servidores SMTP
que utilizan este
tcnica debe utilizar un umbral de rechazo grande, normalmente, al menos
100 entradas recibidas. Sea cual sea mecanismos se utilizan, los servidores
deben
prevean la posibilidad de detectar y detener bucles triviales.
6.4. La compensacin de las irregularidades
Por desgracia, las variaciones, las interpretaciones creativas, y de plano

ocurren violacines de los protocolos de correo de Internet; algunos sugieren
que se producen con bastante frecuencia. El debate acerca de si un bien
receptor SMTP comportado o rel deben rechazar un mensaje con formato
incorrecto,
intentar pasarlo sin cambios, o intentar repararlo para aumentar
las probabilidades de xito de la entrega (o posterior) comenzaron casi de
respuesta
Con el amanecer de correo de la red estructurada y no muestra signos de
disminuir. Los defensores de la reivindicacin rechazo que han intentado
reparaciones son
rara vez completamente adecuado y que el rechazo de mensajes incorrectos es el
nica manera de conseguir el software que no reparan. Los defensores de la
"Reparar" o "entregue sin importar lo que" argumentan que los usuarios
prefieren que

correo pasar por ella si es posible y que no son significativos

las presiones del mercado en esa direccin. En la prctica, estos mercados
las presiones pueden ser ms importantes para los vendedores particulares que
estricta
La conformidad con las normas, independientemente de la preferencia de la
desarrolladores reales.
Los problemas asociados con los mensajes mal formados se ven agravados por
la introduccin de los protocolos de lectura de correo split-UA (Post Office
Protocolo (POP) versin 2 [15], Post Office Protocol (POP) versin 3
[16], IMAP versin 2 [41], y PCMAIL [42]). estos protocolos
fomentado el uso de SMTP como una fijacin (envo de mensajes)
protocolo, y SMTP como servidores de los sistemas de transmisin para estos
Servidores
(Que a menudo estn conectados de manera intermitente a Internet).
Histricamente, muchas de esas mquinas cliente careca de algunas de las
mecanismos e informacin asumidas por SMTP (y, de hecho, por el correo
protocolo de formato, RFC 822 [28]). Algunos no podan mantener un seguimiento
adecuado
de tiempo; otros no tenan concepto de zonas horarias; Todava otros no
pudieron
identificar sus propios nombres o direcciones; y, por supuesto, no poda
satisfacer las suposiciones subyacentes a la concepcin de la RFC 822
direcciones autenticados.
En respuesta a estos clientes SMTP dbiles, muchos sistemas SMTP ahora
mensajes completos que se entregan a ellos en incompleta o
forma incorrecta. Esta estrategia general se considera apropiado
cuando el servidor puede identificar o autenticar el cliente, y hay
son acuerdos previos entre ellos. Por el contrario, no es en el mejor de
gran preocupacin acerca de las correcciones aplicadas por un servidor de
retransmisin SMTP o la entrega
que tiene poco o ningn conocimiento de la mquina del usuario o cliente.
Muchos
de estos problemas se solucionan mediante el uso de un protocolo separado, tal
como se
que se define en RFC 4409 [18], para la presentacin de mensajes, en lugar de
usando originarios servidores SMTP para ese propsito.
Los siguientes cambios en un mensaje que est siendo procesada puede aplicarse
cuando sea necesario por un servidor SMTP de origen, o que se utiliza como el
blanco de SMTP como un desplazamiento (envo de mensajes) inicial protocolo:
o adicin de un campo de mensaje-id cuando aparezca ninguno
o adicin de una fecha, hora o la zona horaria cuando aparezca ninguno
o Correccin de direcciones al formato adecuado FQDN
Cuanto menos informacin que el servidor tiene sobre el cliente, es menos

probable
estos cambios han de ser correcta y la mayor cautela y el conservadurismo
debe aplicarse al considerar si debe o no realizar correcciones
y cmo. Estos cambios no debe ser aplicado por un servidor SMTP que
proporciona una funcin de relevo intermedio.

En todos los casos, los clientes que operan adecuadamente el suministro

correcto
la informacin se prefieren a las correcciones por el servidor SMTP. En todo
casos, la documentacin debe ser proporcionada en los campos de cabecera traza
y / o
campo de encabezado comentarios para las acciones realizadas por los
servidores.
7. Consideraciones de Seguridad
7.1. Seguridad de correo y la suplantacin
correo SMTP es intrnsecamente inseguros en que es factible, incluso para

bastante los usuarios ocasionales pueden negociar directamente con la
recepcin y retransmisin
Los servidores SMTP y crear mensajes que engaar al usuario ingenuo
en la creencia de que vinieron de otro lugar. La construccin de tales
un mensaje para que el comportamiento "falso" no puede ser detectado por una
experto es algo ms difcil, pero no lo suficiente como para ser una
disuasivo para alguien que est decidido y bien informado.
En consecuencia, como el conocimiento de los aumentos de correo de Internet,
tambin lo hace la
conocimiento de que el correo SMTP inherentemente no puede ser autenticada, o
comprobaciones de integridad siempre, en el nivel de transporte. correo real
la seguridad se encuentra slo en los mtodos de extremo a extremo que
implican el mensaje
rganos, tales como los que utilizan las firmas digitales (ver RFC 1847 [43]
y, por ejemplo, Pretty Good Privacy (PGP) en el RFC 4880 [44] o Secure /
Multipurpose Internet Mail Extensions (S / MIME) en el RFC 3851 [45]).
Varias extensiones de protocolo y opciones de configuracin que proporcionan

autenticacin en el nivel de transporte (por ejemplo, desde un cliente de SMTP
a
un servidor SMTP) mejorar algo sobre la situacin tradicional
descrito arriba. Sin embargo, en general, slo se autentican uno
servidor a otro en lugar de una cadena de rels y servidores, tanto
menos la autenticacin de usuarios o equipos de los usuarios. En consecuencia,
a menos
que vayan acompaados de transferencias cuidadosas de responsabilidad en una
entorno de confianza cuidadosamente diseado, siguen siendo inherentemente ms
dbil
que los mecanismos de extremo a extremo que utilizan mensajes firmados
digitalmente en vez
de depender de la integridad del sistema de transporte.
Los esfuerzos para que sea ms difcil para los usuarios establecer retorno
envolvente
ruta y el encabezado "De" campos que apuntan a direcciones que no sean vlidos
su propia son en gran medida equivocada: frustran legtima
aplicaciones en las que el correo es enviado por un usuario en nombre de otro,
en el que el error (o normal) Las respuestas deben ser dirigidas a un especial
direccin, o en los que un mensaje se enva a varios destinatarios
en diferentes hosts. (Los sistemas que ofrecen formas convenientes para los
usuarios
para alterar estos campos de cabecera en un mensaje por mensaje debe intentar
establecer una direccin de buzn de correo principal y permanente para el
usuario as lo
que los campos de cabecera del remitente dentro de los datos de mensaje se
pueden generar
sesudamente.)

Esta especificacin no aborda an ms los problemas de autenticacin

SMTP asociado con otro que abogan por que la funcionalidad til
no estar deshabilitado en la esperanza de proporcionar algn pequeo margen de
proteccin contra un usuario que est intentando electrnico falso.
7.2. Copias "a ciegas"
Las direcciones que no aparecen en la seccin de cabecera del mensaje pueden

aparecer
en el RCPT comandos a un servidor de SMTP para un nmero de razones. los
dos ms comunes implican el uso de una direccin de correo como una "lista
detonador "(una nica direccin que se resuelve en varias direcciones)
y la aparicin de "copia oculta". Especialmente cuando ms de una
comando RCPT est presente, y con el fin de evitar anular algunas de las
propsito de estos mecanismos, los clientes y los servidores SMTP No debe
copiar
todo el conjunto de argumentos de comandos RCPT en la seccin de encabezado,
ya sea como parte de los campos de cabecera traza o tan informativo como en
privado,
campos de cabecera de extensin. Desde esta regla es a menudo violados en
practicar, y no puede ser forzada, el envo de los sistemas de SMTP que son
conscientes
de "BCC" uso puede resultar til para enviar cada copia oculta como una
transaccin de mensaje independiente que contiene slo un nico comando RCPT.
No existe una relacin inherente entre "marcha atrs" (de

CORREO, SAML, etc., comandos) o (RCPT) direcciones "hacia adelante" en el SMTP
transaccin ( "sobre") y las direcciones en la seccin de encabezado.
sistemas de recepcin no debe tratar de deducir este tipo de relaciones y
utilizarlos para modificar la seccin de encabezado del mensaje para su
entrega.
El popular "Al parecer a" campo de encabezado es una violacin de esta
principio, as como una fuente comn de informacin en forma involuntaria
divulgacin y no debe ser utilizado.
7.3. VRFY, EXPN y Seguridad
Como se discuti en la seccin 3.5, los sitios individuales pueden querer

desactivar
uno o ambos de VRFY o EXPN por razones de seguridad (vase ms adelante). Como
corolario de lo anterior, las implementaciones que permitan esto no debe
parecen tener direcciones verificadas que no son, de hecho, verificado.
Si un sitio desactiva estos comandos por razones de seguridad, el SMTP
servidor DEBE devolver una respuesta 252, en lugar de un cdigo que podra ser
confundirse con la verificacin exitosa o no.
La devolucin de un cdigo de respuesta 250 con la direccin que aparece en el

VRFY
mando despus de haber comprobado que slo la sintaxis viola esta regla.
Por supuesto, una implementacin que "apoya" VRFY que siempre devuelve
550 si la direccin es vlida no es igual en
de conformidad.
En la Internet pblica, el contenido de las listas de distribucin se han

convertido
popular como una fuente de informacin de la direccin de los llamados
"spammers".

El uso de EXPN a las direcciones de "cosecha" ha aumentado a medida que la

lista
los administradores han instalado protecciones contra los usos inadecuados
de las propias listas. Sin embargo, VRFY y EXPN siguen siendo tiles para
los usuarios autenticados y dentro de un dominio administrativo. por
ejemplo, VRFY y EXPN son tiles para la realizacin de auditoras internas de
cmo va a parar de correo electrnico para verificar y para asegurarse de que
nadie est
reenviar automticamente el correo sensibles fuera de la organizacin.
Los sitios de aplicacin de autenticacin SMTP pueden optar por hacer y VRFY
EXPN disponible slo para los solicitantes autenticados. implementaciones
En caso de persistir proporcionar soporte para EXPN, pero los sitios deben
cuidadosamente
evaluar las ventajas y desventajas.
Ya sea incapacitante VRFY ofrece ninguna seguridad marginales reales depende
de
una serie de otras condiciones. En muchos casos, los comandos RCPT pueden ser
utilizado para obtener la misma informacin sobre la validez de direcciones.
Sobre el
Por otra parte, sobre todo en situaciones en las que la determinacin de la
direccin de
validez de comandos RCPT se aplaza hasta despus de que el comando DATA
es recibida, RCPT puede devolver ninguna informacin en absoluto, mientras que
es VRFY
espera que haga un intento serio para determinar la validez antes
generar un cdigo de respuesta (vase la discusin anterior).
7.4. El redireccionamiento de correo Sobre la base de los cdigos de respuesta

251 y 551
Antes de que un cliente utiliza los 251 o 551 cdigos de respuesta de un

comando RCPT
para actualizar automticamente su comportamiento futuro (por ejemplo, la
actualizacin de la
de la libreta de direcciones del usuario), debe estar seguro de que el
servidor de
autenticidad. Si no lo hace, puede estar sujeto a un hombre en el
ataque al medio.
7.5. La divulgacin de informacin en Anuncios
Ha habido un debate continuo sobre el equilibrio entre la

ventajas de anunciar el tipo de servidor y la versin de depuracin (y,
a veces, incluso servidor de nombre de dominio) en la respuesta del saludo o
de
respuesta al comando HELP y las desventajas de la exposicin
informacin que podra ser til en un potencial ataque hostil. los
utilidad de la informacin de depuracin es fuera de toda duda. Aquellos que
argumentan a favor de lo que es el punto disponible que es mucho mejor
en realidad asegurar un servidor SMTP en lugar de esperar que intentar
ocultar vulnerabilidades conocidas por ocultar la identidad precisa del
servidor
proporcionar ms proteccin. Se anima a los sitios para evaluar la
solucin de compromiso con ese tema en mente; implementaciones DEBEN
mnimamente
proporcionar para hacer el tipo y la informacin de versin disponible de
alguna manera
a otras mquinas de la red.

7.6. La divulgacin de informacin en los campos de seguimiento
En algunas circunstancias, tales como cuando el correo se origina desde dentro

de una LAN
cuyos anfitriones no son directamente en la Internet pblica, vestigios
( "Recibidos") campos de cabecera producen en conformidad con la presente
especificacin puede revelar los nombres de host e informacin similar que
no estara disponible normalmente. Esto normalmente no representa una
problema, pero los sitios con preocupaciones especiales sobre el nombre de
divulgacin deberan
ser consciente de ello. Adems, la clusula opcional para debe suministrarse
con precaucin o no en absoluto cuando varios destinatarios para que no
participan
inadvertidamente revelar la identidad de los destinatarios "copia oculta"
a otros.
7.7. Divulgacin de la Informacin en el reenvo de mensajes
Como se discuti en la Seccin 3.4, el uso de los 251 o 551 cdigos de

respuesta a
identificar la direccin de sustitucin asociados con un buzn de correo puede
sin querer revelar informacin sensible. Los sitios que son
preocupados por estas cuestiones deben garantizar que se seleccionan y
configurar servidores adecuadamente.
7.8. La resistencia a los ataques
En los ltimos aos, ha habido un aumento de ataques a SMTP

servidores, ya sea en conjuncin con los intentos para descubrir direcciones
para el envo de mensajes no solicitados o simplemente para hacer que los
servidores
inaccesible a otros (es decir, como una negacin de nivel de aplicacin de
denegacin de servicio). Mientras que los medios para hacerlo estn ms all
del alcance de
esta Norma, el modo de funcionamiento racional requiere que los servidores
sean
permitido detectar este tipo de ataques y tomar medidas para defender
s mismos. Por ejemplo, si un servidor determina que un gran nmero
de comandos RCPT TO se estn enviando, la mayora o todos con invlida
direcciones, como parte de un ataque de ese tipo, sera razonable para el
servidor para cerrar la conexin despus de generar un nmero apropiado
de 5yz (normalmente 550) Respuestas.
7.9. Alcance de funcionamiento de los servidores SMTP
Es un principio bien establecido de que un servidor SMTP puede negarse a

aceptar correo por cualquier razn operacional o tcnica que tenga sentido
al sitio que proporciona el servidor. Sin embargo, la cooperacin entre los
sitios
e instalaciones hace posible la Internet. Si los sitios toman
ventaja excesiva del derecho a rechazar el trfico, la ubicuidad de
la disponibilidad de correo electrnico (uno de los puntos fuertes de
Internet) ser
amenazado; mucho cuidado debe ser tomado y el equilibrio mantenido
si un sitio decide ser selectivo sobre el trfico que va a aceptar
y el proceso.

En los ltimos aos, el uso de la funcin de rel a travs de sitios

arbitrarios
se ha utilizado como parte de los esfuerzos hostiles para ocultar el origen
real
de correo. Algunos sitios han decidido limitar el uso del rel
funcionar a fuentes conocidas o identificables, y las implementaciones
deberan
proporcionar la capacidad para llevar a cabo este tipo de filtrado. cuando el
correo
es rechazada por estas u otras razones polticas, un cdigo 550 DEBERA
utilizado en respuesta a EHLO (o HELO), MAIL, RCPT o segn el caso.
8. Consideraciones IANA
IANA mantiene tres registros en apoyo de esta especificacin, todas

de los cuales fueron creados por el RFC 2821 o antes. Este documento se
expande
el tercero, tal como se especifica a continuacin. Las referencias de registro
son enumerados
a partir del momento de la publicacin; IANA no garantiza las ubicaciones
asociado con las direcciones URL. Los registros son los siguientes:
o La primera "Servicio, Simple Mail Transfer Protocol (SMTP)

Extensiones "[46], se compone de extensiones de servicio SMTP con el
palabras clave relacionadas, y, segn sea necesario, los parmetros y los
verbos. Como
especifica en la Seccin 2.2.2, no hay ninguna entrada puede hacerse en
este registro
que comienza en una "X". Las entradas pueden ser hechas por el servicio
(extensiones asociadas y las palabras clave, parmetros, o verbos) que
se definen en las Normas-Track o Experimental RFC especficamente
aprobado por el IESG para este propsito.
o El segundo registro, "Direccin literal Etiquetas" [47], consiste en

"etiquetas" que identifican las formas de literales de dominio distintos de
aquellos para
direcciones IPv4 (especificados en RFC 821 y en este documento). los
entrada inicial en dicho registro es para direcciones IPv6 (especificado en
este documento). tipos literales adicionales requieren la normalizacin
antes de ser utilizado; ninguno se prev en este momento.
o La tercera, "Tipos de correo de transmisin" [46], establecido por el RFC

821
y renovada por esta especificacin, es un registro de enlace y
identificadores de protocolo a utilizar con la "va" y "con"
apartados de la marca de tiempo ( "Recibido:" campo de encabezado) descrito
en la Seccin 4.4. identificadores de enlace y protocolo, adems de
los especificados en este documento solo se podr registrar por
la normalizacin o por medio de un RFC-documentado, aprobado por el IESG,
extensin del protocolo experimental. Este espacio de nombre es para
identificacin y no limitados en tamao: el IESG se anima a
aprobar sobre la base de una documentacin clara y un mtodo distinto
en lugar de preferencias sobre las propiedades del mtodo en s.
Un inciso adicional se ha aadido a los "tipos de enlace a travs de"

y "CON" tipos de protocolo subsecciones de este registro para contener
Los registros de adicionales-numerales registrados" como se describe
encima. El registro contendr los nombres clusula, una descripcin, una

Resumen de la sintaxis de la cadena asociada, y una referencia.

A medida que se definen nuevas clusulas, pueden, en principio, especifique
creacin de sus propios registros si las cadenas se componen de
trminos o palabras clave reservadas en lugar de cadenas menos
restringidas.
Al igual que con identificadores de enlace y protocolo, clusulas
adicionales pueden ser
registrada solamente por la normalizacin o por medio de un documentado
RFC,
IESG aprobados, extensin del protocolo experimental. El adicional
espacio de nombres clusula es para la identificacin y no se limita en
tamao: el IESG se alienta a que apruebe sobre la base de clara
documentacin, uso real o fuertes indicios de que la clusula ser
utilizados, y un requisito independiente en lugar de las preferencias sobre
el
propiedades de la propia clusula.
Adems, si los campos de cabecera de rastreo adicionales (es decir, adems de

Ruta de respuesta y recibidas) se haya creado, esos campos de seguimiento MUST
se aade a la IANA registro establecido por el BCP 90 (RFC 3864) [11]
para su uso con RFC 5322 [4].
9. Agradecimientos
Muchas personas han contribuido al desarrollo de la RFC 2821. Ese

docum ento debe ser consultado para los acuses de recibo. Para el
presente documento, el editor y la comunidad deben gracias al amanecer
Mann y Tony Hansen que colaboraron en el proceso muy doloroso
editar y convertir el formato interno del documento de una
sistema a otro.
Ni este documento ni RFC 2821 habran sido posibles sin

los muchos puntos de vista y la contribucin del difunto Jon Postel. Aquellos
contribuciones de curso incluyen la especificacin original de SMTP en
RFC 821. sigue apareciendo una cantidad considerable de texto desde el RFC 821
en este documento al igual que varios de los ejemplos originales de Jon que
tienen
han actualizado slo cuando sea necesario para reflejar otros cambios en el
especificacin.
Muchas personas hacen comentarios o sugerencias acerca de la lista de correo o

en
notas para el autor. correcciones o aclaraciones importantes eran
sugerido por varias personas, incluyendo Matti Aarnio, Glenn Anderson,
Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
Gulbrandsen, Eric Hall, Richard O. Hammer, de Tony Hansen, Peter J.
Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
Marcos Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hctor Santos,
David F. Skoll, Paul Smith, y Brett Watson.

Los esfuerzos de los Directores de rea - Lisa Dusseault, Ted Hardie, y

Chris Newman - para conseguir este esfuerzo renovadas y mantenerlo en
movimiento, y
de un comit ad hoc con el mismo propsito, son gratamente
admitido. Los miembros de dicha comisin fueron (en orden alfabtico
orden), Dave Crocker, Cyrus Daboo Tony Finch, Ned Freed, Randall
Gellens Tony Hansen, autor, y Alexey Melnikov. tony Hansen
tambin actu como presidente ad hoc sobre la lista de distribucin de revisar
este
documento; sin sus esfuerzos, el sentido del equilibrio y la equidad, y
paciencia, est claro que no habra sido posible.
10. Referencias
10.1. Referencias normativas
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
De agosto de 1982.
[2] Mockapetris, P., "Los nombres de dominio - y Aplicacin

Especificacin ", STD 13, RFC 1035, noviembre de de 1987.
[3] Braden, R., "Requisitos para hosts de Internet - Aplicacin y

Soporte ", STD 3, RFC 1123, octubre de 1989.
[4] Resnick, P., "Formato de mensajes de Internet", RFC 5322, octubre de 2008.
[5] Bradner, S., "Palabras clave para su uso en RFC para Indicar Requisito
Niveles ", BCP 14, RFC 2119, marzo de 1997.
[6] Instituto Nacional Estadounidense de Estndares (anteriormente Estados

Unidos
del Instituto de Normas de Amrica), "EE.UU. Cdigo de Informacin
Intercambio ", ANSI X3.4-1968 de 1968.
ANSI X3.4-1968 ha sido reemplazado por versiones ms nuevas con ligera

modificaciones, pero la versin de 1968 sigue siendo definitivo para la
Internet.
[7] Crocker, D. y P. Overell, "aumentada para Sintaxis BNF

Especificaciones: ABNF ", STD 68, RFC 5234, enero de 2008.
[8] Hinden, R. y S. Deering, "IP versin 6 Direccionamiento

Arquitectura ", RFC 4291, febrero de 2006.
[9] Newman, C., "ESMTP y LMTP Transmisin Tipos de registro",

RFC 3848, julio de 2004.
[10] Klensin, J., Freed, N., y K. Moore, "SMTP Servicio de Extensin

Mensaje para la declaracin del tamao ", STD 10, RFC 1870, noviembre de
1995.

[11] Klyne, G., Nottingham, M., y J. Mogul, "Registro

Procedimientos para la cabecera del mensaje Los campos ", BCP 90, RFC
3864,
Septiembre de 2004.
10.2. Referencias informativas
[12] Partridge, C., "Direccionamiento de correo electrnico y el sistema de

dominio", RFC 974,
Enero de 1986.
[13] Klensin, J., Freed, N., Rose, M., Stefferud, E. y D.

Crocker, "Extensiones de servicio SMTP", STD 10, RFC 1869,
Noviembre de 1995.
[14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,

Abril de 2001.
[15] Butler, M., Postel, J., Chase, D., Goldberger, J., y J.

Reynolds, "Post Office Protocol: Versin 2", RFC 937,
02 1985.
[16] Myers, J. y M. Rose, "Post Office Protocol - Versin 3",

STD 53, RFC 1939, mayo de 1996.
[17] Crispin, M., "PROTOCOLO DE MENSAJE DE ACCESO A INTERNET - VERSIN

4rev1 ", RFC 3501, marzo de 2003.
[18] Gellens, R. y J. Klensin, "Envo de mensajes de correo",

RFC 4409, abril de 2006.
[19] Freed, N., "SMTP Servicio de Extensin Comando de tuberias de diferentes

tipos",
STD 60, RFC 2920, septiembre de 2000.
[20] Vaudreuil, G., "Extensiones de servicio SMTP para la transmisin de

Grandes y Binary MIME Mensajes ", RFC 3030, diciembre de 2000.
[21] Freed, N. y N. Borenstein, "Correo de Internet Multipropsito

Extensiones (MIME) Primera Parte: Formato de los mensajes de Internet
cuerpos ",
RFC 2045, noviembre de 1996.
[22] Klensin, J., Freed, N., Rose, M., Stefferud, E. y D.

Crocker, "SMTP Servicio de Extensin 8bit-MIMEtransport",
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Parte

Tres: Mensaje extensiones de cabecera para texto no ASCII ", RFC 2047,
Noviembre de 1996.

[24] Freed, N. y K. Moore, "MIME valor del parmetro y codificada palabra

Extensiones: el conjunto de caracteres, idiomas y continuaciones ",
RFC 2231, noviembre de 1997.
[25] Vaudreuil, G., "sistema de correo de Cdigos de estado mejorado", RFC

3463,
Enero de 2003.
[26] Hansen, T. y J. Klensin, "un registro de correo SMTP mejorado
Cdigos de estado del sistema ", BCP 138, RFC 5248, junio de 2008.
[27] Freed, N., "Comportamiento y los requisitos de internet

Firewalls ", RFC 2979, octubre de 2000.
[28] Crocker, D., "Norma para el Formato de ARPA Internet de texto

mensajes ", STD 11, RFC 822, agosto de 1982.
[29] Wong, M. y W. Schlitt, "Sender Policy Framework (SPF) de

Que autoriza el uso de dominios de correo electrnico, versin 1 ", RFC
4408,
Abril de 2006.
[30] Fenton, J., "Anlisis de Amenazas Motivar DomainKeys

Correo identificado (DKIM) ", RFC 4686, septiembre de 2006.
[31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., y
M. Thomas, "DomainKeys Identified Mail (DKIM) Las firmas",
RFC 4871, mayo de 2007.
, K., "Servicio (SMTP) [32] Moore Simple Mail Transfer Protocol

Extensin para las notificaciones de estado de entrega (DSN) ", RFC
3461,
Enero de 2003.
[33] Moore, K. y G. Vaudreuil, "un formato extensible Mensaje para

Notificaciones de estado de entrega ", RFC 3464, enero de 2003.
[34] Postel, J. y J. Reynolds, "File Transfer Protocol", STD 9,

RFC 959, Octubre de 1985.
[35] Kille, S., "Mixer (MIME X.400 de Internet Relay mejorado): Cartografa
entre X.400 y RFC 822 / MIME ", RFC 2156, enero de 1998.
[36] De Winter, J., "SMTP Servicio de Extensin de cola de mensajes remoto

A partir ", RFC 1985, agosto de 1996.
[37] Hansen, T. y G. Vaudreuil, "Message Disposition

Notificacin ", RFC 3798, mayo de 2004.
[38] Elz, R. y R. Bush, "Aclaraciones a la Especificacin de DNS",


[39] Nakamura, M. y J. Hagino, "La experiencia operacional en SMTP

Mezclado IPv4 medio ambiente / v6 ", RFC 3974, enero de 2005.
[40] Partridge, C., "mensajes duplicados y SMTP", RFC 1047,

02 1988.
[41] Crispin, M., "Protocolo de acceso al correo interactivo: Versin 2",

RFC 1176, agosto 1990.
"PCMAIL [42] Lambert, M.: Un sistema electrnico distribuido para uso personal
ordenadores ", RFC 1056, junio de 1988.
[43] Galvin, J., Murphy, S., Crocker, S., y N. Freed, "Seguridad
Multiparts para MIME: de varias / Firmado y varias / cifrado ",
RFC 1847, octubre de 1995.
[44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., y R.

Thayer, "Formato de mensaje OpenPGP", RFC 4880, noviembre de 2007.
[45] Ramsdell, B., "Secure Mail Extensions / Multipurpose Internet

(S / MIME) Versin 3.1 especificacin del mensaje ", RFC 3851,
Julio de 2004.
[46] Internet Assigned Nmero Authority (IANA), "Correo de IANA

Parmetros ", 2007,
<Http://www.iana.org/assignments/mail-parameters>.
[47] Internet Assigned Nmero Authority (IANA), "Direccin literal

Tags ", 2007,
<Http://www.iana.org/assignments/address-literal-tags>.

Apndice A. Servicio de Transporte TCP
La conexin TCP soporta la transmisin de bytes de 8 bits. los

datos SMTP es caracteres ASCII de 7 bits. Cada carcter se transmite
como un byte de 8 bits con el bit de orden superior limpiado a cero. Servicio
extensiones pueden modificar esta regla para permitir la transmisin del pleno
de 8 bits
bytes de datos como parte del cuerpo del mensaje, o, si se disean
especficamente
para ello, en los comandos SMTP o respuestas.
Apndice B. Creacin de comandos SMTP de RFC 822 campos de cabecera
Algunos sistemas utilizan una seccin de encabezado RFC 822 (slo) en un

correo
protocolo de presentacin, o de otra manera generar comandos SMTP de RFC 822
campos de cabecera cuando un mensaje de este tipo es entregado a un MTA de una
UA.
Si bien el protocolo ATM-UA es un asunto privado, no cubierta por cualquier
Internet estndar, hay problemas con este enfoque. por
ejemplo, ha habido repetidos problemas con el manejo adecuado de
copias "BCC" y las listas de redistribucin cuando la informacin que se
conceptualmente pertenece a los sobres de correo no est separado a principios
de
procesamiento de la informacin de campo de cabecera (y mantenerse separados).
Se recomienda que la UA proporcionar su inicial ( "sumisin

cliente ") MTA con un sobre separado del mensaje en s.
Sin embargo, si el sobre no se suministra, los comandos SMTP DEBERA
generado como sigue:
1. Cada direccin del destinatario de una, CC, campo de cabecera TO o BCC

DEBERA
copiarse en un comando RCPT (la generacin de mltiples copias de los
mensajes
si lo que se requiere para poner en cola o entrega). Esto incluye
cualquier
direcciones que aparecen en un "grupo" RFC 822. Cualquier campo de
cabecera BCC
A continuacin, debe ser retirado de la seccin de encabezado. Una vez que
esto
el proceso se ha completado, los campos de cabecera restante debe ser
comprobado para verificar que al menos una A, CC o CCO campo de cabecera
permanece. Si ninguno lo hace, a continuacin, un campo de cabecera BCC
sin adicional
La informacin debe ser insertado como se especifica en [4].
2. La direccin del remitente en el comando de correo debera, si es posible,

ser
derivado de la identidad del sistema para que las presentaron (local)
usuario, y el campo "De:" campo de encabezado de otra manera. Si hay un
la identidad del sistema disponible, sino que tambin se debe copiar al
Remitente
campo de encabezado si es diferente de la direccin en el
campo de encabezado. (Cualquier campo de cabecera del remitente que ya
estaba all
Debe ser eliminado.) Los sistemas pueden proporcionar una manera para que
los remitentes a
anular la direccin de retorno sobre, pero puede que desee restringir
su uso a los usuarios privilegiados. Esto no impedir que la falsificacin
de correo,
pero puede disminuir su incidencia; vase la Seccin 7.1.

Cuando un MTA se utiliza de esta manera, que es responsable de

asegurar que el mensaje que se transmite es vlido. los mecanismos
para comprobar que la validez, y para el manejo (o regresar) mensajes
que no son vlidos en el momento de la llegada, forman parte del MUA-MTA
interfaz y no estn cubiertos por esta especificacin.
Un protocolo de comunicacin basado en estndar RFC 822 informacin por s

sola
No deben utilizarse a la pasarela un mensaje de un (SMTP-no) de correo externo
sistema en un entorno de SMTP. Informacin adicional para la construccin de
un sobre debe venir de alguna fuente en el otro ambiente,
si los campos de cabecera suplementarios o envolvente del sistema externo.
Los intentos de gateway mensajes usando slo su encabezado "Para" y "CC"

campos han causado en varias ocasiones bucles de correo y otros
comportamientos adversos
para el buen funcionamiento del entorno de correo de Internet. Estas
problemas han sido especialmente comn cuando el mensaje se origina a partir
una lista de correo de Internet y se distribuye en el extranjero
medio ambiente utilizando informacin de la envolvente. Cuando estos mensajes
son entonces
procesada por un despachador de cabecera de seccin de solo, los bucles de
nuevo a la
entorno de Internet (y la lista de correo) son casi inevitables.
Rutas Apndice C. Fuente
Histricamente, el <reverse-path> era una lista de enrutamiento de origen

inversa
anfitriones y un buzn de origen. El primer anfitrin en el <reverse-path> era
histricamente el envo del comando MAIL anfitrin; hoy en da, las rutas de
origen
No debe aparecer en el camino inverso. Del mismo modo, el <forward-path>
puede ser una fuente de listas de anfitriones y un buzn de destino de
enrutamiento.
Sin embargo, en el <forward-path> general debe contener solamente un buzn
y el nombre de dominio, basndose en el sistema de nombres de dominio para el
suministro de enrutamiento
informacin si es necesario. El uso de rutas de origen est en desuso (vase
F.2 Apndice); mientras que los servidores deben estar preparados para recibir
y manejar
como se discuti en la Seccin 3.3 y Apndice F.2, clientes no deben
transmitirlos y esta seccin se incluye en la actual
Especificacin slo para proporcionar contexto. Se ha modificado algo
a partir del material en el RFC 821 para evitar acciones del servidor que
podran
confundir a los clientes o servidores posteriores que no esperan una completa
implementacin de ruta de origen.
Para los propsitos de rel, el delantero-ruta puede ser una ruta de la fuente
formar "@ UNO, DOS @: JOE @ TRES", donde uno, dos, y tres deben ser por
integracin global
nombres de dominio completos. Este formulario se utiliza para enfatizar la
distincin entre una direccin y una ruta. El buzn (en este caso, JOE @
TRES) es una direccin absoluta, y la ruta es informacin acerca de cmo
para llegar all. Los dos conceptos no deben confundirse.
Si se utilizan las rutas de origen, RFC 821 y el texto a continuacin deben

ser
consultado por los mecanismos para la construccin y actualizacin de la

Hacia el camino. Un servidor que se alcanza por medio de una ruta de origen
(Por ejemplo, su nombre de dominio aparece por primera vez en la lista en el
de la trayectoria directa)
Debe quitar su nombre de dominio desde cualquier-caminos a seguir en la que
ese
nombre de dominio aparece antes de reenviar el mensaje y podr eliminar toda
otra fuente de informacin de enrutamiento. El camino inverso-no debe ser
actualizado por los servidores conformes con esta especificacin.
Observe que la de la trayectoria directa e inversa de la ruta aparecen en el

SMTP
comandos y respuestas, pero no necesariamente en el mensaje. Es decir,
no hay necesidad de que estos caminos y especialmente esta sintaxis para
aparecer
en el campo "Para:", "De:", "CC:", etc. campos de la cabecera del mensaje
seccin. Por el contrario, los servidores SMTP no debe derivar mensaje final
la informacin de enrutamiento de los campos de encabezado del mensaje.
Cuando la lista de los ejrcitos est presente a pesar de las recomendaciones

anteriores,
se trata de una ruta de origen "inversa" e indica que el correo era
retransmitida a travs de cada host en la lista (el primer anfitrin en la
lista era
la ms reciente de rel). Esta lista se utiliza como ruta de origen a
volver avisos de no entrega al remitente. Si, en contra de la
recomendaciones aqu, un sistema de relevo se agrega al comienzo de
la lista, que deber utilizar su nombre como se conoce en el medio ambiente
del transporte
a la que est transmitiendo el correo en lugar de la del transporte
entorno desde el que lleg el correo (si son diferentes). Nota
una situacin que podra fcilmente ocurrir que algunos servidores de
transmisin se suman
sus nombres a la fuente ruta inversa y otros no lo hacen, generando
discontinuidades en la lista de enrutamiento. Esta es otra razn por la cual
servidores que necesitan para devolver un mensaje debe pasar por alto la ruta
de origen
por completo y simplemente utilizar el dominio como se especifica en el buzn.
Apndice D. Escenarios
En esta seccin se presenta escenarios completos de varios tipos de SMTP

sesiones. En los ejemplos, "C:" indica lo que se dice por el SMTP
cliente, y "S:" indica lo que se dice por el servidor SMTP.

D.1. Un escenario tpico de transaccin SMTP

Este ejemplo muestra SMTP electrnico enviado por Smith en bar.com acogida, y
para
Jones, Verde y Brown en foo.com anfitrin. Aqu asumimos que de acogida
bar.com contactos reciban a foo.com directamente. El correo electrnico es
aceptado para su
Jones y Brown. Verde no tiene un buzn en foo.com anfitrin.
S: 220 foo.com Simple Mail Transfer de inicio del servicio

C: EHLO bar.com
S: 250-foo.com saluda bar.com
S: 250-8BITMIME
S: 250 TAMAO
S: 250-DSN
S: 250 AYUDA
C: MAIL FROM: <Smith@bar.com>
S: 250 OK
C: RCPT TO: <Jones@foo.com>
S: 250 OK
C: RCPT TO: <Green@foo.com>
S: 550 Este usuario no existe aqu
C: RCPT TO: <Brown@foo.com>
S: 250 OK
C: DATOS
S: 354 Inicio de entrada de correo; terminar con <CRLF>. <CRLF>
C: Bla, bla, bla ...
C: ... etc. etctera etctera.
C:.
S: 250 OK
C: QUIT
S: canal de transmisin de cierre Servicio 221 foo.com

D.2. SMTP abortado Escenario Transaccin

C: EHLO bar.com
S: 250-8BITMIME
S: 250 TAMAO
S: 250-DSN
S: 250 AYUDA
C: MAIL FROM: <Smith@bar.com>
S: 250 OK
C: RCPT TO: <Jones@foo.com>
S: 250 OK
C: RCPT TO: <Green@foo.com>
S: 550 Este usuario no existe aqu
C: RSET
S: 250 OK
C: QUIT

D.3. Escenario correo retransmitido
Paso 1 - host de origen al rel principal
El host de origen realiza una bsqueda DNS en XYZ.COM (el destino

direccin) y busca los registros MX de DNS especificando xyz.com como el mejor
preferencia y foo.com como una menor preferencia. Se trata de abrir una
la conexin a xyz.com y falla. A continuacin, se abre una conexin con
foo.com, con el siguiente dilogo:

C: EHLO bar.com
S: 250-8BITMIME
S: 250 TAMAO
S: 250-DSN
S: 250 AYUDA
C: MAIL FROM: <JQP@bar.com>
S: 250 OK
C: RCPT TO: <Jones@XYZ.COM>
S: 250 OK
C: DATOS
C: Fecha: Jue, 21 de Mayo de 1998 05:33:29 -0700
C: De: John Q. Public <JQP@bar.com>
C: Asunto: La prxima reunin de la Junta
C: A: Jones@xyz.com
DO:
C: Bill:
C: La prxima reunin del consejo de administracin ser
C: el martes.
C: John.
C:.
S: 250 OK
C: QUIT

Paso 2 - Relevo un husped a otro destino
foo.com, despus de haber recibido el mensaje, ahora hace una bsqueda de DNS
en
xyz.com. Se encuentra el mismo conjunto de registros MX, pero no puede
utilizar el
que seala a s mismo (o de cualquier otro host como una preferencia peor).
Se trata de abrir una conexin con XYZ.com en s y tiene xito. Entonces
tenemos:
S: 220 xyz.com Simple Mail Transfer de inicio del servicio

C: EHLO foo.com
S: 250 xyz.com est en el aire
C: MAIL FROM: <JQP@bar.com>
S: 250 OK
C: RCPT TO: <Jones@XYZ.COM>
S: 250 OK
C: DATOS
C: Fecha: del bar.com por foo.com; Jue, 21 de Mayo de 1998
C: 05:33:29 -0700
C: Fecha: Jue, 21 de Mayo de 1998 05:33:22 -0700
C: De: John Q. Public <JQP@bar.com>
C: Asunto: La prxima reunin de la Junta
C: A: Jones@xyz.com
DO:
C: Bill:
C: La prxima reunin del consejo de administracin ser
C: el martes.
C: John.
C:.
S: 250 OK
C: QUIT

D.4. Verificacin y envo de Escenario

C: EHLO bar.com
S: 250-8BITMIME
S: 250 TAMAO
S: 250-DSN
S: 250 VRFY
S: 250 AYUDA
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: MAIL FROM: <EAK@bar.com>
S: 250 OK
C: RCPT TO: <Admin.MRC@foo.com>
S: 250 OK
C: DATOS
C: Bla, bla, bla ...
C: ... etc. etctera etctera.
C:.
S: 250 OK
C: QUIT
Apndice E. Otras cuestiones previas
En general, puertas de enlace entre el otros sistemas de correo de Internet y

Deben intentar preservar cualquier semntica de capas a travs de la
lmites entre los dos sistemas de correo involucradas. Puerta-
Traduccin acerca de que el intento de tomar atajos por mapeo
(Por ejemplo, sobre de cartografa de la informacin de un sistema a el
mensaje
seccin o cuerpo de otro) cabecea generalmente han demostrado ser
inadecuada de manera importante. Sistemas de traduccin entre
entornos que no soportan ambos sobres y una seccin de cabecera
y el correo de Internet debe estar escrito en el entendimiento de que algunos
prdida de informacin es casi inevitable.

Apndice F. Desaprobados Caractersticas de la RFC 821
Algunas caractersticas de la RFC 821 han demostrado ser problemtica y debe

No se admitirn en el correo de Internet.
F.1. GIRO
Este comando, que se describe en el RFC 821, plantea problemas de seguridad

importantes
ya que, en ausencia de una fuerte autenticacin del host solicitante
de que las funciones de cliente y servidor de conmutacin, que puede ser
fcilmente usado para
desviar el correo de su destino correcto. Su uso est en desuso;
sistemas de SMTP no se debe utilizar a menos que el servidor puede autenticar
el
cliente.
F.2. fuente de enrutamiento
RFC 821 utiliza el concepto de enrutamiento de origen explcita para obtener

el correo
de un host a otro a travs de una serie de rels. El requisito de
utilizar las rutas de origen en el trfico de correo ordinario fue eliminado
por el
introduccin del sistema de nombres de dominio "MX" y el ltimo
justificacin significativa para ellos fue eliminado por la
introduccin, en el RFC 1123, de un requisito claro que se dirige
a raz de una "@" deben estar todos los nombres de dominio totalmente
calificados.
Por consiguiente, las justificaciones que quedan para el uso de la fuente
rutas son muy antiguas apoyo a los clientes SMTP o MUA y en el correo
depuracin del sistema. Pueden, sin embargo, todava ser til en este ltimo
circunstancia y para el encaminamiento de correo torno seria, pero temporal,
problemas tales como problemas con los registros DNS correspondientes.
servidores SMTP debe seguir aceptando la sintaxis de ruta de origen tal como
se especifica
en el cuerpo principal de este documento y en el RFC 1123. Pueden, si
es necesario, hacer caso omiso de las rutas y utilizar slo el dominio de
destino en
la direccin. Si lo hacen utilizar la ruta de la fuente, el mensaje debe
ser enviado a la primera de dominio se muestra en la direccin. En particular,
una
servidor no debe adivinar los accesos directos dentro de la ruta de origen.
Los clientes no deben utilizar el enrutamiento de origen explcita, excepto en

circunstancias inusuales, tales como la depuracin o potencialmente
retransmisin
alrededor de firewall o sistema de correo de errores de configuracin.
F.3. HELO
Como se discuti en las secciones 3.1 y 4.1.1, EHLO DEBE ser usado en lugar
HELO que cuando el servidor aceptar la primera. Los servidores deben
mantener la admisin y el proceso HELO con el fin de apoyar mayores
clientela.

F.4. # -literals
RFC 821 proporcionan para especificar una direccin de Internet como un

decimal
nmero de host nmero entero prefijo de un signo de almohadilla, "#". En la
prctica, esto
formulario ha sido obsoleto desde la introduccin de TCP / IP. Es
obsoleto y no deben utilizarse.
F.5. Las fechas y aos
Cuando las fechas se insertan en los mensajes por parte de clientes o

servidores SMTP
(Por ejemplo, en los campos de cabecera traza), aos de cuatro dgitos debe
ser utilizado. Dos-
dgito aos estn en desuso; aos de tres dgitos nunca fueron permitidos en
el sistema de correo de Internet.
F.6. El envo de correo frente
Adems de especificar un mecanismo para la entrega de mensajes a

buzones de los usuarios, RFC 821 proporcionada adicional, opcional, ordena
entregar mensajes directamente a la pantalla del terminal del usuario. Estas
comandos (SEND, SAML, SOML) rara vez se implementa, y los cambios en
tecnologa de estacin de trabajo y la introduccin de otros protocolos pueden
determinan que sean obsoletos incluso cuando su aplicacin.
Los clientes no deben proporcionar SEND, SAML, o SOML como servicios.
servidores
Podr llevarlas a cabo. Si son implementados por los servidores, la
modelo de aplicacin que se especifica en el RFC 821 debe ser utilizada y la
los nombres de comandos deben ser publicados en la respuesta al comando EHLO.
Direccin del autor
John C. Klensin
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140
Estados Unidos
EMail: john+smtp@jck.com

Declaracin de los derechos completa
Copyright (C) El IETF Trust (2008).
Este documento est sujeto a los derechos, licencias y restricciones

contenida en el BCP 78, y salvo lo dispuesto en l, los autores
conservar todos sus derechos.
Este documento y la informacin contenida en este documento se proporcionan en

una
"TAL CUAL" y LA Contribucin, LA ORGANIZACIN HE / ELLA REPRESENTA
O est patrocinado por (si las hubiere), la sociedad de Internet, el IETF
confianza Y
LA INGENIERA DE INTERNET Grupo renuncia a toda garanta, expresa
O implcita, incluyendo pero no limitado a ninguna garanta de que el uso de
LA INFORMACIN este documento no vulnere cualquier derecho o cualquier
implcita
GARANTAS DE COMERCIALIZACIN O IDONEIDAD PARA UN PROPSITO PARTICULAR.
Propiedad intelectual
El IETF no toma posicin respecto a la validez o el alcance de cualquier

Los derechos de propiedad intelectual u otros derechos que puedan ser
reclamados a
pertenecen a la aplicacin o el uso de la tecnologa descrita en
este documento o en la medida en que ninguna licencia de dichos derechos
puede o no estar disponibles; ni representa que tiene
hecho ningn esfuerzo para identificar independiente de cualquiera de esos
derechos. Informacin
Sobre los procedimientos con respecto a los derechos en los documentos RFC
pueden ser
encontrado en el BCP 78 y BCP 79.
Las copias de las divulgaciones de DPI hechas a la Secretara y cualquier IETF

Garantas de las licencias que se facilitar, o el resultado de una
Intento de obtener una licencia o permiso para el uso de
tales derechos de propiedad de los ejecutores y los usuarios de este
especificacin se puede obtener desde el repositorio IPR IETF en lnea en
http://www.ietf.org/ipr.
El IETF invita a alguna de las partes interesadas a que sealen a su atencin

cualquier
los derechos de autor, patentes o solicitudes de patentes u otros derechos de
propiedad
los derechos que podra incluir la tecnologa que pueden ser necesarias para
poner en prctica
esta norma. Por favor dirigirse a la informacin a la IETF en
ietf-ipr@ietf.org.

Protocolo Simple de Transferencia de Correo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protocolo Simple de Transferencia de Correo

Uploaded by

Copyright:

Available Formats

Protocolo simple de transferencia de correo

Grupo de Trabajo de la Red de J. Klensin

Protocolo simple de transferencia de correo

Este documento especifica un protocolo de seguimiento de normas de Internet

Este documento es una especificacin del protocolo bsico de Internet

Klensin Normas Track [Page 2]

Klensin Normas Track [Page 3]

6.1. Entrega fiable y respuestas por correo electrnico. . . . . . . . . .

1.1. Transporte de Correo Electrnico

El objetivo del Protocolo de transferencia de correo simple (SMTP) es de

SMTP es independiente del subsistema de transmisin particular y

Una caracterstica importante de SMTP es su capacidad para transportar correo

De esta manera, un mensaje de correo electrnico puede pasar a travs de un

1.2. Historia y contexto de este documento

Este documento es una especificacin del protocolo bsico para el

o el original SMTP (Simple Mail Transfer Protocol) especificacin de

o Los requisitos del sistema de nombres de dominio y las implicaciones para el

o las aclaraciones y declaraciones de aplicacin en el RFC 1123 [3],

o material extrado de los mecanismos de extensin SMTP en el RFC 1869

Tambin incluye material adicional de RFC 1123 que requiere

Aunque SMTP fue diseado como un transporte de correo y protocolo de entrega,

Seccin 2.3 proporciona definiciones de trminos especficos de este

1.3. Convenciones del documento

Klensin Normas Track [Pgina 6]

ejemplos ilustrativos que no debera realmente ser utilizados en cualquiera de

2.1. Estructura basica

El diseo SMTP se puede representar como:

Cuando un cliente SMTP tiene un mensaje que transmitir, se establece un

El medio por el cual un mensaje de correo electrnico se presenta a un cliente

Klensin Normas Track [Pgina 7]

Un servidor SMTP puede ser el destino final o una

En otras palabras, la transferencia de mensajes puede ocurrir en una sola

Una vez establecido el canal de transmisin y protocolo de enlace inicial

El servidor responde a cada comando con una respuesta; respuestas pueden

Klensin Normas Track [Pgina 8]

actas. Adems, un cliente de SMTP puede usar una conexin a una

Como se sugiri anteriormente, este protocolo proporciona mecanismos para la

Por lo general, los huspedes intermediarios son determinados a travs del

2.2. El modelo de extensin

En un esfuerzo que comenz en el ao 1990, aproximadamente una dcada despus

SMTP es ampliamente desplegado y las implementaciones de alta calidad han

Klensin Normas Track [Pgina 9]

o El comando SMTP EHLO, dejando sin efecto la anterior HELO,

Registro OA de las extensiones del servicio SMTP,

o Los parmetros adicionales al correo SMTP RCPT y comandos, y

o reemplazos opcionales para los comandos definidos en este protocolo, tales

La fuerza de SMTP proviene principalmente de su simplicidad. Experiencia con

Todos y cada extensin, independientemente de sus beneficios, deben estar

2.2.2. Definicin y registro de las extensiones

La IANA mantiene un registro de las extensiones del servicio SMTP. UN

o el nombre textual de la extensin del servicio SMTP;

o la palabra clave EHLO valor asociada a la extensin;

o los valores de sintaxis y posibles de parmetros asociados con el

o Los nuevos parmetros de los asociados de extensin con el correo o RCPT

Descripcin OA de cmo el apoyo a la extensin afecta a la

Klensin Normas Track [Pgina 10]

o el incremento que la extensin est aumentando al mximo

Adems, cualquier valor de palabra clave EHLO de partida con un superior o

verbos y nombres de parmetros adicionales estn sujetos a las mismas reglas

2.2.3. Problemas especiales con extensiones

Las extensiones que puedan modificar las propiedades bastante bsicas de

En particular, si una extensin implica que la trayectoria de suministro

2.3. SMTP Terminologa

2.3.1. Objetos de correo