Red Grupo de Trabajo P.

Resnick, Editor Peticin de Comentarios: 2822 QUALCOMM Incorporated Obsoletes: 822 04 2001 Categora: Normas Track Formato de mensaje de Internet Condicin de este Memo Este documento especifica un protocolo de normas de Internet para el Comunidad de Internet, y solicita debate y sugerencias para mejoras. Por favor refirase a la edicin actual de la Internet " Normas Oficiales Protocolo "(STD 1) para la normalizacin y el estado de este protocolo. La distribucin de este memorndum es ilimitada. Copyright Notice Copyright (C) The Internet Society (2001). Todos los derechos reservados. Abstracto Esta norma especifica una sintaxis para los mensajes de texto que se envan entre los usuarios de computadoras, en el marco del "correo electrnico" mensajes. Esta norma sustituye a la especificada en la solicitud de Comments (RFC) 822, "Norma para el Formato de Texto ARPA Internet Mensajes ", su actualizacin para reflejar las prcticas actuales y la incorporacin de cambios incrementales que se especifica en el RFC otros. Tabla de contenidos 1. Introduccin ............................................... 3 1.1. Alcance ................................................. ... 3 1.2. Las convenciones de notacin ................................... 4 1.2.1. La notacin de los requisitos de .................................. 4 1.2.2. Notacin sintctica ..................................... 4 1.3. Estructura de este documento ............................... 4 2. Anlisis lxico de los mensajes de ............................... 5 2.1. Descripcin general ...................................... 5 2.1.1. Lmites de longitud de lnea ..................................... 6 2.2. Los campos de cabecera ............................................ 7 2.2.1. Organismos no estructurados campo de encabezado ....................... 7 2.2.2. Campo de cabecera estructurado rganos ......................... 7 2.2.3. Campos de cabecera que ..................................... 7 2.3. Cuerpo ................................................. .... 8 3. Sintaxis ................................................. .... 9 3.1. Introduccin ............................................. 9 3.2. Fichas lxicas ........................................... 9

Resnick Normas Track [Pgina 1]

RFC 2822 Internet Message Format 04 2001 3.2.1. Fichas primitiva ....................................... 9 3.2.2. Personajes citados ...................................... 10 3.2.3. Espacio plegable en blanco y comentarios ....................... 11 3.2.4. Atom ................................................. .. 12 3.2.5. Cadenas entre comillas ......................................... 13 3.2.6. Varios testigos ................................... 13 3.3. Especificacin de fecha y hora .............................. 14 3.4. Especificacin de la direccin .................................... 15 3.4.1. Addr-spec especificacin ................................ 16 3,5 sintaxis mensaje general .................................... 17 3.6. Las definiciones de campo ........................................ 18 3.6.1. El campo de fecha de originacin ............................. 20 3.6.2. Campos creador ...................................... 21 3.6.3. Campos de la direccin de destino ............................. 22 3.6.4. Los campos de identificacin .................................. 23 3.6.5. Campos de informacin ................................... 26 3.6.6. Resienten los campos .......................................... 26 3.6.7. Campos de seguimiento ........................................... 28 3.6.8. Los campos opcionales ........................................ 29 4. Obsoletos sintaxis ............................................ 29 4.1. Varios testigos obsoletos ............................ 30 4.2. Obsoleto plegables espacio blanco ............................. 31 4.3. Fecha y hora obsoletos ................................... 31 4.4. Abordar obsoletos ...................................... 33 4.5. Campos de cabecera obsoletos ................................... 33 4.5.1. Origen obsoletos campo de fecha ........................ 34 4.5.2. Campos obsoletos creador ............................. 34 4.5.3. Obsoletos los campos de direccin de destino .................... 34 4.5.4. Campos de identificacin obsoletos ......................... 35 4.5.5. Obsoletos los campos de informacin .......................... 35 4.5.6. Obsoletos resienten campos ................................. 35 4.5.7. Campos obsoletos rastro .................................. 36 4.5.8. Obsoletos los campos opcionales ............................... 36 5. Consideraciones de Seguridad .................................... 36 6. Bibliografa ............................................... 37 7. Direccin del Editor ........................................... 38 8. Agradecimientos ........................................... 39 Apndice A. Ejemplo de mensajes .................................. 41 A.1. Ejemplos abordar ...................................... 41 A.1.1. Un mensaje de una persona a otra con sencillo abordar ............................................. 41 A.1.2. Los diferentes tipos de buzones de correo ........................... 42 A.1.3. Direcciones de grupo ........................................ 43 A.2. Mensajes de respuesta ........................................... 43 A.3. Resienten mensajes .......................................... 44 A.4. Los mensajes con campos de seguimiento ............................... 46 A.5. El espacio en blanco, comentarios y otras rarezas ................ 47 A.6. Formas obsoletas .......................................... 47

Resnick Normas Track [Page 2] RFC 2822 Internet Message Format 04 2001 A.6.1. Obsoletos frente a .................................... 48 A.6.2. Fechas obsoletos ......................................... 48 A.6.3. Espacio obsoleto en blanco y comentarios ...................... 48 Apndice B. Las diferencias de las anteriores normas ................ 49 Apndice C. Avisos ........................................... 50 Declaracin Completa de Copyright ...................................... 51 1. Introduccin 1.1. Alcance Esta norma especifica una sintaxis para los mensajes de texto que se envan entre los usuarios de computadoras, en el marco del "correo electrnico" mensajes. Esta norma sustituye a la especificada en la solicitud de Comments (RFC) 822, "Norma para el Formato de Texto ARPA Internet Mensajes "[RFC822], su actualizacin para reflejar las prcticas actuales y la incorporacin de los cambios incrementales que se especifica en el RFC otros [STD3]. Esta norma especifica una sintaxis slo para mensajes de texto. En particular, que no prev la transmisin de imgenes, tipo de audio, o de otro tipo de datos estructurados en mensajes de correo electrnico. Hay varias extensiones publicados, tales como el documento MIME serie [RFC2045, RFC2046, RFC2049], que describen los mecanismos para la la transmisin de estos datos por correo electrnico, ya sea por extender la sintaxis proporcionada aqu o mediante la estructuracin de este tipo de mensajes a cumplir con esta sintaxis. Estos mecanismos estn fuera del alcance de la esta norma. En el contexto de correo electrnico, los mensajes son vistos como teniendo un sobre y su contenido. El sobre contiene la informacin que sea necesarios para llevar a cabo la transmisin y la entrega. (Ver [RFC2821] para una discusin de los sobres.) Los contenidos comprenden el objeto que se entregado al destinatario. Esta norma se aplica slo al formato de y algunos de la semntica de los contenidos de los mensajes. No contiene especificacin de la informacin en el sobre. Sin embargo, algunos sistemas de mensaje puede utilizar la informacin de los contenidos para crear el sobre. Se pretende que esta norma facilitar la adquisicin de dicha informacin por programas. Esta especificacin pretende ser una definicin de cul es el mensaje formato de contenido se va a pasar entre los sistemas. Aunque algunos mensajes sistemas a nivel local almacenar mensajes en este formato (que elimina la

necesidad de traduccin entre los formatos) y otras utilizan formatos que difieren de los especificados en este estndar de almacenamiento, locales es fuera del alcance de esta norma.

Resnick Normas Track [Page 3] RFC 2822 Internet Message Format 04 2001 Nota: Esta norma no pretende dictar los formatos internos utilizados por los sitios, el sistema de mensaje de caractersticas especficas que son espera que el apoyo, o de cualquiera de las caractersticas de la interfaz de usuario programas que crean o leer mensajes. Adems, esta norma no especifica una codificacin de los personajes, ya sea para el transporte o almacenamiento, es decir, que no especifica el nmero de bits utilizados o como estos bits son transferidos especficamente a travs del cable o almacenada en el disco. 1.2. Las convenciones de notacin 1.2.1. Los requisitos de la notacin En este documento se utiliza de vez en trminos que aparecen en letras maysculas. Cuando los trminos "DEBE", "DEBE", "recomendada", "NO DEBE", "DEBE NO ", y" MAYO ", aparecen en maysculas, que estn siendo utilizados para indicar necesidades particulares de esta especificacin. Una discusin de las significado de estos trminos aparece en [RFC2119]. 1.2.2. Notacin sintctica Esta norma utiliza el ampliado de Backus-Naur Form (ABNF) notacin se especifica en [RFC2234] para la definicin formal de la sintaxis de mensajes. Los caracteres se especifican, ya sea por un valor decimal (Por ejemplo, el d65% del valor de mayscula y minscula para D97% A) o por un valor literal de maysculas y minsculas entre comillas (por ejemplo, "A", ya sea en maysculas o minsculas A). Ver [RFC2234] para la plena descripcin de la notacin. 1.3. Estructura del documento Este documento se divide en varias secciones. En esta seccin, la seccin 1, es una breve introduccin sobre el documento. La seccin 2 presenta la descripcin general de un mensaje y su partes constitutivas. Este es un resumen para ayudar al lector a comprender algunos de los principios generales utilizados en las partes posteriores de este documento. Algunos ejemplos en esta seccin no deben tomarse como especificacin de la sintaxis formal de cualquier parte de un mensaje.

La seccin 3 especifica las reglas formales ABNF para la estructura de cada parte de un mensaje (la sintaxis) y describe la relacin entre las partes y su significado en el contexto de un mensaje (el semntica). Es decir, que describe las reglas actuales de la estructura de cada parte de un mensaje (la sintaxis), as como una descripcin de las piezas y las instrucciones sobre cmo deben ser interpretados (la semntica). Esto incluye el anlisis de la sintaxis y la semntica de

Resnick Normas Track [Page 4] RFC 2822 Internet Message Format 04 2001 subpartes de los mensajes que tienen una estructura especfica. La sintaxis incluidos en la seccin 3 representa los mensajes que se deben crear. Tambin hay notas en la seccin 3 para indicar si alguna de las opciones especificado en la sintaxis se debe utilizar sobre cualquiera de los otros. Ambas secciones 2 y 3 describen los mensajes que son legales para generar a los efectos de esta norma. Seccin 4 de este documento especifica un "obsoleto" sintaxis. Hay referencias en la seccin 3 de las presentes elementos sintcticos obsoletos. La las reglas de la sintaxis de obsoletas, son elementos que han aparecido en revisiones anteriores de esta norma, o han sido ampliamente utilizados en los mensajes de Internet. Por lo tanto, estos elementos deben ser interpretado por analizadores de mensajes con el fin de ser conformes a este estndar. Sin embargo, dado que los elementos de la sintaxis se ha determinado a falta de interoperabilidad o de causar problemas significativos para destinatarios de los mensajes, no deben ser generados por los creadores de Mensajes conformes. La seccin 5 detalla las consideraciones de seguridad a tener en cuenta a la hora aplicacin de esta norma. Seccin 6 es una bibliografa de las referencias en este documento. Seccin 7 contiene la direccin del editor. La seccin 8 contiene reconocimientos. Apndice A se muestran ejemplos de diferentes tipos de mensajes. Estos ejemplos no son exhaustivos de los tipos de mensajes que aparecen en Internet, sino dar una visin general de ciertas formas sintcticas. Apndice B muestra las diferencias entre esta norma y anteriores normas para los mensajes de Internet. Apndice C tiene avisos de copyright y propiedad intelectual.

2. Anlisis lxico de los mensajes 2.1. Descripcin General En el nivel ms bsico, un mensaje es una serie de caracteres. A mensaje de que es conforme con esta norma se compone de personajes con valores en el rango de 1 a 127 y se interpreta como US-ASCII [ASCII]. Por razones de brevedad, el presente documento a veces se refiere a esta gama de personajes simplemente como "US-ASCII".

Resnick Normas Track [Page 5] RFC 2822 Internet Message Format 04 2001 Nota: La norma especifica que los mensajes se componen de caracteres en el rango de US-ASCII de 1 a 127. Hay otros documentos, especficamente la serie de documentos MIME [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049], que se extienden a esta norma para permitir que los valores fuera de ese rango. La discusin de esos mecanismos no se encuentra dentro de el alcance de esta norma. Los mensajes se dividen en lneas de caracteres. Una lnea es una serie de personajes que se delimita con los dos caracteres de retorno de carro y la lnea de alimentacin, es decir, el retorno de carro (CR) de caracteres (ASCII valor de 13) seguido inmediatamente por el avance de lnea (LF) (ASCII valor 10). (El par retorno de carro se suele escribir en este documento como "CRLF".) Un mensaje se compone de los campos de cabecera (llamados en conjunto "en el encabezado del mensaje "), seguido, opcionalmente, por un cuerpo. La cabecera es un secuencia de lneas de caracteres con sintaxis especial tal como se define en esta norma. El cuerpo es simplemente una secuencia de caracteres que sigue a la cabecera y se separa de la cabecera de una lnea en blanco (Es decir, una lnea con nada anterior a la CRLF). 2.1.1. Lmites de longitud de lnea Hay dos lmites que esto pone de serie en el nmero de caracteres en una lnea. Cada lnea de caracteres debe ser no ms de 998 caracteres, y no debe ser mayor de 78 caracteres, excluyendo el CRLF. El lmite de caracteres es 998 debido a las limitaciones en muchas implementaciones que enviar, recibir, o que tienda en Internet mensajes de formato de mensaje simplemente no pueden manejar ms de 998 caracteres en una lnea. Recepcin implementaciones hara bien para manejar un nmero arbitrariamente grande

