11

私はメールプロジェクトに取り組んでいます。ここでは説明しませんが、長い電子メール メッセージで引用符付きの印刷可能なエンコードを行うことは、顧客の環境では問題があります。

送信する SMTP 電子メールの HTML およびテキスト セクションで base64 エンコードを行うことは、実行可能なオプションのようです。テストでは、いくつかのテスト クライアント (Gmail など) で問題なく動作するようです。

ただし、これにより、さまざまな電子メールクライアントで問題が発生するかどうか疑問に思っています. RFC 仕様を読むと、base64 はテキスト セクションの準拠エンコーディングのように見えますが、考慮すべき潜在的な問題があるかどうかを知りたいテキストと html セクションには十分珍しいです。

問題のある可能性と思われるもの:

  • おそらく、一部の古いクライアントや堅牢性の低いクライアントは、テキストまたは HTML メール セクションで base64 を予期せず、エンコードに失敗します。
  • おそらく一部の電子メール クライアントは生のコンテンツに基づいてプレビューまたは検索を行うため、受信者には実際のコンテンツではなく base64 が表示されます。
  • おそらく、base64 は配信率/スパム スコアリングに悪影響を与える可能性がありますか?

誰かが共有できる経験を持っていますか? これは良い解決策のように思えますが、何かが欠けていないことを確認したいと思います。

4

1 に答える 1

14

これは答えるのが難しいです -- はい、quoted-printableより頻繁に使用されます。単純に無駄なバイト数が少なく (ほとんどが ASCII テキストの場合)、メール本文部分の生のテキストが (ほとんどが ASCII テキストの場合) デコードされた出力に似ているためです。base64ただし、テキストメッセージ部分に使用することを禁じるものはありません。

これは未解決の問題です。どこかの MUA が絶望的に​​壊れていて、何も表示されていないことを確認することはできません。そこには多くの「おそらく」があり、あなたは正しいですが、問題は、あなたが決して知らないということです. よく眠れるようになるなら、次の企業はすべて、私が受け取っているマーケティング スパムで base64 でエンコードされた HTML を使用しています。

  • メラノックス
  • Alza.cz
  • Aukro.cz
  • 現代物理学ジャーナル

埋め込み画像を表示できる MUA には、base64 デコーダーを含める必要があります。text/plainMUA がそのコードをデコードおよびに使用することを明示的に拒否する可能性は間違いなくありますtext/htmlが、その場合、とにかくめちゃくちゃになります。

楽しい事実として、これらの企業の 1 つは、UTF-8 でエンコードされたサブジェクトをマルチバイト文字内のバイト境界で分割し、テキストの両方の半分を別々のエンコードされた単語 (ここでは RFC2047 用語) でエンコードすることに満足しています。

于 2013-05-01T14:37:20.603 に答える