ドコモ、メールアドレスをRFC準拠に 75
タレコミ by Fatalwedge
Fatalwedge 曰く、
以前からアットマーク直前のドットや連続したドットを許容し、実際にトラブルの原因となるなどRFC的によろしくない状態だったドコモのiモードメールアドレスだが、4月以降新規取得（変更）するアドレスについてはこれらを許容しないこととなった。
現在使用中のアドレスについては継続して利用可能との事で、まだ当分の間は「RFC準拠」を謳えないと思うが、過去に困った経験のあるタレコミ子としては今回の改善を素直に歓迎したい。
関連ストーリー：
GMail、ezwebとdocomo宛のみメールアドレス中の連続ドットや@直前ドットを許可
auのEメールアドレスが相互接続性を保障できないルールに変更?
au、メールアドレス仕様変更で自身がハマる
anetから誤配メール……個人情報付き
意味あるんでしょうか (スコア:1)
俺の周りにはまだ電話番号@docomo.ne.jpの人もいるし、
俺自身も、途中で@jp-tから@t.vodafoneになったものの、10年間アカウント変えてないです。
これが多数派か少数派かわかりませんが、
メールアドレスなんて変えるもんじゃないと思ってる人が一定数いて、その中に変なアドレスの人が含まれてたら、
「新規に取れなくしました」だけでは変なアドレスはなくならないし、
なくならないと言うことは、結局メールを使うサービスを提供しているほかのシステムがそれに合わせた仕様にせざるを得ないわけで、
じゃぁもう別に新規に取れなくしてくれなくても変わらんと思うのですが・・・
一瞬にして消滅しなきゃ意味が無いと？ (スコア:2, すばらしい洞察)
病気の根本原因を取り除いて完治させられないならば、
感染拡大防止や対処療法なんて何の意味も無い、と言い切るぐらいに、
> なくならないと言うことは、結局メールを使うサービスを提供している
> ほかのシステムがそれに合わせた仕様にせざるを得ないわけで、
確かにauなんかはdocomoのダメ仕様に合わせてしまいましたが、
広くネット上を見渡せば、合わせてないシステムなんて幾らでもあります。
自前でなくフリーのCMSを使ってる場合なんかは、
自分でそこを書き換えるのはメンドーだと言う判断や、
CMSのアップデート時に再適用するのがメンドーと言う判断もあるでしょう。
また、自分がフリーで公開しているシステムでそこを合わせちゃうと、
日本以外の利用者からツッコミが入る事も在るかもしれませんし、
そもそも、環境によって送信出来ない可能性が低くないアドレスを、
特定システムにおいて許容するかどうかはポリシーの問題。
「アドレスが間違ってるので変更して下さい」
と言う対応が間違っているとは思いません。
それはそれで説明が大変だけど、
今回のdocomoの対応により、説明し易くなったのは確かです。
もう世の中がたいてい合わせちゃってるなら兎も角、
人類の中でE-mailを使ってるヒトの大半は、
合わせてないシステムを利用しているので、
それらのシステムの改修コスト的にも、意味が無いわけはありません。
# 個人的には、auに追随するよう求められるのが最大の「意義」
Re:意味あるんでしょうか (スコア:2)
あー、すいません。
なんか「こんなことするな」って感じになってしまいましたが、
「これだけじゃ不足なので、今後は変なアドレス使ってる人に変更を求めるぐらいしてくれんとダメだ」
という意見です。これは。
Re:意味あるんでしょうか (スコア:2)
「まだdocomo仕様のアドレスの人がいるのでしょう。
なら、システムテストのため、変なアドレスのまま変更できません。」
という、システム開発者が変更せずに、いつまでも残ってしまったり...
Re:意味あるんでしょうか (スコア:1)
いまだに@jp-k.ne.jpでメールを受けることのあるわたしも電話番号@docomo.ne.jpで変えてなかったりします。
電話番号@キャリアドメインなアドレスが設定されなくなってから久しいですが、希望者には（優先的に）設定できるようにしても罰は当たらないような気がします。
#アドレスが変わるので@i.softbankに移行できない。というか巻き取りキャンペーンしつこい
Re: (スコア:0)
しかしいつかはやらねばならないでしょう．
リスクが許容できる割合以下になれば，まだRFC準拠ではない使用者に案内を送ったり変更願いを出したりし始めると思います．
Re: (スコア:0)
問題となるアドレスを、RFC準拠のアドレスに正規化したとして
衝突するようなものは存在するんですかね？
もし、それが無いのならば一律に全部変更して、エイリアスでしがらみを残せば良いのに
記述が足りない (スコア:1)
見えるけど、実際にはそうでないアドレスが残ってるんですよね？
これでは今後ドコモのサイトで仕様を確認したりする技術者が混乱するのではないでしょうか
Re:記述が足りない (スコア:1, すばらしい洞察)
> 混乱するのではないでしょうか
まず、あのページで「RFC準拠」を謳っているわけではない事は御注意。
確かにあのページを参照したヒトは、docomoの携帯電話メールアドレスでは、
「..」の様な書き方は混入していない、と誤解してしまうだろうから、
メールが送信出来なかった場合等に混乱を招くであろう事は同意。
でも、あのページは現状のルールとして利用者に案内されているだけで、
技術者向けに仕様として提示されているワケでは無い、と言う事も踏まえて欲しい。
利用者向けと技術者向けの案内が食い違うのは今までも良くあった事なので、
あのページで「仕様を確認したりする技術者」は居ないと思う。
一方で、今後もし仕様を案内するページで「RFC準拠」を謳うとしたら、
（あくまで仮定ですが、）
当然、そのページを参照したヒトはdocomoの言い分を鵜呑みにして良く、
それによって生じたトラブルは、docomoが責任をもってフォローしてくれる事でしょう。
SPAM 避け (スコア:0)
準拠すると SPAMer の餌食になるだけじゃん。
真っ当な技術者にとってハンドリングしやすいということは、SPAMer にとってもハンドリングしやすいということを意味している。
技術者が「そんなの想定していなかった！」と悲鳴を上げるくらいでちょうどいい。
まともな技術者が想定できないということは、ほとんど全ての SPAMer も想定できないわけだから。
Re:SPAM 避け (スコア:4, 興味深い)
別にSPAMerじゃなくてもメールが送れないケースが出るわけで、これをSPAM対策に使うのは適切ではないかと。
SPAMer側が対応したらどっちみち無意味になる。
Re:SPAM 避け (スコア:1)
#ここにぶら下げ
Google Appsでメーリングリスト作成した場合にも、
docomoの連続ドットは蹴られてしまい登録できません。
他の場面でも同様のことが起こると思いますので、今回の変更は嬉しいです。
puts "This user is a beginning Ruby programmer."
Re: (スコア:0)
ダブルドットなんかもないし…。
以前docomoに問い合わせたら、「迷惑メール対策してるはずだ」しか返って来なかった。
全部オフにしてもらってもだめなんだけどなあ…。
Re:SPAM 避け (スコア:1)
以下、妄想に近い想像
docomo に連続して同一 IP からメールが送られてくると、そのIPそのものをはじくような仕組みがあったりして?
誰かがそれに引っかかって GoogleGroups の IP からの配信が出来なくなってしまったとか。
不適切だと思う (スコア:1)
＞これをSPAM対策に使うのは適切ではないかと。
どう考えてもRFC的に正しくないアドレスを
SPAM対策に使うのは不適切だと思う。
＃釣られてるのかな？
屍体メモ [windy.cx]
Re:SPAM 避け (スコア:4, おもしろおかしい)
Re: (スコア:0)
> まともな技術者が想定できないということは、ほとんど全ての SPAMer も想定できないわけだから。
ここがダウト。「使ってはいけない文字がある」ルールなんだから、RFCに準拠させようとするほうが面倒なんですよ。SPAMerがアドレスをランダムに生成しようとするときにわざわざRFCに準拠させるようにある文字を除外させるなんてあるわけない。
Re: (スコア:0)
Re:SPAM 避け (スコア:2)
SPAMをあてずっぽうで10億件も送っている業者ならば、たかがdocomoユーザー程度の細かい数量は、コストとは思わないかも。
Re: (スコア:0)
Re: (スコア:0)
アドレスをrfc準拠にしてるし、フィルタも制限もかけてないけど、
スパムメールこないよ。
グッジョブ (スコア:0)
RFCを守ることがどれだけ大切なことか判ったんだろう
Re:グッジョブ (スコア:1)
同感です。
そしてもし新しい機能を追加したいなら、広く使用する前にRFCを書くべきだ。たとえば「@マークの前に.を入れることでスパム対策をおこなう方法」とかね。
Re: (スコア:0)
「不景気なのに、これ以上DoCoMo仕様に準拠するコストを負担しつづけられません！」
と泣きついた事業者が出たんじゃないかと邪推。
＃車輪の再発明は辛いんだ。
Re:グッジョブ (スコア:2)
私は、他所で開発した携帯向けメール配信システムのお守りを
請け負っているんですが、登録時のメールアドレスチェックが
RFC準拠っぽくなっているため、入力できないケースが多発…
開発元は M&A でぜんぜん別の会社になってしまったので、
ソースを直すこともできず、とりあえず直接データベースに
つっこんでお茶を濁しています（ｗ
まあこんな事例もあるということで。
Re:グッジョブ (スコア:1)
元コメントとは直接関係ありませんが、.NetFramework 以降で使える
メールアドレスクラス(System.Net.Mail.MailAddress)で
RFC非準拠のメールアドレスを扱おうとすると、例外が発生しますね。
後から気づいて、クラスに格納する直前でドットやらハイフンやらを置換することで
誤魔化しましたが、あんまり置換箇所が多いと、メールが長すぎるというエラーになったり、
やっつけ感が否めない状況になってしまったことがあります。
それ以降、同様のシステムを構築するときは有料のライブラリを買うようになったとか。
Re:グッジョブ (スコア:1)
けど、SMTP でのメールアドレス定義をきちんとバリデーションするのは、
非常に大変じゃないですか?
エスケープすると何でも入れられたりしますし。
あと、UUCPアドレスにも対応が必要だったりして。
Re: (スコア:0)
IPv6なんてどれだけのソフトが準拠してる? ISO-2022なんてもう。
と思うと準拠しようとするのも大変です。メールのRFCだけで何百あるのか。
過去のしがらみをもっとなくして欲しい (スコア:0, 参考になる)
個人的に切実な物としては
・reply-to 設定を可能とする
・返信を原則全文引用とする
この2点を実装して欲しいです。auからdocomoに乗り換えてこの2つがないのが地味に痛いことに気づきました。
特に後者はメール文字数制限が厳しかった時代の名残なのではないかと推測しています。
最新機種はMB単位の添付ファイルも可能なのに、実稼動としてByte単位が標準の端末もある現実では難しいのもわかるのですが。
---
ガラケーでもいい。たくましく育ってくれ。
Re:仕様の改善といえば (スコア:2, すばらしい洞察)
auみたいに自動で他のメールアドレスに転送できる仕組みがほしいねぇ。メールの保存が出来て便利なんだが。
Re:過去のしがらみをもっとなくして欲しい (スコア:1)
私はFOMAを使っていますが、引用返信はできていますよ。
※ 機種はP904iです。
Re:過去のしがらみをもっとなくして欲しい (スコア:1)
＞・返信を原則全文引用とする
そもそもこういうのは MUA の機能なので、MTA の仕様とは関係ないですが、
MUA の機能、もしくはメール送信のマナーとしても、おかしくないですか?
無駄にトラフィックを増やしているだけですよね。
Reference がつけられるのだから、それを MUA が引っ張ってきて表示
すればそれですむことじゃないですか。
もちろん、Reference されたメールを持っていない人はみられないのですが、
逆に全文引用して宛先を増やすのもあまりいいマナーとは思えませんし。
Re: (スコア:0)
>返信を原則全文引用とする
こちらに関しては、携帯電話のアプリケーションの実装ではないでしょうか。
私が使用しているN904iは標準の"返信"機能では引用は行いませんが、
メニュー内に"引用返信"機能があり、そちらを選択すれば引用返信ができます。
個人的には携帯電話のメールに関しては引用することがほとんど無いので、
現在の仕様で特に困っておりません。
Re: (スコア:0)
全文引用かどうかは返信者によるので，送信バイト数が増えて嫌だという人は
あまり引用しないでしょう…引用できないなら、その端末の実装がタコなんだだと思います。
まさかi-Modeサーバでもって全文引用分を返信メールへ付加するように書き換えろと仰るつもりで？
Reply-Toは同意しますよ。あったらいいのに。
Re:過去のしがらみをもっとなくして欲しい (スコア:2)
素直に歓迎なんてできない (スコア:0)
Re: (スコア:0)
春休みだなあ…
Re: (スコア:0)
ダメアドレスの一掃を望む声はちらほらあるけど、こういう「急いでるんです！」て意見は初めて見た。
気になるのでちょっと事情を聞かせてください。
別にぎゃーぎゃー騒がないで (スコア:0)
っていうかさ、みんないろいろとアドレスに小細工してSPAM避けしてるけど、
あんなの単純にアドレスあほみたいに長くすれば業者も類推する気無くしてぜんぜん来ないのに・・・って思うんだよね。
携帯間ならどんな長くてもどうせ赤外通信で渡せるんだし。
Re:別にぎゃーぎゃー騒がないで (スコア:3, おもしろおかしい)
そして長いメールアドレスが回線容量を無駄に消費している [srad.jp]と問題に...。
Re:別にぎゃーぎゃー騒がないで (スコア:2, すばらしい洞察)
私の主観なんですが、そもそもメールアドレスの変更によって
spam対策とすること自体ナンセンスだと思っています。
フィルタリングで篩いにかけるのが本来ではないでしょうか。
"小細工"にしろ、長いアドレスにしろ、
携帯間以外での利便性が落ちるので私は好きになれません。
puts "This user is a beginning Ruby programmer."
Re:別にぎゃーぎゃー騒がないで (スコア:1, 興味深い)
ようするにPC世界との隔絶を積極的に望んでるので、
携帯間以外の利便性が落ちることは何も気にしてないのです。
もともとはつまんない事から起きている、つまんない問題なんですが、
技術者の都合はさておきユーザーにはそういう意思があることは踏まえた方が良いと思います。
ただ、そうは言ってもWebサーバーはPC世界のものなのでいろいろと軋轢が出てきます。
そこを吸収するべきのはコンテンツプロバイダであって、
スジがどうとか何が正しいとかは関係ないと思うんです。
別にユーザーは携帯とPCが同じ規格で通信してることなんて望んでないんですから。
別にユーザーは頭悩ませながらPC用のサーバーでコンテンツ構築してくれなんて言ってないんですから。
携帯専用に用意すれば良いだけでしょ？
Re:別にぎゃーぎゃー騒がないで (スコア:2, 興味深い)
冒頭にも記したとおり私の主観ですので、
私自身はPC等とのメール送受信や、手書きを含めるアドレスの通知などの利便性から、
メールアドレスそのものでspam対策はしませんよ、ということです。
ただ仰ることは、
スジがどうとか何が正しいとかは関係ないと思うんです。
この点も含め理解できます。
ただ、一点どうしても引っかかるのですが
ようするにPC世界との隔絶を積極的に望んでるので
確証ありますか。知らずに隔絶されてるユーザも少なからず居ると思いますが。
フィルタリングでしたら選択式ですので、こちらこそ望んで行う方法だと思います。
puts "This user is a beginning Ruby programmer."
Re:別にぎゃーぎゃー騒がないで (スコア:1)
まぁ、インターネットにおける電子メールではなくｉモードのメールですからね。アドレスは電子メールに似てて紛らわしいですが、RFCに準拠していない電子メール以外の何かでありいわばショートメールの親分みたいなもんですから。
PCとの隔絶というか、そういう割り切りは十分にアリだと思いますね。
それでDoCoMo以外のユーザーからメールが届かなくなった時に文句言わないならそれで良い気がします。
◆IZUMI162i6 [mailto]
Re:別にぎゃーぎゃー騒がないで (スコア:2)
時折この手の事を聞くのですが、電話番号以外、メールアドレスは収集されたものに対し送られています。したがって、幾ら長くしたとしても収集されれば送って来ますが、短くても収集されなければ送ってきません。
つまり、長さや複雑さの問題ではありません。露出の問題です。
当然ですね (スコア:0)
まったく辺境のガラパゴス企業ごときが、国際的な標準を無視して俺様仕様を世界に押し付けようなどとは身の程知らずにもほどがある。
by Microsoft
Re:当然ですね (スコア:1)
口調はアレだが、こればっかりはMSだろうとCiscoだろうとlinus torvaldsだろうと同じことを言いそうな気がする。
Re: (スコア:0)
自分以外の企業の勝手仕様に対応させられそうになったら、
同じ様な事を言いますね。
「お前が言うか」ってのも、どこも同じ。
Re:何で制限する方向でしか対応できないのかなあ (スコア:1, 興味深い)
そのとおりですね。 そして二重引用符そのものを含めることもできますよね。 適切にクォートすれば。
(「SMTPの」という部分は不要ですが)そのとおりですね。
さて、
や
のような、二重引用符をその一部とする アカウントを作成した場合にメールアドレスを伝えるにはどうしたらよいでしょうか？
逆に、
や
という 文字列がメールアドレスとして与えられたとき、プログラムはどう処理したらよいでしょうか？
全てのシステムがRFCに準拠したとして、ユーザはクォートを意識して使いこなすことができるでしょうか？
あるいは、ユーザがクォートを意識する必要のないシステムは実現可能でしょうか？
Re:何で制限する方向でしか対応できないのかなあ (スコア:1)
RFCに準拠して真面目に処理してもいいですし、さらに制限を加えて、エラー吐いてもいいんじゃないでしょうか。もちろん独自仕様にして、非準拠なアドレスであっても、メールを送る際にRFCに準拠するように書き換えても(安全に作るためには、コストが見合わないと思いますが)。どこまで通すかはコストとのトレードオフで……。
現実は、備え付けのバリデータを使いますから、その仕様次第(多くはRFC5322よりも制限された状態)になると思いますよ。