É citado-imprimível o suficiente para fazer um email compatível com a restrição de comprimento de linha colocada no RFC 2822?

Question

No RFC 2822 (definindo E-Mail) é definido, que nenhuma linha deve ser mais de 78 caracteres (excluindo CRLF) e não deve ser superior a 998 caracteres. Com as linhas longas imprimíveis citadas serão quebradas em mais linhas, terminando cada uma com um '=' até que a quebra de linha real seja alcançada. Conforma um email ao padrão, se ele contiver linhas com mais de 78 (ou 998) caracteres, mas estiver codificado com imprimível entre aspas?

Existem argumentos, que isso não é compatível, porque o cliente de email de recebimento tem linhas mais longas depois de decodificar a mensagem impressa entre aspas.

EDITAR : Para esclarecer a questão da forma como foi perguntado por David Cary: Sim, quero dizer que o e-mail codificado para impressão por aspas deve ser compatível com o texto para impressão, significa que as linhas não são mais do que 76 caracteres. Mas as mensagens decodificadas podem ter linhas mais longas que esse limite. Portanto, minha pergunta é: o software cliente que está implementando a RFC 1521 deve lidar com linhas longas indefinidamente depois de decodificar o conteúdo de texto que pode ser cotado na impressora? Isto é respondido sim com ambas as respostas até agora (obrigado) com a restrição de que é desencorajado por Netiquette (RFC 1855). Mas a Netiquette limita até mesmo um comprimento de linha a 65 caracteres, um limite que quase ninguém segue.

    

Answer 1

Não sei ao certo o que você está perguntando:

um cliente de e-mail receptor encontra linhas longas antes de decodificar entre aspas e imprimir

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

Isso não é compatível.

Lines of quoted-printable encoded data must not be longer than 76 characters. To satisfy this requirement without altering the encoded text, soft line breaks may be added ... These soft line breaks also allow encoding text without line breaks (or containing very long lines) for an environment where line size is limited, such as the "1000 characters per line" limit of some SMTP software, as allowed by RFC 2821.

- Wikipedia: citado para impressão , parafraseando RFC2045 Página 21.

as linhas codificadas são curtas, mas um cliente de e-mail receptor encontra linhas longas após a decodificação entre aspas e imprime

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

No entanto, criar tais mensagens é desencorajado por várias Diretrizes de Netiqueta, incluindo Página 3 de RFC 1855 "Diretrizes de Netiqueta".

    

Answer 2

É definitivamente compatível. O ponto principal de Quoted-Printable, e o resto 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 em e-mail. O RFC 2822 explicitamente (e repetidamente!) Aponta os leitores dessas RFCs para obter informações sobre como fazer isso.

    

Answer 3

Se você realmente quer saber como é complicado criar um complemento e um analisador de e-mail compatível, você deve assistir a este vídeo no YouTube: link

Ricardo Signes dá visões internas sobre diferentes RFCs e que estupidez trazem para a vida real.

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