アカウント名:
パスワード:
例: "hoge@hoge"@example.com
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
質問 (スコア:0)
rfcの件はわかっていまっすが、なぜそういう仕様なのか、前から気になっています。
Re:質問 (スコア:2, 参考になる)
明文化されていたのでは?「.」を区切り文字としてsplitしたときに
空文字列が入ったり頭や尻が「.」だったりするとバグを誘発しそうですしね。
BINDの設定ファイルなんかは尻が「.」であることが終端の意味だし。
Re: (スコア:0)
特別扱いしていますよね。
メールアドレスが Anonymous.coward @ gmail.com だったとき、Ano.nymou.scowar.d @ gmail.com
とか区切っても届きます。
……ふと思って試しに <"Anonymous...coward" @ gmail.com> に送ってみたら届きました。
何なんだ。
# /.のアカウント名がGmailのメールボックス名と同じなのでAC
Re:質問 (スコア:1)
表すために使っていたからです。
既に . を特別扱いしているメールサーバは、困ってしまうのです。
どっとどっとすらっしゅ (スコア:0)
セキュリティ上のこれ(ひとつ上のフォルダ)対策じゃないですか?
Re: (スコア:0)
@ を複数使ったらメールアドレスの処理として困るけど、
. は複数使ってもドメインとして普通に使うからなぁ。
Re: (スコア:0)
Re:質問 (スコア:1)
みんつ
@は使えるんでは? (スコア:0)
ん?確かRFCの仕様ではE-MAILアドレスのアカウント部に「@」は使用可能じゃなかったっけ?
なので、ファイル名の拡張子と同じく最後の「@」以降をサーバ部として処理すれば良い。
#ドメイン名には「@」は使えない筈だからこれで良いんだよね?
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: (スコア:0)
別に技術的な問題があってドットの連続や@直前のドットを排除した訳では無いでしょう。
逆にいえば、これらの事が許容されても特にメリットは無いのでは?
Re: (スコア:0)
区切る対象である文字列が存在しない状態では、
存在すべきではない、
と言う論理的な理由だと思います。
それに基づいて、技術的には、
区切り文字と区切り文字の間がNullである可能性を排除しています。
> rfcの件はわかっていまっすが、なぜそういう仕様なのか、
もし、ドットが区切り文字であるとは聞いた事が無いと仰るなら、
RFCは分かっている等とは仰らない方が宜しいかと。
Re: (スコア:0)
「rfcをわかっている」んじゃなくて、「この件がrfcに記述されている仕様との不整合であることがわかってる」という意味なんですけどね。まあ、上記理由はなんとなくわかりました。
Re: (スコア:0)
Re:質問 (スコア:1)
dot-stringとして明確に定義、予約しておいてくれたほうが混乱がなくていいね。
区切る必要がないって誰がきめたの?
区切る必要がある部分に区切り文字という概念を適用するのは論理的ですよ。
Re: (スコア:0)
??
どの部分が「区切る必要のない部分」ですか?
それってどこに定義されてます?
Re:質問 (スコア:2, すばらしい洞察)
それは要するに仕様変更。
仕様を変えただけでは何も変わらんからです。
RFCに準拠しているインターネット、そのための古今東西全てのハードウェアと
ソフトウェアを書き換えて、デバッグやテストが終わった段階で、初めてRFCの
変更作業が完了します。
まるで、ある日突然無意味な仕様変更が入って、
「仕様変更したから明日までに直してね♪」
と上司に言われるようなものなのです。
そんな仕様変更して追加料金を請求しないのは、日本企業の社畜くらいのものでしょう。
Re: (スコア:0)
Re:質問 (スコア:1)
◆IZUMI162i6 [mailto]
Re:質問 (スコア:2, おもしろおかしい)
fjの教祖様
Re:質問 (スコア:1)
#狭い世界だなあ・・・
敢えて釣られるが (スコア:0)
何故かauもdocomoもその様な働きかけをしてないんですけど、
> こだわってるほうがおかしいね。
って少数(世界の中での2企業)が言っても、
その他大多数からは「お前の方がおかしい」としか思われないので、
早くその他大多数に向けて働きかけして欲しいものです。
あるいは、旧態依然な都合を引きずるその他大多数との縁を切り、
2企業だけのネットワークを作るのもありだと思います。
> 実際に送受信できてるんだから、少なくとも技術的に何ら困らない話なんだし。
ソースは?
送受信出来ない例の方がたくさん挙がってますけど、
繰り返しになりますが、2企業だけのネットワークを作れば何ら困りませんね。
Re: (スコア:0)
rfcを変更する理由に値するかどうかですね。
働きかけをしてみるのもいいかもしれませんが、
メールアドレスの仕様変更は様々な所に影響を及ぼすため、
反発を招きそうな予感です。
Re:質問 (スコア:2)
#変更する課程で議論にはなるだろうけど、面倒臭がらずに説得していけばいいだけ。
Re:質問 (スコア:1, すばらしい洞察)
RFCを改定したら既存のソフトや稼働中の多数のサーバが勝手に対応するわけじゃない。
メールソフトウェアの修正開発動作検証、既存のメールサーバのソフトウェアリプレスなどの作業にかかる工数や諸経費はばかにならないわけで。
さらにはエンドユーザが使用するメールクライアントだって影響を受けうるわけだから、買い直しだって必要になるかもしれないし、メールクライアントの入れ直しだって手間がかかる。
そういう諸々のコストをDoCoMoやauの業者なりユーザーなりが負担してくれるんですか?
一部の携帯業者やユーザの都合を押し通すために、その他の業者やユーザーが費用を払うってのは理不尽でしょ。
こういう金にかかわる問題は技術者だけが頑張ればどうにかなる問題じゃないのよ。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
今頃みんなIPv6を使っています。
その通り、めんどくさい (スコア:0)
めんどくさくて、世界中の人の手と金と時間が掛かるのですよ。
どっかの誰かがササッとやってくれる仕事、じゃないのです。
Re: (スコア:0)
rfcを上書きしようとする努力を誰も否定はしないので、変えたいと思う人はがんばればいいんじゃないのかな?
#「.」なんて些細なことより、漢字使えるようになったほうが便利だな
Re: (スコア:0)
今頃みんな地デジを使っています。
# 他に無いかな?
Re: (スコア:0)
今頃中国は消滅してます。
Re:質問 (スコア:1, おもしろおかしい)
今頃WindowsはVISTAだけになってます。
Re: (スコア:0)
Re: (スコア:0)
>何が嫌なんだろ
つ「言い出しっぺの法則」
Re: (スコア:0)