de caracteres en una lnea por el bien de la solidez. Sin embargo, no son tan muchas implementaciones que (de conformidad con el transporte requisitos de [RFC2821]) no aceptan mensajes que contengan ms de 1000 caracteres incluyendo la lnea por CR y LF, es importante para las implementaciones de no crear ese tipo de mensajes. La ms conservadora recomendacin 78 es de carcter para dar cabida a las muchas implementaciones de interfaces de usuario que muestran estos mensajes que pueden truncar, o desastrosamente abrigo, la pantalla de ms de 78 caracteres por lnea, a pesar del hecho de que tales implementaciones no son conformes a la intencin de esta especificacin (y la de [RFC2821] si realmente la causa prdida de informacin). Una vez ms, a pesar de esta limitacin se pone en mensajes, es encumbant las implementaciones que mostrar mensajes Resnick Normas Track [Pgina 6] RFC 2822 Internet Message Format 04 2001 para manejar un nmero arbitrariamente grande de caracteres en una lnea (Por cierto, al menos hasta el lmite de caracteres 998) por el bien de robustez. 2.2. Los campos de cabecera Campos de la cabecera se compone de las lneas de un nombre de campo, seguido de dos puntos (":"), Seguido de un cuerpo de campo, y terminada por CRLF. Un campo nombre debe estar compuesto por caracteres imprimibles US-ASCII (es decir, personajes que tienen valores entre 33 y 126, ambos inclusive), salvo colon. Un cuerpo de campo puede estar compuesto de caracteres US-ASCII, a excepcin de CR y LF. Sin embargo, un cuerpo de campo puede contener cuando CRLF utilizados en la cabecera de "plegado" y "desarrollo" como se describe en la seccin 2.2.3. Todos los cuerpos de campo deber ajustarse a la sintaxis descrita en las secciones 3 y 4 de esta norma. 2.2.1. No estructurados Cuerpos Campo de cabecera Algunos cuerpos de campo en esta norma se definen simplemente como "No estructurados" (que se expresa a continuacin los caracteres US-ASCII, a excepcin de CR y LF), sin restricciones. Estos son conoce como cuerpos de campo no estructurados. Semnticamente, no estructurados cuerpos de campo son slo para ser tratados como una sola lnea de caracteres sin procesamiento adicional (excepto para el encabezado "plegado" y "Desarrollo" como se describe en la seccin 2.2.3). 2.2.2. Estructurado Cuerpos Campo de cabecera Algunos cuerpos de campo en esta norma han especficas sintcticas estructura ms restrictivos que los cuerpos de campo no estructurados se ha descrito anteriormente. Estos se conocen como cuerpos "estructurada" sobre el terreno. Instancias estructuradas de campo son secuencias especficas de fichas lxicas como descritos en las secciones 3 y 4 de esta norma. Muchos de estos smbolos

se les permite (de acuerdo con su sintaxis) que se introduzcan o terminar con comentarios (como se describe en la seccin 3.2.3), as como el espacio (SP, Valor ASCII 32) y tabulador horizontal (HTAB, el valor ASCII 9) caracteres (Conocidos en conjunto como los espacios en blanco, el PAS) y los PAS los personajes estn sujetos a la cabecera de "plegado" y "desarrollo" como se describe en la seccin 2.2.3. Anlisis semntico de campo estructurado cuerpos se administra junto con su sintaxis. 2.2.3. Campos de cabecera que Cada campo de encabezado es lgicamente una sola lnea de caracteres, de los el nombre del campo, el colon, y el cuerpo sobre el terreno. Para mayor comodidad Sin embargo, y para hacer frente a las limitaciones de caracteres por lnea 998/78, la parte del cuerpo de un campo de cabecera se puede dividir en un mltiplo representacin de la lnea, lo que se llama "plegable". La regla general es

Resnick Normas Track [Page 7] RFC 2822 Internet Message Format 04 2001 que donde quiera que esta norma permite plegar el espacio blanco (no personajes simplemente WSP), un CRLF se puede insertar antes de PSA. Para ejemplo, el campo de la cabecera: Asunto: Esto es una prueba se puede representar como: Asunto: Este es una prueba Nota: A pesar de instancias estructuradas de campo est definido de tal manera que plegamiento puede tener lugar entre muchas de las fichas lxicas (e incluso en algunas de las fichas lxicas), plegables deben estar limitados a la colocacin de la CRLF a alto nivel sintctico rompe. Por ejemplo, si cuerpo de un campo se define como valores separados por comas, se recomienda plegables que se producen despus de la coma que separa los elementos de estructura en preferencia a otros lugares donde podra ser el campo de plegado, incluso si se permite en otros lugares. El proceso de pasar de este doblado varias lneas de representacin de un campo de encabezado en su representacin de una sola lnea que se llama "Evolucin". Despliegue se realiza mediante la simple eliminacin de cualquier CRLF que es seguido inmediatamente por el PAS. Cada campo de cabecera debe ser tratado en su forma desplegada por ms sintctica y semntica evaluacin. 2.3. Cuerpo

El cuerpo de un mensaje es simplemente lneas de caracteres US-ASCII. La slo dos limitaciones en el cuerpo son las siguientes: - CR y LF DEBE slo ocurren al mismo tiempo como CRLF, no deben aparecer de forma independiente en el cuerpo. - Las lneas de caracteres en el cuerpo debe limitarse a 998 caracteres, y debe limitarse a 78 caracteres, excluyendo el CRLF. Nota: Como se indic anteriormente, existen documentos de otras normas, especficamente los documentos MIME [RFC2045, RFC2046, RFC2048, RFC2049] que se extienden a esta norma para permitir diferentes tipos de mensaje cuerpos. Una vez ms, estos mecanismos estn fuera del alcance de este documento.

Resnick Normas Track [Page 8] RFC 2822 Internet Message Format 04 2001 3. Sintaxis 3.1. Introduccin La sintaxis que figura en esta seccin define la sintaxis legal de Mensajes de Internet. Los mensajes que se conformes con esta norma Deber ajustarse a la sintaxis en esta seccin. Si hay opciones en esta seccin en la que debera ser una opcin generada, que se indica ya sea en prosa o en un comentario junto a la sintaxis. De las expresiones definidas, una breve descripcin de la sintaxis y la uso se le da, seguido de la sintaxis en ABNF, seguido de una semntica anlisis. Smbolos primitivos que se utilizan, pero no especificada de otra manera provienen de [RFC2234]. En algunas de las definiciones, habr no-terminales, cuyos nombres comienzan con "obs-". Estos "obs-" elementos se refieren a smbolos definidos en la sintaxis obsoleta en la seccin 4. En todos los casos, estas producciones se deben ignorar a los efectos de la generacin de Internet legal mensajes y no debern ser utilizados como parte de un mensaje. Sin embargo, la hora de interpretar los mensajes, estas seales deben ser respetados como parte de la sintaxis legal. En este sentido, el artculo 3 define una gramtica para generacin de mensajes, con "obs-" elementos que deben ser ignorados, mientras que el artculo 4 aade la gramtica para la interpretacin de los mensajes.

3.2. Fichas lxicas Las siguientes reglas se utilizan para definir una base lxica analizador, que se alimenta de las fichas de los analizadores de nivel superior. Este seccin define los smbolos utilizados en los rganos estructurados campo de encabezado. Nota: Los lectores de esta norma han de prestar especial atencin a cmo estas fichas lxicas se utilizan tanto en el nivel inferior y alto nivel de sintaxis ms adelante en el documento. En particular, el blanco fichas de espacio y las fichas de observacin se define en la seccin 3.2.3 se acostumbra en las fichas de nivel inferior se define aqu, y las fichas de menor nivel a su vez se usan como parte de las fichas de ms alto nivel se define ms adelante. Por lo tanto, el espacio en blanco y comentarios pueden ser permitidos en el de ms alto nivel fichas, aunque no explcitamente pueden aparecer en un definicin particular. 3.2.1. Fichas primitiva Los siguientes son smbolos primitivos que se refiere a la otra parte de este estndar, pero que no se definen en [RFC2234]. Algunos de ellos se No aparecen en ningn otro lugar en la sintaxis, pero son convenientes para se refieren a otras partes de este documento.

Resnick Normas Track [Page 9] RFC 2822 Internet Message Format 04 2001 Nota: Los "especiales" a continuacin son slo un ejemplo. A pesar de la especiales smbolo no aparece en ningn otro lugar en esta norma, es til para los ejecutores que utilizan las herramientas que analizar lxicamente mensajes. Cada uno de los personajes especiales se pueden utilizar para indicar un punto de los comandos en el anlisis lxico. NO-WS-CTL =% d1-8 /; US-ASCII caracteres de control % D11 /, que no incluyen la D12% /; de retorno de carro, avance de lnea % D14-31 /, y los caracteres de espacio en blanco % D127 text =% d1-9 /; Personajes excluyendo CR y LF % D11 / % D12 / % D14-127 / obs-texto especiales = "(" / ")" /, los caracteres especiales utilizados en "<" / ">" /; Otras partes de la sintaxis "[" / "]" /

":" / "," / "@" / "\" / "," / "." / DQUOTE No semntica especial se adjunta a estas fichas. Se trata simplemente de caracteres individuales. 3.2.2. Personajes citados Algunos caracteres estn reservados para la interpretacin especiales, tales como delimitacin de fichas lxicas. Para permitir el uso de estos personajes, los datos no interpretados, un mecanismo de cita se proporciona. citado par = ("\" text) / obs-qp En caso de cualquier cita de par aparece, debe ser interpretado como el texto carcter nico. Es decir, el carcter "\" que aparece como parte de una cita de par es semnticamente "invisible". Nota: El carcter "\" puede aparecer en un mensaje en el que no es parte de una cita de par. Un carcter "\" que no aparece en un cita de par no es semnticamente invisible. Los nicos lugares en este estndar en el citado par aparece actualmente son ccontent, qcontent, dcontent, no doble-citar, no veces literal-.

Resnick Normas Track [Pgina 10] RFC 2822 Internet Message Format 04 2001 3.2.3. Espacio plegable en blanco y comentarios Los espacios en blanco, incluyendo el espacio blanco que se utiliza en el plegamiento (Que se describe en la seccin 2.2.3), pueden aparecer entre muchos elementos en rganos de campo de encabezado. Adems, las cadenas de caracteres que se tratan como Los comentarios pueden ser incluidos en los rganos de campo estructurado como personajes entre parntesis. A continuacin se definen el plegamiento blanca espacio (FWS) y construye un comentario. Las cadenas de caracteres entre parntesis se consideran comentarios siempre y cuando no aparecen dentro de una "cita de cadena", tal como se define en la seccin 3.2.5. Los comentarios pueden anidar. Hay varios lugares en esta norma en los comentarios y FWS puede ser libremente insertado. Para dar cabida a que la sintaxis, una muestra adicional para "CFWS" se define por los lugares donde los comentarios y / o FWS puede ocurrir. Sin embargo, cuando CFWS se produce en esta norma, no se deben introducir

de tal manera que cualquier lnea de un campo de encabezado plegado se compone solamente caracteres del PSA y nada ms. FWS = ([* WSP CRLF] 1 * WSP) /; espacio en blanco plegable obs-FWS ctext = NO-WS-CTL /; no controla el espacio en blanco % D33-39 /, y el resto de la US-ASCII % D42-91 /, sin incluir los caracteres "(", % D93-126, ")", o "\" ccontent = ctext / cita de par / comentario comment = "(" * ([FWS] ccontent) [FWS] ")" CFWS = * ([FWS] comentario) (([FWS] comentario) / FWS) A lo largo de esta norma, donde FWS (el smbolo de doblar el espacio en blanco) aparece, indica un lugar en el plegamiento de cabecera, como se discuti en la seccin 2.2.3, puede tener lugar. Siempre que sea plegable encabezado aparece en un mensaje (es decir, un cuerpo que contiene un campo de cabecera CRLF seguido por cualquier WSP), encabezado desarrollo (extirpacin de la CRLF) se realiza antes cualquier anlisis lxico ms se lleva a cabo en ese campo de la cabecera de acuerdo con esta norma. Es decir, cualquier CRLF que aparece en FWS es semnticamente "invisible". Un comentario se utiliza normalmente en un cuerpo de campo estructurado para proporcionar algunos humanos textos informativos legible. Desde un comentario se le permite contienen FWS, plegable est permitido dentro de los comentarios. Tambin tenga en cuenta que ya citado de par se permite en un comentario, parntesis y

