Được trích dẫn - có thể in đủ để làm cho thư tuân thủ giới hạn độ dài dòng được đặt trong RFC 2822 không?

Trong RFC 2822 (xác định E-Mail) được xác định, không có dòng nào NÊN dài hơn 78 ký tự (không bao gồm CRLF) và PHẢI không dài hơn 998 ký tự. Với các dòng dài hơn có thể in được trích dẫn sẽ được chia thành nhiều dòng hơn, kết thúc mỗi dòng bằng '=' cho đến khi đạt được mức ngắt dòng thực. Tuân thủ một thư theo tiêu chuẩn, nếu nó chứa các dòng dài hơn 78 (hoặc 998) ký tự nhưng được mã hóa với trích dẫn có thể in được?

Có nhiều đối số cho rằng điều này không tuân thủ, bởi vì ứng dụng nhận thư có dòng dài hơn sau khi giải mã thư có thể in được trích dẫn.

EDIT : Để làm rõ câu hỏi theo cách mà David Cary đã hỏi: Có, ý tôi là thư được mã hóa có thể in được phải tương thích với trích dẫn có thể in được, có nghĩa là các dòng không dài hơn 76 ký tự. Nhưng các tin nhắn được giải mã có thể có dòng dài hơn giới hạn này. Vì vậy, câu hỏi của tôi là: Phần mềm máy khách triển khai RFC 1521 có phải xử lý các dòng dài vô hạn sau khi giải mã nội dung văn bản có thể in được không? Điều này được trả lời là có với cả hai câu trả lời cho đến nay (cảm ơn) với hạn chế là nó không được Netiquette (RFC 1855) khuyến khích. Nhưng Netiquette thậm chí giới hạn độ dài dòng tới 65 ký tự, giới hạn gần như không ai tuân thủ.

Tôi không chắc chắn những gì bạn đang hỏi:

một ứng dụng thư nhận sẽ tìm thấy các dòng dài trước khi giải mã có thể in được

Giả sử phần mềm mã hóa có thể in được ở đầu truyền chỉ đơn giản là trích dẫn các chữ cái không in được, làm cho dòng được mã hóa dài hơn dòng gốc, mà không bao giờ thêm "ngắt dòng mềm", dẫn đến dòng được mã hóa dài hơn giới hạn.

Điều này là không tuân thủ.

Các dòng dữ liệu được mã hóa có thể in được trích dẫn không được dài hơn 76 ký tự. Để đáp ứng yêu cầu này mà không làm thay đổi văn bản được mã hóa, có thể thêm ngắt dòng mềm ... Các ngắt dòng mềm này cũng cho phép mã hóa văn bản mà không ngắt dòng (hoặc chứa các dòng rất dài) cho môi trường bị giới hạn kích thước dòng, chẳng hạn như " Giới hạn 1000 ký tự trên mỗi dòng "của một số phần mềm SMTP, được cho phép bởi RFC 2821.

- Wikipedia: trích dẫn có thể in , diễn giải RFC2045 Trang 21.

các dòng được mã hóa ngắn, nhưng một ứng dụng thư nhận sẽ tìm thấy các dòng dài sau khi giải mã được trích dẫn có thể in được

Điều đó tương thích với RFC2822 và RFC2045 và phải được tất cả phần mềm hỗ trợ.

Tuy nhiên, việc tạo các tin nhắn như vậy không được khuyến khích bởi một số Nguyên tắc Netiquette, bao gồm cả "Nguyên tắc Netiquette" của RFC 1855 .

Nó chắc chắn tuân thủ. Toàn bộ điểm của Trích dẫn có thể in và phần còn lại của loạt RFC MIME (RFC 2045 đến RFC 2049), là cho phép mã hóa dữ liệu nếu không sẽ không hợp lệ trong e-mail. RFC 2822 rõ ràng (và lặp đi lặp lại!) Chỉ người đọc tại các RFC đó để biết thông tin về cách thực hiện việc này.

Nếu bạn thực sự muốn biết mức độ phức tạp của việc xây dựng trình soạn thảo và phân tích email tuân thủ, thì bạn phải xem video này trên Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes đưa ra quan điểm bên trong về các RFC khác nhau và những gì ngu ngốc mà họ mang vào cuộc sống thực.

Nó dài 40 phút và chỉ làm trầy xước bề mặt của "nội dung" email xấu và tốt. Sau khi xem, bạn sẽ thay đổi ý kiến ​​của mình về phần mềm email mà bạn nghĩ rằng nó phù hợp với tiêu chuẩn email.