パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

auのEメールアドレスが相互接続性を保障できないルールに変更?」記事へのコメント

  • by kawaz (15398) on 2006年06月01日 19時06分 (#951772) ホームページ
    携帯向けメール転送サービスとかやってますが、初めはRFCを読んで正確にlocal-partに使える文字をチェックした方がよいかな、と思っていたのですが。
    各携帯キャリアがRFCに従わないアドレスを許容しており、またそういったアドレスを利用するユーザが非常に多い現状を踏まえて、

     ・転送先アドレスの設定では使用可能文字のチェックだけして素通し
     ・新たに取得する転送アドレスのlocal-partでは厳密チェックを行う

    といった対応をしています。

    しかし幸い?メジャーなMTAではRFCに厳密に従わないメールアドレスでも致命的な問題(使用できない文字を使う等)がなければ素通しで普通に送受信可能なようなのです。
    何年か前に、postfix,qmail,sendmail,exim 辺りでRFC軽視アドレスの送受信テストをやってみましたが、どれも問題なく送受信できた覚えがあります。(間にメールスキャナとかない前提で)
    また当然ですが、RFCに従わない各キャリア同士も問題なく送受信ができてます。

    このようなアドレスを使っている人はとりあえず今使えてれば問題とは思わないんでしょうね。
    これはもう戻せない流れになってしまっている気がします。
    • by stssk (27523) on 2006年06月01日 22時24分 (#951942) ホームページ 日記
      RFCは過去の経緯でいろいろ制限をしている様ですが、メールアドレスのローカル部分(@の左側)は、RFCでも書いてある通り、ドメインで指定したホストが解釈するだけなので、制限を付ける必然性はないし、長い目で見れば制限解除の方向に流れていくのではないでしょうか。MIMEや国際化ドメイン名みたいに、そのうちにローカル部分に日本語を使う仕様も作られるんじゃないかな。
      親コメント
      • by kawaz (15398) on 2006年06月01日 23時53分 (#951998) ホームページ
        >MIMEや国際化ドメイン名みたいに、そのうちにローカル部分に日本語を使う仕様も作られるんじゃないかな。

        ちなみに現行のRFC(822ではなく2822)でもクオート処理をすればlocal-partにどんな文字でも使えることにはなっています。
        (参考:RFC2822 [ietf.org] の local-part にある quoted-string)

        ただ、メールアドレスのlocal-partのクオート処理に対応している、MTA 及び MUA が恐らくとても少ない為、忘れ去られている気がします。
        僕も最近調べるまでそんなものが使えるとは思ってもみませんでした。
        多分知ってる人の方が少ないと思います。

        RFCが全てみたいに、ただ準拠して欲しいとか言っている人が居ますが、恐らくquoted-stringに対応した方が余程深刻な障害を招くんじゃないかと思います。
        それを思うと、今流行の記号メアドなんて現実にはシステム的に大した支障が出ない分可愛いものです。
        親コメント
        • RFC2822のquoted-stringの定義は8ビット文字を含まない様に見えるので、SJISやEUCやユニコードでの日本語の記述は無理そう。RFCの定義上はエスケープコードが使えるので、ISO形式で日本語を書くのはできそうですね。といっても、実際に制御文字を含むアドレスを使うのは無理でしょうから、MIMEの様な相互運用性を確保した文字の拡張を定義しないといけないと思います。

          quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]
          qcontent = qtext / quoted-pair
          qtext = NO-WS-CTL / %d33 / %d35-91 / %d93-126
          NO-WS-CTL = %d1-8 / %d11 / %d12 / %d14-31 / %d127
          quoted-pair = ("\" text)
          text = %d1-9 / %d11 / %d12 / %d14-127
          親コメント
      • > MIMEや国際化ドメイン名みたいに、そのうちにローカル部分に日本語を使う仕様も作られるんじゃないかな。

        その辺の拡張は既にEmail Address Internationalization Working Group [ietf.org]あたりで議論されてます。
        # 本当に普及するかは謎ですが
        --
        だが、いいこともあるぞ、外の天気は上々なんだ
        親コメント
    • by Anonymous Coward
      無理が通れば道理引っ込むな事態が許容されていくようになるを見るのは辛いモンがありますねぇ。

      まぁ今回の件やDoCoMoの件にしても、国内で収まるレベルの事なら、外国の識者達から「企業レベルで何厚顔無恥な事やってんだ」と国内のキャリアが馬鹿にされる程度で済むとは思いますが。

      ところで外国(特に欧米)の有名所で、こういったRFC無視な方針を取ってる所ってあるんでしょうか?
      #あっちでそんな事やってたら、それこそ黙っちゃいない団体が多数だとは思いますが
      • Re:こうして (スコア:3, 興味深い)

        by kawaz (15398) on 2006年06月01日 19時42分 (#951799) ホームページ
        >ところで外国(特に欧米)の有名所で、こういったRFC無視な方針を取ってる所ってあるんでしょうか?

        上でコメントされてますが Google の Gmail なんかも従ってないようですね。
        (まぁ、Gmailは永遠のβでしょうからどうとでも言い訳はできるんでしょうけど)
        きっと探せば他にも沢山、数え切れないくらいあるでしょう。

        こういったところから、だんだんRFC軽視の流れが広がっていくんでしょうね。

        #いっそ現状に即した、もちっと緩くて問題が出ないくらいのRFCを作ってくれたほうが幸せだと思う今日この頃
        親コメント
        • Re:こうして (スコア:2, すばらしい洞察)

          by tuneo (2938) on 2006年06月01日 20時04分 (#951826) ホームページ 日記
          > こういったところから、だんだんRFC軽視の流れが広がっていくんでしょうね。
          >
          > #いっそ現状に即した、もちっと緩くて問題が出ないくらいのRFCを作ってくれたほうが幸せだと思う今日この頃
          「現状に即した、もちっと緩くて問題が出ないくらいのRFC」を作ったところで、RFCを軽視する連中が軽視を止めるかどうか疑問ですけどね。

          その手の無法者共が「ルールの方が現実に合わせてくれたんだから、これからはキチンとルールを守っていこう!」なんて考えてくれるんでしょうか?
          親コメント
          • by Anonymous Coward
            ユーザのニーズに即した現実的なルールなら守ろうと考えてはもらえるんじゃないでしょうか?
            現行のRFCが守られないのはニーズに合っていないからというのが大きいと思います。
            例えばXMLの世界では実態参照やCDATAなど必要に足る基準が揃っているおかげで今の広がりがあるんじゃないかと思います。
      • Re:こうして (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2006年06月01日 21時39分 (#951904)
        逆にRFCにちゃんと準拠しているMTAを教えてもらえませんか?
        私の知る限りでは、少なくともsendmail,qmail,postfixはRFCを一部無視した仕様になっています。
        親コメント
    • そもそもメールユーザ、特に携帯電話のユーザがRFCなんて
      知らないと思いますし、それを知っていることを期待するのは
      無理でしょう。
      そういう場合は、システム側で対応をとるのが、まあ現実的な
      選択になるのではないでしょうか。
      まあ、キャリアにとっては、外ネットワークとやり取りするのは
      いわばおまけで、自網で問題がなければそれでいいや、って
      思っているのかもしれません。
      まあ、そもそも携帯電話でのInternetなんて、なんちゃって
      Internetですからね。

      いづれにしても、キャリアが無知なのか、ユーザ主体でサービスを
      考えた結果なのかそのへんの事情はよくわかりませんが、RFC、
      RFCって言う人ほど、なぜRFCでそのように規定されているか、
      本質的な部分で考えを深めようとしない人も多いような気がします。
      (だから「原理主義者」なんて言われるのでしょう)

      • by ikuuya (14857) on 2006年06月01日 19時45分 (#951802) 日記
        >まあ、キャリアにとっては、外ネットワークとやり取りするのは
        >いわばおまけで、自網で問題がなければそれでいいや、って
        >思っているのかもしれません。
        >まあ、そもそも携帯電話でのInternetなんて、なんちゃって
        >Internetですからね。

        (メール本文で)絵文字やら半角カナが使えるのを知ったときから
        「あ、これ(携帯のemail)はインターネットの仕組みを自分たちが使いたいように拡張しちゃったんだな」
        と思ってました。
        今回もその延長線上なんでしょう。元コメントの「自網で問題なければ〜」に集約されると思います。

        そのうちメールアドレスにも絵文字が使えるようになったり、日本語ドメインへの対応も無茶苦茶になったりとか。 …こわいこわい。
        親コメント
        • や、半角仮名は使えるでしょう。ふつーに。

          iso-2022-jpを宣言してたらダメだけど。
        • >(メール本文で)絵文字やら半角カナが使えるのを知ったときから
          >「あ、これ(携帯のemail)はインターネットの仕組みを自分たちが使いたいように拡張しちゃったんだな」
          >と思ってました。

          他の方のコメントにもありますが、半角カナはISO-2022-JPでなければOK、
          絵文字については外字(DoCoMo/auはShiftJISコードそのまま、VodafoneはISO-2022-JPのエスケープシーケンスで実現)なので、いずれもインターネットの仕組みを尊重しているように感じていますがどうなんでしょうか。
          • by ikuuya (14857) on 2006年06月02日 16時33分 (#952423) 日記
            手元にあるメールのヘッダを見てみました。

            某ezweb.ne.jpから(4/27)のメールヘッダより
            >Content-Type: text/plain; charset="iso-2022-jp"
            >Content-Transfer-Encoding: 7bit

            某docomo.ne.jpから(4/17)のメールヘッダより
            >Content-Type: text/plain; charset="iso-2022-jp"
            >Content-Transfer-Encoding: 7bit

            なので、8ビット目が立っているShiftJISは危険(というかアウト)だと思います。
            絵文字については、受信するためにこちらも外字を用意して対応しないといけない、というのがねぇ、と思っているだけです。

            #SMTPは7ビット/1文字 (残り1ビットはパリティビット)、なんて話はもう過去の遺物ですか?
            親コメント
      • Re:水は低きに流れる (スコア:2, すばらしい洞察)

        by tomotan (20625) on 2006年06月01日 20時03分 (#951825)
        基本的に、こうした仕様を決めているのはエンジニアでなくて携帯会社の中の文系の偉い人たちだと思います・・・。
        親コメント
        • Re:水は低きに流れる (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年06月01日 20時36分 (#951851)
          基本的なのか?
          親コメント
        • by Anonymous Coward on 2006年06月02日 11時52分 (#952198)
          # 文系の人かどうかはともかく

          中の人から漏れ聞いた話だと、社内の力関係は明らかに
          i-modeビジネス系の部署>>>>>>>>移動機開発のエンジニア系部署
          らしいですね。
          えらい人の重視する方向もそんな感じらしい。
          良い悪いは一概には言えないとは思いますが……

          # 余談ですが、ドコモにしてもこのlocal-part仕様は
          # (少なくともエンジニアの間では)負の遺産ということになっているらしいです(苦笑)
          # ビジネス系部署が問題視してるかどうかはさておき、とのこと。
          親コメント
          • >えらい人の重視する方向もそんな感じらしい。
            >良い悪いは一概には言えないとは思いますが……

            単純に、お金稼ぐ人重視(成果主義としても評価しやすい)、
            開発周りはコストなので低く抑える、という図式のまんまなだけじゃないかと。
        • どうして文系だと思ったの?
        • 文系/理系という分類になんの疑問も感じないのは(旧)文部省に洗脳された人?
          「獣医学部でも農業土木でも、理系出身のトップなら技術ガイドからは逸脱しないんだぁー」

          #文系を非難する理系=自分の専門以外を軽視する人
          #という印象を与えるから理系を名乗って欲しくない。
          • 文系理系の2種類のみの分類に意味がないことには同意だが、
            大卒レベルでは文系の連中を「文系」でひとくくりにしても、まったく問題ない。
        • 偉い人が仕様を決めてくれるなら楽で良いですよ・・・。
          こんな細かいところまで見てくれるわけ無いでしょ。
    •  メジャーじゃないかもしれませんけど、IIS5.0のSMTPサーバは".."という記述をエラーで弾きます。

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

処理中...