RFC 2822で規定されている行長制限にメールを準拠させるのに十分なquoted-printableはありますか？

RFC 2822（電子メールの定義）で定義されているように、78文字（CRLFを除く）を超えてはならず、998文字を超えてはなりません（SHOULD）。quoted-printableを使用すると、長い行はより多くの行に分割され、実際の改行に達するまで各行は「=」で終了します。メールが標準（78（または998）文字より長い行を含むがquoted-printableでエンコードされている場合）

quoted-printableメッセージをデコードした後、受信メールクライアントに長い行があるため、これは準拠していないという議論があります。

編集：David Caryの質問のとおりに質問を明確にするために：はい、私はquote-printableでエンコードされたメールはquoted-printableと互換性があるべきであることを意味します、つまり行が76文字を超えないことを意味します。ただし、デコードされたメッセージには、この制限より長い行がある場合があります。だから私の質問です：RFC 1521を実装するクライアントソフトウェアは、quoted-printableテキストコンテンツをデコードした後、無期限に長い行を処理するはずですか？これは、これまでの両方の回答で「はい」と回答されています（ありがとう）。これは、ネチケット（RFC 1855）によって推奨されないという制限があります。しかし、Netiquetteは、行の長さを65文字に制限し、誰も守らない制限にさえしています。

私はあなたが何を求めているのかわかりません：

受信メールクライアントがquoted-printableをデコードする前に長い行を見つける

送信側の印刷可能なエンコードソフトウェアが、印刷できない文字を単に引用し、「ソフトな改行」を追加せずに結果のエンコードされた行を元の行よりも長くすると、エンコードされた行が制限よりも長くなります。

これは非準拠です。

quoted-printableエンコードされたデータの行は、76文字を超えてはなりません。エンコードされたテキストを変更せずにこの要件を満たすために、ソフト改行を追加できます。これらのソフト改行を使用すると、「 RFC 2821で許可されている一部のSMTPソフトウェアの「1行あたり1000文字」の制限。

- ウィキペディア：quoted-printableの、言い換えRFC2045 21ページ。

エンコードされた行は短いですが、受信メールクライアントはquoted-printableをデコードした後に長い行を見つけます

これはRFC2822およびRFC2045に準拠しており、すべてのソフトウェアでサポートされているはずです。

ただし、そのようなメッセージを作成することは、RFC 1855の 3ページ目の「ネチケットガイドライン」を含むいくつかのネチケットガイドラインでは推奨されていません。

間違いなく準拠しています。Quoted-Printable、およびRFCのMIMEシリーズの残り（RFC 2045からRFC 2049）の全体的なポイントは、他の方法では電子メールで有効ではないデータのエンコードを許可することです。RFC 2822は、明示的に（そして繰り返し！）、これを行う方法についての情報を読者にそれらのRFCに向けています。

準拠したメールコンポーザーとパーサーを作成することがいかに複雑か知りたい場合は、YouTubeでこのビデオを見る必要があります。http：//www.youtube.com/watch？ v = JENdgiAPD6c

Ricardo Signesは、さまざまなRFCと、それらが実際の生活にもたらす愚かさについて内部の見解を示しています。

それは40分の長さで、悪いメールと良いメールの「コンテンツ」の表面をなぞっただけです。見た後は、メールの標準に準拠していると思っていたメールソフトウェアについての見解が変わります。