アカウント名:
パスワード:
原理主義的には「間違っているのは使っちゃダメ」なのかも知れないが、有る物は有るんだから仕方ない。適当にユーザーが慣れてから、新規メールアドレスに制限を入れて…って10年じゃ変更は出来ないと見た。
過去に何回も話題に出ているけど、RFC上、＠の前をダブルクォーテーションで囲えば連続ドットでも送れるんだから、メールアドレスの変更をする必要はない。http://srad.jp/it/comments.pl?sid=421870&cid=1434447 [srad.jp]
これぐらいのことは、携帯キャリアが責任を持って変換すればいいんじゃないの？
>悪いのはdomcomo側>それでdomcomoのためにそうなのか。
GMailや他のメールクライアントを落として来れば使えるってのだから、htcのプリインストールしているあのメールクライアントがクオートしていないとかじゃなかろうか。
foo..bar@example.com と "foo..bar"@example.com を同一視しないワナもあるかも。
"foo..bar"@example.comを扱えないシステムも結構あるんだよなぁ。それはそれで問題だけど。
RFC違反のメアドを使ってるユーザーがメールを受信できないとか送信できないだけなら放置すればいいけど、他に迷惑かかるからやめて欲しいわ。
メールアドレスを登録するサービスで、RFC違反のアドレスが登録できずエラーになったら、文句言われるのはサービス側なんだぜ?こういうアドレス使ってる連中って理由を説明しても逆切れするだけだし。(それがあるからキャリアも今までの非を認めたがらないんでしょうけど)登録フォームのチェック要件を緩和するだけで済めばいいが、システムそのものを変えないといけない場合は誰がそのコスト持ってくれるんだ?
対応を行うのは携帯電話会社ではなく、すべての MUA の作成元ですね。あと、API 提供元。
携帯電話会社の gateway で変換ではそこまでたどり着くまでに MTA を経由することがあるので対応としてはダメです。
RFC5321 [ietf.org] では Quoted-string 形式は認められているわけで、Dot-string では許可されていない連続する "." や "( ) [ ] : ; @ ," が含まれた場合、自動的に Quoted-string に変換すればいいと思いますけど。
さすがにその変換をやらなければダメとは RFC532 には書かれてませんけどね。
変換も何もクライアントが弾いていたらそもそも受け取れないんでは？特定のクライアントで起こるってアナウンスなんだから、キャリア側は対応されていると思われます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
今有る物は使える様にするしかないのじゃ？ (スコア:0)
原理主義的には「間違っているのは使っちゃダメ」なのかも知れないが、有る物は有るんだから仕方ない。
適当にユーザーが慣れてから、新規メールアドレスに制限を入れて…って10年じゃ変更は出来ないと見た。
Re:ダブルクォーテーション (スコア:1, 参考になる)
過去に何回も話題に出ているけど、RFC上、＠の前をダブルクォーテーションで囲えば連続ドットでも送れるんだから、メールアドレスの変更をする必要はない。
http://srad.jp/it/comments.pl?sid=421870&cid=1434447 [srad.jp]
これぐらいのことは、携帯キャリアが責任を持って変換すればいいんじゃないの？
Re:ダブルクォーテーション (スコア:1, 興味深い)
Re: (スコア:0)
>悪いのはdomcomo側
>それでdomcomoのために
そうなのか。
Re: (スコア:0)
GMailや他のメールクライアントを落として来れば使えるってのだから、htcのプリインストールしているあのメールクライアントがクオートしていないとかじゃなかろうか。
Re: (スコア:0)
foo..bar@example.com と "foo..bar"@example.com を同一視しないワナもあるかも。
Re: (スコア:0)
"foo..bar"@example.comを扱えないシステムも結構あるんだよなぁ。
それはそれで問題だけど。
RFC違反のメアドを使ってるユーザーがメールを受信できないとか送信できないだけなら放置すればいいけど、
他に迷惑かかるからやめて欲しいわ。
メールアドレスを登録するサービスで、RFC違反のアドレスが登録できずエラーになったら、
文句言われるのはサービス側なんだぜ?
こういうアドレス使ってる連中って理由を説明しても逆切れするだけだし。
(それがあるからキャリアも今までの非を認めたがらないんでしょうけど)
登録フォームのチェック要件を緩和するだけで済めばいいが、システムそのものを変えないといけない場合は誰がそのコスト持ってくれるんだ?
Re:ダブルクォーテーション (スコア:1)
対応を行うのは携帯電話会社ではなく、すべての MUA の作成元ですね。あと、API 提供元。
携帯電話会社の gateway で変換ではそこまでたどり着くまでに MTA を経由することがあるので対応としてはダメです。
RFC5321 [ietf.org] では Quoted-string 形式は認められているわけで、Dot-string では許可されていない連続する "." や "( ) [ ] : ; @ ," が含まれた場合、自動的に Quoted-string に変換すればいいと思いますけど。
さすがにその変換をやらなければダメとは RFC532 には書かれてませんけどね。
Re: (スコア:0)
変換も何もクライアントが弾いていたらそもそも受け取れないんでは？
特定のクライアントで起こるってアナウンスなんだから、キャリア側は対応されていると思われます。