ちなみに、Gmail MTA は quoted string を含むメールアドレスへの送信を "The recipient address ＜メールアドレス＞ is not a valid RFC-5321" と嘘のメッセージを出して拒否するメールサービスの1つです。 そういうこともあるので、Gmail の + によるエイリアスが他社で弾かれるのは「自業自得」であって個人的には同情しにくいという思いもあります。
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.
そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:5, 参考になる)
皆がそういっているから正しいんだろう、と思い込む前にRFC原文を読んで下さい。
まともに原文を読まないエセエンジニアが、「.」の連続がRFC違反だというガセを流して、それが真実だと信じるエンジニアが増えてしまいましたが、誤りです。
（DNS"浸透"問題でも嘘が信じられていた時代もあったので、エンジニアの皆様もフェイク情報に惑わされやすいようです）
"hoge."@example.com や "ho..ge"@example.com は RFC 準拠です。
local partは、 クオーテーションマーク「"」のなかにスペースを含むいろんな文字が入ったquoted stringを含むことができる（廃止済みの RFC2822 3.2.5 → RFC 5322 3.2.4. に継承)とされています。
ガラケーも本当の初期の数年以外は、外部（インターネット）とのやり取り時には、"で正しく括ったquoted stringに自動変換して処理していたので、扱えないMTAの方が問題なのに、何故か携帯電話会社にRFC違反だという冤罪を押し付けるエンジニアが多く、それをRFCも読めないエンジニアが信じてしまったのです。
quoted stringが複雑怪奇で止めるべきだから冤罪を押し付けても良いと考える「確信犯」も中には大勢いたと思われますが、実装が面倒だからと排除が進んでしまうと、今回のようにエイリアス目的での「+」が弾かされるなどして、多くの人が不利益を被るようになってしまうのです。
ちなみに、Gmail MTA は quoted string を含むメールアドレスへの送信を "The recipient address ＜メールアドレス＞ is not a valid RFC-5321" と嘘のメッセージを出して拒否するメールサービスの1つです。
そういうこともあるので、Gmail の + によるエイリアスが他社で弾かれるのは「自業自得」であって個人的には同情しにくいという思いもあります。
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:3, すばらしい洞察)
またお前か
いい加減にしろ
Re: (スコア:0)
#4292971のようなコメントにスコアが付きやすいのがスラドのだるいところではある。
まあモデレータが面白いと思ったなら仕方ないんだが。
タイトルミスった (スコア:1)
正) そもそも「.」の連続や「"hoge."@example.com」はRFC違反ではありません
ちなみに、セキュリティの専門家の徳丸さんは https://www.tokumaru.org/ の連絡先として下記のメールアドレスを使っています。
"><script>alert('and/**/1=1--')</script>"@tokumaru.org
これは、RFC準拠です。
メールアドレスを受け付けるサービスを運営する場合には、quoted-string だけでなく、こういったメールアドレスも正しく処理できるようにテストしましょう。
Re: (スコア:0)
偉い人が使ってて対応せよとなる。
Re: (スコア:0)
確かに。
質の悪いユーザ (≠客) をはじくのに便利かも。
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:1)
「"foo."@example.com」はOK
「foo.@example.com」はアウト
まぁこんなんを一般ユーザー相手に説明する苦労は背負いたくないわな
いくら互換性が必要とはいえ、メールのRFCは複雑で不合理な仕様を保持しすぎだったと思う
一企業が自由に運用できるサービスに利便性で勝てないのは必然だった
今Web3とか言ってる連中はその辺どうするつもりなんだろな
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:1)
Web3とか言ってるものはWebと関係がないもので、それを持ち上げているのはただの詐欺集団です。
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:1)
RFC信者には、こういう手段と目的が逆転してる人が多いね。
RFCに準拠するとかえってトラブルが増えるからあえて制限してるのにね。
「RFCがー」と叫ぶだけで、なぜみんな準拠しないかを考えもしないし、準拠してないプロジェクトを支援することも絶対にしない。ただただRFCを金科玉条として崇め奉るだけ。
Re: (スコア:0)
ならRFC違反だから使えなくしましたという嘘をつくなという話やろ
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:1)
「高度に複雑化した仕様は、バグと見分けが付かない」
このジョークにピッタリの例の一つが、E-mailアドレスだと思う。
Re:そもそも「.」の連続や「.@」はRFC違反ではありません (スコア:1)
は？ さらっと責任転嫁すんな！！
外に出す時だけ自動変換して処理すればオッケーとでも思ってんのか？
外から入ってくるときのことを都合よく無視して「冤罪」ってお前さぁ……
携帯電話会社が"で正しく括ったquoted stringのアドレスをユーザーに払い出したか？
違うだろ、括らないRFC違反のアドレスを払い出しまくって世の中に迷惑かけてたんだよ
1年半前までそんな様だったからiOS 14 [mobile.srad.jp]で問題起こしてたんじゃねーか！
Re: (スコア:0)
そこをくくるのはUA (メーラー) の役割だぞ。
お前は手動で Subject ヘッダを B encoding してるんか？
UUCPをサポートしているのでなければRFC 5321を見ろ定期 (スコア:0)
RFC違反のメールアドレスの話になると必ず湧いてきて、RFC 5321の
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.
は(知ってるくせに)いつも無視するやつ
Re: (スコア:0)
いや、この手の輩は本当にこの辺知らないぞ。
RFC原文を読めという割に読んでなくて、自説に都合のいいところだけ検索して抜き出してる。
それメールボックスを作るときの話だし、RFCの理念を理解すべき (スコア:0)
#4293091 と #4293131 は似たような主張なのでまとめて反論しておく。
まず、quoted string がRFC違反でないことは、それが RFC 5322 3.2.4. で定義されていることからも明らか。
「自説に都合のいいところだけ検索して抜き出してる」のは、むしろ #4293091 の方。
お前さんが引用した部分は、
「上記の Local-part の定義は比較的寛容である。
相互運用性を最大にするために、メールを受信することを期待するホストは、
Quoted-string form や 大文字小文字を区別するメールボックスを定義することは避けるべきです」と言っているのであって、
これはメールボックスを作成
Re: (スコア:0)
「相互運用性を最大にするため」って言ってんだから、quoted stringを拒否する受信側があるのは仕方がないという意味のRFC。
したがって、会員サービスで拒否してはならない、許容しなければならないというのは間違い。
Re: (スコア:0)
今回の例でいえばユーザで使用不能なアドレスをマシマシしてるだけで何の相互運用性をあげたんだ？
Re: (スコア:0)
こいつ携帯電話会社のエンジニアか？
ずーっとスラドで恨み節書き続けてるよな
はよ成仏してクレメンス
Re: (スコア:0)
>メールアドレスの国際基準に準拠するために実施するものであり
あー、なるほど。こりゃ荒れるよね。
国際基準→デファクトスタンダードと読み替えてみてはどうでしょう。
# スタンダードは、デファクトスタンダード 槍が飛んできそうなのでAC
Re: (スコア:0)
そもそもRFCちゃんと読もうよ！って意見の人でさえ複雑怪奇って言っちゃうRFCも悪いのよね。
あんなもの完全に対応するコストより少数ユーザーを捨てるほうを選んじゃうのも理解できる。
RFC準拠なら間違いなく処理してくれるメールクライアント、メールサーバーはどれだけ存在することか。
Re: (スコア:0)
クオーテーションマークで括ったらどちらにしろピリオドはlocal-partの最後にはならないのでは。