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

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

  • by tiatia (22244) on 2006年06月01日 19時18分 (#951781) 日記
    RFCで、"."の使用に制限が付けられているって事は、何か理由があるんでしょうか?
    もし、その仕様に理由があったのなら、それを破ってしまえば、どこかで不具合が起きませんか?
    逆に、特に問題が無いのなら、それはそれでいいような。

    • by kawaz (15398) on 2006年06月01日 19時52分 (#951815) ホームページ
      ピリオドに制限がある理由は主に Unix 上でのMTAの実装の問題にあったんでしょうね、きっと。
      例えば . はカレントディレクトリだし、.. は親ディレクトリ、.で始まるファイルは隠しファイルだし。

      例えばメールサーバの実装がサーバ上のメールボックスをお気楽にエスケープもせず、/保存ディレクトリ/ユーザID なファイルに保存するようになっていたら、..@example.jp とかいうメールアドレスはどうにもできないでしょう。

      これは実際によくある実装だし。
      昔は、今みたいにユーザ本位じゃなく開発者本位だったから、
      利便性よりも実装の容易さとルール守ればいいじゃんっていう都合から出来たんでしょうね。
      親コメント
    • by targz (14071) on 2006年06月01日 19時38分 (#951796) 日記
      >RFCで、"."の使用に制限が付けられているって事は、何か理由があるんでしょうか?

      ../../../../../bin/rm@example.com のようなメールアドレスが sendmail で動いているメールサーバーに動いた場合、変な動作をするかもしれません。

      親コメント
      • by banana (10420) on 2006年06月02日 2時09分 (#952065)
        "." よりも "/" の方に問題があったみたいですよ。

        postfix のFAQ [kobitosan.net]

        「変な動作」というより「意図した動作」だったんでしょうけど。
        親コメント
      • by yamaya (25867) on 2006年06月02日 1時04分 (#952038)
        >>RFCで、"."の使用に制限が付けられているって事は、何か理由があるんでしょうか?

        RFC821 の定義から察するに、"." はデリミタのような意味で使われることを
        意図していたのではないかと思われます。
        区切り文字だから連続するのはおかしいし、区切り文字で始まったり終わったりしない、
        ただそれだけのことでしょう。

        >sendmail で動いているメールサーバーに動いた場合、

        あたかも sendmail にそういう問題があったかのような書かれ方ですが、
        そのような事実はありません。
        いくら sendmail が古くからあるといっても、それでも RFC821 の方が1年早いです。
        親コメント
        • >あたかも sendmail にそういう問題があったかのような書かれ方ですが、
          >そのような事実はありません。

          もちろん通常ではそんな動作はしないと思います。
          でも、sendmail で発見されたセキュリティホールではそういうのがあったように思っていましたが、思い違いかもしれません (古いセキュリティホール情報はなかなか調べにくい……)。
          ローカルパートとプログラムをごっちゃにしている部分があるらしいので、さもありなんと考えていましたが、勘違いでしたか……。

          >いくら sendmail が古くからあるといっても、それでも RFC821 の方が1年早いです。

          あ、そうでしたか。それは失礼いたしました。sendmail の歴史まで調べてなかったです。
          親コメント
      • それは、sendmailだけに起きる事なんでしょうか?
        また、RFCの仕様に従った結果の「変な動作」なのか、RFCから外れたメールアドレスに対する処理をsendmailが怠っているのか?
        どっちですか?
        親コメント
        • >RFCから外れたメールアドレスに対する処理をsendmailが怠っているのか?

          明らかにsendmail(だけではない)が怠っていたんでしょうね。
          というか寧ろ、RFCの方が開発者の怠りに偏ったものになってしまっているのが問題でしょう。
          性善説で牧歌的な開発が通っていましたからね。
    • Re:"."に制限がある理由 (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2006年06月01日 20時07分 (#951831)
      「コンピュータの制限でユーザに不利益が生じるのは間違っている。」
      と思うのでRFCを修正する方向でどうでしょうか?

      RFCを軽視?無視?して進んでいるのは問題ですが、制限を解除する方向は間違っていないと思います。
      制限をなるべく無くす方向が技術者として目指すべき方向だと思います。

      今あるルールを破っていいって話じゃないですけどね。
      携帯キャリアが連携してRFC改訂に持っていけばいいのにな。
      親コメント
      • Re:"."に制限がある理由 (スコア:1, フレームのもと)

        by gtk (14477) on 2006年06月01日 20時42分 (#951855) 日記
        どうぞ。
        何十年掛かるか分かりませんが。

        # たとえば RFC822 から RFC2822 への転換って10年くらい掛かったんよ。
        親コメント
      • DEL、BS、CR、LFなどの制御文字や"とかも認めると混乱の元だと思うが....
        下手すると穴にもなりかねないし。
        親コメント
        • Re:"."に制限がある理由 (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年06月01日 21時55分 (#951916)
          # なぜ今まで全くquoted-stringの話が出てこないのだ?

          > "とかも認めると
          っquoted-string

          > DEL、BS、CR、LFなどの制御文字や
          RFC2822のobs-形式ではなくRFC822の範囲なら
          これもquoted-stringに含めることができましたが。
          親コメント
          • >これもquoted-stringに含めることができましたが。

            「混乱の元」を否定しているように感じるが、「混乱の元」なんだろ?

            ところで、cgiとかでメールアドレス受け取るときにquoted-stringを認めているの?制御文字も認めているの?
            多くのところって、200バイト超える様な長いドメインすら認めてないのでは?

            http://srad.jp/comments.pl?sid=318448&cid=951831 の「制限をなるべく無くす」の話だよね。
            xxx"xxx@xxx.xx とかはどう考えても「混乱の元」だと思うけど。

            ついでに、quoted-stringなんてRFCから無くして欲しいと俺は思っている。
            親コメント
            • >cgiとかでメールアドレス受け取るときにquoted-stringを認めているの?制御文字も認めているの?
              >多くのところって、200バイト超える様な長いドメインすら認めてないのでは?

              ???
              とりあえず、わかってる振りをして何か単語を並べてみたのですか?
      • 新しいRFCをおこして、世界中のメジャーなMTAがそれに準拠するまでの時間が問題ですね。
        なのでインターネットの標準は変わりにくいんだと思います。
        親コメント
      • 100の立派な言い訳よりも、拙いあなたの案がいい
      • >「コンピュータの制限でユーザに不利益が生じるのは間違っている。」
        >携帯キャリアが連携してRFC改訂に持っていけばいいのにな。

        そりゃそうですが、いままでそういうルールで実装してきて問題なかったものを書き換える手間・コストをルール破りした者が払ってくれるわけじゃないってのが問題なんじゃ。

        そこを全部保証してくれるなら何も文句はないですけどねえ。
    • by Anonymous Coward
      実装都合の理由にもなってないショボイ理由って事?
      もっとマシな理由があるんじゃないのか?

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...