auのEメールアドレスが相互接続性を保障できないルールに変更? 183
今更改悪しなくても… 部門より
kazu070曰く、"インプレス ケータイWatchの au、Eメールアドレスの設定文字数を最大30文字に拡張 によると、
メールアドレスの20文字から30文字への文字数の拡張にあわせて、
「_」(アンダースコア/アンダーバー)の利用や、「.」(ピリオド/ドット)の連続使用、@直前での利用も可能となる。
という仕様が発表されている。効果としては、迷惑メールを受信しにくくなるという後ろ向きなメリットが挙げられる。
しかしながら、RFCを読まなかった携帯キャリアの罪にも記述があるとおり、特定のメールシステムにおいては "." に関する扱いに制限がある。また "." の二重使用や @ 直前の "." については、メールアドレスに使える文字やRFC によるメールアドレスの local-part におけるピリオドの取り扱いについての考察が参考になる。
auのEメールアドレス変更方法では、
「.(ピリオド/ドット)」をアドレス内で連続使用したり、アドレスの最後に設定すると、一部のプロバイダーとメールを送受信できない場合があります。
との記述があるが、この範囲では十分な警告とは言えない。タレコミ人はこうしたメールアドレスの場合、メールアドレス取得・変更時に、「このメールアドレスでは外部に対してメール送受信できない可能性がある」亊を警告すべきと考える。
RFCの位置づけも、絶対的に崇め奉る技術者がいたり、そもそも読んでない(あることを知らない)なんて技術者がいたりとまちまちだが、相互接続に影響する部分は準拠しておいてほしいと思う。
携帯各社のメールアドレス仕様でユーザより「PCのメールからメール送受信ができない!」とクレームを受けたことのあるタレコミ人としては、ユーザに対しきっちり警告も行わないままで、相互接続に問題がある形式を採用するのは迷惑なだけ、と思うのだが、みなさんはいかが? そもそも、メールの相互接続は保障していない!って?"
なお同様のことは ドコモのメールアドレス でも以前からある。ドコモのページでも au と同様の注意書きがあり、以前にはRFCに準拠していますとの記載もあったようだが現在は削除されている。 Vodafone のメールアドレス では同様の事は設定不可能で、WILLCOMではそもそも「.」をローカルパートに使うことが出来ない仕様のようだ。
こういうサービスには速やかに淘汰されて欲しい (スコア:5, すばらしい洞察)
Re:こういうサービスには速やかに淘汰されて欲しい (スコア:4, おもしろおかしい)
Re:こういうサービスには速やかに淘汰されて欲しい (スコア:2, おもしろおかしい)
むしろRFCが淘汰されてしまうのですかね。 (スコア:3, 興味深い)
水は低きに流れる (スコア:5, 参考になる)
各携帯キャリアがRFCに従わないアドレスを許容しており、またそういったアドレスを利用するユーザが非常に多い現状を踏まえて、
・転送先アドレスの設定では使用可能文字のチェックだけして素通し
・新たに取得する転送アドレスのlocal-partでは厳密チェックを行う
といった対応をしています。
しかし幸い?メジャーなMTAではRFCに厳密に従わないメールアドレスでも致命的な問題(使用できない文字を使う等)がなければ素通しで普通に送受信可能なようなのです。
何年か前に、postfix,qmail,sendmail,exim 辺りでRFC軽視アドレスの送受信テストをやってみましたが、どれも問題なく送受信できた覚えがあります。(間にメールスキャナとかない前提で)
また当然ですが、RFCに従わない各キャリア同士も問題なく送受信ができてます。
このようなアドレスを使っている人はとりあえず今使えてれば問題とは思わないんでしょうね。
これはもう戻せない流れになってしまっている気がします。
Re:水は低きに流れる (スコア:5, 参考になる)
Re:水は低きに流れる (スコア:4, 参考になる)
ちなみに現行のRFC(822ではなく2822)でもクオート処理をすればlocal-partにどんな文字でも使えることにはなっています。
(参考:RFC2822 [ietf.org] の local-part にある quoted-string)
ただ、メールアドレスのlocal-partのクオート処理に対応している、MTA 及び MUA が恐らくとても少ない為、忘れ去られている気がします。
僕も最近調べるまでそんなものが使えるとは思ってもみませんでした。
多分知ってる人の方が少ないと思います。
RFCが全てみたいに、ただ準拠して欲しいとか言っている人が居ますが、恐らくquoted-stringに対応した方が余程深刻な障害を招くんじゃないかと思います。
それを思うと、今流行の記号メアドなんて現実にはシステム的に大した支障が出ない分可愛いものです。
Re:こうして (スコア:3, 興味深い)
上でコメントされてますが Google の Gmail なんかも従ってないようですね。
(まぁ、Gmailは永遠のβでしょうからどうとでも言い訳はできるんでしょうけど)
きっと探せば他にも沢山、数え切れないくらいあるでしょう。
こういったところから、だんだんRFC軽視の流れが広がっていくんでしょうね。
#いっそ現状に即した、もちっと緩くて問題が出ないくらいのRFCを作ってくれたほうが幸せだと思う今日この頃
Re:こうして (スコア:2, すばらしい洞察)
>
> #いっそ現状に即した、もちっと緩くて問題が出ないくらいのRFCを作ってくれたほうが幸せだと思う今日この頃
「現状に即した、もちっと緩くて問題が出ないくらいのRFC」を作ったところで、RFCを軽視する連中が軽視を止めるかどうか疑問ですけどね。
その手の無法者共が「ルールの方が現実に合わせてくれたんだから、これからはキチンとルールを守っていこう!」なんて考えてくれるんでしょうか?
Re:水は低きに流れる (スコア:2)
>いわばおまけで、自網で問題がなければそれでいいや、って
>思っているのかもしれません。
>まあ、そもそも携帯電話でのInternetなんて、なんちゃって
>Internetですからね。
(メール本文で)絵文字やら半角カナが使えるのを知ったときから
「あ、これ(携帯のemail)はインターネットの仕組みを自分たちが使いたいように拡張しちゃったんだな」
と思ってました。
今回もその延長線上なんでしょう。元コメントの「自網で問題なければ〜」に集約されると思います。
そのうちメールアドレスにも絵文字が使えるようになったり、日本語ドメインへの対応も無茶苦茶になったりとか。 …こわいこわい。
Re:水は低きに流れる (スコア:2, すばらしい洞察)
送れないのは送信者の責任、だった (スコア:5, すばらしい洞察)
↓
しかし受信側からしたら(自分が制御できない外部から)送られてきたメールはキチンと自分のユーザには届けてあげないといけない。
ユーザ様の大切なメールが自分のサーバの設定が厳しいせいで紛失してしまうなんてことを考えたら受信側は寛容な設定にせざるを得ない、と考える管理者が出てくる。
ましてやそんなアドレスで送ってくる相手が既に沢山いようものなら無視できない…。
↓
一度そのアドレスが通るとなったらユーザは使ってもよいアドレスなんだと理解。
↓
今度は自分も新たにRFC軽視アドレスを使いたいとユーザが言い出す。
みんな使ってるのになんでうちではできないんだ、と。
↓
ユーザ様の意見だし、周りを見回すとなんだか氾濫してて実際に問題はあんまり起こっていなさそうだからうちでも少し緩くするか…。
以下無限ループで今に至る。
メールが重要なインフラと化してしまった今では元には戻れないでしょうね。
参考 (スコア:2, 参考になる)
読んでもらえないどころか、愉快な返信をもらえるかもしれませんね。
危険なアドレスの実例 (スコア:5, 興味深い)
とあるメーリングリストのオーナーから「メールアドレスの一括登録をしようとすると途中でエラーになる」との問い合わせ。
結論から先に言えば、「@の前にドット2つ」などまさに今回タレコミにあるようなドコモユーザーのアドレスが原因でした。
調査の過程で数千のアドレスを見ましたが、いわゆる顔文字アドレス(例えば「(-_-;)@docomo」みたいな)や先にあげたダブルドットなど、システム屋としてはクラクラするようなアドレスが大量にありました。
タレコミにあるような警告を挟んだ所で無視する人は無視するでしょうし、今回の措置は全く改悪だとしか思えません……
ビジネスではとても困ることに (スコア:5, 興味深い)
ネット通販やってると携帯メールからも注文が来ます。でもこんなことされると最初の「受注しました」すら返せないことになります。で、店に対して「シカトかよ!」と逆ギレされ(この場合は「逆」とも言えませんが)、下手すると「最低の店」などと風評を流されることにもなりかねません。
auなど大会社はそれでもいいでしょうよ。でも弱小のうちらは文字どおり死活問題になります。
Re:ビジネスではとても困ることに (スコア:4, 興味深い)
うちで利用している某ウィルス対策ゲートウェイがRFCにうるさく、docomoの問題メールアドレスに送信できないんだが、仕様改善を要求してもRFCを楯に「docomoが悪い」と言われ、対応してもらえない。
おかげで、クレームメールに返信できなくて、怒鳴り込まれたことがある。
# ただ、RFCにうるさいくせにクオートに対応してないのは、どうかと思うぞ。>マカフィー
意外と (スコア:4, 興味深い)
「"."はメールアドレスに使えます」というのは理解しても、
「けれども先頭や末尾に使ったり、連続で使うのはダメです」っていうのには「何でよ!?」となる(というかそのルールを見ていない)人というのは結構いるような気がします。
# 一般的なユーザーでRFCを読んで理解してる人っていうのも少ないでしょうし
……と考えると、Willcom方式(ピリオド不可)にしてしまうのが正しいのかも(苦笑)
Re:意外と (スコア:5, 興味深い)
中の人から漏れ聞こえてきた話によるとどうやらそのようですね。
「標準に準拠しなければならないことは重々理解しているが、ユーザの大多数が『標準?なにそれ?俺(あたし)のメアドが使えないなんて乗り換える気になんね〜よ(なんな〜い)』っていう状態であるため、標準から逸脱してでも最大のシェアを持つドコモとの互換性を保つことが至上命題」のようです。
これが良い方向性だとは全く思いませんが、後ろからはソフトバンクが前にはドコモが居る状況下で商売(利益)を優先させたという流れでしょう。
MNP対策だと思いますよ。 (スコア:4, すばらしい洞察)
お客さんに対するサービスでしょう。
ドコモのアドレスを変更せずに受け入れられるように
ドコモのルールにあわせるようにしたのでは。
ドコモでそれを使ってる人は不便ないということでしょうし。
Re:MNP対策だと思いますよ。 (スコア:2, 参考になる)
>example@docomo.ne.jp で au に届くってこと?
いや、さすがにそれはないでしょ。
多分、example@docomo.ne.jpのexampleってのをそのまま
au(ezweb)に持っていけるようにしたってことでしょ。
これだとユーザは
example@docomo.ne.jp → example@ezweb.ne.jpと
ドメインがかわっても、ユーザ名がそのまま使えるのであれば、
ユーザの心理的な敷居が下がるんじゃないかってことじゃないですかね。
まあ、もちろん既にezweb側でそのユーザ名が使われてた場合は
どうにもならないですがね。
>(留守電にたまったメッセージの移行とかありうるんだろうか…)
留守電なんか、解約する前にすべて聞いておけば問題ないでしょうし、
問題になりそうなのは電話帳とメールアドレスでしょうねぇ。
個人的には契約期間を引き継いでくれるとうれしいが絶対無理だな(笑)
いや、PCの「インターネット」の方が括弧付きなんだし (スコア:4, 興味深い)
携帯会社にしてみればPCを含む一般の「インターネット」より携帯キャリアの内部で閉じたネットワークにとって利便性が(アドレスに顔文字入れたい!とか)の重要度は高いんでしょう
せいぜい他社携帯との相互接続で問題なければOK
「インターネット接続PC数をはるかに超える5000万以上の加入者が毎日のようにメールを送受信し、サイトを使用する。i-modeこそが本当のインターネットだ」
と語った某キャリア幹部がいました
そんなんもんです
そこまで必要なの? (スコア:3, すばらしい洞察)
もっとも、迷惑メール送信側も何か考えてきそうな気がしますがorz
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA
Re:そこまで必要なの? (スコア:5, 興味深い)
-.-somenone^_^@dokoka.ne.jp
のような無茶苦茶なアドレスの人は何人かいますし。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:そこまで必要なの? (スコア:1, 参考になる)
-や.や^が使えないために「顔文字が出来ないーっ」って嘆いていたのが印象的でした。
Re:そこまで必要なの? (スコア:3, すばらしい洞察)
自然言語処理や機械学習でSPAMを弾くことくらいできるだろうに。
「迷惑メール箱」をつくって、「これは迷惑メールではない」「迷惑メールとして処理し報告する」といったユーザ操作ができない携帯電話では仕方がない?
Re:そこまで必要なの? (スコア:2, 参考になる)
サーバーからの通知を受けて自動で端末から取りに行くので、この時に課金されます。
受信も送信もシステム的には端末からサーバーへの発呼なのですよ。なので、送信にも受信にもパケット代がかかるという理屈が成り立つ(本当か?)んです。
Re:そこまで必要なの? (スコア:2, すばらしい洞察)
> んでしょうね。
インターネットに接続しているからでしょう。
> 送る側が金を払えばいいと思うんですよ、電話と同じで。
携帯電話網で完結しているのなら可能でしょう。
> たぶん受信側の方が(TOやCCにずらっとならべたりしたら)
> 数が多くてパケット代が稼げるからなんでしょうね.....
と言うより、インターネットから届いたメールでは送信者から徴収する事が不可能だからでしょう。
送信者を特定できませんし、特定できても徴収手段が有りません。
Re:そこまで必要なの? (スコア:1)
ローカルパートにアルファベット14文字、数字2文字、ドット1文字、ハイフン1文字使用
ですが、今までに迷惑メールが届いたことはありませんよ。
1を聞いて0を知れ!
Re:そこまで必要なの? (スコア:1)
Re:そこまで必要なの? (スコア:2, 参考になる)
Re:そこまで必要なの? (スコア:1, 参考になる)
メールアドレスをどっかに書いた記憶はない(書いたかもしれないし書いてないかもしれない)んだけども、「@の左側」は /.-J の ID とかにしてそこら中に書いているので、適当に組み合わせて送りつければ届く。
で、最近は適当に生成したアドレスに送りつけるなんて spammer もいるらしいので、そういうのにあたったのかも。
これ(このメールアドレス)はもうダメかな。
--
一応 AC で
URLフィルターでも駄目ですか? (スコア:4, 参考になる)
「特定URLを含むメールのみ受け取らない」にすると、
ほとんど迷惑メールが届かなくなりました。
さらに、「URLを含むメールを全て受け取らない」にすると全く来なくなりました。
必要なメールもすべて止めてしまうので、注意が必要ですが。
メアドは、名前そのままで、何もひねってません。
PCの方のメアドと一緒にしたかったんですが、昔のJ-PHONEは、
ローカルパートに"."が使えなかったので、一緒に出来ませんでした。
Re:URLフィルターでも駄目ですか? (スコア:2, 参考になる)
いちいち自分で設定するような機能ではspamに対応しきれないのでは?
#個別にホワイトリスト機能があればもっといいのだが。
Re:そこまで必要なの? (スコア:2, 参考になる)
一方、ケータイのアドレスは短いものにしていますが、転送専用で知人にも知らせていないせいかspamは届きません。
そんなわけで、ランダム生成は意外とマイナーではないかと予想しています。
Re:そこまで必要なの? (スコア:2, 参考になる)
知人のPCで、不本意にもワームが活動してしまうことは、よくあることです。
"."に制限がある理由 (スコア:3, 興味深い)
もし、その仕様に理由があったのなら、それを破ってしまえば、どこかで不具合が起きませんか?
逆に、特に問題が無いのなら、それはそれでいいような。
Re:"."に制限がある理由 (スコア:5, 参考になる)
例えば . はカレントディレクトリだし、.. は親ディレクトリ、.で始まるファイルは隠しファイルだし。
例えばメールサーバの実装がサーバ上のメールボックスをお気楽にエスケープもせず、/保存ディレクトリ/ユーザID なファイルに保存するようになっていたら、..@example.jp とかいうメールアドレスはどうにもできないでしょう。
これは実際によくある実装だし。
昔は、今みたいにユーザ本位じゃなく開発者本位だったから、
利便性よりも実装の容易さとルール守ればいいじゃんっていう都合から出来たんでしょうね。
Re:"."に制限がある理由 (スコア:3, 興味深い)
../../../../../bin/rm@example.com のようなメールアドレスが sendmail で動いているメールサーバーに動いた場合、変な動作をするかもしれません。
Re:"."に制限がある理由 (スコア:3, 参考になる)
postfix のFAQ [kobitosan.net]
「変な動作」というより「意図した動作」だったんでしょうけど。
Re:"."に制限がある理由 (スコア:2, 参考になる)
RFC821 の定義から察するに、"." はデリミタのような意味で使われることを
意図していたのではないかと思われます。
区切り文字だから連続するのはおかしいし、区切り文字で始まったり終わったりしない、
ただそれだけのことでしょう。
>sendmail で動いているメールサーバーに動いた場合、
あたかも sendmail にそういう問題があったかのような書かれ方ですが、
そのような事実はありません。
いくら sendmail が古くからあるといっても、それでも RFC821 の方が1年早いです。
Re:"."に制限がある理由 (スコア:3, すばらしい洞察)
と思うのでRFCを修正する方向でどうでしょうか?
RFCを軽視?無視?して進んでいるのは問題ですが、制限を解除する方向は間違っていないと思います。
制限をなるべく無くす方向が技術者として目指すべき方向だと思います。
今あるルールを破っていいって話じゃないですけどね。
携帯キャリアが連携してRFC改訂に持っていけばいいのにな。
全く日本的な話 (スコア:3, すばらしい洞察)
なんて外国の技術者に言ったら、何て顔をするだろうな。
# "アスキーアート"は本来違うものを指すということは承知の上です
まぐろたべたい
RFC準拠でも困るメールアドレス (スコア:3, 参考になる)
-xxxxxx.09000000000-@ezweb.ne.jp
という形式なのですが(RFC準拠)、
このようなメールアドレスにメールが送れないMTAがあるようです。
たまに困ります。
迷惑メールがこないのは嬉しいですが。
Re:RFC準拠でも困るメールアドレス (スコア:2, 参考になる)
Postfix ですね。
コマンドライン経由で渡した時にコマンドラインオプションと解釈されないようにという配慮らしいです。
そんなことしないので
allow_min_user=yes
と書いて受け付けるようにしてますが。
Re:RFC準拠でも困るメールアドレス (スコア:2, 参考になる)
そのまま "sendmail -fuga@example.com" とやってしまうと、
これは「送信者は uga@example.com である」という意味になってしまいます。
こういう事故を防ぐため、postfix はデフォルトでは先頭がハイフンのアドレスを
エラーにします。けっして「送れない」わけではありません。
設定を変更する (allow_min_user = yes) ことで送れるようになります。
Gmailは? (スコア:2, 参考になる)
@の直前につけても、連続して複数つけて見てもちゃんと届くよ。
RFC に準拠することは携帯キャリアだけの責任ではない (スコア:2)
RFC を読んでその範囲から逸脱しないようにする責任が、キャリアの手を離れて
一般ユーザに移ったということです。
なんだか嬉しいなあー。
番号ポータビリティを控えた今 (スコア:2, 参考になる)
au:「(技術オタ的解説)」
客:「ハァ?」
なんてわけにはいかないのでしょうね。
何時だって「使えりゃいーじゃん」が消費者の圧倒的多数なわけで
Re:RFCってそんなにエライのか? (スコア:5, 参考になる)
ISO-IETF間でRFCのStandards Trackにあるものは
国際標準扱いにしてよい(PAS:Publicly Available Specificationといいます)ことになっているはずです。
ISOのページ [iso.org]を見ても、
ISO専門委員会とIETFが協力関係にあることがわかります。
「そこまでクソ真面目に『これに従わないとイカンよ,キミ!!』みたいに言い切れる世界じゃない」という認識は10年以上古いと思いますよ。
RFC 822/2822みたいなStandards TrackなRFCは国際標準扱いなんです。
偉いんです。
ただ、"as is"で"rough consensus"がIETFの基本ですので、
ドコーモな仕様が"de facto"で、互換性があるんだったらそれでいい、
という考え方もできるんじゃないですか。
それを国際標準にするために仕様を書けばいいんです。
日本国内の閉じた仕様にしている限り、
「インターネット用メールと互換性がある」とはいっちゃいけないというだけ。
/K
Re:? は? (スコア:2, 参考になる)
前からじゃないです。「前は」です。
今はダメです。
# 昔、言ってみたことがある [srad.jp]。