htc 端末のメールアプリで一部のメールアドレスへ送信できない「不具合」? 86
ストーリー by reo
コメント求む 部門より
コメント求む 部門より
htc 製 Android 端末の「メール」アプリで、一部のメールアドレスへメールを送信できない「不具合」があると報じられている。au および SoftBank Mobile 向け端末で生じることが確認されており、イーモバイル向け端末では確認中とのこと (ITmedia +D モバイルの記事、ガプシスの記事より) 。
ところがこの「不具合」、連続したドットが含まれるメールアドレス宛にメールを送信できないというもので、RFC5321、RFC5322 での定義からすれば不具合でもなんでもない。KDDI およびソフトバンクモバイルでは、送信可能にするためのソフトウェア更新を提供することを表明しているが、わざわざ「書式に問題のあるメールを送信できるようにしている」とも言える。
RFC に準拠しないメールアドレスを取得できるようにしていた i モードメールなどの「日本のケータイメール」の問題と言えそうだが、NTT ドコモや KDDI といった日本のキャリアは、自ら引き起こしたこのような問題をどう収束させるつもりなのだろうか。また、ユーザやソフトウェア開発者／メーカーはこの RFC 違反のメールアドレスに対してどう対処すべきだろうか。
連続ドットを根絶しよう！ (スコア:5, すばらしい洞察)
２重に RFC 違反しているアドレスの好きなやつ！
これの対応には、私も昔、苦労しました。
docomo でも、注意事項で使わない様に書いてあるので、
皆でエラーにして、根絶すべきだと思います。
Re:連続ドットを根絶しよう！ (スコア:1, 興味深い)
【警告】あなたのメールアドレスはRFCに違反しています！
うんたからかんたら理屈を考えるのは面倒なので飛ばすけどとにかく金を振り込め
という詐欺を思いつきました
Re:連続ドットを根絶しよう！ (スコア:1)
Re:連続ドットを根絶しよう！ (スコア:1, おもしろおかしい)
dotdotがかぶったら、dotdotdotにする処理を入れればいいじゃないか(素
Re:連続ドットを根絶しよう！ (スコア:1)
でもね、RFC違反メールアドレスってSPAM避けって事で推奨している話も（ソース失念だけど）聞いた事があったんですよね。確かに携帯電話網以外からは送信できませんから。
Softbankの対応 (スコア:3, おもしろおかしい)
同じ内容のメールが157から送られてきました。
「不具合」ではなく「事象」という扱いなようで、「ソフトウェア更新にて対応」するようです。
http://mb.softbank.jp/scripts/japanese/information/fota/detail.jsp?id=... [softbank.jp]
Re:Softbankの対応 (スコア:1)
「不具合的事象が発生しましたが、直ちに問題ありません」
# 「爆発的事象」は流行語大賞にならないかな？
-- う～ん、バッドノウハウ？
Re:Softbankの対応 (スコア:1)
私のDesireにも来てました。で、この事象は純正ROMだけ？（ぉぃ）
あとで実験してみよう。
あなたのメールアドレスは国際ルールに反しています (スコア:2, おもしろおかしい)
当社といたしましては当面自社メールに関してはサポートを続けさせていただきますが、他のメールサービス等からハブられる可能性が高いので
ボッチになりたくない方は早急にメールアドレスの変更されることをお勧めします。マミ(仮名)「こんなにメールボックスが軽いのは初めて！」
Re:あなたのメールアドレスは国際ルールに反しています (スコア:1)
「......使えるようにしたから、docomoからうちにおいでよ！」という。。。
＃OutlookやGmailなんかも昔は送れなくて、問い合わせ来てた記憶がかすかに。
Re: (スコア:0)
そんなに重要な事なら法律で定めるなりすればいいのにわけわからないよ。
Re:あなたのメールアドレスは国際ルールに反しています (スコア:1, すばらしい洞察)
ともだち同士や，成熟した「コミュニティ」では
「ルール」や「マナー」が大切。
だから，法律なんかじゃなく RFC を使う。それだけのこと。
法律で縛らないとルールを守れないのは，
その社会が未熟だから。
Re: (スコア:0)
ネタをスルーしてマジレスすると、そんなに重要でもないです。
守れない極稀な例をハブればいいだけなんで、
全利用者が対象になるように法整備するなんてコストかかり過ぎですよ。
「禁煙」や「土足厳禁」の張り紙と一緒です。
そこの管理者達が、その場のルールとして定めている。国のお墨付きなんかいりません、
そこの都合でルールを変える事だってあるんだし、法律で定める必要なんてない。
# 「法律で」等とわけのわからんこと言い出す時点でネタを逸脱してるよな。残念ながら、
RFC 5233 (スコア:2, すばらしい洞察)
Re:RFC 5233 (スコア:1, 参考になる)
gmailで_を受け付けれくれなくて泣いた.
Re:RFC 5233 (スコア:1)
「＋」を使えるとgmail等で、相手毎にメールアドレスを変えられるから便利ですよね。
メールサーバは問題無いだろうに、Webの入力で「＋」付きのメールアドレスを入力すると
入力エラーになることが多々あります。
# 九十九のサポート受付画面は、入力時はエラーにならないけど、勝手に「＋」を削除してくれました。
送受信できるようにする (スコア:0)
間違いとはいえ登録してしまったものはしょうがないから使えるようにしないと。
しないならそれなんて巫女SE?
Re: (スコア:0)
筋としては当該顧客に謝罪して、アドレス変更をお願いする事なんですけどね…
キャリアにとって都合のよい、周波数改変による機種変更強制はできてるんだから、
メールアドレスを変更させる事が、できないとは思えないんですけど。
Re:送受信できるようにする (スコア:2)
> 筋としては当該顧客に謝罪して、アドレス変更をお願いする事なんですけどね…
他キャリアの顧客にどうやって変更をお願いするのでしょうか？
だが、いいこともあるぞ、外の天気は上々なんだ
Re:送受信できるようにする (スコア:1)
説明が足りなかったですね。申し訳ありません。
今回の問題で困っているのはhtc端末を採用したKDDIとSBMですが、アドレス変更となるとdocomoも対応する必要があるわけですよね。特に困っていないdocomoの顧客にどうやってアドレス変更をお願いするのかな、と疑問に思った次第です。
#1955593のご意見は、 "docomoは別に今のところ困ってないけど、RFCに準拠していないアドレスの変更を顧客に要求するべき" ということでしょうか？ だとすると、さすがにちょっと現実的ではないなぁ、と思います。
問題となっているKDDIとSBMですら、明らかにコストが安い端末のソフトウェア改修に傾いているのに、被害を受けていないdocomoが相応のコストをかけて顧客流出のリスクを負ってまで顧客にアドレス変更をお願いするという動機はないですよね。まあ、元コメントは "コストや動機など関係なしに何が何でもRFC準拠とするべき" ということなのかもしれませんが。
だが、いいこともあるぞ、外の天気は上々なんだ
Re:送受信できるようにする (スコア:1, 興味深い)
＞被害を受けていないdocomoが相応のコストをかけて
逆でしょ。docomoが被害を受けてないというよりは、RFC非準拠のアドレスを受け付けちゃったのが原因で、被害を「与えている側」。
なら、docomoが相応のコストをかけるべき。と元ACは言いたいんのでは？
Re:送受信できるようにする (スコア:1)
えーと、docomoが被害を与えている側で、技術者の道義的に見ればdocomoが対応するべきというのはよく分かってますよ。
ただ、現実的にdocomoは直接被害を受けていないので、(技術者の道義という理由を除けば) コストをかけて顧客にアドレス変更をお願いする理由がないですよね。自分も技術者なので技術者の筋を通せという理屈はわからないでもないですが、この規模のものを変更するコストを考えるとさすがに無理筋過ぎるんじゃないかなぁ、と思う次第です。自分がdocomoの中の人だったらと考えたら、アドレス変更を企画する気にはなれません……。
だが、いいこともあるぞ、外の天気は上々なんだ
Re:送受信できるようにする (スコア:1, すばらしい洞察)
「私がルールを守らなかったせいで他人に被害がでてるけど、
私には害が無いから、私が対応する必要はありません」
これは「技術者の道義」なんてものじゃなくて、
社会人・現代人としてどうかと思うんですが。
Re: (スコア:0)
周波数を変えるために端末を変えさせることはあっても、電話番号を変えさせるってことはないからなぁ。
＃メールアドレスを変えさせるっていうのは電話番号を変えさせるというのと同じだよね。
Re:送受信できるようにする (スコア:1)
既存番号には頭に3を付加して3xxx、新規発番は5xxx。
あの頃はまだのんきな時頃だったからか、短縮登録の修正の手間もたんたんと受け入れてた記憶がある。
そういえば、0422以外の東京都下、042x-xx-がいつの間にか、042-xxx-に変わっていたのには驚いた。
通信上はハイフンは無意味なので実害はないんだけど、三鷹武蔵野の0422-だけは堅持されている点、
詮索はしていないけど、三鷹市民だった頃の感覚だと、東京都って、23区、三鷹武蔵野、都下、島嶼で
区分していた。そのあたりが反映された結果なのかな。
都下にしても早くから市だったエリアと◯◯郡◯◯町ではまた印象が違うんだけどね。
それにしても、最近東京23区内の新規発番って03-6xxx-なのね。そういうところと付き合いがないから
気付かなかった。
Re:送受信できるようにする (スコア:3, 参考になる)
先はちょっと端折りましたが大体こんな流れです。
030/040時代
→番号が足りなくなって080/090が追加された
→さらに番号が足りなくなったので、距離区分を廃止し040と090も廃止、代わりに010が追加されて010，030, 080時代到来
→足りなくなったので020追加
→足りなくなったので040追加
→足りなくなったので090追加
→もう全然足りないから090で統一して11桁化(平成11年1月1日で11桁ウサギ♪ [youtube.com]のCMがあった) ※youtube 音声注意
→また足りなくなったので080追加
で、今に至る。
だいたいこんな感じの筈です。結構泥縄式?
iPhoneにはこの「不具合」ないの? (スコア:0)
あったとしてソフトバンクがどう対処するつもりなのか知らないけど。
ちなみにWindows Live MailやWindows Mailがサポートを拒んでくれたおかげで、現在では連続ドットアドレスの新規取得はauやドコモでもできなくなっています。既存のアドレスをどうしてくれるのかは知りませんが。
Re:iPhoneにはこの「不具合」ないの? (スコア:3, 参考になる)
、「このアドレス、アドレスとしておかしいけどこのまま送ってもいい？」
みたいなことを聞いてきます。許可すればそのまま送信可能。
#メールアプリの場合、かつ最新iOSの場合
#MMSの場合は知らない
Re: (スコア:0)
iPhoneに限らず、別のAndroid端末メーカーにも有りそうな気がするが。
今有る物は使える様にするしかないのじゃ？ (スコア:0)
原理主義的には「間違っているのは使っちゃダメ」なのかも知れないが、有る物は有るんだから仕方ない。
適当にユーザーが慣れてから、新規メールアドレスに制限を入れて…って10年じゃ変更は出来ないと見た。
Re:今有る物は使える様にするしかないのじゃ？ (スコア:1)
…あれ？大丈夫な気がしないよ…？
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:ダブルクォーテーション (スコア:1)
対応を行うのは携帯電話会社ではなく、すべての MUA の作成元ですね。あと、API 提供元。
携帯電話会社の gateway で変換ではそこまでたどり着くまでに MTA を経由することがあるので対応としてはダメです。
RFC5321 [ietf.org] では Quoted-string 形式は認められているわけで、Dot-string では許可されていない連続する "." や "( ) [ ] : ; @ ," が含まれた場合、自動的に Quoted-string に変換すればいいと思いますけど。
さすがにその変換をやらなければダメとは RFC532 には書かれてませんけどね。
Re: (スコア:0)
Re: (スコア:0, 荒らし)
全くだ。猶予期間１ヶ月で根絶させろ。
何十年やっとるんじゃボケ。死ね。
告知打つだけでいいから手間も費用も最小じゃないの？
できない理由がさっぱりわからない。
Re: (スコア:0)
システム作る人間がどれだけ苦労するか判ってねえな。
そのコストをドコモやKDDIが持ってくれる訳でもないくせに。
そんな変則的なドットのアドレスが重要か？
Re: (スコア:0)
そのシステムを作る人の食い扶持を持って来る顧客からの苦情が来るから、困るんだと思うが。
言ってしまえばそういう意見は
「ユーザーの金でユーザーの利便性を奪い取れ」
って事に成るので、世の中で広く営業している人は原理原則だけでは動けないんですよ。
狭い社会や自前の金でなら、誰も苦労しないとは思いますが。
Re: (スコア:0)
Re: (スコア:0)
いますよね、できない理由を探すスペシャリスト。
Re:今有る物は使える様にするしかないのじゃ？ (スコア:1)
営業にしたら、できない理由を探して顧客の無理な要求を
断ってくれるスペシャリストにならないかな？
-- う～ん、バッドノウハウ？
必要悪 (スコア:0)
迷惑メール対策で大活躍していたのでは？
パケット従量制である以上は致し方ないでしょう。
ってことで国内ではまかり通って良いんじゃないかな？
強いて言えば、
迷惑メール対策を充実させた上で、
RFC非準拠メールアドレスを
アドレス移行期間を設けて廃止ってのが筋かと。
# 迷惑メール対策自体いたちごっこだから必要悪継続？
# それともパケフリをデフォにして大通し？
Re:必要悪 (スコア:5, すばらしい洞察)
迷惑メール対策になっていたのは、ほんの初期だけです。
あっという間に迷惑メール送信ツールは対応したので
今ではRFC違反だろうがなんだろうが短いメアドには来ます。
なので無意味だから根絶して欲しい・・・
どっとはらい (スコア:0)
先頭と末尾の dot の扱いは大丈夫？
.foobar@docomo.ne.jp
foobar.@ezweb.ne.jp
とかはちゃんと刎ねてますかね？
関心事はそっちじゃない (スコア:0)
『弊社の独自仕様』なのか『他社の拡張仕様』なのか『日本のデファクトスタンダード』なのか。
非標準への追加対応なら当然追加コストが発生するわけで、それはどちらが負担するのか。
メールって重要だから、規格に反する異様な仕様なんて頼まれても対応したくないはず。
RFC違反で迷惑メール回避☆ (スコア:0)
今回のような..や先頭.のようなアドレスにすることで、
「迷惑メールを来づらくさせる」
という「テクニック」を紹介しているサイトがありました。
# その超絶裏テクニックを知った友人が自慢げにメールアドレスを変えてましたが、今は…。
Re: (スコア:0)