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. For any purposes that require generating or comparing
Local-parts (e.g., to specific mailbox names), all quoted forms MUST
be treated as equivalent, and the sending system SHOULD transmit the
form that uses the minimum quoting possible.
一応、このように、quoted-stringはなるべく避けるべき(SHOULD NOT)とはありますが、 「してはならない( MUST NOT )」ではないので、「RFCに準拠していない」というのはガセです。
これってセキュリティ的な理由ではないってこと? (スコア:1)
単にキャリアメール対応マンドクセって話なんですかね?
それともキャリア業参入への布石とか...
Re: (スコア:1)
キャリアメールを特別扱いするだけの理由がなくなったってことかなと。
そもそも2段階認証の手段として経路上が平文の電子メールは不適切なわけだから。
あと日本国内でも「キャリアメール」が特別なものではなくなってきてる事情もあるしね。
一時期はスマホ持ってたら確実にキャリアメールも持ってたけど、MVNOが広まったおかげ
「持ってない人」も多いわけで、メール経路はSMSに一本化してもいいという判断にもなる。
Re: (スコア:1, 参考になる)
日本だけのためにいつまでも特別対応していられないということかもしれない。
対応を間違えるとRe:ハマトラ事件の再来にもなり得るし。
SHOULD NOT を「RFCに準拠していない」と書くな (スコア:5, 参考になる)
“" "”でくくられたquoted-stringの形式であれば、ドット . の連続やローカル部最後の使用も可能です(quoted-string中では制限はない)。
実際の運用でも、3キャリアのMTAも主要MTAもquoted-string形式に対応していますし、ユーザがquoted-stringの形式にしていなくてもMTAが勝手にエスケープ処理してquoted-string形式にしてくれるので特に互換性での問題も生じていません。
あと、RFCに準拠したMTAなんてスパゲッティーコードのsendmailぐらいしか存在しないので、キャリアメール批判のために、RFCがどのと言い出すと大抵の場合ブーメランになります。
https://tools.ietf.org/html/rfc5321#section-4.1.2 [ietf.org]
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. For any purposes that require generating or comparing
Local-parts (e.g., to specific mailbox names), all quoted forms MUST
be treated as equivalent, and the sending system SHOULD transmit the
form that uses the minimum quoting possible.
一応、このように、quoted-stringはなるべく避けるべき(SHOULD NOT)とはありますが、
「してはならない( MUST NOT )」ではないので、「RFCに準拠していない」というのはガセです。
https://www.ipa.go.jp/security/rfc/RFC2119JA.html [ipa.go.jp]
RFC において要請の程度を示すために用いるキーワード
もご覧ください。
Re: (スコア:0)
> “" "”でくくられたquoted-stringの形式であれば、ドット . の連続やローカル部最後の使用も可能です(quoted-string中では制限はない)。
キャリアメールは、古にそのルールをガン無視した顔文字風メールアドレス
(エイリアス部に -.- を含むなど)作成できた時代があったので、
今もメアド変更されず、亡霊のように残ってる件数が意外と多いのかな
https://www.asobou.co.jp/blog/web/mail-rfc [asobou.co.jp]
Re: (スコア:0)
以前はquoted-string形式にしないで送り付けてきたり、
quoted-string形式で送っても無視されてたとかそういう話じゃないの?
今はquoted-string形式で送受信出来てるんであれば「過去の悪行」かもしれないが…
…悪行は悪行って言う人は言うだろうね。
Re: (スコア:0)
前回この話題になったときにコメントした内容をちゃんと反映してくれてて嬉しい(ツッコミの内容を無視してまったく同じこと繰り返すやつのほうが多いくらいなのに)。
Re: (スコア:0)
ちなみにHTML5の<input type="email">はquoted-string形式のメールアドレスに(意図的に [whatwg.org])対応していない。
どうしてもquoted-string形式のメールアドレスをサポートしたければCustom Elementsで頑張る等の手もあるにはあるので、SHOULD NOTの趣旨を踏まえれば妥当だと思う。
Re: (スコア:0)
メールアドレスの入力ってのはアドレス所有者にとってポジティブな意図で行われるばかりではない。
例えばメール拒否リストにこの入力要素を使われた場合、
拒否を避けてメール送りつけたい人はSHOULD NOTなメールアドレス取得してメール送りつける事が出来てしまう。
いやメール拒否リストに制限のある入力要素使うなよって話ではあるけど、
制限があると知られていなけりゃ意味がない。
つかそもそも、意図的に排除してんのはわかったけどその理由が理由になってない気がするわ。
非推奨アドレスを皆が拒否することで撲滅しようって意図だとしても、
前述のとおり悪意に対するネガティブな応答まで阻害してしまうのは公益にならない。