システム イベント (サービス ウィンドウ、アラートなど) について、計画されたサポート通知メールを送信する必要があります。ベンダーから受け取るそのような電子メールのほとんどは、プレーン テキスト形式です。
プレーンテキスト形式 (制限付き) に固執するか、HTML ベースの形式をより視覚的に提供する必要があるのだろうか?
さまざまな電子メール クライアントの HTML レンダリング機能が制限されていることは承知していますが、画像を含む複雑でない HTML は問題ないと思います。
システム イベント (サービス ウィンドウ、アラートなど) について、計画されたサポート通知メールを送信する必要があります。ベンダーから受け取るそのような電子メールのほとんどは、プレーン テキスト形式です。
プレーンテキスト形式 (制限付き) に固執するか、HTML ベースの形式をより視覚的に提供する必要があるのだろうか?
さまざまな電子メール クライアントの HTML レンダリング機能が制限されていることは承知していますが、画像を含む複雑でない HTML は問題ないと思います。
HTML 電子メールを受け入れないクライアントが存在する可能性があるかどうかを判断する必要があります。
これは以前ほど一般的ではありませんが、HTML を許可しないセキュリティ意識の高いユーザーがまだいる可能性があります。
ただし、同じメール内でプレーン テキストの代替を提供することはできます。
http://www.wilsonweb.com/wmt5/html-email-multi.htm
また、HTML はプレーン テキスト以上の価値を提供するかどうかを考慮する必要がありますか? 私にとって、私が通常受け取る情報は、最大限の読みやすさのために、件名の行の中で送信されます。
明らかに、それはあなたが電子メールで何をしているかに大きく依存しますが、HTML 形式を使用することに実際の価値がないのであれば、なぜそれをいじる必要があるかを私は言います。
私は、HTML 形式の電子メールを真剣に受け止めない傾向があります。通常、それらはニュースレターか、あなたが持っているものです。ほとんどの場合、平文の電子メールは「ビジネス」を意味します。それは私だけかもしれません。
HTML を送信することを選択した場合は、必ずテキスト バージョン (マルチパート MIME として送信) も含めるようにしてください...ほとんどのスパム フィルターは、HTML のみのメール (テキストのみのコンポーネントなし) を解釈する可能性が高いためです。 ) スパムとして。
マルチパート MIME を使用するもう 1 つの明白な利点は、受信者が (電子メール クライアントを介して) 読みたいバージョンを選択できることです。
スパム フィルターは、HTML メールを送信するときに、特に自動送信された場合に、メッセージに「スパムの可能性がある」というフラグを立てることもあります。少なくとも SpamAssassin は HTML にペナルティを課します。
常にRFCを尊重し、常にテキストメール本文を提供してください!!!
HTML の「リッチ」バージョンをプレーンテキストの電子メールに添付して送信することはできますか? シンプルな電子メールクライアントをいじる手間を省きますか?