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を生成できない低エントロピーのデバイスは珍しいけど、古いデバイスはまだ使われてるから、その回避策は正当化されると思う。