Resnick Normas Track [Pgina 11] RFC 2822 Internet Message Format 04 2001 caracteres de barra invertida puede aparecer en un comentario, siempre y cuando aparezcan como una cita de par. Semnticamente, los parntesis no estn parte del comentario, el comentario es lo que est contenido entre los dos entre parntesis. Como se dijo anteriormente, la "\" en cualquier cita de par y la CRLF en cualquier FWS que aparece dentro de los comentarios son semnticamente "Invisible" y por tanto, no parte del comentario sea. Las series de comunicacin escrita, el comentario o CFWS que se producen entre fichas lxicas en un campo de cabecera estructurado son semnticamente interpretado como una sola carcter de espacio.

3.2.4. tomo Varias producciones en el campo de cabecera estructurado rganos son simplemente cadenas de ciertos caracteres bsicos. Entre esas producciones se llaman los tomos. Algunos de los cuerpos campo estructurado de cabecera tambin permiten que el perodo de carcter (".", valor ASCII 46) en carreras de atext. Adicionales "Dot-tomo" token se define para esos fines. atext = ALPHA / DIGIT /; Cualquier carcter excepto los controles, "!" / "#" /, SP, y especiales. "$" / "%" /, Que se utiliza para los tomos "&" / "" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "` "/" {"/ "|" / "}" / "~" tomo = [CFWS] 1 * atext [CFWS] punto-tomo = [CFWS] punto tomo de texto [CFWS] punto tomo de texto = 1 * 1 * atext *("." atext) Ambos tomo y tomo de puntos-se interpretan como una sola unidad, integrada por la cadena de caracteres que lo componen. Semnticamente, la opcin comentarios y FWS que rodea el resto de los personajes no son parte del tomo, el tomo es slo la serie de caracteres atext en un tomo, o el atext y "." personajes en un punto del tomo.

Resnick Normas Track [Pgina 12] RFC 2822 Internet Message Format 04 2001 3.2.5. Cadenas entre comillas Las cadenas de caracteres que incluyen caracteres que no sean los permitidos en los tomos pueden ser representadas en un formato de cadena entre comillas, donde los personajes estn rodeados de cotizacin (DQUOTE, el valor ASCII 34) personajes.

qtext = NO-WS-CTL /; no controla el espacio en blanco % D33 /, y el resto de la US-ASCII D35-91% /, sin incluir los caracteres "\" % D93-126, o el carcter de comillas qcontent = qtext / cita par citada cadena = [CFWS] DQUOTE * ([FWS] qcontent) [FWS] DQUOTE [CFWS] Una cita de cadena se trata como una unidad. Es decir, citada cadena es idntico al tomo, semnticamente. Desde una cita de cadena se le permite contienen FWS, plegable est permitido. Tambin tenga en cuenta que desde que cotiza en el mercado de par se permite en una cita de cadena, los caracteres de comillas y barra invertida puede aparecen en una cita de cadena siempre y cuando se presentan como una cita de par. Semnticamente, ni el CFWS opcional fuera de la cita los personajes ni los caracteres de comillas son ellos mismos parte de la citada cadena, la citada cadena es lo que est contenido entre los dos caracteres de comillas. Como se dijo anteriormente, la "\" en cualquier cita de par y el CRLF en cualquier FWS / CFWS que aparece en la citada cadena se parte semnticamente "invisible" y no tanto, de la citada cadena tampoco. 3.2.6. Varios testigos Tres fichas adicionales se definen, palabras y frases para las combinaciones de los tomos y / o cadenas entre comillas-, y no estructurados para su uso en los campos no estructurados de cabecera y en algunos lugares dentro de estructura campos de cabecera. = palabra tomo / citada cadena frase = 1 * palabra / frase obs-

Resnick Normas Track [Pgina 13] RFC 2822 Internet Message Format 04 2001 utext = NO-WS-CTL /; no controla el espacio en blanco

% D33-126 /, y el resto de la US-ASCII obs-utext no estructurados = * ([FWS] utext) [FWS] 3.3. Fecha y hora de la especificacin Fecha y hora se producen en varios campos de la cabecera. En esta seccin se especifica la sintaxis de una fecha completa y la especificacin del tiempo. A pesar de plegado espacio en blanco se permite a travs de la especificacin de fecha y hora, se RECOMIENDA que un nico espacio se utilizar en cada lugar que FWS aparece (si es necesario u opcional), y algunos mayores implementaciones no pueden interpretar otras apariciones de plegado blanco el espacio correctamente. fecha y hora = [da de la semana ","] de fecha y hora FWS [CFWS] da de la semana = ([FWS] nombre del da) / obs-da de la semana da-name = "Mon" / "mar" / "Mar" / "Jueves" / "Vie" / "Sat" / "Sun" date = da mes ao ao = 4 * DIGIT / obs-ao mes = (FWS nombre del mes-FWS) / obs-mes mes-name = "Jan" / "febrero" / "Mar" / "abril" / "May" / "Jun" / "julio" / "agosto" / "Septiembre" / "octubre" / "noviembre" / "diciembre" da = ([FWS] 1 * 2 dgitos) / obs-da tiempo = tiempo del da FWS zona la hora del da = horas ":" minuto [":" segundos] hora = 2 dgitos / obs-hora minuto = 2 dgitos / obs-minuto segundo = 2 dgitos / obs-segundo zona = (("+" / "-") 4DIGIT) / obs-zona

Resnick Normas Track [Pgina 14]

RFC 2822 Internet Message Format 04 2001 El da es el da numrico del mes. El ao es cualquier numricos ao 1900 o posterior. La hora del da especifica el nmero de horas, minutos y opcionalmente segundos desde la medianoche de la fecha indicada. La fecha y la hora del da, debe expresar la hora local. La zona especifica el desplazamiento de Tiempo Universal Coordinado (UTC, anteriormente conocido como la "hora media de Greenwich") que la fecha y la hora del da representan. El "+" o "-" indica si el la hora del da est por delante de (es decir, al este de) o detrs (es decir, al oeste de) Tiempo Universal. Los dos primeros dgitos indican el nmero de horas diferencia de la hora universal, y los dos ltimos dgitos indican el nmero de minutos de diferencia a la hora universal. (Por lo tanto, + hhmm los medios + (hh * 60 mm +) minutos, y hhmm significa - (hh * 60 + mm) minutos). El formulario de "0000" DEBEN ser utilizados para indicar una zona horaria en la Tiempo Universal. Aunque "-0000", tambin indica la hora universal, es utiliza para indicar que el tiempo se ha generado en un sistema que puede ser en una zona horaria que no sea tiempo universal y por lo tanto indica que la fecha y hora no contiene informacin sobre los locales de zona horaria. Una especificacin de fecha y hora deben ser semnticamente vlido. Es decir, el da de la semana (si se incluye) debe ser el da que implica la fecha, el teclado numrico del da de mes debe estar entre 1 y el nmero de das permitido para el mes especificado (en el ao especificado), la la hora del da debe estar en el rango de 00:00:00 a 23:59:60 (la nmero de segundos, dejando para un segundo salto, ver [STD12]), y el zona debe estar dentro del rango de -9959 a 9959. 3.4. Direccin Especificacin Las direcciones se producen en varios campos de encabezado del mensaje para indicar que los remitentes y los receptores de los mensajes. Una direccin o bien puede ser un individuo buzn de correo, o un grupo de buzones. address = buzn de correo / grupo mailbox = nombre-dir / dir-spec nombre-dir = [display-name] ngulo-addr ngulo-dir = [CFWS] "<" addr-spec ">" [CFWS] / obs-ngulo-addr grupo = display-name ":" [buzn de la lista / CFWS] ";" [CFWS]

Resnick Normas Track [Pgina 15] RFC 2822 Internet Message Format 04 2001 display-name = frase buzn de correo-list = (buzn de correo *(",")) / obs-mbox-list direccin de la lista = (direccin *("," direccin)) / obs-addr-list Un buzn de correo recibe el correo. Se trata de una entidad conceptual que no necesariamente se refieren al almacenamiento de archivos. Por ejemplo, algunos sitios pueden optar por imprimir en una impresora de correo y entregar la produccin a la escritorio del destinatario. Normalmente, un buzn de correo se compone de dos partes: (1) un nombre para mostrar opcional que indica el nombre del destinatario (Que podra ser una persona o un sistema) que puede mostrar a la usuario de una aplicacin de correo, y (2) una direccin addr-spec encerrado en parntesis angulares ("<" y ">"). Tambin hay una forma sencilla alternativa de un buzn en la direccin addr-spec aparece solo, sin la el nombre del destinatario o de los parntesis angulares. Internet addr-spec direccin se describe en la seccin 3.4.1. Nota: Algunas implementaciones legado utiliza la forma simple en que la addr-spec aparece sin los corchetes, pero incluy el nombre de del destinatario en parntesis como un comentario despus de la addr-spec. Dado que el significado de la informacin en un comentario no se especifica, implementaciones es conveniente utilizar el nombre completo-addr forma de buzn, en vez de la forma de legado, para especificar el nombre para mostrar asociado con un buzn de correo. Adems, debido a que algunas implementaciones de interpretar el legado el comentario, comentario general, no deben ser utilizados en los campos de direccin para no confundir este tipo de implementaciones. Cuando se desea para el tratamiento de varios buzones de correo como una sola unidad (Es decir, en una lista de distribucin), la construccin del grupo se puede utilizar. La grupo de construccin hace que el remitente para indicar un grupo con nombre de destinatarios. Esto se hace dando un nombre para el grupo, seguido de dos puntos, seguida por una lista separada por comas de cualquier nmero de buzones de correo (incluyendo el cero y uno), y terminando con un punto y coma. Debido a que la lista de buzones de correo puede estar vaco, utilizando el grupo de construccin Tambin es una forma sencilla de comunicar a los destinatarios que el mensaje fue enviado a uno o ms conjuntos con nombre de los beneficiarios, sin llegar a proporcionar la direccin de correo individuales para cada uno de los destinatarios. 3.4.1. Addr-spec especificacin Un addr-spec es un identificador especfico de Internet que contiene una

cadena local interpretado seguido por el carcter arroba ("@", Valor ASCII 64) seguido por un dominio de Internet. El local cadena se interpreta ya sea una cita de cadena o un tomo de puntos. Si el cadena se puede representar como un punto de tomos (es decir, que no contiene caracteres no atext o "." rodeado de atext

Resnick Normas Track [Pgina 16] RFC 2822 Internet Message Format 04 2001 caracteres), entonces la forma punto-tomo debe ser utilizada y la citada cadena formulario no debe ser utilizado. Comentarios y plegado blanco el espacio no debe ser utilizado alrededor de la "@" en el addr-spec. addr-spec = local-parte "@" dominio parte-local = punto-tomo / cita de cadena / obs-parte-local domain = punto-tomo / dominio literal / obs dominio dominio literal = [CFWS] "[" * ([FWS] dcontent) [FWS] "]" [CFWS] dcontent = DText / cita par DText = NO-WS-CTL /; no controla el espacio en blanco % D33-90 /, y el resto de la US-ASCII % D94-126, sin incluir los caracteres "[", ; "]", O "\" La parte del dominio identifica el punto en que el correo es entregado. En la forma punto-tomo, esto se interpreta como una Internet nombre de dominio (un nombre de host o un nombre de intercambio de correo) como se describe en [STD3, STD13, STD14]. En la forma de dominio-literal, la dominio se interpreta como la direccin de Internet literal de la host en particular. En ambos casos, cmo abordar y cmo se utiliza se transportan los mensajes a un host en particular est cubierto en el correo documento de transporte [RFC2821]. Estos mecanismos estn fuera de la alcance de este documento. La parte local de todo es una cadena de dominio dependiente. En las direcciones, se trata simplemente de interpretar en el host en particular como el nombre de una buzn de correo particular. 3,5 sintaxis mensaje general Un mensaje se compone de los campos de cabecera, seguido de un mensaje cuerpo. Las lneas de un mensaje debe ser un mximo de 998 caracteres excluyendo el CRLF, pero se recomienda que las lneas se limitar a 78

excluyendo los caracteres CRLF. (Vea la seccin 2.1.1 para una explicacin.) En el cuerpo del mensaje, a pesar de todos los caracteres que aparecen en el texto regla puede ser utilizado, el uso de caracteres de control US-ASCII (valores 1 a 8, 11, 12 y 14 a 31) no se recomienda, ya que su interpretacin por parte de los receptores para la visualizacin no est garantizada.

