¿Es lo suficientemente imprimible como para que un correo cumpla con la restricción de longitud de línea planteada en RFC 2822?

En RFC 2822 (definición de correo electrónico) se define que ninguna línea DEBE tener más de 78 caracteres (excluyendo CRLF) y NO DEBE tener más de 998 caracteres. Con las líneas más largas imprimibles entre comillas se dividirán en más líneas, terminando cada una con un '=' hasta que se alcance el salto de línea real. ¿Cumple un correo con el estándar si contiene líneas de más de 78 (o 998) caracteres pero está codificado con comillas imprimibles?

Hay argumentos de que esto no cumple, porque el cliente de correo receptor tiene líneas más largas después de decodificar el mensaje imprimible entre comillas.

EDITAR : Para aclarar la pregunta en la forma en que lo hizo David Cary: Sí, quiero decir que el correo codificado imprimible entre comillas debe ser compatible con imprimible entre comillas, lo que significa que las líneas no tienen más de 76 caracteres. Pero los mensajes decodificados pueden tener líneas más largas que este límite. Entonces mi pregunta es: ¿se supone que el software del cliente que implementa RFC 1521 maneja líneas indefinidamente largas después de decodificar el contenido de texto imprimible entre comillas? Esto se responde sí con ambas respuestas hasta ahora (gracias) con la restricción de que Netiquette lo desalienta (RFC 1855). Pero Netiquette incluso limita una longitud de línea a 65 caracteres, un límite al que casi nadie se adhiere.

No estoy seguro de lo que estás preguntando:

un cliente de correo receptor encuentra largas colas antes de decodificar para imprimir

Digamos que el software de codificación imprimible entre comillas en el extremo de transmisión simplemente citó letras no imprimibles, haciendo que la línea codificada resultante sea más larga que la línea original, sin agregar "saltos de línea suaves", lo que resulta en una línea codificada más larga que el límite.

Esto no es conforme.

Las líneas de datos codificados imprimibles entre comillas no deben tener más de 76 caracteres. Para satisfacer este requisito sin alterar el texto codificado, se pueden agregar saltos de línea suaves ... Estos saltos de línea suaves también permiten codificar texto sin saltos de línea (o que contienen líneas muy largas) para un entorno donde el tamaño de línea es limitado, como el " Límite de 1000 caracteres por línea "de algún software SMTP, según lo permitido por RFC 2821.

- Wikipedia: parafraseado, citado, imprimible RFC2045 Página 21.

las líneas codificadas son cortas, pero un cliente de correo receptor encuentra líneas largas después de decodificar para imprimir

Eso cumple con RFC2822 y RFC2045, y debe ser compatible con todo el software.

Sin embargo, la creación de tales mensajes es desaconsejada por varias Directrices de Netiquette, incluida la página 3 de RFC 1855 "Directrices de Netiquette".

Definitivamente es compatible. El objetivo de Quoted-Printable, y el resto de la serie MIME de RFC (RFC 2045 a RFC 2049), es permitir la codificación de datos que de otro modo no serían válidos en el correo electrónico. RFC 2822 explícitamente (¡y repetidamente!) Señala a los lectores a esos RFC para obtener información sobre cómo hacer esto.

Si realmente desea saber qué tan complicado es crear un analizador y analizador de correo electrónico compatible, debe ver este video en Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes ofrece opiniones internas sobre diferentes RFC y qué estupidez aportan a la vida real.

Tiene una duración de 40 minutos y solo rasca la superficie del "contenido" de correo electrónico bueno y malo. Después de verlo, cambiará su opinión sobre el software de correo electrónico que pensó que se ajusta a los estándares de correo electrónico.