GMail、ezwebとdocomo宛のみメールアドレス中の連続ドットや@直前ドットを許可 102
ストーリー by hylom
携帯電話のネットはインターネットではない 部門より
携帯電話のネットはインターネットではない 部門より
あるAnonymous Coward 曰く、
Gmailでは先月頃から「.」(ピリオド)を連続して含むメールアドレスや、「@」直前に「.」があるメールアドレス宛のメールを送信できなくなっていたのだが、Web屋のネタ帳によると、どうやら最近また仕様変更が行われたらしく、@ezweb.ne.jpおよび@docomo.ne.jpの2つのドメインの場合のみ、これらを許可するようになっていることが確認されたそうだ。
メールアドレスに「.」を使うこと自体は問題ないが、「.」を連続して含んだり、@の直前に「.」があるメールアドレスはインターネットの標準仕様(RFCの規定)に違反するアドレスとなり、有効性が保証されない。これはNTTドコモやauの携帯電話向用Eメールサービスの仕様で、一応「一部のプロバイダとメールを送受信できない場合があります」といった旨の注意は行われているとのこと。
しかしドコモやauの携帯電話ユーザーの間では、メールアドレスに「.」を複数並べることは比較的一般的に行われているようで、確認してみたところ自分の携帯電話の電話帳内でもこのようなアドレスを数件確認できた。
どうみてもこのGmailの仕様変更は苦肉の策にしか見えないのだが、ドコモやauはまだ命名ルールを変更する気はないのだろうか?
Gmail以外にも (スコア:4, 興味深い)
親はメールや携帯電話に詳しくないのでメールアドレスの設定はドコモショップで
やってもらったのでピリオドを故意に付けたのはドコモショップ店員の可能性が高いのです。
結局はこちら側が折れ、苦情を述べた上でピリオドを削除するようにしました。
そのときググった結果Postfix、Outlook2003(sp3以上)、Outlook2007、Microsoft Exchange、Hotmail、Gmail
等のメールソフト、サーバーで弾かれるようです。
下記サイトがいろいろ情報をまとめているようです。
http://neta.ywcafe.net/000799.html [ywcafe.net]
http://neta.ywcafe.net/000803.html [ywcafe.net]
Re:Gmail以外にも (スコア:1)
他のMTA/MUAは良く知りませんが、Postfixは弾かないですよ。
Postfixはそのようなメールアドレスでも受け取ります。
問題になる(事もある)のは送信する時ですね。
hoge.@example.co.jpというようなメールアドレスに送信する時は、
"hoge."@example.co.jpというようにクォートします。
これはRFCにも書かれている正しい処理なのですが、
docomo側がクォートされていると受け取らない事があるようです。
ただ、#1434362 [srad.jp]のように問題なく受け取るという話も聞きますし、
自分ではそのようなメールアドレスに送った事は無いので、実際にはどちらが正しいのかはわかりません。
# 時期によって違ったとか、それ以外の条件があるとか?
少なくとも自分が聞いた事があるのは、すべてdocomo側が受け取らないという話です。
# でそのような時は、docomo向けはsmtp_quote_rfc821_envelopeをnoにしろという話になります
Postfix側でそのようなメールアドレスから/へのメールを弾くように設定する事も可能ですが、
かなり特殊(少なくとも普通ではない)設定ですし、設定した側も理解しているでしょうから、
それはPostfixの問題ではなくそのサイトのポリシーの問題になると思います。
確信犯 (スコア:2, 興味深い)
SPAMer があて先をランダムに生成する場合、独自仕様なら回避できるという発想です。
最近はフィルタが高性能化したため、SPAM避けの意味はほとんどなくなってしまいましたが…。
Re: (スコア:0, すばらしい洞察)
「一部のプロバイダとメールを送受信できない場合があります」というのはデメリットであると同時にメリットでもあるよね。
それによってSPAMがブロックされるケースもある訳だから。
Re:確信犯 (スコア:2, すばらしい洞察)
そりゃ、インターネットと「なんちゃって接続」しかしてないんだから、インターネットのデメリットを被らない事もあるでしょう。でも、「なんちゃって接続」なのでメリットを享受できない事もあります。そもそも「普通のメールアドレスと同等に考えられない」時点で、それをメールアドレスと見せかけている docomo / au の「仕様」はおかしいのです。
以前、ある会社の人事部の方から「就活中の学生さんに同報した説明会開催のメールが、学生の申請ミスで結構エラーになって戻ってくるんですよ」という話を伺い、「そういえば docomo は……(当時は docomo と Vodafone が問題だった)」と、この話をしたところ、実際に数十人がこういうメールアドレスの人達だったそうです。でも、彼らのフォローはしなかったようです。
(ここで言ってもしょうがない話ですが、就活中の学生さんは念のため、こういうメールアドレスでエントリしないようにした方がいいでしょうね)
学生さんは RFC に詳しいとは思えませんから、知らなかったのでしょう。docomo / au が OK を出したメールアドレスだったので、メールアドレスと信じてそのまま書いたのでしょう。でも、あるいは「SPAM フィルターとしてこっちの方がいいぜ!」というあなたたちの情報を鵜呑みにし、こんなメールアドレスにしたのかも知れませんよ。
「SPAM 避けになる便利なメールアドレスである」というのは間違いです。あえてそれをメリットと言うのであれば、「メールアドレスではないので SPAM 避けになる」というのが正しいのです。
(でも、ややこしいですよね?)
……やっぱり、普通の人が普通に使って正しいメールアドレスを取得できるよう、docomo / au は仕様を改めるべきだと思いませんか?
ドコモ、KDDIが歩み寄るべき (スコア:2)
許容したキャリアが歩み寄るべきですよね。即座にRFC違反の
アドレスを撲滅出来なくとも、新規設定を禁止して、そのような
メールアドレスを使用しているユーザは機種変更の際に
メールアドレスの変更を必須とするなどの対応はできますし。
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
> いるユーザは機種変更の際にメールアドレスの変更を必須とする
> などの対応はできますし。
これも現実問題としては難しいと思います。
さすがにシステム上、ドットが続くアドレスを許容していたのに「RFCを知らなかったユーザーが悪い」とは言い切れませんし。
「他プロバイダーと送受信できない可能性がある」というリスクは許容できても、後日強制的にメアドを変えさせられるリスクまでは許容できない、という人が居ることは十分に考えられます。(そうでなくとも、ただでさえ知り合いに周知する手間がありますし、たとえば名刺などに携帯のメアドを書いていた場合、名刺の作り直し費用なども発生するわけで……。)
どうしても対処するなら、ドットが連続するユーザーに対してはエイリアスとなるようなメールアドレスを用意して、そちらへの移行を促す、ぐらいでしょうかね?
神社でC#.NET
Re:ドコモ、KDDIが歩み寄るべき (スコア:2, 参考になる)
新規登録禁止、継続使用は認めるということにしておけばずっとアドレスを変えない人には影響もないし、新規登録は出来なくするというのはそれほど悪い手だとは思えません。
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
俺も歳食ったんだなぁ・・・
凛々しく、あほらしく。
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
寡聞にして名刺に携帯のメアドを書いてるの見たことはないけど、今時ソレは普通の情景なのでしょうか?
#ネットオークションで相手がフリーのメアド使ってたらかなり警戒してしまうのは別のお話。
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
# 副業のほうは別のところで管理してるからすぐにはみれません……後でみてみよう。
神社でC#.NET
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
悪いのはユーザではなくキャリアですが、キャリアの責任をユーザの手間に転嫁するのも
やむなしでしょう。
ただ、新割引オプション付加の際には料金プランの変更に必要あり、というように
何らかのメリットと引き換えに今までも同様の事は行っていたものの、
RFC準拠のメールアドレスへの変更の場合、ユーザから見える大きなメリットがないのが
問題でしょうか。
Re:ドコモ、KDDIが歩み寄るべき (スコア:1, すばらしい洞察)
きちんと送受信できるようになるのがメリット。".."や".@"のメリットなんて、所詮バッドノウハウ以外の何者でもないんだから。
特にd○c○m○の場合(Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
それによって考えうる被害程度を大幅に超えた被害を被った
として、サポートにネジこんでくる方々もいらっしゃいますので。。。
# かつて聞いたことがある理屈
# 通話にノイズが乗り、突然切れた。
# → 通話相手に、「お前が料金滞納してるからじゃないのか」と馬鹿にされた。
# → また、仲間内に、あいつは携帯料金もまともに払ってないという噂が流れ、
# 仲間内での地位が下がった。
# → 長年かけて築いてきた地位を携帯のノイズのせいで失った。
# → それに対して誠意を見せろ。
# そういうクレーム担当部署の課長は空手有段者、応接室の灰皿はアルミ。
# 。。。という都市伝説なのでID
-- Tig3r on the hedge
ポコポコヘッド (スコア:1)
その課長って島木譲二? [wikipedia.org]
Re:ドコモ、KDDIが歩み寄るべき (スコア:1, 興味深い)
日本仕様のメールアドレス... [ohgaki.net]
スラッシュドット・ジャパン | auのEメールアドレスが相互接続性を保障できないルールに変更? [srad.jp]
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
Re:ドコモ、KDDIが歩み寄るべき (スコア:1)
MacOSX アドレス帳に登録されるとき・・・ (スコア:2, 参考になる)
自動登録されたときだと思うんですが、
@の前にドットの入っている親のアドレスは
"hogehoge."@docomo.ne.jp
というアドレスで登録されていました。
へー、っと思いました。
Re:MacOSX アドレス帳に登録されるとき・・・ (スコア:1, すばらしい洞察)
しかし "" で囲ったメールアドレスを受け付けないMUAやウェブのフォームが多いこと多いこと。
Re:MacOSX アドレス帳に登録されるとき・・・ (スコア:2, 参考になる)
Re:MacOSX アドレス帳に登録されるとき・・・ (スコア:2, 参考になる)
RFC5321 [ietf.org]には以下のような記述があるので、保証されていると考えていいと思いますよ。
個別の実装に関しては別の話ですが。
自分が出す時はクォートすべき(SHOULD)とも書かれていますね。
実際、まともなMTAやMUAならばクォートすると思います。
Re:MacOSX アドレス帳に登録されるとき・・・ (スコア:1, 参考になる)
元ACです。
docomoの、親のアドレスについては送信できました。
送信側のMTAは、courier-mtaです。
# あれ? mobilemeから送ったんだっけ・・?
# 実は、親が docomoからSBMにキャリアを変えたので今は試せてないです・・・
NGワード (スコア:1)
Re: (スコア:0)
同じ先祖から違う進化(適応淘汰)を遂げた、とかでは無いので、
その表現はあまりにも的外れだ。
# 的外れなところで使われてるのをよく見るけど。流行ってるみたいね。
Re: (スコア:0)
同じ先祖だから aaa@bbb.ccc みたいな形をしてて、 適応淘汰は社内であったかと。
グーグル最悪だな (スコア:1, おもしろおかしい)
短期的には利益になるかもしれないけど、長期的には癌になるでしょ。
日本法人がやらせたんだろうか。
本国のGoogle社員がこういう技術的に悪なことをやるとは思えないよ。
幹部は知ってるのかな。
Re: (スコア:0)
サービス提供側としては、嫌々でも、サポートしていかないといけない。私もウェブ開発を仕事にしてますが、もうIEのクソ仕様にはこりごりですが、IEユーザーが多いから、仕方なく時間と手間かけてサポートしてますよ・・・
質問 (スコア:0)
rfcの件はわかっていまっすが、なぜそういう仕様なのか、前から気になっています。
Re:質問 (スコア:2, 参考になる)
明文化されていたのでは?「.」を区切り文字としてsplitしたときに
空文字列が入ったり頭や尻が「.」だったりするとバグを誘発しそうですしね。
BINDの設定ファイルなんかは尻が「.」であることが終端の意味だし。
Re:質問 (スコア:1)
表すために使っていたからです。
既に . を特別扱いしているメールサーバは、困ってしまうのです。
どっとどっとすらっしゅ (スコア:0)
セキュリティ上のこれ(ひとつ上のフォルダ)対策じゃないですか?
Re: (スコア:0)
@ を複数使ったらメールアドレスの処理として困るけど、
. は複数使ってもドメインとして普通に使うからなぁ。
Re: (スコア:0)
Re:質問 (スコア:1)
みんつ
Re:@は使えるんでは? (スコア:2, 興味深い)
RFC2822 3.4.1 addr-spec仕様 [srgia.com] から抜粋
「addr-spec は、ローカルで解釈される文字列の後にアットマーク("@" ASCII 値 64)とインターネットドメイン名とを含むインターネットでの限定識別子である。」
あと、RFC3986 2.2 予約文字 と 3.2.1 ユーザ情報 あたりから、「@」って予約文字に含まれるんで使えないかと。
Thunderbirdだと、[hoge@hoge@example.com] は認識してくれず。
直接サーバとSMTPで話せば通るのだろうか?
Re:@は使えるんでは? (スコア:1, 参考になる)
例: "hoge@hoge"@example.com
Re: (スコア:0)
別に技術的な問題があってドットの連続や@直前のドットを排除した訳では無いでしょう。
逆にいえば、これらの事が許容されても特にメリットは無いのでは?
Re:質問 (スコア:2, すばらしい洞察)
それは要するに仕様変更。
仕様を変えただけでは何も変わらんからです。
RFCに準拠しているインターネット、そのための古今東西全てのハードウェアと
ソフトウェアを書き換えて、デバッグやテストが終わった段階で、初めてRFCの
変更作業が完了します。
まるで、ある日突然無意味な仕様変更が入って、
「仕様変更したから明日までに直してね♪」
と上司に言われるようなものなのです。
そんな仕様変更して追加料金を請求しないのは、日本企業の社畜くらいのものでしょう。
Re:質問 (スコア:1)
◆IZUMI162i6 [mailto]
Re:質問 (スコア:2, おもしろおかしい)
fjの教祖様
Re:質問 (スコア:1)
#狭い世界だなあ・・・
Re:質問 (スコア:2)
#変更する課程で議論にはなるだろうけど、面倒臭がらずに説得していけばいいだけ。
Re:質問 (スコア:1, すばらしい洞察)
RFCを改定したら既存のソフトや稼働中の多数のサーバが勝手に対応するわけじゃない。
メールソフトウェアの修正開発動作検証、既存のメールサーバのソフトウェアリプレスなどの作業にかかる工数や諸経費はばかにならないわけで。
さらにはエンドユーザが使用するメールクライアントだって影響を受けうるわけだから、買い直しだって必要になるかもしれないし、メールクライアントの入れ直しだって手間がかかる。
そういう諸々のコストをDoCoMoやauの業者なりユーザーなりが負担してくれるんですか?
一部の携帯業者やユーザの都合を押し通すために、その他の業者やユーザーが費用を払うってのは理不尽でしょ。
こういう金にかかわる問題は技術者だけが頑張ればどうにかなる問題じゃないのよ。
Re:質問 (スコア:1, おもしろおかしい)
今頃WindowsはVISTAだけになってます。
Re: (スコア:0)
>何が嫌なんだろ
つ「言い出しっぺの法則」
Re:質問 (スコア:1)
dot-stringとして明確に定義、予約しておいてくれたほうが混乱がなくていいね。
区切る必要がないって誰がきめたの?
区切る必要がある部分に区切り文字という概念を適用するのは論理的ですよ。
一度広げた風呂敷は畳めない (スコア:0)
Re: (スコア:0, オフトピック)
修正しました。
Re:J-PHONEの (スコア:2)
今話してることとちがうでしょ。。