Resnick Normas Track [Pgina 17] RFC 2822 Internet Message Format 04 2001 message = (campos / obs-campos) [Cuerpo CRLF] body = * (* 998text CRLF) * 998text Los campos de cabecera llevan la mayor parte de la informacin semntica y se se define en la seccin 3.6. El cuerpo es simplemente una serie de lneas de texto que son sin interpretar a los efectos de esta norma. 3.6. Las definiciones de campo Los campos del encabezado de un mensaje se definen aqu. Todos los campos de la cabecera tienen la misma estructura sintctica en general: Un nombre de campo, seguido por dos puntos, seguido por el cuerpo sobre el terreno. La sintaxis especfica para cada campo de la cabecera se define en las secciones siguientes. Nota: En la sintaxis ABNF para cada campo en las siguientes secciones, cada una nombre del campo es seguido por los dos puntos necesarios. Sin embargo, por razones de brevedad a veces el colon no se hace referencia en la descripcin textual de la sintaxis. Es, sin embargo, necesaria. Es importante tener en cuenta que los campos de cabecera no se garantiza que estar en un orden particular. Pueden aparecer en cualquier orden, y han sido conocidos por ser reordenados en ocasiones cuando se transportan ms de la Internet. Sin embargo, a los efectos de esta cabecera estndar, los campos no deben ser reordenadas cuando un mensaje se transporta o transformado. Ms importante an, los campos de cabecera de seguimiento y resienten campos de cabecera, no debern ser reordenados, y debe mantenerse en los bloques al principio del mensaje. Vanse las secciones 3.6.6 y 3.6.7 para ms de la informacin. Los campos de cabecera slo se requiere son el campo de fecha de origen y el campo de la direccin de autor (s). Todos los campos de la cabecera otros sintcticamente opcional. Ms informacin est contenida en la tabla

despus de esta definicin. * = campos (trace * (Resentimiento fecha / resentimiento de / resentimiento remitente / resentimiento a / resentimiento cc / resentimiento bcc / resentimiento msg-id)) * (Orig-fecha / de / emisor / Responder a /

Resnick Normas Track [Pgina 18] RFC 2822 Internet Message Format 04 2001 a/ cc / CCO / mensaje-id / en respuesta a / referencias / sujeto / Comentarios / palabras clave / opcional de campo) La siguiente tabla indica los lmites en el nmero de veces que cada campo puede ocurrir en un encabezado del mensaje, as como cualquier dao especial limitaciones en el uso de esos campos. Un asterisco junto a un valor en la columna de mnimos o mximos indica que una restriccin especial aparece en la columna Notas. Min campo Nmero mximo nmero de notas traza 0 ilimitada Bloque antepone - ver 3.6.7 resentimiento fecha 0 * ilimitado * A una cuadra por, requiere si otros resienten los campos presente - ver 3.6.6 resentimiento de 0 ilimitado * Uno por bloque - ver 3.6.6 resentimiento remitente 0 * ilimitado * A una cuadra por, DEBE

ocurrir con multi-direccin resentimiento de - vase 3.6.6 resentimiento a 0 ilimitado * Uno por bloque - ver 3.6.6 resentimiento cc 0 ilimitado * Uno por bloque - ver 3.6.6 resentimiento bcc 0 ilimitado * Uno por bloque - ver 3.6.6 resentimiento msg-id 0 ilimitado * Uno por bloque - ver 3.6.6 orig-fecha 1 1 de 1 1 Ver el remitente y el 3.6.2

Resnick Normas Track [Pgina 19] RFC 2822 Internet Message Format 04 2001 remitente 0 * 1 debe ocurrir con la multidireccin de - vase 3.6.2 Responder a 0 1 a01 cc 0 1 bcc 0 1 Message-ID 0 * 1 debe estar presente - ver 3.6.4 en respuesta a 0 * 1 debe ocurrir en algunos Respuestas - vase 3.6.4 referencias 0 * 1 debe ocurrir en algunos Respuestas - vase 3.6.4 tema 0 1 0 comentarios ilimitados 0 palabras clave ilimitada

opcional de campo ilimitado 0 La interpretacin exacta de cada campo se describe en el siguiente secciones. 3.6.1. El campo de fecha de originacin El campo de fecha de iniciacin consiste en el nombre del campo "Fecha", seguida por una especificacin de fecha y hora. orig-date = "Fecha:" fecha y hora CRLF La fecha de origen especifica la fecha y hora en que el creador del mensaje indica que el mensaje fue completo y listo para entrar en el sistema de entrega de correo. Por ejemplo, este podra ser el momento que un usuario pulsa "Enviar" o botn "enviar" en una aplicacin del programa. En cualquier caso, lo que no est dirigida a transmitir la momento en que el mensaje se transporta, sino ms bien el momento en que el creador humano u otro de los mensajes ha puesto el mensaje en su forma final, lista para su transporte. (Por ejemplo, un porttil usuario de la computadora que no est conectado a una red podra en cola un mensaje

Resnick Normas Track [Pgina 20] RFC 2822 Internet Message Format 04 2001 para la entrega. La fecha de iniciacin est destinado a contener la fecha y el tiempo que el usuario en la cola el mensaje, no el momento en que el usuario conectado a la red para enviar el mensaje.) 3.6.2. Campos originador Los campos de remitente de un mensaje consiste en el campo, el campo del remitente (si procede), y, opcionalmente, el campo de respuesta. El campo consiste en el nombre del campo "De" y un lista separada por comas de una o ms especificaciones buzn. Si el desde el campo contiene ms de una especificacin de buzn en el buzn de la lista, entonces el campo del remitente, que contenga el nombre del campo "Remitente" y una especificacin de un nico buzn, debe aparecer en el mensaje. En cualquier caso, una opcin de respuesta al campo puede ser incluido, el cual contiene el nombre del campo "Responder a" y un lista separada por comas de una o ms direcciones. from = "From:" buzn de la lista CRLF sender = "Sender:" buzn CRLF Responder a = "Responder a:" Direccin de la lista CRLF

Los campos de autor indican el buzn de correo (es) de la fuente de la mensaje. El campo "De:" campo especifica el autor (s) del mensaje, es decir, el buzn de correo (es) de la persona (s) o sistema (s) responsable para la redaccin del mensaje. El "Sender:" campo especifica el buzn del agente responsable de la transmisin real de la mensaje. Por ejemplo, si un secretario fuera a enviar un mensaje de otra persona, el buzn de la secretaria que aparecen en el "Sender:" campo y el buzn de los verdaderos autores que aparecen en "De:" campo. Si el autor del mensaje puede ser indicado por un nico buzn y el autor y el transmisor son idnticos, "Sender:" el campo no debe ser usado. De lo contrario, ambos campos deben aparecen. Los campos originales tambin proporcionar la informacin requerida cuando responder a un mensaje. Cuando el "Responder a:" el campo est presente, indica que el buzn de correo (es) a la que el autor del mensaje sugiere que las respuestas se enviarn. En ausencia de la "Responder a:" el campo, Las respuestas debern ser enviadas por defecto al buzn de correo (es) especificado en el "De:" campo a menos que se especifique lo contrario por la persona que componen el respuesta. En todos los casos, el campo "De:" El campo no debe contener ningn buzn que no pertenece a la autora (s) del mensaje. Vase tambin la seccin 3.6.3 para obtener ms informacin sobre la formacin de las direcciones de destino para un respuesta.

Resnick Normas Track [Pgina 21] RFC 2822 Internet Message Format 04 2001 3.6.3. Campos de la direccin de destino Los campos de destino de un mensaje consta de tres mbitos posibles, cada uno de la misma forma: El nombre del campo, que es "A", "Cc", o "CCO", seguida por una lista separada por comas de una o ms direcciones (Ya sea buzn o la sintaxis de grupo). a = "Para:" direccin de la lista CRLF cc = "Cc:" direccin de la lista CRLF bcc = "CCO:" (direccin de la lista / [CFWS]) CRLF Los campos de destino especifique los destinatarios del mensaje. Cada campo de destino puede tener una o ms direcciones, y cada uno de los indican las direcciones de los destinatarios del mensaje. El nico diferencia entre los tres campos es cmo se utiliza cada uno.

El campo "Para:" campo contiene la direccin (es) del receptor primario (s) del mensaje. El "Cc:" el campo (donde el "Cc" significa "Carbon Copy" en el sentido de hacer una copia en una mquina de escribir con papel carbn) contiene la direcciones de otros que van a recibir el mensaje, aunque la contenido del mensaje no puede ser dirigida a ellos. El "CCO:" el campo (donde la "copia oculta" significa "Blind Carbon Copy") contiene direcciones de los destinatarios del mensaje, cuyas direcciones no deben ser revel a otros destinatarios del mensaje. Hay tres formas en las que el "CCO:" el campo se utiliza. En el primer caso, cuando un mensaje contiene un "CCO:" el campo est preparado para ser enviado, el "CCO:" la lnea es eliminado a pesar de que todos los destinatarios (incluyendo aquellos especificados en el "CCO:" sobre el terreno) se envi una copia del mensaje. En el segundo caso, los destinatarios especificados en el campo "Para:" y "CC:" las lneas de cada uno se envan una copia del mensaje con el "CCO:" eliminar la lnea que el anterior, pero el destinatarios de la "CCO:" la lnea de conseguir una copia separada del mensaje contiene un "CCO:" lnea. (Cuando hay mltiples destinatarios direcciones en el "CCO:" el campo, algunas implementaciones en realidad enviar un copia separada del mensaje a cada destinatario con un "CCO:" que contiene slo la direccin de ese receptor en particular.) Finalmente, ya que un "CCO:" el campo no puede contener direcciones, un "CCO:" El campo se puede enviado sin ningn tipo de direcciones que indican a los destinatarios que ciega se enviaron copias a alguien. El mtodo a utilizar con "CCO:" los campos depende de la implementacin, sino que se refieren a la seguridad " Consideraciones "de este documento para una discusin de cada uno.

Resnick Normas Track [Pgina 22] RFC 2822 Internet Message Format 04 2001 Cuando un mensaje es una respuesta a otro mensaje, los buzones de los los autores del mensaje original (los buzones de correo en el campo "De:" del campo) o buzones de correo especificada en el "Responder a:" (si existe) MAYO aparecen en el campo "Para:" de la respuesta, ya que estos normalmente se los destinatarios principales de la respuesta. Si se enva una respuesta a un mensaje que los campos de destino, a menudo es conveniente enviar una copia de la respuesta a todos los destinatarios del mensaje, adems de la autor. Cuando esta respuesta se forma, las direcciones en el campo "Para:" y "Cc:" los campos del mensaje original puede aparecer en el "Cc:" campo de la la respuesta, ya que estos suelen ser los destinatarios de la secundaria respuesta. Si un "CCO:" el campo est presente en el mensaje original, direcciones en este campo puede aparecer en el "CCO:" de la respuesta, pero no deben aparecer en el campo "Para:" o "Cc:" los campos.

Nota: Algunas aplicaciones de correo tienen comandos de respuesta automtica que incluyen las direcciones de destino del mensaje original en el direcciones de destino de la respuesta. Cmo se comportan los comandos de respuesta depende de la implementacin y est fuera del alcance de este documento. En particular, no se si para incluir el destino original direcciones cuando el mensaje original tiene una "Responder a:" El campo no es se tratan aqu. 3.6.4. Los campos de identificacin Aunque opcional, cada mensaje debe tener un "Message-ID:" campo. Adems, los mensajes de respuesta debe tener "In-Reply-To:" y "Referencias:" los campos en su caso, como se describe a continuacin. El "Message-ID:" contiene un nico identificador de mensaje nico. El "Referencias" y "In-A-Respuesta:" el campo cada uno contiene una o ms identificadores nicos mensaje, separada por CFWS. El identificador de mensaje (msg-id) es similar en sintaxis a un ngulo-addr construir sin el CFWS interna. mensaje-id = "Message-ID:" msg-id CRLF en respuesta a = "In-Reply-To:" 1 * msg-id CRLF referencias = "Referencias:" 1 * msg-id CRLF msg-id = [CFWS] "<" izquierda-id "@" id a la derecha ">" [CFWS] id-izquierda = punto tomo de texto / no-plegable cotizacin / obs-id-izquierda id-derecha = punto tomo de texto / no-plegable literal / obs-id-derecha no doble-quote = DQUOTE * (qtext / cotizar-pareja) DQUOTE

Resnick Normas Track [Pgina 23] RFC 2822 Internet Message Format 04 2001 veces no-literal = "[" * (DText / cotizar-pareja) "]" El "Message-ID:" el campo proporciona un identificador nico mensaje que se refiere a una versin particular de un mensaje particular. La singularidad del identificador de mensajes est garantizada por la acogida que lo genera (ver ms abajo). Este identificador de mensaje est destinado a ser legible por mquina, y no necesariamente significativo para los seres humanos. Un mensaje corresponde exactamente a un identificador de instancia de un particular mensaje, las revisiones posteriores al mensaje de cada uno recibe un nuevo mensaje identificadores.

