パスワードを忘れた? アカウント作成
14979788 story
携帯電話

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メールアドレスが相互接続性を保障できないルールに変更?)。

  • by Anonymous Coward on 2020年11月06日 21時02分 (#3919948)

    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 アドレスにメールが送れないというトラブルが発生している。

    ここに返信
    • by Anonymous Coward on 2020年11月07日 3時29分 (#3920064)

      security を up させる purpose で double-quotation (") を sanitizing した result として、
      RFC violation が occurred しちゃって error になっちゃってるだけな気がする。

      english が very well な people が Google に bug report したら案外 solve the problem するのでは?

  • by eriol (46576) on 2020年11月06日 12時47分 (#3919586)

    RFCであんな難解なフォーマットを規定した合理的理由がないのも問題だと思いますけどね。

    これは有効だけど、
    !#$%&'*+-/=?^_`.{|}~@example.com
    これは無効。
    !#$%&'*+-/=?^_`{|}~.@example.com

    有効な例でもバリデーションで弾くユーザ登録フォームが結構ありますし。

    ここに返信
    • docomoが微妙なのもわかるが、
      大元の問題はこれ(RFCがいけてない)だと思う
      文字セットだけ決める、に変えればいいのに
      quotedも禁止で

      • by Anonymous Coward

        とは言えなんでRFC違反が多発したかっていうとドコモやガラケー関係者が頑なになってRFC準拠を拒否したからでもある
        例えば記号禁止にするとかいくらでも安易な回避方法があるのに、ガラケー時代は「そうした方がPCを排除できて良い」
        と言った愚かな意見が罷り通っていた

        というか「PCと携帯の世界は分けなければマナー違反」というアパルトヘイト思想が酷かった

        • いやでも実際「そんなの必要か??」ってぐらい複雑なんですよ

          • by Anonymous Coward on 2020年11月06日 18時59分 (#3919872)

            RFC 5322はメールアドレスだけの仕様を定めているわけではなく、メールメッセージフォーマット全体の仕様なので、メールメッセージ中にメールアドレスを記述するだけために必要な、メールアドレス単体のフォーマットとしてはぶっちゃけ無意味で無駄な仕様が含まれている。

            今日UUCPはもう無視していいと思うので、メールアドレスだけの仕様についてはRFC 5321を参照したほうがいい。これもSMTPの仕様であってメールアドレスだけの仕様ではないが、RFC 5322よりは断然マシ。

    • by Anonymous Coward on 2020年11月06日 13時50分 (#3919642)

      まぁ、もうすでに歴史的ではあるんですけど
      ユーザパートのドットの制限はおそらく uucp 等のためです。
      昔は%ハックなどの方法で uucp など SMTP 以外の世界へメールをルーティングする書式が使われていたので。
      uucp を考慮しない実装でよければ @ の前は @ 以外の文字なんでもよかったんでしょうけどね。
      # uucp をサポートした sendmail cf などもルールを記述する際にドットで区切って文字列を扱うのよね

      • by Anonymous Coward on 2020年11月07日 21時12分 (#3920385)

        mailbox.sub1.sub2@this-domain や sub-net.mailbox@sub-domain.domain のように
        local-part の一部に domain を埋め込む例が RFC822 に載っていますので
        local-part に dot-atom を許容するのは当初は配送のためだったと思いますが
        RFC2822 への改定を生き延びたのは Firstname.Lastname@domain という使用例が
        それなりにあるという主張が通ったためというおぼろげな記憶があります。

    • by Anonymous Coward on 2020年11月06日 13時10分 (#3919606)

      Gmail でも利用できる + を使用した拡張アドレスを受け付けないフォームが時々あるね。
      ローカルパートの記号は ._- しか使えないと勘違いしている Web 屋も結構残ってそう。

      • by Anonymous Coward

        複垢対策のためにエイリアスを使わせたくないっていう意味もあると思う

    • by Anonymous Coward

      dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
      1行の正規表現でとかやるから難解になるんじゃね?

      ローカルパート作るときはアルファベットのみとかの制限つければいいし
      既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。

      いくらバリデーションしても届かないものは届きませんし
      RFC準拠なら何でも登録させろというのはまた違うでしょ。

      • by Anonymous Coward

        ガバガバすぎるでしょ。

        dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。

        だけじゃなくて他にも決まりはあるし、実際その3つだけでも真面目に実装したら結構たいへんですよ。

        ローカルパート作るときはアルファベットのみとかの制限つければいいし
        既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。

        ん?送信エラーにおまかせってことですか?

        RFC準拠なら何でも登録させろというのはまた違うでしょ。

        チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。

        • by Anonymous Coward

          > チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。

          ええと、MTAの実装の話をしているのかな?

          バリデーション書けないならライブラリとか使えば良くない?
          そんなに複雑なコードでもないよ。

          例えばこれとか
          https://pypi.org/project/validate_email/#files [pypi.org]

          • by Anonymous Coward

            そのライブラリ試したらこんなですけど?

            $ python3
            >>> from validate_email import validate_email
            >>> validate_email('やっふーい@example.com')
            True

            まぁ複雑かどうかは主観なのでどっちでもいいのですが、
            やる必要がないことをやらされてる感が半端ないです。

  • by st1100 (45287) on 2020年11月07日 15時52分 (#3920269)

    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によって推進されている、ということを再認識した次第。

    ここに返信
  • by Anonymous Coward on 2020年11月06日 12時11分 (#3919565)

    × 絵文字文化
    〇 顔文字文化

    ここに返信
  • by Anonymous Coward on 2020年11月06日 12時24分 (#3919570)

    フォームのメールアドレス欄がクオート可となり
    やっつけ対応のシステムで阿鼻叫喚みたいな

    # Wordpress Pluginとか素敵なことになりそう

    ここに返信
    • by Anonymous Coward

      逆にRFC準拠のはずの、+使ったメールアドレス使えないフォームとか頭にくる

      • あと、英語圏の名字によく入っているシングルクォート。

        o'neil@example.com とかめっちゃいそう。

      • by Anonymous Coward

        うっ。耳が遺体

        うちのシステム的には +もおっけーにしたかったんだけど、
        E-mailアドレスを介してIDとして利用している連携先のシステムが +不許可なので、
        やむを得ずこっちのも +不許可にしたことがあったなあ。

        技術的にはもちろん回避可能だけど、たかがIDにそこまで手間かけられるか
        今まで問題になったことねえぞということで、なし崩し的に。

      • by Anonymous Coward

        チェックの簡略化はまあいいと思うんだけど、+は許容して欲しいんだよね。
        それともGmailの仕様のセンスが良くなかったのかな。

      • by Anonymous Coward

        RFCって、規格とかとちがって、勧告文書なので、だいたいでいいんだよ
        というのをかなり昔にどっかで見たが見つからない

        • by Anonymous Coward

          確かになんの強制力もないわな、RFCって名前の通りだ
          言い訳したり、逆に説得するのに便利
          だいたいで済ませていいかどうかは、ケースバイケース

  • by Anonymous Coward on 2020年11月06日 12時30分 (#3919574)

    ガラケーからスマホに機種変する人に強制変更させればよかったのに。
    スマホになると使えないんですよーとか言えばほとんどの人は疑わないよ。

    ここに返信
    • by Anonymous Coward on 2020年11月06日 14時09分 (#3919661)

      AppleIDとかにキャリアメールを登録してる人が結構いるんですわ。
      友達がMNPしたのにAppleIDのアドレスが前のキャリアのアドレスで登録したままで詰んでた。
      あいつ結局どうしたんだろう・・・

      強制変更すると、古いアドレスで登録してたサービスが使えなくなる可能性(所有者確認できなくなる)が出てくる。

    • by Anonymous Coward

      ガラケーからスマホに機種変する人に強制変更させればよかったのに。
      スマホになると使えないんですよーとか言えばほとんどの人は疑わないよ。

      では5Gを期に
      ちょっと出遅れだけどまだ間に合うよね

      そして5G忌避が加速。。。

      なので
      スマホ過渡期と同じく対処なし確定でしょうね

    • by Anonymous Coward

      今、機種変とアドレス変更を同時にさせると阿鼻叫喚なりそうな気がする。

      docomoのアカウントは変更するメアドだし、
      契約内容の確認が送付されるのもメール。
      わからないからと言って、ショップに行こうにも予約するのはアカウント経由。

      せめて契約が紙媒体の時代に強制させておけばねえ。

    • by Anonymous Coward

      元auで「○○○...」というアカウント使っていましたが、
      他社のスマホと通信出来ないのは仕様と説明されて変更した記憶が。

  • by Anonymous Coward on 2020年11月06日 12時36分 (#3919579)

    MNPの障害の一つがキャリアメールだと思ってるのなら、相互運用させるより廃止したほうが手っ取り早い。
    国のトップダウンで決めればRFCの負の遺産から解放される以外にMMS非採用という呪縛からも抜けられる。

    問題は受け皿をどうするか。国民総背番号制ならぬ国民総メールアドレス制でも必須になるのかね。

    ここに返信
    • by Anonymous Coward

      MNPの障害の一つがキャリアメールだと思ってるのなら、相互運用させるより廃止したほうが手っ取り早い。
      国のトップダウンで決めればRFCの負の遺産から解放される以外にMMS非採用という呪縛からも抜けられる。

      問題は受け皿をどうするか。国民総背番号制ならぬ国民総メールアドレス制でも必須になるのかね。

      メールアドレス不要には同意ですが、MMSについてはむしろ電話番号宛MMSを全キャリア統一採用させるべきだと思いますね。
      今はSoftBankとauのiPhoneしか利用できませんが、これが全キャリアで相互接続されれば非常に利便性が高い。

      • by Anonymous Coward
        あの何とかっていう大手キャリアだけで使えるLINE対抗アプリだしてる(た?)ので
        MMSが各社繋がる線は薄いんではないでしょうか
        #名前思い出せませんが、使っている人いるんですかね?
        • by Anonymous Coward on 2020年11月06日 13時23分 (#3919621)

          +メッセージ(3大キャリア限定RCS)は、今時の端末だとSMS用にプリインストールされてるので強制的に使うことに。
          キャリア毎に独自カスタムが入っているのでMNPしたらそのキャリア向けの+メッセージを入れないと駄目。
          尚、使用しないにするとマイページに電話番号が出ないバグが有ったり(過去形)、spam通報が簡単に出来ないとか、今時プレビューがデフォルトオンとか、仕様の品質もゴミ。

        • by Anonymous Coward

          それは「+メッセージ」です。これはdocomo,au,SoftBankしか使えないのでゴミです。
          最低でもMNOとMVNOの全社で使えるようにならない限り(SMSの上位互換としての)実用になりません。
          現状ではMNOである楽天ですら使用不可ですから。

          • by Anonymous Coward

            SIMフリー機で使うと読めたり読めなかったりで面倒だしなあ。
            さっさと廃止してほしいものだ。

  • by Anonymous Coward on 2020年11月06日 12時41分 (#3919583)

    "/."@srad.jpとか
    "/."@"/.".jpとか

    可能ということか!?

    # それはない

    ここに返信
  • by Anonymous Coward on 2020年11月06日 12時48分 (#3919588)

    RFC的には

    ここに返信
    • by Anonymous Coward

      だから強制的にクォートで囲むプロファイルをドコモがリリースしたという話

    • by Anonymous Coward

      ドコモは該当するメールアドレスを含むメールを外部へ出すときにクォートしてますね。
      だからRFC違反ではないといえるのでは、と常々思っているわけですが、どんなもんでしょ?
      (KDDIとSBがどうなっているのかは知らない)

      RFC準拠のメールアドレスとか言っても、クォートしているのが通らないのが多いですよね。
      それはそれでRFC違反なんではと思わないでもなかったり。

  • by Anonymous Coward on 2020年11月06日 14時33分 (#3919682)

    キャリアメールの話題からちょっと外れるけど。
    数十年使ってる自社メールアドレスのローカルパートが、全部英大文字で構成されてる。
    自社のサーバーは大小文字を厳密にチェックしてる(これはRFC非推奨だが違反じゃない)。
    Outlook系のメールサーバーから上記アドレスに送ると、メールヘッダのTo:パートは
    大文字のままだが、エンベロープtoのローカルパートが小文字にされ、
    そんなユーザはおらんとエラーが返る。
    自社サーバー管理者に小文字も通してと依頼すればいい話だけど、
    そもそもユーザが設定したメールアドレスを勝手に書き換えてる時点で
    「メール送信システム側のバグ」だと認識してるので、頼んでない。
    送信側はローカルパート大小文字を区別しなきゃいけない(MUST)。

    # たぶん余計な「CapsLock押されてる補正」が効いてる

    ここに返信
    • by Anonymous Coward

      違反じゃなくたって迷惑なサーバーだよ、目糞鼻糞レベル
      不幸な話だ

  • 実は、連続ドットやアットマーク直前のドットがあるメールアドレスを発行していた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違反」というレッテル張りをされた被害者です。

    ここに返信
typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...