A impressão entre aspas é suficiente para tornar um email compatível com a restrição de comprimento de linha apresentada na RFC 2822?

Na RFC 2822 (definindo e-mail) é definido, que nenhuma linha deve ser superior a 78 caracteres (excluindo CRLF) e não deve exceder 998 caracteres. Com linhas mais longas, imprimíveis entre aspas, serão divididas em mais linhas, terminando cada uma com um '=' até que a quebra de linha real seja atingida. Conforma um email com o padrão, se ele contiver linhas com mais de 78 (ou 998) caracteres, mas estiver codificado com impressão entre aspas?

Existem argumentos de que isso não é compatível, porque o cliente de email de recebimento possui linhas mais longas após decodificar a mensagem de impressão entre aspas.

EDIT : Para esclarecer a pergunta da maneira solicitada por David Cary: Sim, quero dizer que o correio codificado para impressão de aspas deve ser compatível com o para impressão em aspas, significa que as linhas não têm mais que 76 caracteres. Mas as mensagens decodificadas podem ter linhas mais longas que esse limite. Portanto, minha pergunta é: o software cliente que implementa a RFC 1521 deveria lidar com linhas indefinidamente longas após decodificar o conteúdo de texto entre aspas imprimível? Isso é respondido sim com as duas respostas até o momento (obrigado), com a restrição de que a Netiquette não recomenda o uso da Netiquette (RFC 1855). Mas a Netiqueta até limita um comprimento de linha a 65 caracteres, um limite que quase ninguém adere.

Não tenho certeza do que você está perguntando:

um cliente de correio receptor encontra longas filas antes de decodificar entre aspas imprimíveis

Digamos que o software de codificação imprimível entre aspas na extremidade transmissora simplesmente cite letras não imprimíveis, tornando a linha codificada resultante mais longa que a linha original, sem nunca adicionar "quebras de linha flexível", resultando em uma linha codificada maior que o limite.

Isso não é compatível.

Linhas de dados codificados imprimíveis entre aspas não devem ter mais de 76 caracteres. Para atender a esse requisito sem alterar o texto codificado, podem ser adicionadas quebras de linhas suaves ... Essas quebras de linhas suaves também permitem a codificação de texto sem quebras de linha (ou contendo linhas muito longas) para um ambiente em que o tamanho da linha é limitado, como " Limite de 1000 caracteres por linha "de alguns softwares SMTP, conforme permitido pela RFC 2821.

- Wikipedia: RFC2045 parafraseada e imprimível entre aspas Página 21.

as linhas codificadas são curtas, mas um cliente de recebimento de mensagens encontra longas filas após decodificar

Isso é compatível com RFC2822 e RFC2045 e deve ser suportado por todos os softwares.

No entanto, a criação dessas mensagens é desencorajada por várias diretrizes de netiqueta, incluindo a Página 3 da RFC 1855 "Diretrizes de netiqueta".

É definitivamente compatível. O objetivo de Quoted-Printable, e o restante da série MIME de RFCs (RFC 2045 a RFC 2049), é permitir a codificação de dados que, de outra forma, não seriam válidos no email. O RFC 2822 indica explicitamente (e repetidamente!) Os leitores nesses RFCs para obter informações sobre como fazer isso.

Se você realmente quer saber como complicar é construído um compositor de e-mail compatível e analisador, então você deve ver este vídeo no Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes dá uma visão interna de diferentes RFCs e que estupidez eles trazem para a vida real.

Tem 40 minutos de duração e apenas arranha a superfície de "conteúdo" ruim e bom de email. Depois de assistir, você mudará de opinião sobre o software de email que você acha que está em conformidade com os padrões de email.