Nota: Hay muchos casos en que los mensajes son "cambiado", pero los los cambios no constituyen una instancia nueva de ese mensaje, y por lo tanto, el mensaje no obtener un identificador de un nuevo mensaje. Para ejemplo, cuando los mensajes se introducen en el sistema de transporte, que a menudo son precedidas por los campos de cabecera adicionales, tales como trazas campos (que se describe en la seccin 3.6.7) y resienten los campos (que se describe en seccin 3.6.6). La adicin de los campos de cabecera no modifica la identidad del mensaje y por lo tanto, el original "Message-ID:" campo se mantiene. En todos los casos, es el sentido de que el remitente del mensaje desea transmitir (es decir, si este es el mismo mensaje o un mensaje diferente), que determina si el "Message-ID:" cambios en el campo, no una diferencia sintctica que aparece (o no aparece) en el mensaje. El "In-Reply-To:" y "Referencias:" Los campos se utilizan cuando se crea una responder a un mensaje. Ellos tienen el identificador de mensaje del original mensaje y los identificadores de mensaje de los mensajes de otros (por ejemplo, en el caso de una respuesta a un mensaje que a su vez era una respuesta). La "In-Reply-To:" El campo puede ser utilizado para identificar el mensaje (o mensajes) para que el nuevo mensaje es una respuesta, mientras que el "Referencias:" El campo se puede utilizar para identificar a un "hilo" de conversacin. Al crear una respuesta a un mensaje, el "In-Reply-To:" y "Referencias:" Los campos del mensaje resultante se construyen como siguiente manera: El "In-Reply-To:" campo contendr el contenido del "mensajeID: "de que el mensaje que esta es una respuesta (el" padre mensaje "). Si hay ms de un mensaje de los padres, entonces el" InResponder a: "campo contendr el contenido de todos los padres "Message-ID:" los campos. Si no hay un "Message-ID:" en cualquier campo de los mensajes de los padres, entonces el nuevo mensaje no tendr "In-Reply-To:" sobre el terreno.

Resnick Normas Track [Pgina 24] RFC 2822 Internet Message Format 04 2001 El "Referencias:" campo contendr el contenido de la matriz "Referencias" de campo (si los hay), seguido por el contenido de la matriz "Message-ID:" sobre el terreno (si existe). Si el mensaje de los padres no contiene un "Referencias:" el campo, pero tiene un "In-Reply-To:" campo que contiene un identificador nico mensaje, entonces el "Referencias:" el campo contendr el contenido de los padres "In-Reply-To:" campo

seguido por el contenido de los padres "Message-ID:" el campo (si los hay). Si el padre no tiene ninguna de las "Referencias", "In-Reply-To:", o "Message-ID:" los campos, entonces el nuevo mensaje no tendr "Referencias:" campo. Nota: Algunas implementaciones de analizar las "referencias" de campo para mostrar el "hilo de la discusin". Estas implementaciones asumir que cada nuevo mensaje es una respuesta a una madre soltera y que por lo tanto se puede caminar hacia atrs a travs de la "Referencias:" el campo para encontrar a los padres de cada mensaje aparece all. Por lo tanto, tratando de formar un "Referencias" de campo para una respuesta que tiene varios padres se desanimado y cmo hacer para que no se define en este documento. El identificador de mensaje (msg-id) s debe ser un nico global identificador de un mensaje. El generador del identificador de mensaje Debe garantizar que el msg-id es nico. Hay varios algoritmos que se pueden utilizar para lograr esto. Desde el msg-id ha una sintaxis similar al ngulo-addr (idnticas, excepto que los comentarios y espacio en blanco plegado no se permiten), un buen mtodo es poner la nombre de dominio (o una direccin IP del dominio literal) de la mquina en la que el identificador de mensaje se ha creado en el lado derecho de la "@", y poner una combinacin de la fecha actual y el tiempo absolutos, junto con algn otro momento nico (tal vez secuencial) identificador disponibles en el sistema (por ejemplo, un nmero de identificacin de proceso) en la mano izquierda secundarios. Usando una fecha en el lado izquierdo y un nombre de dominio o el dominio literal en el lado derecho hace que sea posible garantizar singularidad ya que no hay dos mquinas usan el mismo nombre de dominio o direccin IP al mismo tiempo. Aunque los algoritmos de otros trabajos, es RECOMIENDA que el lado derecho contiene un identificador de dominio (Ya sea de la propia sede o no) de tal manera que el generador de el identificador de mensaje puede garantizar la exclusividad de la mano izquierda lado en el mbito de ese dominio. Semnticamente, los personajes de soporte en ngulo no forman parte de la msg-id, el msg-id es lo que est contenido entre el soporte de ngulo de dos personajes.

Resnick Normas Track [Pgina 25] RFC 2822 Internet Message Format 04 2001 3.6.5. Campos de informacin

Los campos de informacin son opcionales. El "Palabras clave:" el campo contiene una lista separada por comas de una o ms palabras o cita de cadenas. El "Asunto" y "Comentarios:" los campos son los campos no estructurados como se define en la seccin 2.2.1, y por lo tanto puede contener texto o espacios en blanco plegado. subject = "Asunto:" CRLF no estructurados comentarios = "Comentarios:" CRLF no estructurados palabras clave = "Palabras clave:" frase *("," frase) CRLF Estos tres campos estn destinados a tener slo legible para el contenido con informacin sobre el mensaje. El "Asunto:" es la ms comn y contiene una cadena corta identificar el tema de la mensaje. Cuando se utiliza en una respuesta, el cuerpo de campo puede comenzar con la cadena "Re:" (del latn "res", en el asunto de) seguido de el contenido del "Asunto:" campo cuerpo del mensaje original. Si se hace esto, slo una instancia de la cadena literal "Re:" debe para ser utilizado ya que el uso de otras cadenas o una instancia ms de uno puede llevar a consecuencias indeseables. Los "Comentarios:" campo contiene comentarios adicionales sobre el texto del cuerpo del mensaje. La "Palabras claves:" contiene una lista separada por comas de palabras importantes y frases que podran ser tiles para el destinatario. 3.6.6. Resienten los campos Resienten los campos deben ser aadidos a cualquier mensaje que se presentada de nuevo por un usuario en el sistema de transporte. Un conjunto separado de resentir los campos Se debe agregar cada vez se hace esto. Todos los campos de resentimiento que corresponde a un particular de volver a enviar el mensaje debe ser juntos. Cada nuevo conjunto de campos se resienten al principio del mensaje; es decir, el conjunto ms reciente de resentir los campos aparecen antes en el mensaje. No hay otros campos en el mensaje que se modifican al resentimiento campos se agregan. Cada uno de los campos resienten corresponde a un campo particular en otro lugar en la sintaxis. Por ejemplo, el "Reenviado-Date:" el terreno corresponde a la "Fecha:" campo y el "Reenviado-a:" corresponde a la "A" sobre el terreno. En cada caso, la sintaxis para el campo cuerpo es idntica a la la sintaxis dada anteriormente para el campo correspondiente. Cuando se resienten los campos son utilizados, el "Reenviado-De:" y "Reenviado-Date:" los campos deben ser enviados. El "Reenviado-Message-ID:" el campo debe ser enviada. "Reenviado-Sender:" no se debe utilizar si "Reenviado-Sender:" sera idntica a la "Reenviado-De:".

Resnick Normas Track [Pgina 26] RFC 2822 Internet Message Format 04 2001

resentir-date = "Reenviado-Date:" fecha y hora CRLF resentimiento de = "Reenviado-De:" buzn de la lista CRLF resentimiento remitente = "Reenviado-Sender:" buzn CRLF molesta a = "Reenviado-A:" direccin de la lista CRLF resentir-cc = "Reenviado-CC:" la direccin de lista de CRLF resentimiento bcc = "Reenviado-CCO:" (direccin de la lista / [CFWS]) CRLF resentimiento msg-id = "Reenviado-ID del mensaje:" msg-id CRLF Resienten los campos se utilizan para identificar un mensaje como si hubiera sido reintroducido en el sistema de transporte por un usuario. El propsito de la utilizando resienten los campos es que el mensaje aparezca a la final destinatario como si se hubiese enviado directamente por el remitente original, con todos los campos originales que quedan en el mismo. Cada conjunto de resentimiento campos corresponden a un evento de volver a enviar particular. Es decir, si un mensaje es reenviado varias veces, cada conjunto de campos da resienten informacin de identificacin para cada vez individual. Resienten los campos son estrictamente informativos. Ellos no debern ser utilizados en el curso normal procesamiento de las respuestas u otras acciones automticas en los mensajes. Nota: La reintroduccin de un mensaje en el sistema de transporte y el uso de resienten los campos es una operacin diferente de la "expedicin". "Desvo" tiene dos significados: Una sensacin de reenvo es que un e-mail programa de lectura puede ser contada por un usuario que transmita una copia de un mensaje a otra persona, haciendo que el mensaje enviado el cuerpo de la nueva mensaje. Un mensaje enviado en este sentido no parece haber provienen del remitente original, pero es un mensaje completamente nuevo de el promotor del mensaje. Por otro lado, es tambin el reenvo utiliza para decir cuando un cliente de correo recibe un mensaje y lo remite a un destino diferente para la entrega final. Resienten campos de cabecera no estn destinados para su uso con cualquier tipo de de reenvo. Los campos de autor resienten indicar el buzn de la persona (s) o sistema (s) que resienten el mensaje. Al igual que con el autor regulares campos, hay dos formas: una simple "Reenviado-De:" la forma que contiene el buzn de la persona haciendo el reenvo, y el forma ms compleja, cuando un individuo (identificado en la "Reenviado-Sender:" el campo) vuelve a enviar un mensaje en nombre de uno o ms otros (identificados en el "Reenviado-De:" del campo). Nota: Al responder a un mensaje reenviado, las respuestas se comportan igual que hara con cualquier otro mensaje, con el original "De:",

Resnick Normas Track [Pgina 27] RFC 2822 Internet Message Format 04 2001 "Responder a:", "Message-ID:", y otros campos. Los campos se resienten slo informativos y no debern ser utilizados en el procesamiento normal de respuestas. El "Reenviado-Date:" indica la fecha y la hora en que se resienten mensaje es enviado por el resender del mensaje. Al igual que el "Fecha:" el campo, no es la fecha y hora que el mensaje fue realmente se transporta. El "Reenviado-Para:", "Reenviado Cc-:", y "Reenviado-CCO:" la funcin campos idntica a la "A:", "Cc:", y "CCO:" los campos, respectivamente, salvo que se indique a los destinatarios del mensaje no se resienten, los destinatarios del mensaje original. El "Reenviado-Message-ID:" el campo proporciona un identificador nico para el resienten mensaje. 3.6.7. Campos de seguimiento Los campos de seguimiento son un grupo de campos de cabecera que consiste en un opcional "Return-Path:" el campo, y uno o ms "Fecha:" los campos. El "Return-Path:" campo de encabezado contiene un par de parntesis angulares que incluya una opcin addr-spec. La "Fecha:" contiene una (Posiblemente vaca) lista de pares nombre / valor seguido por un punto y coma y una especificacin de fecha y hora. El primer elemento del par nombre / valor es definido por el punto de nombre, y el segundo es o bien un addr-spec, una tomo, un dominio o una Identificacin del msg-. Otras restricciones pueden aplicar a la sintaxis de los campos de seguimiento de las normas que establecen sus uso, tales como [RFC2821]. trace = [volver] 1 * recibido retorno = "Return-Path:" CRLF camino path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / obs-path recibido = "Fecha:" nombre-val-lista "," fecha y hora CRLF nombre-val-list = [CFWS] [nombre-val-par * (CFWS nombre-val-par)] el nombre de par-val = nombre del elemento-CFWS valor del elementoitem-name = ALPHA *(["-"] (ALPHA / DIGIT)) elemento-valor = 1 * ngulo addr / addr-spec /

tomo / domain / msg-id

Resnick Normas Track [Pgina 28] RFC 2822 Internet Message Format 04 2001 Una discusin completa sobre el uso de correo de Internet de los campos de seguimiento se contenidas en [RFC2821]. A los efectos de esta norma, la traza los campos son estrictamente informativos, y cualquier interpretacin formal de que se encuentra fuera del alcance de este documento. 3.6.8. Los campos opcionales Los campos pueden aparecer en los mensajes que son de otra manera no especificada en este estndar. Que deber ajustarse a la sintaxis de un campo opcional. Se trata de un nombre de campo, formado por los caracteres imprimibles US-ASCII excepto SP y el colon, seguido de dos puntos, seguido por cualquier texto que se ajusta a no estructurados. Los nombres de campo de cualquier campo opcional-no debe ser idntico a cualquier campo de nombre especificado en otras partes de esta norma. opcional de campo = campo de nombre ":" CRLF no estructurados nombre de campo = 1 * TextoNO TextoNO% = d33-57 /; Cualquier carcter excepto % D59-126, los controles, SP, y ; ":". A los efectos de esta norma, cualquier campo es opcional sin interpretar. 4. Sintaxis obsoletos Las versiones anteriores de esta norma permite para diferentes (por lo general ms liberal) de sintaxis que se permite en esta versin. Asimismo, se han sido elementos sintcticos utilizados en los mensajes a travs de Internet, cuyo interpretacin no han sido documentados. Aunque algunos de estos formas sintcticas, no debern ser generados de acuerdo con la gramtica la seccin 3, que debe ser aceptado y analizado por un receptor conforme. En esta seccin se documenta muchos de estos elementos sintcticos. Tomando el gramtica en la seccin 3 y la adicin de las definiciones utilizadas en este seccin dar lugar a la gramtica a utilizar para la interpretacin de mensajes. Nota: Esta seccin identifica las formas sintcticas que cualquier aplicacin Razonablemente debe interpretar. Sin embargo, hay sin duda Internet Mensajes que no se ajusten a incluso la sintaxis adicional dada en

