RFC 2822에 규정 된 회선 길이 제한을 준수하는 메일을 작성할 수있을 정도로 인용 인쇄 할 수 있습니까?

RFC 2822 (전자 메일 정의)에 78 자 (CRLF 제외)보다 길거나 998 자 이하 여야합니다. 인용 인쇄 가능한 긴 줄은 더 많은 줄로 나누어 져 실제 줄 바꿈에 도달 할 때까지 각각 '='로 끝납니다. 78 자 (또는 998) 자보다 긴 행을 포함하지만 따옴표로 묶을 수있는 문자로 인코딩 된 경우 메일을 표준에 맞 춥니 다.

인용 된 인쇄 가능한 메시지를 디코딩 한 후 수신 메일 클라이언트가 더 긴 행을 가지므로이 규칙이 호환되지 않는다는 주장이 있습니다.

편집 : David Cary가 요청한 방식으로 질문을 명확히하려면 : 따옴표로 인쇄 가능한 인코딩 된 메일이 따옴표로 묶을 수있는 인쇄 가능해야한다는 것을 의미합니다. 줄은 더 이상 76자를 넘지 않습니다. 그러나 디코딩 된 메시지는이 한계보다 긴 라인을 가질 수 있습니다. 그래서 내 질문은 : RFC 1521을 구현하는 클라이언트 소프트웨어가 인용 인쇄 가능한 텍스트 내용을 디코딩 한 후 무한히 긴 줄을 처리해야합니까? 이것은 네티켓 (RFC 1855)에 의해 권장되지 않는 제한과 함께 지금까지 두 답변 모두에 대해 그렇습니다 (감사). 그러나 Netiquette는 줄 길이를 65 자로 제한합니다.

나는 당신이 무엇을 요구하는지 잘 모르겠습니다.

수신 메일 클라이언트는 인용 인쇄 가능 디코딩 전에 긴 행을 찾습니다.

송신 측의 인용 인쇄 가능한 인코딩 소프트웨어는 인쇄 할 수없는 문자를 단순히 인용하여 "부드러운 줄 바꿈"을 추가하지 않고 결과 인코딩 된 라인을 원래 라인보다 길게 만들어서 인코딩 된 라인이 한계보다 길어 졌다고 가정 해보십시오.

이것은 비준수입니다.

인용 인쇄 가능한 인코딩 된 데이터 행은 76자를 넘지 않아야합니다. 인코딩 된 텍스트를 변경하지 않고이 요구 사항을 충족하기 위해 부드러운 줄 바꿈을 추가 할 수 있습니다. 이러한 부드러운 줄 바꿈은 "와 같이 줄 크기가 제한된 환경에서 줄 바꿈없이 텍스트를 인코딩하거나 매우 긴 줄을 포함 할 수 있습니다. RFC 2821에서 허용하는 일부 SMTP 소프트웨어의 한 줄에 1000 자 "제한.

- 위키 백과 : 인용 - 인쇄 , 의역 RFC2045 21 페이지.

인코딩 된 줄은 짧지 만받는 메일 클라이언트는 따옴표로 묶은 인쇄 가능한 디코딩 후 긴 줄을 찾습니다.

RFC2822 및 RFC2045를 준수하며 모든 소프트웨어에서 지원해야합니다.

그러나 RFC 1855 "Netiquette Guidelines"의 3 페이지를 포함하여 여러 Netiquette Guidelines에서 이러한 메시지를 작성하지 않는 것이 좋습니다 .

확실히 준수합니다. Quoted-Printable의 요점과 나머지 MIME RFC 시리즈 (RFC 2045-RFC 2049)는 전자 메일에서 유효하지 않은 데이터의 인코딩을 허용하는 것입니다. RFC 2822는이 작업을 수행하는 방법에 대한 정보를 명시 적으로 (반복적으로) 해당 RFC 독자에게 지적합니다.

호환되는 이메일 작성기 및 파서를 만드는 것이 얼마나 복잡한 지 알고 싶다면 YouTube에서 다음 동영상을 시청 해야합니다 . http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes는 다양한 RFC에 대한 내부 견해와 실제 생활에 가져 오는 어리 석음을 보여줍니다.

길이는 40 분이며 나쁜 전자 메일 "콘텐츠"의 표면 만 긁습니다. 보고 나면 이메일 표준을 준수한다고 생각하는 이메일 소프트웨어에 대한 의견이 변경됩니다.