by
Anonymous Coward
on 2020年11月07日 6時13分
(#3920083)
4.1.2. Command Argument Syntax
While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive.
Gmail は quoted-string 形式 を扱えないので糞 (スコア:4, 興味深い)
Gmail のSMTPサーバで "hoge..hoge"@example.com にメールを送ろうとするとエラーが返ってくる。
以下、4行は実際にGmalのSMTPサーバにデータを投げた時の生ログの一部
＞ RCPT TO:＜"hoge..hoge"@example.com＞
＜ 553-5.1.3 The recipient address ＜hoge..hoge@example.com＞ is not a valid RFC-5321
＜ 553 5.1.3 address. 【固有番号】 - gsmtp
* RCPT failed: 553
※スラドで正常に投稿できるように一部の記号を全角にしていますが実際には半角
RCPT TO: として ＜"hoge..hoge"@example.com＞ を指定しているのに、何故か Google のSMTPサーバは " (ダブルクォー
Re: (スコア:0)
まぁしかし実際、quoted-stringが必要なmailboxは避けるべき（SHOULD)ってRFCにも書かれてんだし、
Googleみたいに影響力のあるところが率先してこういうことしてくんないと、いつまでも過去のクソが残り続けて邪魔だわ
今はセキュリティとかもあって、古いものはガンガン更新させるのがトレンドだしな
Re: (スコア:0)
> quoted-stringが必要なmailboxは避けるべき（SHOULD)ってRFCにも書かれてんだし
ていうか当のRFC 5321に書かれてんのに、なぜ元米は自分の主張に都合のいいところしか読まないのか。まあメッセージは確かによくないけど
Re:Gmail は quoted-string 形式 を扱えないので糞 (スコア:1)
4.1.2. Command Argument Syntax
While the above definition for Local-part is relatively permissive,
for maximum interoperability, a host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or
uses) the Quoted-string form or where the Local-part is case-
sensitive.
（和訳）
上記の Local-part の定義は比較的寛容だが、最大限の相互運用性のために、メールの受信を期待するホストは、
Local-part が Quoted-string 形式を必要とする(または使用する)メールボックス、
または Local-part が大文字・小文字を区別するようなメールボックスの定義を避けるべきである(SHOULD)。
と確かに、Quoted-string を必要とするメールボックスは避けるべき (SHOULD) なのですが、
だからといって、直ちにRFC違反というわけではないので「not a valid RFC-5321」ではないし、
エラーとしては弾くのはいきすぎです。
「したほうがいいこと」「すべきこと」のレベル感
https://qiita.com/jkr_2255/items/5e20100e4e8527baea03 [qiita.com]
絶対的要求
MUST、REQUIRED、SHALLといった単語は、「そのとおりに実装しなければならない」という絶対的な指示で、逆にMUST NOTやSHALL NOTといった表現は「それをしてはならない」という絶対的な禁止となっています。これらの単語については、「相互運用性確保のために不可欠である場合や、 有害である可能性がある動作を制限するために限って、使用されるべき（MUST）」とされています。
推奨事項
SHOULDやRECOMMENDED、逆のSHOULD NOTやNOT RECOMMENDEDについては、守らなければ直ちにRFC違反となるわけではないのですが、もちろん推奨するからにはそれ相応の理由があるわけで、あえて外れる場合には「慎重に重要性を判断しなければならない」ものです。
Re: (スコア:0)
だってエラーにして弾かないと、いつまで経っても迷惑な奴らがいなくならないんだもの
RFCを絶対視して崇め奉るより、そうしてくれた方がずっといい
Re: (スコア:0)
メールの作成元であるMUAがそうするのはわかるが、仲介役でしかないMTAが独自ルールを押し付けるのはただの身勝手だと思う
せめて「今後はこうしよう」と新たなRFCを公開するなどの手順は踏んだ方がいい