Content-Transfer-Encodingを使用しますか？text64とhtmlのbase64で問題がありますか？

Question

私は電子メールプロジェクトに取り組んでいます。私がここには入り込まない理由で、長い電子メールメッセージに引用符で囲まれた印字可能なエンコーディングを行うのは、顧客の環境では問題があります。

私たちが送信しているSMTP電子メールのHTMLセクションとテキストセクションでbase64エンコーディングを実行することは実行可能な選択肢のようです。テストでは、Gmailのようなカップルのテストクライアントで問題なく動作しているようです。

しかし、これが異なるメールクライアントに問題があるかどうかは疑問です。 RFC仕様を読むと、base64はテキストセクションの準拠エンコーディングのようですが、考慮すべき潜在的な問題があるかどうかを知りたいテキストの& htmlセクションでは珍しいことです。問題のある可能性のように見える

もの：

• は、おそらくいくつかの古い以下堅牢なクライアントは、テキストまたはHTML形式の電子メールのセクションでbase64で期待していない、そしてそれは
• おそらくいくつかの電子メールクライアントが行うエンコードするために失敗します。プレビューまたは生のコンテンツに基づく検索のため、受信者は実際のコンテンツの代わりにbase64を表示します
• おそらくbase64が配信性/スパムスコアに悪影響を及ぼす可能性がありますか？

誰も共有できる体験はありますか？これは良い解決策のようですが、私は何かが欠けていないことを確認したいと思います。

Answer 1

これは答えが難しいです - はい、quoted-printableは、バイトが浪費されず、メールの本文部分の生のテキストがデコードされた出力に似ているために頻繁に使用されます。しかし、文字メッセージ部分にはbase64を使用することを禁じているものはありません。

これはかなりオープンな質問です.MUAが何かを見せないほど絶望的に壊れているとは決して確信できません。そこには多分 "多分"、あなたは正しいですが、問題はあなたが決して知らないことです。それはあなたがより良い、以下の企業にマーケティングのスパム内のすべての使用Base64でエンコードされたHTMLを眠るようになります場合、私は受けています：

• をメラノックス
• Alza.cz
• Aukro.cz
• 誌現代の物理

組み込み画像を表示できるMUAには、base64デコーダが含まれている必要があります。間違いなく、MUAがtext/plainとtext/htmlをデコードするためにそのコードの使用を明示的に拒否している可能性がありますが、その場合はどうにかなります。

これらの企業の1人は、UTF-8でエンコードされた件名をマルチバイト文字のバイト境界で分割し、別々のエンコードされた単語で半分のテキストをエンコードすることに満足しています（RFC2047用語） 。