RFC違反のキャリアメールアドレスという負の遺産、iOS 14で再び顕在化 82
ストーリー by nagazou
レガシー仕様 部門より
レガシー仕様 部門より
あるAnonymous Coward 曰く、
NTTドコモは4日、RFC違反のメールアドレスを利用している場合にiOS 14でメールを送信できない事象に対処するためのプロファイルを公開した（iOS14アップデート後、メール送信不可となる事象に関して）。
NTTドコモによると、アドレス内に2連続のドット「..」が含まれていたり、アットマーク前にドット「.@」が含まれているアドレスをiOS 14以降のメールアプリに設定すると、ドコモメールを送信することができなくなるとして、対象者にはSMSを通じてアドレスの変更またはプロファイルの更新を呼び掛けている。プロファイルを更新することで、アットマークの左側がクオートで囲まれ、RFC 5321 / RFC 5322 準拠の quoted-string 形式に変わるようだ。
こうしたRFC違反のアドレスはしばしばトラブルを引き起こすことから技術者からは批判の的となっていたが、日本のキャリアメールにおいては絵文字文化や迷惑メール対策として長らく容認・推奨されていた。
docomoでは2009年4月以降、RFC違反のアドレスは新規取得できなくなっていたが、すでに取得済みのものは継続利用できるため、システム側で互換性に配慮しなければいけない負の遺産となっている（ドコモ、メールアドレスの仕様を修正）。
なお、現在KDDIからの発表はないが、auメールでも同様の事象が発生していたとの情報もある。auでは2006年6月から2009年9月までRFC違反のアドレスが取得できるようになっていた（auのEメールアドレスが相互接続性を保障できないルールに変更?）。
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サーバは " (ダブルクォート) を勝手に削除したあげく
＜ 553-5.1.3 The recipient address ＜hoge..hoge@example.com＞ is not a valid RFC-5321
＜ 553 5.1.3 address. 【固有番号】 - gsmtp
と、RFC 5321 に違反しているかのようなメッセージを返してくる。自分のサーバが quoted-string を扱えないだけなのに、まるでユーザがRFCに違反しているかのようなエラーを返すのは誤解を招くという意味で最悪。
RFC 準拠の quoted-string を扱えないMTAは非難されるべき。
このせいで、Gmail から "hoge..hoge"@example.com のようなRFC準拠の quoted-string アドレスにメールが送れないというトラブルが発生している。
これ、bug なんじゃないの？ (スコア:1)
security を up させる purpose で double-quotation (") を sanitizing した result として、
RFC violation が occurred しちゃって error になっちゃってるだけな気がする。
english が very well な people が Google に bug report したら案外 solve the problem するのでは？
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違反となるわけではないのですが、もちろん推奨するからにはそれ相応の理由があるわけで、あえて外れる場合には「慎重に重要性を判断しなければならない」ものです。
違反なのはわかってるけど (スコア:3, 参考になる)
RFCであんな難解なフォーマットを規定した合理的理由がないのも問題だと思いますけどね。
これは有効だけど、
!#$%&'*+-/=?^_`.{|}~@example.com
これは無効。
!#$%&'*+-/=?^_`{|}~.@example.com
有効な例でもバリデーションで弾くユーザ登録フォームが結構ありますし。
Re:違反なのはわかってるけど (スコア:3)
docomoが微妙なのもわかるが、
大元の問題はこれ(RFCがいけてない)だと思う
文字セットだけ決める、に変えればいいのに
quotedも禁止で
Re: (スコア:0)
とは言えなんでRFC違反が多発したかっていうとドコモやガラケー関係者が頑なになってRFC準拠を拒否したからでもある
例えば記号禁止にするとかいくらでも安易な回避方法があるのに、ガラケー時代は「そうした方がPCを排除できて良い」
と言った愚かな意見が罷り通っていた
というか「PCと携帯の世界は分けなければマナー違反」というアパルトヘイト思想が酷かった
Re:違反なのはわかってるけど (スコア:2)
いやでも実際「そんなの必要か??」ってぐらい複雑なんですよ
Re:違反なのはわかってるけど (スコア:1)
RFC 5322はメールアドレスだけの仕様を定めているわけではなく、メールメッセージフォーマット全体の仕様なので、メールメッセージ中にメールアドレスを記述するだけために必要な、メールアドレス単体のフォーマットとしてはぶっちゃけ無意味で無駄な仕様が含まれている。
今日UUCPはもう無視していいと思うので、メールアドレスだけの仕様についてはRFC 5321を参照したほうがいい。これもSMTPの仕様であってメールアドレスだけの仕様ではないが、RFC 5322よりは断然マシ。
Re:違反なのはわかってるけど (スコア:3, 参考になる)
まぁ、もうすでに歴史的ではあるんですけど
ユーザパートのドットの制限はおそらく uucp 等のためです。
昔は％ハックなどの方法で uucp など SMTP 以外の世界へメールをルーティングする書式が使われていたので。
uucp を考慮しない実装でよければ @ の前は @ 以外の文字なんでもよかったんでしょうけどね。
# uucp をサポートした sendmail cf などもルールを記述する際にドットで区切って文字列を扱うのよね
Re:違反なのはわかってるけど (スコア:1)
mailbox.sub1.sub2@this-domain や sub-net.mailbox@sub-domain.domain のように
local-part の一部に domain を埋め込む例が RFC822 に載っていますので
local-part に dot-atom を許容するのは当初は配送のためだったと思いますが
RFC2822 への改定を生き延びたのは Firstname.Lastname@domain という使用例が
それなりにあるという主張が通ったためというおぼろげな記憶があります。
Re:違反なのはわかってるけど (スコア:1)
Gmail でも利用できる + を使用した拡張アドレスを受け付けないフォームが時々あるね。
ローカルパートの記号は ._- しか使えないと勘違いしている Web 屋も結構残ってそう。
Re: (スコア:0)
複垢対策のためにエイリアスを使わせたくないっていう意味もあると思う
Re: (スコア:0)
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
1行の正規表現でとかやるから難解になるんじゃね？
ローカルパート作るときはアルファベットのみとかの制限つければいいし
既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。
いくらバリデーションしても届かないものは届きませんし
RFC準拠なら何でも登録させろというのはまた違うでしょ。
Re: (スコア:0)
ガバガバすぎるでしょ。
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
だけじゃなくて他にも決まりはあるし、実際その3つだけでも真面目に実装したら結構たいへんですよ。
ローカルパート作るときはアルファベットのみとかの制限つければいいし
既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。
ん？送信エラーにおまかせってことですか？
RFC準拠なら何でも登録させろというのはまた違うでしょ。
チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
Re: (スコア:0)
> チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
ええと、MTAの実装の話をしているのかな？
バリデーション書けないならライブラリとか使えば良くない？
そんなに複雑なコードでもないよ。
例えばこれとか
https://pypi.org/project/validate_email/#files [pypi.org]
Re: (スコア:0)
そのライブラリ試したらこんなですけど？
$ python3
>>> from validate_email import validate_email
>>> validate_email('やっふーい@example.com')
True
まぁ複雑かどうかは主観なのでどっちでもいいのですが、
やる必要がないことをやらされてる感が半端ないです。
公的な国際標準は？ (スコア:2)
RFC違反の
RFCってどういう根拠の国際標準だったっけ？
全然わかってなかったので復習してみた
ISO,IEC
各国の代表的標準化機関から成る国際標準化機関
参考 https://www.jisc.go.jp/international/index.html [jisc.go.jp]
ITU
国連専門機関
参考 https://www.mofa.go.jp/mofaj/gaiko/page22_000757.html [mofa.go.jp]
IETF
任意団体(学会機関ISOCに属する, ISOCは、RFCの著作権を所有、ITUと協力関係を確立)
参考 https://www.nic.ad.jp/ja/tech/ietf/section3.html [nic.ad.jp]
IETFとRFC
・・・いろいろ解説してくれてるけど・・・一言でまとめてくれない
参考 https://www.nic.ad.jp/ja/tech/rfc-jp.html [nic.ad.jp]
RFC
IETFが策定し、標準化過程を経て標準プロトコルとなる
参考 https://www.nic.ad.jp/ja/tech/glos-ietf.html [nic.ad.jp]
標準化に対する思想
ITU,ISO 標準は変わらないもの 先に仕様を決める
IETF 標準は変わるもの 先に実装を考える
SMTPは、任意団体IETFによる標準であって、ISOとかITUによるものじゃないんでですね。
任意団体だから公的じゃない、と言いたいわけではないです。
SMTPを含め、インターネット技術の標準化のほとんどが任意団体IETFによって推進されている、ということを再認識した次第。
訂正 (スコア:0)
× 絵文字文化
〇 顔文字文化
そしてインジェクションへ (スコア:0)
フォームのメールアドレス欄がクオート可となり
やっつけ対応のシステムで阿鼻叫喚みたいな
# Wordpress Pluginとか素敵なことになりそう
Re: (スコア:0)
逆にRFC準拠のはずの、+使ったメールアドレス使えないフォームとか頭にくる
Re:そしてインジェクションへ (スコア:1)
あと、英語圏の名字によく入っているシングルクォート。
o'neil@example.com とかめっちゃいそう。
Re: (スコア:0)
うっ。耳が遺体
うちのシステム的には ＋もおっけーにしたかったんだけど、
E-mailアドレスを介してIDとして利用している連携先のシステムが ＋不許可なので、
やむを得ずこっちのも ＋不許可にしたことがあったなあ。
技術的にはもちろん回避可能だけど、たかがIDにそこまで手間かけられるか
今まで問題になったことねえぞということで、なし崩し的に。
Re: (スコア:0)
チェックの簡略化はまあいいと思うんだけど、+は許容して欲しいんだよね。
それともGmailの仕様のセンスが良くなかったのかな。
Re: (スコア:0)
サブアドレス(+任意文字列)はGmailではなくずっと前(sendmail)から引き継がれてきた仕様だったような
Re:そしてインジェクションへ (スコア:2, 参考になる)
Gmailでメアドが無限に増殖できるワザの名前と起源について - in between days [hateblo.jp]
sendmail由来みたいですね
Re: (スコア:0)
勉強になった。ひとつ上のコメントもありがとう。
Re: (スコア:0)
RFCって、規格とかとちがって、勧告文書なので、だいたいでいいんだよ
というのをかなり昔にどっかで見たが見つからない
Re: (スコア:0)
確かになんの強制力もないわな、RFCって名前の通りだ
言い訳したり、逆に説得するのに便利
だいたいで済ませていいかどうかは、ケースバイケース
強制変更させればよかったのに (スコア:0)
ガラケーからスマホに機種変する人に強制変更させればよかったのに。
スマホになると使えないんですよーとか言えばほとんどの人は疑わないよ。
Re:強制変更させればよかったのに (スコア:1)
AppleIDとかにキャリアメールを登録してる人が結構いるんですわ。
友達がMNPしたのにAppleIDのアドレスが前のキャリアのアドレスで登録したままで詰んでた。
あいつ結局どうしたんだろう・・・
強制変更すると、古いアドレスで登録してたサービスが使えなくなる可能性(所有者確認できなくなる)が出てくる。
Re: (スコア:0)
ガラケーからスマホに機種変する人に強制変更させればよかったのに。
スマホになると使えないんですよーとか言えばほとんどの人は疑わないよ。
では5Gを期に
ちょっと出遅れだけどまだ間に合うよね
そして5G忌避が加速。。。
なので
スマホ過渡期と同じく対処なし確定でしょうね
Re: (スコア:0)
今、機種変とアドレス変更を同時にさせると阿鼻叫喚なりそうな気がする。
docomoのアカウントは変更するメアドだし、
契約内容の確認が送付されるのもメール。
わからないからと言って、ショップに行こうにも予約するのはアカウント経由。
せめて契約が紙媒体の時代に強制させておけばねえ。
Re: (スコア:0)
元auで「○○○...」というアカウント使っていましたが、
他社のスマホと通信出来ないのは仕様と説明されて変更した記憶が。
政府が禁止すればいいんでね (スコア:0)
MNPの障害の一つがキャリアメールだと思ってるのなら、相互運用させるより廃止したほうが手っ取り早い。
国のトップダウンで決めればRFCの負の遺産から解放される以外にMMS非採用という呪縛からも抜けられる。
問題は受け皿をどうするか。国民総背番号制ならぬ国民総メールアドレス制でも必須になるのかね。
Re: (スコア:0)
RFC違反のメールアドレスの廃止の要請 by ikemoさん | デジタル改革アイデアボックス [cio.go.jp]
Re: (スコア:0)
MNPの障害の一つがキャリアメールだと思ってるのなら、相互運用させるより廃止したほうが手っ取り早い。
国のトップダウンで決めればRFCの負の遺産から解放される以外にMMS非採用という呪縛からも抜けられる。
問題は受け皿をどうするか。国民総背番号制ならぬ国民総メールアドレス制でも必須になるのかね。
メールアドレス不要には同意ですが、MMSについてはむしろ電話番号宛MMSを全キャリア統一採用させるべきだと思いますね。
今はSoftBankとauのiPhoneしか利用できませんが、これが全キャリアで相互接続されれば非常に利便性が高い。
Re: (スコア:0)
MMSが各社繋がる線は薄いんではないでしょうか
#名前思い出せませんが、使っている人いるんですかね？
Re:政府が禁止すればいいんでね (スコア:1)
+メッセージ(3大キャリア限定RCS)は、今時の端末だとSMS用にプリインストールされてるので強制的に使うことに。
キャリア毎に独自カスタムが入っているのでMNPしたらそのキャリア向けの+メッセージを入れないと駄目。
尚、使用しないにするとマイページに電話番号が出ないバグが有ったり(過去形)、spam通報が簡単に出来ないとか、今時プレビューがデフォルトオンとか、仕様の品質もゴミ。
Re: (スコア:0)
それは「+メッセージ」です。これはdocomo,au,SoftBankしか使えないのでゴミです。
最低でもMNOとMVNOの全社で使えるようにならない限り(SMSの上位互換としての)実用になりません。
現状ではMNOである楽天ですら使用不可ですから。
Re: (スコア:0)
SIMフリー機で使うと読めたり読めなかったりで面倒だしなあ。
さっさと廃止してほしいものだ。
なんということだ！ (スコア:0)
"/."@srad.jpとか
"/."@"/.".jpとか
可能ということか！？
# それはない
Re: (スコア:0)
前者は可能、後者はドメイン名のルール違反で不可だと思われ
Re:なんということだ！ (スコア:1)
"..-/-.-/./-././.-./.-/.."@～
とかもありなんですね。
区切り文字で何種類かできてしまうか。
-- う～ん、バッドノウハウ？
Re: (スコア:0)
"..-/-.-/./-././.-./.-/.."@～
とかもありなんですね。
顔文字入りか！？
""で囲めば大丈夫なんじゃなかったっけ？ (スコア:0)
RFC的には
Re: (スコア:0)
だから強制的にクォートで囲むプロファイルをドコモがリリースしたという話
Re: (スコア:0)
ドコモは該当するメールアドレスを含むメールを外部へ出すときにクォートしてますね。
だからRFC違反ではないといえるのでは、と常々思っているわけですが、どんなもんでしょ？
（KDDIとSBがどうなっているのかは知らない）
RFC準拠のメールアドレスとか言っても、クォートしているのが通らないのが多いですよね。
それはそれでRFC違反なんではと思わないでもなかったり。
RFC準拠アドレスでも送れないケース (スコア:0)
キャリアメールの話題からちょっと外れるけど。
数十年使ってる自社メールアドレスのローカルパートが、全部英大文字で構成されてる。
自社のサーバーは大小文字を厳密にチェックしてる(これはRFC非推奨だが違反じゃない)。
Outlook系のメールサーバーから上記アドレスに送ると、メールヘッダのTo:パートは
大文字のままだが、エンベロープtoのローカルパートが小文字にされ、
そんなユーザはおらんとエラーが返る。
自社サーバー管理者に小文字も通してと依頼すればいい話だけど、
そもそもユーザが設定したメールアドレスを勝手に書き換えてる時点で
「メール送信システム側のバグ」だと認識してるので、頼んでない。
送信側はローカルパート大小文字を区別しなきゃいけない(MUST)。
# たぶん余計な「CapsLock押されてる補正」が効いてる
Re: (スコア:0)
違反じゃなくたって迷惑なサーバーだよ、目糞鼻糞レベル
不幸な話だ
そもそも、quoted-string 形式を扱えないタコなMTAが原因で3キャリアは冤罪被害者だった (スコア:0)
実は、連続ドットやアットマーク直前のドットがあるメールアドレスを発行していた3キャリアは、実はRFC的には問題ありませんでした。
というメールアドレスであっても MTA が とすれば良いだけなのです。
quoted-string 形式を扱えないタコな MTA で不具合が生じていただけで、3キャリアはRFC的には悪くありませんでした。
問題となっているRFCは、通信に使われるメッセージフォーマットを定めたものであって、ユーザーが使用するメールアドレス、つまりはMUAのアドレス欄とかWebのフォーム等に入力するメールアドレスの表示を定めたものではありません。
即ち、エンドユーザーのメーラーの表示は「"hoge..hoge."@example.com」であっても「hoge..hoge.@example.com」であってもどちらでもよろしいです。
それを外部に出す前に適切に quoted-string 形式に変換すれば良いだけなので、Webフォームでは「hoge..hoge.@example.com」を validation で弾くのではなく、「"hoge..hoge."@example.com」に escape すべきなのです。
3キャリアはRFCを読んだことのない人達やRFCで定められたquoted-string 形式をまともに扱えないタコなMTAを使っている事業者から、冤罪で「RFC違反」というレッテル張りをされた被害者です。