RFC2119によるSHOULDの公式定義はこうだよ：3. SHOULD この言葉、または形容詞「RECOMMENDED」は、特定の状況において特定の項目を無視する正当な理由が存在するかもしれないことを意味するが、異なる選択をする前にその全ての影響を理解し、慎重に考慮する必要がある。Googleの人たちがMessage-IDについてこれをどう解釈したのか、ちょっと疑問だね。

その通り。Message-IDは必須じゃないんだ。私の別のイライラポイントは、Message-IDを上書きしない方がいいのに、例えばSESはあなたのMessage-IDを捨てて別のものに置き換えちゃうこと :(

私がMessage-IDなしで受け取るメッセージはスパムやフィッシングだけだよ。Notmuchに認識されないから、チェックしないと見えないんだ。

その通りだね。ブログを更新して反映させたよ。ありがとう！

これは、メールが「正当なもの」として認識され、スパムに分類されないための要件だと思う。確かに、好きなヘッダーを使ったり、変な組み合わせやIPアドレス、返信先を設定しても、技術的には有効なメールかもしれないけど、人の受信箱に届くべきものではないよね。それに、世界で最も人気のあるメールプロバイダーで自分のメールをテストしない決済処理業者って、ちょっとおかしいよね。

ヨーロッパのテクノロジーがダメなのは、そういう議論にオープンな人が多いからだと思う。アメリカのエンジニアが「SHOULD」と「MUST」について話し始めたら、PMは「何を聞いてるんだ？」って顔をするだろうし、数分間かけて顧客体験の方が仕様より重要だって納得させようとするだろうね。もし失敗したら、上に報告して自分の望む決定を引き出すんだ。例えば、Googleが消費者アカウントと企業アカウントで扱いを変えるのはなんで？まあ、Googleだから「彼らは整理されてない」って答えもあるけど、両方のケースで顧客の優先順位がちょっと違うから、実際には実用的な選択だった可能性が高いよ。

GMailは君のメッセージを処理するべきだ、じゃなくて、処理しなきゃならないわけじゃない。

RFCの文言に従うべきだし、Googleの解釈には従わなきゃならない。それが違いだよ。

推奨される理由は、受信したメールがすでにメールボックスにあるかどうかを検出するのに役立つからだよ。そうしないと重複がたまっちゃうからね。そうじゃなければ、完全なメールを比較しなきゃいけなくなるけど、たぶんどのMUAもそんなことはしないと思う。もう一つの理由は、返信に元のメッセージへの参照が含まれることがあるから、MUAによって適切にスレッド化できるようになるんだ。だから、これは主に生活の質を向上させる理由で、メールを拒否する理由にはならないよ。

SHOULDは要件だよ。それは、特定の理由がない限り、やらなきゃいけないってこと。例えば「やりたくない」は有効な言い訳じゃないし、「理由が見当たらない」もダメ。確かこの特定のルールはSHOULDになってるのは、MUAがしばしばメッセージをMessage-IDなしで送信するからで、必要に応じて送信サーバーが追加するんだ。https://www.rfc-editor.org/rfc/rfc6409.html#section-8.3 このSHOULDのおかげで、そういうメッセージが有効になるんだよ。今は良いランダムIDを生成できない低エントロピーのデバイスは珍しいけど、古いデバイスはまだ使われてるから、その回避策は正当化されると思う。

こういう広い主張には、普通は過激で誇張されてるって言うんだけど、実際にHarland Financial Systemsのコアシステムを使ってた金融機関で働いたこともあるんだ。彼らの「暗号化」は、窓口のワークステーションからコアシステムへのデータ転送のためのものが、たったの2バイトのXORで、接続の最初にキーを送ってたんだ！PCAPのパターンに気づいたら、30分もかからずにこれを解読できるなんて信じられなかった。自分の目で見なければ信じなかったよ。その詐欺は我々の規制当局や彼らの規制当局にも十分だったから、業界には腐った無能が満ちてるのは間違いないね。

FAAMGには無能な部分がたくさんあるよね。ノートパッド……ヨーロッパの金融機関もアメリカと同じくらい腐敗してるのかな？例えば、アメリカン・エキスプレスが誤った有効期限でクレジットカードの取引を承認して最大の利益を上げたり、ウェルズ・ファーゴが消費者の同意なしに新しい口座を開設したりするみたいな。

ちょっと気になるんだけど、送信するメールがHTMLバージョンだけの実装を見たことがあるんだ。送信プロセスの一部として、HTMLがLynxブラウザプロセスを通して-dumpコマンドで実行されて、プレーンテキストが得られて、それがメールのtext/plain部分に含まれるってやつ。これって実際に価値があるのかな？例えば、Lynxのテキストダンプの出力は、HTMLメールの表示よりもプレーンテキストメールクライアントにとって良いの？

可愛くしようとするやつが一番イライラする。新しいメッセージ通知に出てくるから、通知から直接削除できないんだよね。「このエキサイティングな発表を共有したいけど、別のメールアプリを使ってね」って。まぁ、メールクライアントはAIを使ってHTMLをプレーンテキストに要約すべきだっていう意見が出るんだろうけど。

そうだよね、だって世界中がGoogleワークスペースを使ってるからね、って感じだよね /s

この切り替えを考えたことがあるんだけど、つまり以前はGmailがメールを落としてたか、スパムに入ってたってこと？

Fastmailは新しいスパム技術にちょっと遅れて対応する時期があるみたいで、ユーザーがある程度フィルタリングするのに頼ってるよ。年に2回くらいスパムが混ざるけど、スパムとして報告すればすぐに止まる。まあ、他の面では何年も満足して使ってるけどね。

それを言うと面白いね、最近Fastmailに切り替えたら前よりスパムが増えたんだけど、しばらくスパムとしてマークしたら今は落ち着いてきたと思う。これもプロバイダーを変えたことの症状かもしれないね。前のプロバイダーは過去のスパムの傾向を知ってたけど、Fastmailは慣れるまでに時間がかかったのかも。君も同じような体験になるといいな。

これが一番イライラするんだよね。時々、面倒なことをするシステムと付き合わざるを得ないことがある。イライラするけど、理論的に標準で必要かどうかよりも、ユーザーが問題を抱えないようにすることの方が重要なんだ。これよりもひどいケースをたくさん経験してきたけど、統合していたシステムが全然合理的じゃないことをしてた。でも、彼らには市場の力があったから、ユーザーのために我慢して対処したんだ。もしかしたらGoogleが間違ってるかもしれないけど、それでも解決策を実装しないのはどういうこと？

そうだね。この細かいところが全部変だよね。メールを正式な仕様として扱うのはうまくいかないし、業界全体がそれを何十年も受け入れてきたんだ。スパムと有効なトラフィックをフィルタリングするには、たくさんのヒューリスティックを使ったり、どんどん増えていく補助信号（SPF、DKIM、などなど）を活用しないと無理だよ。要するに、この世界のほとんどのことは「SHOULD」で、せいぜいその程度。ルールは会話みたいなもんだね。