esta seccin. El hecho de que una forma particular no aparece en ninguna seccin de este documento no es una justificacin para los programas de ordenador de accidente o de datos con formato incorrecto que se pierde irremediablemente por cualquier implementacin. Para repetir un ejemplo, aunque este documento se requiere lneas en los mensajes que no ms de 998 caracteres, en silencio

Resnick Normas Track [Pgina 29] RFC 2822 Internet Message Format 04 2001 descartando los personajes 999a y posteriores en una lnea sin advertencia seguira siendo el mal comportamiento de una aplicacin. Es por a la aplicacin para hacer frente a los mensajes con firmeza. Una diferencia importante entre el obsoleto (interpretacin) y el actual (generacin) la sintaxis es que en el campo de cabecera estructurado rganos (Es decir, entre el colon y el CRLF de cualquier cabecera estructurado campo), los caracteres de espacio en blanco, incluidos espacios en blanco plegado, y Los comentarios pueden ser libremente insertado entre los smbolos sintcticos. Este permite muchas formas complejas que han demostrado ser difcil para algunos implementaciones de analizar. Otra diferencia clave entre el obsoleto y es la sintaxis actual que la regla en el punto 3.2.3 respecto a las lneas compuesto en su totalidad de espacio en blanco en los comentarios y espacios en blanco plegables no se aplica. Ver la discusin de doblar el espacio en blanco en la seccin 4.2. Por ltimo, algunos personajes que antes se les permita en los mensajes aparecen en esta seccin. El carcter NUL (cdigo ASCII 0) fue una vez permitido, pero ya no es por razones de compatibilidad. CR y LF permite que aparezca en los mensajes que no sean como CRLF; este uso tambin es se muestra aqu. Otras diferencias en la sintaxis y la semntica se indican en la siguiente secciones. 4.1. Varios testigos obsoletos Estos elementos sintcticos se utilizan en otras partes de la sintaxis obsoleta o en la sintaxis principal. Los elementos obs-char y obs-qp cada complemento ASCII el valor 0. Desnudas CR y LF desnudo se aaden a obs-texto y obs-utext. El carcter de punto se aade a obs-frase. El obs-frase-list prev "vaco" elementos de una lista separada por comas de las frases. Nota: El "perodo" (o "punto final") de carcter (".") en obs-la frase es no una forma que se permite en versiones anteriores de este o cualquier otro estndar. Perodo (ni ningn otro personaje de ofertas), no se permitido en la frase, ya que introduca una dificultad de anlisis distinguir entre las frases y partes de un addr-spec (ver

seccin 4.4). Aparece aqu porque el carcter de punto es actualmente se utilizan en muchos mensajes en la parte de visualizacin del nombre de direcciones, sobre todo por las iniciales de los nombres, y por lo tanto debe ser interpretado correctamente. En el futuro, el perodo puede aparecer en la sintaxis regular de la frase. obs-qp = "\" (% d0-127) obs-text = LF * * CR * (obs-char * LF CR *)

Resnick Normas Track [Pgina 30] RFC 2822 Internet Message Format 04 2001 obs-char =% d0-9 /% d11 /;% d0-127, excepto CR y D12% /% d14-127, LF obs-utext = obs-texto obs-frase = palabra * (palabra / "". / CFWS) obs-frase-list = frase / 1 * ([frase] [CFWS] "," [CFWS]) [la frase] Desnudas CR y LF desnudo aparece en los mensajes con dos significados diferentes. En muchos casos, desnudas o desnudas CR LF se utilizan incorrectamente en lugar de CRLF para indicar los separadores de lnea. En otros casos, desnudos y desnudas CR LF utiliza simplemente como caracteres ASCII de control con sus tradicionales ASCII significados. 4.2. Obsoletos espacio en blanco plegado En la sintaxis obsoleta, cualquier cantidad de espacio en blanco plegables pueden ser insertado en la regla obs-FWS est permitido. Esto crea la posibilidad de tener dos aos consecutivos "pliegues" en una lnea, y por lo tanto, la posibilidad de que una lnea que representa un encabezado plegado campo podra estar compuesto en su totalidad de los espacios en blanco. obs-FWS = 1 * * WSP (CRLF 1 * WSP) 4.3. Fecha y hora obsoletos La sintaxis para el formato de fecha obsoleto permite a un ao de 2 dgitos en el campo de fecha y permite una lista de zona horaria alfabtico especificaciones que fueron utilizados en versiones anteriores de esta norma. Tambin permite que los comentarios y espacios en blanco plegado entre muchos de los fichas. obs-da de la semana = [CFWS] nombre del da [CFWS]

obs-ao = [CFWS] 2 * dgitos [CFWS] obs-mes = CFWS nombre del mes-CFWS obs-da = [CFWS] 1 * 2 dgitos [CFWS] obs-hora = [CFWS] 2 dgitos [CFWS] obs-minuto = [CFWS] 2 dgitos [CFWS] obs-segundo = [CFWS] 2 dgitos [CFWS] obs-zona = "UT" / "GMT" /; Tiempo Universal

Resnick Normas Track [Pgina 31] RFC 2822 Internet Message Format 04 2001 , En Amrica del Norte UT , Las compensaciones "EST" / "EDT" /; del Este: - 5 / - 4 "CST" / "CDT" /; Central: - 6 / - 5 "MST" / "MDT" /; Montaa: - 7 / - 6 "PST" / "PDT" /; del Pacfico: - 8 / - 7 % D65-73 /, las zonas militares - "A" % D75-90 /, a travs de "I" y "K" % D97-105 /, a travs de "Z", tanto % D107-122, en maysculas y minsculas Donde un nio de dos o tres dgitos se produce en una fecha, el ao se interpretado de la siguiente manera: Si un ao de dos dgitos que se encuentra valor est entre 00 y 49, el ao se interpreta mediante la adicin de 2000, terminando con un valor entre 2000 y 2049. Si un ao con dos dgitos encontr con un valor entre 50 y 99, o un ao de tres dgitos se encuentra, el ao se interpreta mediante la adicin de 1900. En la zona horaria en desuso, "UT" y "GMT" indicios de "Tiempo universal" y "Tiempo Medio de Greenwich", respectivamente, y son a la vez semnticamente idntico al "0000". Los otros tres zonas de carcter son las zonas horarias de EE.UU.. La primera carta, "E", "C", "M", o "P" significa "oriental", "Central", "Montaa" y "Pacfico". La segunda letra es "S" para "Standard" de tiempo, o "D" de "Daylight" (o verano) el tiempo. Sus las interpretaciones son las siguientes: EDT es semnticamente equivalente a -0400 EST es semnticamente equivalente a -0500

CDT es semnticamente equivalente a -0500 CST es semnticamente equivalente a -0600 MDT es semnticamente equivalente a -0600 MST es semnticamente equivalente a -0700 PDT es semnticamente equivalente a -0700 PST es semnticamente equivalente a -0800 Las zonas 1 carcter militar de tiempo se define de una manera no estndar forma en [RFC822] y por lo tanto, impredecible en su significado. Las definiciones originales de las zonas militares "A" a "yo" se equivalente a "0100" al "0900", respectivamente, "K", "L" y "M" es equivalente a "1000", "1100", y "1200", respectivamente, "N" a travs de "Y" son equivalentes a "-0100" a travs de "-1200", respectivamente; y "Z" es equivalente a "0000". Sin embargo, debido al error en [RFC822], todos ellos deben considerarse equivalente a "-0000" a menos que existe fuera de la banda de la informacin que confirma su significado.

Resnick Normas Track [Pgina 32] RFC 2822 Internet Message Format 04 2001 Otros mltiples caracteres (generalmente entre 3 y 5) zonas alfabtico tiempo se han utilizado en los mensajes de Internet. Cualquier zona momento en que significado no es conocido debera considerarse como equivalente a "-0000" a menos que exista fuera de la banda de la informacin que confirma su significado. 4.4. Abordar obsoletos Hay tres diferencias principales en el tratamiento. En primer lugar, en el buzn direcciones se les permiti tener una porcin de la ruta antes de la addr-spec se encuentran dentro del "<" y ">". La ruta es simplemente una separada por comas lista de nombres de dominio, cada uno precedido por "@", y la lista termina por dos puntos. En segundo lugar, se les permiti CFWS entre el perodo separados elementos de la parte-local y de dominio (es decir, punto-tomo no se utiliz). En Adems, parte-local se puede contener citada cadena, adems de a tan slo un tomo. Por ltimo, el buzn de la lista y direccin de la lista-se les permiti tiene "nula" miembros. Es decir, podra haber dos o ms comas en como una lista sin nada entre ellos. obs-ngulo-dir = [CFWS] "<" [obs-ruta] addr-spec ">" [CFWS] obs-ruta = [CFWS] obs-domain-list ":" [CFWS] obs-domain-list = "@" dominio * (* (CFWS / ",") [CFWS] "@" dominio) obs-parte-local = palabra *("." palabra) obs-domain = tomo *("." tomo)

obs-mbox-list = 1 * ([buzn] [CFWS] "," [CFWS]) [buzn] obs-addr-list = 1 * ([direccin] [CFWS] "," [CFWS]) [direccin] En la interpretacin de las direcciones, la porcin de la ruta debe ser ignorado. 4.5. Campos de cabecera obsoletos Sintcticamente, la principal diferencia en la sintaxis del campo es obsoleto que permite que mltiples ocurrencias de cualquiera de los campos y puede que ocurrir en cualquier orden. Adems, cualquier cantidad de espacio en blanco se permite antes del ":" al final del nombre del campo. obs-campos * = (obs-retorno / obs-recibido / obs-orig-fecha / obs-de / obs-emisor / obs-respuesta-a / obs-a /

Resnick Normas Track [Pgina 33] RFC 2822 Internet Message Format 04 2001 obs-cc / obs-cco / obs-message-id / obs-in-reply-to / obs-referencias / obs-sujeto / obs-comentarios / obs-palabras / obs-resentimiento fecha / obs-resentimiento de / obs-molesta-send / obs-resentimiento rply / obs-molesta-a / obs-molesta-cc / obs-molesta-cco / obs-molesta-a mediados / obs-opcional) Excepto para los campos de direccin de destino (que se describe en la seccin 4.5.3), la interpretacin de las mltiples ocurrencias de los campos no se especifica. Adems, la interpretacin de los campos de seguimiento y resienten los campos que no no se presentan en bloques al principio del mensaje no se especifica as. A menos que se indique lo contrario en las siguientes secciones, la interpretacin de

otros campos es idntica a la interpretacin de su no obsoletos homlogos en la seccin 3. 4.5.1. Origen obsoletos campo de fecha obs-orig-date = "Fecha" * PAS ":" de fecha y hora CRLF 4.5.2. Campos obsoletos autor obs-from = "De" * PAS ":" buzn de la lista CRLF obs-remitente = "Remitente" * PAS ":" buzn CRLF obs-reply-to = "Responder a" * PAS ":" buzn de la lista CRLF 4.5.3. Obsoletos los campos de direccin de destino obs-to = "A" * PAS ":" direccin de la lista CRLF obs-cc = "Cc" * PAS ":" direccin de la lista CRLF obs-bcc = "Bcc" * PAS ":" (direccin de la lista / [CFWS]) CRLF

Resnick Normas Track [Pgina 34] RFC 2822 Internet Message Format 04 2001 Cuando mltiples ocurrencias de los campos de direccin de destino se producen en un mensaje, que debe ser tratado como si la direccin de la lista en el primer ocurrencia del campo se combina con las listas de direcciones de la las repeticiones posteriores mediante la adicin de una coma y la concatenacin. 4.5.4. Campos de identificacin obsoletos El obsoleto "In-Reply-To:" "Referencias:" y los campos difieren de los sintaxis actual en que permiten que la frase (palabras o cadenas entre comillas) para aparecen. Las formas obsoletas de los lados izquierdo y derecho del msg-id permiten CFWS intercalados, por lo que sintcticamente idntica a parte-local y de dominio, respectivamente. obs-message-id = "Message-ID" * PAS ":" msg-id CRLF obs-in-reply-to = "In-Reply-To" * PAS ":" * (frase / msg-id) CRLF obs-referencias = "Referencias" * PAS ":" * (frase / msg-id) CRLF obs-id-izquierda = local-parte

obs-id-derecha = dominio Para efectos de interpretacin, las frases de la "In-Reply-To:" y "Referencias:" Los campos se ignoran. Semnticamente, ninguno de los CFWS opcional que rodea la parte local y el dominio son parte de la obs-id-izquierda y obs-Identificacin del derecho , respectivamente. 4.5.5. Obsoletos los campos de informacin obs-subject = "Asunto" * PAS ":" CRLF no estructurados obs-comments = "Comentarios" * PAS ":" CRLF no estructurados obs-palabras clave = "Keywords" * PAS ":" obs-frase-lista CRLF 4.5.6. Obsoletos resienten los campos La sintaxis obsoleta aade un "Reenviado-Reply-To:" el campo, que consiste en del nombre del campo, los comentarios opcionales y un espacio en blanco plegado, el colon, y una lista separada por comas de las direcciones. obs-molesta-from = "Reenviado-Desde" * PAS ":" buzn de la lista CRLF obs-molesta-send = "Reenviado-Remitente" * PAS ":" buzn CRLF

