アカウント名:
パスワード:
RFCであんな難解なフォーマットを規定した合理的理由がないのも問題だと思いますけどね。
これは有効だけど、!#$%&'*+-/=?^_`.{|}~@example.comこれは無効。!#$%&'*+-/=?^_`{|}~.@example.com
有効な例でもバリデーションで弾くユーザ登録フォームが結構ありますし。
docomoが微妙なのもわかるが、大元の問題はこれ(RFCがいけてない)だと思う文字セットだけ決める、に変えればいいのにquotedも禁止で
とは言えなんでRFC違反が多発したかっていうとドコモやガラケー関係者が頑なになってRFC準拠を拒否したからでもある例えば記号禁止にするとかいくらでも安易な回避方法があるのに、ガラケー時代は「そうした方がPCを排除できて良い」と言った愚かな意見が罷り通っていた
というか「PCと携帯の世界は分けなければマナー違反」というアパルトヘイト思想が酷かった
いやでも実際「そんなの必要か??」ってぐらい複雑なんですよ
RFC 5322はメールアドレスだけの仕様を定めているわけではなく、メールメッセージフォーマット全体の仕様なので、メールメッセージ中にメールアドレスを記述するだけために必要な、メールアドレス単体のフォーマットとしてはぶっちゃけ無意味で無駄な仕様が含まれている。
今日UUCPはもう無視していいと思うので、メールアドレスだけの仕様についてはRFC 5321を参照したほうがいい。これもSMTPの仕様であってメールアドレスだけの仕様ではないが、RFC 5322よりは断然マシ。
まぁ、もうすでに歴史的ではあるんですけどユーザパートのドットの制限はおそらく uucp 等のためです。昔は%ハックなどの方法で uucp など SMTP 以外の世界へメールをルーティングする書式が使われていたので。uucp を考慮しない実装でよければ @ の前は @ 以外の文字なんでもよかったんでしょうけどね。# uucp をサポートした sendmail cf などもルールを記述する際にドットで区切って文字列を扱うのよね
mailbox.sub1.sub2@this-domain や sub-net.mailbox@sub-domain.domain のようにlocal-part の一部に domain を埋め込む例が RFC822 に載っていますのでlocal-part に dot-atom を許容するのは当初は配送のためだったと思いますがRFC2822 への改定を生き延びたのは Firstname.Lastname@domain という使用例がそれなりにあるという主張が通ったためというおぼろげな記憶があります。
Gmail でも利用できる + を使用した拡張アドレスを受け付けないフォームが時々あるね。ローカルパートの記号は ._- しか使えないと勘違いしている Web 屋も結構残ってそう。
複垢対策のためにエイリアスを使わせたくないっていう意味もあると思う
そういう意図はあるかもしれないけど意味はないよねエイリアス(サブアドレス拡張)を禁止したところでメールアドレスなんて作り放題なんだからfacebookも昔は複垢対策みたいなこと言ってた [h7a.org]けど今は「+」を受け入れるようになった
バックエンド側の制約とかでフォーム作ってる側ではどうしようもないこともあるし
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。1行の正規表現でとかやるから難解になるんじゃね?
ローカルパート作るときはアルファベットのみとかの制限つければいいし既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。
いくらバリデーションしても届かないものは届きませんしRFC準拠なら何でも登録させろというのはまた違うでしょ。
ガバガバすぎるでしょ。
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
だけじゃなくて他にも決まりはあるし、実際その3つだけでも真面目に実装したら結構たいへんですよ。
ん?送信エラーにおまかせってことですか?
RFC準拠なら何でも登録させろというのはまた違うでしょ。
チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
> チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
ええと、MTAの実装の話をしているのかな?
バリデーション書けないならライブラリとか使えば良くない?そんなに複雑なコードでもないよ。
例えばこれとかhttps://pypi.org/project/validate_email/#files [pypi.org]
そのライブラリ試したらこんなですけど?
$ python3>>> from validate_email import validate_email>>> validate_email('やっふーい@example.com')True
まぁ複雑かどうかは主観なのでどっちでもいいのですが、やる必要がないことをやらされてる感が半端ないです。
もしかして、RFC 6531あたりの国際化対応で'やっふーい@example.com'は正当なメールアドレスに分類されるので、Trueを返すのが適切という可能性がある?
現状がすでに制限されまくっていて、問題ない入力でも弾かれまくりですよ。
多様なメール環境を相互接続するためにローカルパートでは任意の文字列を表現可能にしたのでしょう。RFC822に載っている例ですがメールアドレスが "FULL NAME"@DOMAIN という組織もあったようで、これがどう処理されていたかはおそらく DOMAIN 宛のメールはプリンタ直行で印刷されたメールが机の上の文字通りのメールボックスに届けられたのだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
違反なのはわかってるけど (スコア:3, 参考になる)
RFCであんな難解なフォーマットを規定した合理的理由がないのも問題だと思いますけどね。
これは有効だけど、
!#$%&'*+-/=?^_`.{|}~@example.com
これは無効。
!#$%&'*+-/=?^_`{|}~.@example.com
有効な例でもバリデーションで弾くユーザ登録フォームが結構ありますし。
Re:違反なのはわかってるけど (スコア:3)
docomoが微妙なのもわかるが、
大元の問題はこれ(RFCがいけてない)だと思う
文字セットだけ決める、に変えればいいのに
quotedも禁止で
Re: (スコア:0)
とは言えなんでRFC違反が多発したかっていうとドコモやガラケー関係者が頑なになってRFC準拠を拒否したからでもある
例えば記号禁止にするとかいくらでも安易な回避方法があるのに、ガラケー時代は「そうした方がPCを排除できて良い」
と言った愚かな意見が罷り通っていた
というか「PCと携帯の世界は分けなければマナー違反」というアパルトヘイト思想が酷かった
Re:違反なのはわかってるけど (スコア:2)
いやでも実際「そんなの必要か??」ってぐらい複雑なんですよ
Re:違反なのはわかってるけど (スコア:1)
RFC 5322はメールアドレスだけの仕様を定めているわけではなく、メールメッセージフォーマット全体の仕様なので、メールメッセージ中にメールアドレスを記述するだけために必要な、メールアドレス単体のフォーマットとしてはぶっちゃけ無意味で無駄な仕様が含まれている。
今日UUCPはもう無視していいと思うので、メールアドレスだけの仕様についてはRFC 5321を参照したほうがいい。これもSMTPの仕様であってメールアドレスだけの仕様ではないが、RFC 5322よりは断然マシ。
Re:違反なのはわかってるけど (スコア:3, 参考になる)
まぁ、もうすでに歴史的ではあるんですけど
ユーザパートのドットの制限はおそらく uucp 等のためです。
昔は%ハックなどの方法で uucp など SMTP 以外の世界へメールをルーティングする書式が使われていたので。
uucp を考慮しない実装でよければ @ の前は @ 以外の文字なんでもよかったんでしょうけどね。
# uucp をサポートした sendmail cf などもルールを記述する際にドットで区切って文字列を扱うのよね
Re:違反なのはわかってるけど (スコア:1)
mailbox.sub1.sub2@this-domain や sub-net.mailbox@sub-domain.domain のように
local-part の一部に domain を埋め込む例が RFC822 に載っていますので
local-part に dot-atom を許容するのは当初は配送のためだったと思いますが
RFC2822 への改定を生き延びたのは Firstname.Lastname@domain という使用例が
それなりにあるという主張が通ったためというおぼろげな記憶があります。
Re:違反なのはわかってるけど (スコア:1)
Gmail でも利用できる + を使用した拡張アドレスを受け付けないフォームが時々あるね。
ローカルパートの記号は ._- しか使えないと勘違いしている Web 屋も結構残ってそう。
Re: (スコア:0)
複垢対策のためにエイリアスを使わせたくないっていう意味もあると思う
Re: (スコア:0)
そういう意図はあるかもしれないけど意味はないよね
エイリアス(サブアドレス拡張)を禁止したところでメールアドレスなんて作り放題なんだから
facebookも昔は複垢対策みたいなこと言ってた [h7a.org]けど今は「+」を受け入れるようになった
Re: (スコア:0)
バックエンド側の制約とかでフォーム作ってる側ではどうしようもないこともあるし
Re: (スコア:0)
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
1行の正規表現でとかやるから難解になるんじゃね?
ローカルパート作るときはアルファベットのみとかの制限つければいいし
既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。
いくらバリデーションしても届かないものは届きませんし
RFC準拠なら何でも登録させろというのはまた違うでしょ。
Re: (スコア:0)
ガバガバすぎるでしょ。
dot-atomとquoted-stringとquoted-pairをサポートすればいいだけ。
だけじゃなくて他にも決まりはあるし、実際その3つだけでも真面目に実装したら結構たいへんですよ。
ローカルパート作るときはアルファベットのみとかの制限つければいいし
既存のメールアドレスを入力させる場合は@が含まれているか程度のチェックでいいだろ。
ん?送信エラーにおまかせってことですか?
RFC準拠なら何でも登録させろというのはまた違うでしょ。
チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
Re: (スコア:0)
> チェックしなくていいっていう主張と矛盾してるんですが、RFC準拠なら届かなきゃおかしいです。
ええと、MTAの実装の話をしているのかな?
バリデーション書けないならライブラリとか使えば良くない?
そんなに複雑なコードでもないよ。
例えばこれとか
https://pypi.org/project/validate_email/#files [pypi.org]
Re: (スコア:0)
そのライブラリ試したらこんなですけど?
$ python3
>>> from validate_email import validate_email
>>> validate_email('やっふーい@example.com')
True
まぁ複雑かどうかは主観なのでどっちでもいいのですが、
やる必要がないことをやらされてる感が半端ないです。
Re: (スコア:0)
もしかして、RFC 6531あたりの国際化対応で'やっふーい@example.com'は正当なメールアドレスに分類されるので、Trueを返すのが適切という可能性がある?
Re: (スコア:0)
現状がすでに制限されまくっていて、問題ない入力でも弾かれまくりですよ。
Re: (スコア:0)
RFCであんな難解なフォーマットを規定した合理的理由がないのも問題だと思いますけどね。
多様なメール環境を相互接続するためにローカルパートでは任意の文字列を表現可能にしたのでしょう。
RFC822に載っている例ですがメールアドレスが "FULL NAME"@DOMAIN という組織もあったようで、
これがどう処理されていたかはおそらく DOMAIN 宛のメールはプリンタ直行で
印刷されたメールが机の上の文字通りのメールボックスに届けられたのだと思います。