Apakah kutipan-cetak cukup untuk membuat surat sesuai dengan batasan-panjang-garis yang diajukan dalam RFC 2822?

Dalam RFC 2822 (mendefinisikan E-Mail) didefinisikan, bahwa tidak ada baris HARUS lebih dari 78 karakter (tidak termasuk CRLF) dan HARUS tidak lebih dari 998 karakter. Dengan garis yang dikutip-cetak yang lebih panjang akan dipecah menjadi lebih banyak garis, akhiri masing-masing dengan '=' sampai garis pemisah yang sebenarnya tercapai. Menyesuaikan email dengan standar, jika mengandung garis yang lebih panjang dari 78 (atau 998) karakter tetapi dikodekan dengan kutipan-cetak?

Ada argumen, bahwa ini tidak sesuai, karena klien email penerima memiliki garis yang lebih panjang setelah decoding pesan yang dikutip-cetak.

EDIT : Untuk mengklarifikasi pertanyaan dengan cara yang ditanyakan oleh David Cary: Ya, maksud saya surat berkode kutipan-cetak harus kompatibel dengan kutipan-cetak, artinya garis tidak lebih dari 76 karakter. Tapi pesan yang diterjemahkan mungkin memiliki garis yang lebih panjang dari batas ini. Jadi pertanyaan saya adalah: Apakah perangkat lunak klien yang mengimplementasikan RFC 1521 seharusnya menangani garis panjang tanpa batas setelah mendekode konten teks yang dikutip-cetak? Ini dijawab ya dengan kedua jawaban sejauh ini (terima kasih) dengan batasan yang tidak disarankan oleh Netiquette (RFC 1855). Tetapi Netiquette bahkan membatasi panjang garis hingga 65 karakter, batas yang hampir tidak dipatuhi siapa pun.

Saya tidak yakin apa yang Anda tanyakan:

klien email penerima menemukan antrean panjang sebelum decoding yang dikutip-cetak

Katakanlah perangkat lunak pengkodean yang dikutip-cetak pada ujung transmisi cukup mengutip huruf-huruf yang tidak dapat dicetak, membuat garis yang disandikan lebih lama dari garis aslinya, tanpa pernah menambahkan "pemutusan garis lunak", sehingga menghasilkan garis yang disandikan lebih panjang dari batas.

Ini tidak sesuai.

Garis-garis data yang dikodekan-cetak yang dapat dicetak tidak boleh lebih dari 76 karakter. Untuk memenuhi persyaratan ini tanpa mengubah teks yang disandikan, jeda baris lunak dapat ditambahkan ... Jeda baris lunak ini juga memungkinkan penyandian teks tanpa jeda baris (atau berisi garis yang sangat panjang) untuk lingkungan di mana ukuran garis terbatas, seperti " Batas 1000 karakter per baris "beberapa perangkat lunak SMTP, sebagaimana diizinkan oleh RFC 2821.

- Wikipedia: dikutip-cetak , parafrase RFC2045 Halaman 21.

baris yang dikodekan pendek, tetapi klien email penerima menemukan garis panjang setelah decoding dikutip-cetak

Itu sesuai dengan RFC2822 dan RFC2045, dan harus didukung oleh semua perangkat lunak.

Namun, membuat pesan semacam itu tidak disarankan oleh beberapa Pedoman Netiquette, termasuk Halaman 3 dari RFC 1855 "Pedoman Netiquette".

Itu pasti sesuai. Inti dari Quoted-Printable, dan sisa dari seri MIME dari RFC (RFC 2045 hingga RFC 2049), adalah untuk memungkinkan penyandian data yang jika tidak tidak akan valid dalam email. RFC 2822 secara eksplisit (dan berulang kali!) Menunjukkan pembaca di RFC tersebut untuk informasi tentang cara melakukan ini.

Jika Anda benar-benar ingin tahu seberapa rumitnya membangun komposer dan parser email yang sesuai, maka Anda harus menonton video ini di Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes memberikan pandangan orang dalam tentang berbagai RFC dan kebodohan apa yang mereka bawa ke kehidupan nyata.

Ini adalah 40 menit panjang dan hanya menggaruk permukaan "konten" email yang buruk dan baik. Setelah menonton Anda akan mengubah pendapat Anda tentang perangkat lunak email yang Anda pikir sesuai dengan standar email.