Resnick Normas Track [Pgina 35] RFC 2822 Internet Message Format 04 2001 obs-molesta-date = "Reenviado-Date" * PAS ":" de fecha y hora CRLF obs-molesta-a = "Reenviado-Para" * PAS ":" direccin de la lista CRLF obs-molesta-cc = "Reenviado-Cc" * PAS ":" direccin de la lista CRLF obs-molesta-bcc = "Reenviado-CCO" * PAS ":" (Direccin de la lista / [CFWS]) CRLF obs-molesta-mid = "Reenviado-Message-ID" * PAS ":" msg-id CRLF obs-resentimiento rply = "Reenviado-Responder a" * PAS ":" direccin de la lista CRLF Al igual que con otros resienten los campos, el "Reenviado-Reply-To:" el campo se tratada como informacin de seguimiento solamente.

4.5.7. Campos obsoletos rastro El obs-retorno y obs-se recibi una vez ms que aqu como plantilla definiciones, as como el retorno y se reciben en la seccin 3. Sus sintaxis completa se da en [RFC2821]. obs-retorno = "Return-Path" * PAS ":" ruta CRLF obs-recibido = "Recibido" * PAS ":" nombre-val-lista CRLF obs-path = obs-ngulo-addr 4.5.8. Obsoletos los campos opcionales obs-opcional = nombre de campo * PAS ":" CRLF no estructurados 5. Consideraciones de seguridad Cuidado se debe tener cuando se muestran mensajes de un terminal o emulador de terminal. Terminales de poderosos pueden actuar en las secuencias de escape y otras combinaciones de caracteres ASCII de control con una variedad de consecuencias. Se puede reasignar el teclado o el otro permiso modificaciones a la terminal que podra conducir a una denegacin de servicio o incluso de datos daados. Que pueden provocar (a veces programable) Respuesta con mensajes que pueden permitir que un mensaje a causa de los comandos que se emitido en nombre del destinatario. Tambin puede afectar el funcionamiento de la terminal de los dispositivos conectados, como impresoras. Visores de mensajes puede desea quitar secuencias terminales potencialmente peligroso escape de el mensaje antes de la pantalla. Sin embargo, otras secuencias de escape aparecen en los mensajes con fines tiles (cf. [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049, ISO2022]) y por lo tanto no debe ser despojado de manera indiscriminada.

Resnick Normas Track [Pgina 36] RFC 2822 Internet Message Format 04 2001 La transmisin de la no-objetos de texto en mensajes de aumentos adicionales problemas de seguridad. Estos temas se discuten en [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049]. Muchas implementaciones de utilizar el "CCO:" (copia oculta) de campo describe en la seccin 3.6.3 para facilitar el envo de mensajes a destinatarios sin revelar las direcciones de uno o ms de los destinatarios a los dems destinatarios. Mal manejo de este uso de "CCO:" tiene implicaciones para la informacin confidencial que podra ser revelado, que eventualmente podra conducir a problemas de seguridad a travs del conocimiento de incluso la existencia de una direccin de correo electrnico en particular. Por ejemplo, si utilizando el mtodo descrito por primera vez en la seccin 3.6.3, donde el "CCO:"

lnea se quitan del mensaje, destinatarios ciegos no tienen explcito indicacin de que se les ha enviado una copia oculta, salvo en la medida su direccin no aparece en el encabezado del mensaje. A causa de esto, uno de los destinatarios ciego podra enviar una respuesta al todos los destinatarios se muestra y revela accidentalmente que el mensaje se fue al destinatario ciego. Cuando el segundo mtodo de la seccin 3.6.3 se utiliza, la direccin del destinatario ciego aparece en el "CCO:" campo de una copia separada del mensaje. Si el "CCO:" campo enviado contiene todos los destinatarios ciego, todos los "CCO:" los beneficiarios ser visto por cada uno "CCO:" destinatario. Incluso si un mensaje es independiente enviada a cada "CCO:" destinatario con slo la direccin de la persona, implementaciones todava hay que tener cuidado para procesar las respuestas a la mensaje de acuerdo con la seccin 3.6.3 a fin de no revelar accidentalmente el receptores ciegos a otros destinatarios. 6. Bibliografa [ASCII] American National Standards Institute (ANSI), codificado Conjunto de caracteres - 7-Bit de Amrica Cdigo Estndar Nacional de El intercambio de informacin, ANSI X3.4, 1986. [ISO2022] de la Organizacin Internacional de Normalizacin (ISO), Procesamiento de la informacin - ISO 7-bit y 8-bits codificados juegos de caracteres - cdigo tcnicas de extensin, Tercera edicin - 01.05.1986, ISO 2022, 1986. [RFC822] Crocker, D., "Norma para el Formato de ARPA Internet Mensajes de texto ", RFC 822, agosto de 1982. [RFC2045] Freed, N. y N. Borenstein, "Correo de Internet Multipropsito Extensions (MIME) Primera Parte: Formato de mensajes de Internet Cuerpos ", RFC 2045, noviembre de 1996. [RFC2046] Freed, N. y N. Borenstein, "Correo de Internet Multipropsito Extensions (MIME) Segunda Parte: Tipos de soportes ", RFC 2046, Noviembre de 1996.

