Web開発
エラーメールを送るのをやめてください
Stop sending me your errors (kramkow.ski)
要約
この記事は、 multipart/alternative を誤用してエラーメッセージをプレーンテキスト形式で送信することの問題点を指摘しています。これは、メールクライアントの互換性やユーザーの意図しない表示を引き起こし、問題を解決するどころか悪化させる可能性があると論じています。著者は、代替形式として機能しないプレーンテキストパートの送信を停止することを提案しています。
全文翻訳
私のデスクトップメールクライアントは、text/plainとtext/htmlの両方のメールをレンダリングできます。私はtext/plainバージョンを好みます。そして、それは正しいです、私は時代に追いつくべきです。しかし、あなたが multipart/alternative を誤用して私にエラーを送るとき、あなたは私や他の誰かを助けているわけではありません。実際、あなたは正反対のことをしています。
古い文書には、同じ情報を複数の交換可能な形式で提示する方法として multipart/alternative が記載されています。最も一般的には、これはHTMLバージョンのメールをプレーンテキストの対応物と一緒に送信するために使用されます。
言い換えれば、multipart/alternative は私にあなたたちの忌々しいエラーを送るためのものではありません。私のメールクライアントがあなたのメールを処理できない場合、そのようなエラーを報告するのはクライアントの仕事です。
今朝、私は次のような本文のメールを受け取りました。
Plain text version not available
HTMLバージョンに切り替えたところ、次のようなレンダリングされた同等のものには出会いませんでした。
<!DOCTYPE html>
<html>
<head>
<title>...</title>
</head>
<body>
<p>Plain text version not available</p>
</body>
</html>
代わりに、実際のメールコンテンツに出会いました。これがこれほど一般的でなければ驚いたでしょう。
ユーザーがtext/plainバージョンに遭遇する可能性のあるシナリオを考えてみましょう。
シナリオ：彼らは80年代からのタイムトラベラーであり、古いMIME以前のメールクライアントを使用しています。結果：彼らはいくつかの意味不明な文字列、次に「Plain text version not available」、そしてHTML風の意味不明な文字列を見ます。もし彼らがすでに何が起こっているのかを知らなければ、このメッセージは彼らが何かを修正するのに役立たないでしょう。それは彼らがそれを意味不明な文字列の中から見つけると仮定してもです。
シナリオ：彼らはtext/htmlを処理できないMIME対応メールクライアントを使用しています。結果：彼らはこの「エラー」を見て、クライアントはMIMEを理解しているので、この「エラー」が理解できない部分と交換可能であると推測し、それを提示します。クライアントがHTMLを取得する方法を提供するかもしれませんが、提供しないかもしれません。ユーザーは状況が回復可能であることを理解していないかもしれません。もしtext/plain部分がなかったら、クライアントはおそらくあなたの「エラー」メッセージよりも悪くはならず、実際の回復パスさえ提供するかもしれません。そして、もしそれがもっと悪かったとしても、あなたはあなたのメッセージが実際に彼らを助けるかどうかを再び自問すべきです。
シナリオ：彼らはtext/htmlとtext/plainの両方を処理できるMIME対応メールクライアントを使用していますが、text/plainを優先するように設定しています。結果：シナリオ2と非常によく似ていますが、あなたがエラーをtext/plainパートとして追加しなかったら、彼らは意図したエクスペリエンスをすぐに得られたでしょう。今、彼らは状況の理解とメールクライアントの知識に頼って、明示的に優先しないように設定したフォーマットに切り替えるオプションを見つけなければなりません。あなたは彼らの人生をより困難にしただけです。
あなたのメールシステムが有用なtext/plainバージョンを生成できない場合、それを彼らに伝えることは誰の役にも立ちません。もしシナリオ1があなたにとって望ましいと思われたなら1、あなたは代わりにHTMLコメントを使用して、あなたのHTMLメールの犠牲者に、RFCを無視したり、ランダムなインターネットの無名の人々を怒らせたりすることなく、多かれ少なかれ同様に混乱するエクスペリエンスを与えることができます。
「しかし」と、あなたは叫ぶのを聞きます、「私はtext/plainバージョンを最初に、text/htmlバージョンを最後に置きました。スクロールが私に好ましい表現を示すように言うように。」
それはクールです。あなたがHTMLを好むことは理解できますが、私はプレーンテキストを好みます。multipart/alternative が正しく使用されている場合、プレーンテキスト部分はHTML部分からレンダリングできるものよりもはるかにクリーンになる可能性があります。もし私がtext/plainの好みをメールクライアントに登録していなかったら、私はシナリオ3の鏡像に直面したでしょう。
幸いなことに、これらすべてに対する簡単な解決策があります。実際には代替ではないtext/plainの代替を送信するのをやめることです。それは私たち全員10人を幸せにするだけでなく、あなたのメールがスパムとしてマークされるのを避けるのにも役立ちます。
それはエラーにさえ止まりません。最近受け取ったmultipart/alternative メールで、実際のtext/plain部分の例をいくつか紹介します（[角括弧]内の部分を除く、そのまま）。
This email contains html content. Please configure your email client for html or visit <site.website>[sic] for latest show times.
text/html
Use it before it’s gone [50 blank lines] [... a bit more content ...] [... random CSS stylesheet oneliner ...] [100 more blank lines] [... et cetera ...]
[title] Hi Tom /, Thanks for your order! [date] Your receipt is attached to this email. If you do not want to receive receipts by email, you can <a style="text-decoration:none;" href="https://[domain]/optOut/receiptOptOut?businessId=[id]&emailAddress=[my-email]&token=[token]">unsubscribe<a/>.
脚注
2026年において、この状況に混乱する人がMIMEサポートなし、あるいはtext/htmlサポートなしのメールクライアントを使用しているとは、私はあまり疑っていません。↩