Resnick Normas Track [Pgina 37] RFC 2822 Internet Message Format 04 2001 [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Tercera parte: Extensiones de cabecera de mensaje de texto no ASCII ", RFC 2047, noviembre de 1996. [RFC2048] Freed, N., Klensin, J. y J. Postel, "multipropsito Internet Mail Extensions (MIME) Cuarta Parte: Formato de Cuerpos de mensajes de Internet ", RFC 2048, noviembre de 1996.

[RFC2049] Freed, N. y N. Borenstein, "Correo de Internet Multipropsito Extensions (MIME) Quinta parte: criterios de conformidad y Ejemplos ", RFC 2049, noviembre de 1996. [RFC2119] Bradner, S., "Palabras clave para su uso en RFC para Indicar Niveles de exigencia ", BCP 14, RFC 2119, marzo de 1997. [RFC2234] Crocker, D., Editor, y Overell P., "aumentada para BNF Sintaxis Especificaciones: ABNF ", RFC 2234, noviembre de 1997. [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, marzo de 2001. [STD3] Braden, R., "Requisitos de acogida", STD 3, RFC 1122 y RFC 1123, octubre de 1989. [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, Septiembre de 1989. [STD13] Mockapetris, P., "Sistema de Nombres de Dominio", STD 13, RFC 1034 y RFC 1035, noviembre de 1987. [STD14] Partridge, C., "el enrutamiento de correo y el sistema de dominio", STD 14, RFC 974, enero de 1986. 7. Direccin del editor Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse unidad San Diego, CA 92121-1714 EE.UU. Telfono: +1 858 651 4478 Fax: +1 858 651 1102 EMail: presnick@qualcomm.com

Resnick Normas Track [Pgina 38] RFC 2822 Internet Message Format 04 2001 8. Agradecimientos Muchas personas contribuyeron a este documento. Entre ellos gente que participaron en la revisin detallada y actualizacin de mensajera

Normas (batera) Grupo de Trabajo de la Internet Engineering Task Force (IETF), el presidente de los tambores, los Directores de rea de la IETF, y personas que simplemente han enviado sus observaciones en la va e-mail. El editor es profundamente en deuda con todos ellos y les agradece sinceramente. El siguiente lista incluye a todos los que enviaron e-mail acerca de este documento. Con suerte, todos los que contribuyeron se llama aqu: Matti Aarnio Barry Finkel Larry Masinter Akira Tanaka Erik Forsberg Denis McKeon Russ Allbery Chuck Foster William P McQuillan Eric Allman Paul Fox Alexey Melnikov Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger Ran Atkinson Ned Freed Steven Miller Jos Backus Jochen Friedrich Keith Moore Bruce Balden Randall C. Gellens John Gardiner Myers Dave Barr Sukvinder Singh Gill Chris Newman Alan Barrett Tim Goodwin John W. Noerenberg John Beck Felipe Guenther Eric Norman J. Robert von Behren Tony Hansen, Mike O'Dell Jos den Bekker John Hawkinson Larry Osterman DJ Bernstein Philip Hazel Pablo Overell James Berriman Kai Henningsen Jacob Palme Norbert Bollow Robert Herriot Michael A. Patton Raj Bose Pablo Hethmon Uzi Paz Antony Bowesman Jim Hill Michael A. Quinlan Scott Bradner Paul E. Hoffman, Eric S. Raymond Randy Bush Steve agujero Sam Roberts Tom Byrer Kari Hurtta Hugh Sasse Bruce Campbell Marco S. Hyman Bart Schaefer Larry Campbell Ofer Inbar Tom Scola WJ Carpenter Olle Jarnefors Wolfgang Segmller Michael Chapman Kevin Johnson Nick Shelness Richard Clayton Sudish Joseph John Stanley Maurizio Codogno Maynard Kang Einar Stefferud Jim Conklin Prabhat Keni Jeff Stephenson R. Kelley John Cook C. Klensin Bernard Stern, Steve Coya Graham Klyne Pedro Silvestre Mark Crispin Knowles Brad marca Symons Dave Crocker Shuhei Kobayashi Eric Thomas Matt Curtin Peter Koch Lee Thompson Michael D'Errico Dan Kohn, Karel De Vriendt Ciro Daboo cristiana Kuhtz Mateo Muro Jutta Degener Anand Kumria Rolf Weber Marcar Delany Steen Larsen Brent B. Welch

Resnick Normas Track [Pgina 39] RFC 2822 Internet Message Format 04 2001

Steve Dorner Eliot Lear Dan ala Harold A. Driscoll Barry Leiba Jack De Invierno Michael Elkins Jay Levitt Gregory J. Woodhouse Robert Elz Lars-Johan Liman Greg A. Woods Johnny Eriksson Charles Lindsey Kazu Yamamoto Erik E. Feria Pete Loshin Alain Zahm Roger Fajman Simon Lyall Jamie Zawinski Patrik Faltstrom Bill Manning Timothy S. Zurcher Claus Andr Farber John Martin

Resnick Normas Track [Pgina 40]

RFC 2822 Internet Message Format 04 2001 Apndice A. Ejemplo de mensajes En esta seccin se presenta una seleccin de mensajes. Estos estn destinados a contribuir a la aplicacin de esta norma, pero no debe ser toman como norma, es decir, a pesar de los ejemplos de este seccin fueron revisados con cuidado, si es que hay un conflicto entre estos ejemplos y la sintaxis que se describe en las secciones 3 y 4 de este documento, la sintaxis de las secciones debe ser tomado como correcta. Los mensajes se delimitan en esta seccin entre las lneas de "----". La "----" Lneas no son parte del mensaje en s. A.1. Frente a ejemplos Los siguientes son ejemplos de mensajes que pueden ser enviados entre dos los individuos. A.1.1. Un mensaje de una persona a otra con sencillo frente a Esto se podra llamar un mensaje cannico. Tiene un solo autor, John Doe, un solo destinatario, Mary Smith, un tema, la fecha, un identificador de mensaje, y un mensaje de texto en el cuerpo. ---De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ----

Resnick Normas Track [Pgina 41] RFC 2822 Internet Message Format 04 2001 Si el secretario de Juan Miguel envi realmente el mensaje, aunque Juan fue el autor y las respuestas a este mensaje debe ir de nuevo a l, el campo del remitente se utiliza: ---De: <jdoe@machine.example> John Doe Remitente: Michael Jones <mjones@machine.example> A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ---A.1.2. Los diferentes tipos de buzones de correo Este mensaje incluye varias direcciones en los campos de destino y tambin utiliza varias formas diferentes de direcciones. ---De: "Joe Q. Public" <john.q.public@example.com> A: Mara Smith <mary@x.test>, jdoe@example.org, Quin? <one@y.test> Cc: <boss@nil.test>, "Gigante \" Big \ "Box" <sysservices@example.net> Fecha: Martes, 01 de julio 2003 10:52:37 0200 Message-ID: <5678.21-Nov-1997 @ example.com> Hola a todos. ---Tenga en cuenta que los nombres de pantalla de Joe Q. Public, y Gigante, "Big" Caja necesarios para estar entre comillas, porque el primero contiene el perodo y el segundo contiene punto y coma y doble cotizacincaracteres (los caracteres de comillas dobles que aparece citado par construccin). Por el contrario, el nombre para mostrar para quin? podra aparecer sin ellos, porque el signo de interrogacin es legal en un tomo. Aviso tambin que jdoe@example.org y boss@nil.test no tienen nombres para mostrar asociados con ellos en todo, y jdoe@example.org utiliza la ms simple direccin de forma, sin el parntesis angulares.

Resnick Normas Track [Pgina 42] RFC 2822 Internet Message Format 04 2001 A.1.3. Direcciones de grupo ---De: Pete <pete@silly.example> Para: Grupo A: Chris Jones <c@a.test>, joe@where.test, John <jdoe@one.test>; Cc: los destinatarios no divulgada:; Fecha: Jueves, 13 de febrero 1969 23:32:54 -0330 Message-ID: <testabcd.1234@silly.example> Pruebas. ---En este mensaje, el campo "Para:" El campo tiene un destinatario nico grupo llamado A Grupo que consta de 3 direcciones, y un "CC:" el campo con un vaco grupo receptor llamado destinatarios no divulgada. A.2. Mensajes de respuesta La siguiente es una serie de tres mensajes que forman una conversacin hilo entre Juan y Mara. Primeros John enva un mensaje a Mary, Mary a continuacin, responde al mensaje de Juan, y luego John respuesta a un mensaje respuesta de Mara. Tenga en cuenta especialmente el "Message-ID:", "Referencias", y "In-Reply-To:" campos de cada mensaje. ---De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ----

Resnick Normas Track [Pgina 43] RFC 2822 Internet Message Format 04 2001 Cuando el envo de respuestas, el campo Asunto a menudo se mantiene, aunque precedidas por "Re:" como se describe en la seccin 3.6.5. ---De: Mary Smith <mary@example.net> Para: Juan Prez <jdoe@machine.example> Responder a: "Mary Smith: Cuenta Personal" <smith@home.example> Asunto: Re: saludar Date: Fri, 21 de noviembre 1997 10:01:10 -0600 Message-ID: <3456@example.net> In-Reply-To: <1234@local.machine.example> Referencias: <1234@local.machine.example> Esta es una respuesta a su saludo. ---Tenga en cuenta el "Responder a:" el campo en el mensaje anterior. Cuando John respuestas El mensaje de Mara a lo anterior, la respuesta debe ir a la direccin en la "Responder a:" de campo en lugar de la direccin en el campo "De:" campo. ---Para: "Mary Smith: Cuenta Personal" <smith@home.example> De: <jdoe@machine.example> John Doe Asunto: Re: saludar Date: Fri, 21 de noviembre 1997 11:00:00 -0600 Message-ID: <abcd.1234@local.machine.tld> In-Reply-To: <3456@example.net> Referencias: <1234@local.machine.example> <3456@example.net> Esta es una respuesta a su respuesta. ---A.3. Resienten mensajes Comience con el mensaje que se ha utilizado como ejemplo varios los tiempos: ----

De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ----

Resnick Normas Track [Pgina 44] RFC 2822 Internet Message Format 04 2001 Decir que Mara, al recibir este mensaje, quiere enviar una copia de el mensaje a Jane tales que (a) el mensaje parece haber vienen directamente de John, (b) si Jane responde al mensaje, el respuesta debe volver a John, y (c) todos los originales informacin, como la fecha en que se envi el mensaje original a Mara, el identificador de mensaje y el destinatario original, se conserva. En este caso, los campos se resienten al principio del mensaje: ---Reenviar-De: Mary Smith <mary@example.net> Resentimiento a: Jane Brown <j-brown@other.example> Resentimiento Fecha: Lunes, 24 de noviembre 1997 14:22:01 -0800 Resentimiento Message-ID: <78910@example.net> De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ---Si Jane, a su vez, ha querido enviar este mensaje a otra persona, ella antepone su propio conjunto de campos de cabecera resienten de lo anterior y enviarlo.

Resnick Normas Track [Pgina 45] RFC 2822 Internet Message Format 04 2001 A.4. Los mensajes con campos de seguimiento Como los mensajes se envan a travs del sistema de transporte como se describe en [RFC2821], campos de seguimiento son al principio del mensaje. Los siguientes es un ejemplo de lo que los campos de seguimiento podra ser similar. Tenga en cuenta que hay algo de espacio plegable blanco en la primera desde estas lneas puede ser largo. ---Recibido: x.y.test de por example.net a travs de TCP con ESMTP Identificacin ABC12345 para <mary@example.net>, 21 de noviembre 1997 10:05:43 -0600 Fecha: del machine.example por xytest, 21 de noviembre 1997 10:01:22 -0600 De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Date: Fri, 21 de noviembre 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ----

Resnick Normas Track [Pgina 46] RFC 2822 Internet Message Format 04 2001 A.5. El espacio en blanco, comentarios y otras rarezas El espacio en blanco, incluidos espacios en blanco plegado, y los comentarios se pueden insertado entre muchas de las fichas de los campos. Tomando el ejemplo de A.1.3, el espacio en blanco y comentarios se pueden insertar en todos los campos. ---De: Pete (Un maravilloso \) cap) <pete(his account)@silly.test(his host)> A: Un grupo (Algunas personas) : Chris Jones <c@(Chris's host.)public.example>, joe@example.org, John <jdoe@one.test> (mi querido amigo), (al final del grupo) Cc: (lista vaca) (inicio) los destinatarios no divulgada: (nadie (que yo sepa)); Date: Thu, 13 Febrero 1969 23:32 -0330 (Hora de Terranova) Message-ID: <testabcd.1234@silly.test> Pruebas. ---El ejemplo anterior es estticamente desagradable, pero perfectamente legal.

Nota especial (1) los comentarios en el campo "De:" de campo (incluidos uno que tiene un carcter ")" que aparece como parte de una cita de par), (2) el espacio en blanco despus de la ausencia ":" en el campo "Para:" el campo, as como el comentario y el espacio en blanco despus de doblar el nombre del grupo, el especial carcter (".") en el comentario en la direccin de Chris Jones, y el espacio plegable blanco antes y despus "joe@example.org", (3) la varios comentarios y anidado en el "Cc:" sobre el terreno, as como la comentario inmediatamente despus del ":" despus de "Cc", (4) el plegamiento espacio en blanco (sin comentarios, excepto al final) y la falta segundo en el tiempo del campo de fecha, y (5) el espacio en blanco antes de (Pero no dentro) el identificador en el "Message-ID:" campo. A.6. Formas obsoletas Los siguientes son ejemplos de los obsoletos (esto es, el "NO DEBE generar ") se describen los elementos sintcticos en la seccin 4 de este documento.

Resnick Normas Track [Pgina 47] RFC 2822 Internet Message Format 04 2001 A.6.1. Obsoletos frente a Tenga en cuenta en el siguiente ejemplo de la falta de comillas alrededor de Joe Q. Public, la ruta que aparece en la direccin de Mary Smith, las dos comas que aparecen en el campo "Para:" el campo, y los espacios que aparecen en todo el "." en la direccin jdoe. ---De: Joe Q. Public <john.q.public@example.com> A: Mara Smith <@ machine.tld: mary@example.net>, jperez @ test. ejemplo Fecha: Martes, 01 de julio 2003 10:52:37 0200 Message-ID: <5678.21-Nov-1997 @ example.com> Hola a todos. ---A.6.2. Fechas obsoletos El mensaje siguiente se utiliza un formato de fecha obsoleto, incluyendo un nozona horaria numrico y un ao de dos dgitos. Tenga en cuenta que aunque el da de la semana que falta, que no es especfico de la sintaxis obsoleta; es opcional en la sintaxis actual tambin.

---De: <jdoe@machine.example> John Doe A: Mara Smith <mary@example.net> Asunto: saludar Fecha: 21 de noviembre 97 09:55:06 GMT Message-ID: <1234@local.machine.example> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ---A.6.3. Espacio obsoleto en blanco y comentarios El espacio en blanco y los comentarios pueden aparecer entre muchos elementos ms en la sintaxis actual. Adems, las lneas de plegado que se componen enteramente de espacio en blanco son legales.

Resnick Normas Track [Pgina 48] RFC 2822 Internet Message Format 04 2001 ---De: John Doe <jdoe mquina @ (comentario). ejemplo> A: Mary Smith __ <mary@example.net> Asunto: saludar Date: Fri, 21 Nov 1997 09 (comentario): 55: 06 -0600 Message-ID: <.. 1234 @ local (bla) mquina de ejemplo> Este es un mensaje slo para decir hola. Por lo tanto, "Hola". ---Tenga en cuenta especialmente la segunda lnea de la "A:" campo. Se inicia con dos espacios. (Tenga en cuenta que "__" representan los espacios en blanco.) Por lo tanto, se considera parte del plegado como se describe en la seccin 4.2. Adems, los comentarios y espacios en blanco a lo largo de direcciones, fechas, y los identificadores de mensaje son parte de la

sintaxis obsoleta. Apndice B. Las diferencias de las normas anteriores Este apndice contiene una lista de cambios que se han hecho en el Internet Formato de los mensajes de las normas anteriores, en concreto [RFC822] y [STD3]. Los artculos marcados con un asterisco (*) a continuacin son los elementos que aparecen en la seccin 4 de este documento y por lo tanto no puede ser mayor generados. 1. Plazo sealado en forma obsoleta de la frase. 2. ABNF salido del documento en [RFC2234]. 3. Cuatro o ms dgitos permitidos para el ao. 4. Campo de la cabecera del pedido (y la falta de ella) hace explcito. 5. Campo de la cabecera cifrada eliminado. 6. Recibi la sintaxis suelta para permitir que cualquier smbolo / valor par. 7. Especficamente permiten y dan sentido a la zona horaria "-0000". 8. Espacio en blanco plegado no est permitido entre cada token. 9. Requisito para los destinos eliminado. 10. Reenvo y reenvo redefinido. 11. Campos de cabecera de extensin ya no especficamente indicadas. 12. ASCII 0 (cero) elimina .* 13. Las lneas de plegado de continuacin no slo puede contener espacios en blanco .* 14. Insercin gratuita de los comentarios no estn permitidos en la fecha .* 15. No numrico husos horarios no permitidos .* 16. Aos de dos dgitos no se les permite .* 17. Tres aos ms dgitos interpretado, pero no se permite para la generacin. 18. Rutas en las direcciones no se les permite .* 19. CFWS en locales de piezas y los dominios no se les permite .* 20. Miembros vacos de direccin no permite listas .*

Resnick Normas Track [Pgina 49] RFC 2822 Internet Message Format 04 2001 21. Espacio en blanco entre plegables nombre del campo y el colon no se les permite .* 22. Comentarios entre el nombre de campo y el colon no est permitido. 23. La sintaxis de apretar en respuesta a las referencias y .* 24. CFWS en msg-id no se les permite .* 25. Semntica apretado de resentimiento campos informativos. 26. Resentimiento Responder a no se les permite .* 27. No hay mltiples ocurrencias de los campos (excepto resentimiento y recibidas) .* 28. Libre de CR y LF no se les permite .* 29. Rutas en el camino de regreso no se les permite .* 30. Longitud de la lnea de los lmites especificados. 31. CCO ms claramente. Apndice C. Avisos

Propiedad Intelectual El IETF no toma posicin con respecto a la validez o alcance de cualquier propiedad intelectual u otros derechos que pueden ser reclamados a se refieren a la aplicacin o uso de la tecnologa descrita en este documento o en la medida en que ninguna licencia de dichos derechos pueden o no estar disponible, ni tampoco representa que se ha hecho ningn esfuerzo para identificar a cualquiera de esos derechos. La informacin sobre la IETF procedimientos con respecto a los derechos en vas de estandarizacin y relacionadas con las normas de documentacin se puede encontrar en el BCP-11. Copias de reivindicacin de los derechos disponibles para su publicacin y garantas de cualquier las licencias que se dispone, o el resultado de un intento de obtener una licencia o permiso para el uso de tales derechos de propiedad por los ejecutores o los usuarios de esta especificacin puede obtenerse de la Secretara de la IETF.

Resnick Normas Track [Pgina 50] RFC 2822 Internet Message Format 04 2001 Declaracin Completa de Copyright Copyright (C) The Internet Society (2001). Todos los derechos reservados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y las obras derivadas que comentar o lo explican o ayudar en su implementacin pueden ser preparados, copiados, publicados y distribuido, en su totalidad o en parte, sin restriccin de ningn especie, siempre que el aviso de copyright anterior y este prrafo son incluidos en todas esas copias y trabajos derivados. Sin embargo, este

documento en s mismo no puede ser modificado de ninguna manera, como mediante la eliminacin el aviso de copyright o referencias a la Sociedad Internet o de otro tipo Organizaciones de Internet, excepto cuando sea necesario con el fin de el desarrollo de estndares de Internet, en cuyo caso los procedimientos para derechos de autor se define en el proceso de normalizacin de Internet debe ser seguido, o como sea necesario traducirla a otros idiomas distintos Ingls. Los limitados permisos concedidos anteriormente son perpetuos y no sern revocados por la Internet Society ni sus sucesores o cesionarios. Este documento y la informacin contenida en este documento se proporciona en un "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING GRUPO DE TRABAJO DE RENUNCIA A TODA GARANTA, EXPRESA O IMPLCITA, INCLUYENDO PERO NO LIMITADO A CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACIN AQU NO INFRINGE NINGN DERECHO O GARANTAS DE COMERCIALIZACIN O IDONEIDAD PARA UN PROPSITO PARTICULAR. Acuse de recibo La financiacin de la funcin del Editor RFC es actualmente el Internet Society.

Resnick Normas Track [Pgina 51]