アカウント名:
パスワード:
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。example.com は独自ドメインで、有効なメールアドレス（@の左部）はコマンド1行で増やせ
確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う
Gmailだとしたら、hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。フィルター機能でラベル分けすることもできます。なので、サービス毎にメールアドレスを分けるのも簡単にできます。
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。
あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった（何故か信じている技術者が多い）せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。
正しくは、local-part を quoted-string (") で囲えば、" と \ を除く すべての記号 （印字可能 ASCII 記号）が利用できます。 さらに、quoted-string の中では quoted-pair が利用できると書かれているので、" と \ でさえも、直前に \ を配置すれば利用できます。
つまり
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
はRFC準拠の正しいメールアドレスです。これが弾かれるシステムは糞ですので、試してみると良いと思います。糞システムを検出するリトマス試験紙になります。
[参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意をhttps://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を> https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
この記事のコメントによるとSMTPに限定しているようだが、それなら参照するのはRFC 5321のほうがいいと思うの(間違っているまとめに言えという話かもしれんが)。FWSとかコメントとか考えなくてよくなるし。
で、RFC 5321には> While the above definition for Local-part is relatively permissive,> for maximum interoperability, a host that expects to receive mail> SHOULD avoid defining
むしろE-mailアドレスについては、アドレスの方が糞仕様，又は仕様バグだよねとしか。仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。JavaScriptが糞言語であるのと同じような物．
態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。
こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。
# フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。
もはや昔話だけど、日本にはNTTドコモっていう、「仕様で認められないアドレスが選べて、スパムが来なくて便利」というのをウリにしていた恐ろしい大企業があったんだぞ。
「正しいE-mailアドレス」に準拠することの無意味さを教えられました。＃IE6の残した教訓：無理が通れば道理が引っ込む.
逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。
RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。
でも今更変えようとなると、折角だからUTF-8に対応させようとか、アプリケーション固有の拡張ができるようにメタ構造を作ろうとか、余計なこと言い出すやつが現れるに決まっている。そしてセキュリティの話になって、そもそも論が始まる。
+ をはじくのは糞システムだというのはわかるけど" をはじかないシステムに出会ったことがない
「弾く糞サイト」というのは、どういう状況なのだろう？たとえばWebメールで宛先に入力すると拒否されるというのならそれは確かに問題だが、メールアカウントを新規作成するときにRFCよりも厳しい基準にすることはサービス提供者の自由だし、問題はないと思うが。
問題ないから糞扱いなんだろ。直しようがないんだから。
エイリアス使って無限にアカウント作られるのを防止する目的もありそう。
gmailは「.」を無視するので、gmail特化でユーザ名を正規化してるのでない場合はどこに「.」を入れるかによって2^(文字数-1)個のアドレス使い分けができるかもです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
ID＝メールアドレスをランダムにすべき (スコア:0)
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、
現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。
私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。
qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。
example.com は独自ドメインで、有効なメールアドレス（@の左部）はコマンド1行で増やせ
Re: (スコア:0)
確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない
用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う
Gmailは+nameで対応済み (スコア:2, 参考になる)
Gmailだとしたら、
hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。
フィルター機能でラベル分けすることもできます。
なので、サービス毎にメールアドレスを分けるのも簡単にできます。
Re:Gmailは+nameで対応済み (スコア:1)
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
皆がRFC5322を守れば良いのに (スコア:1)
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。
Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。
あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった（何故か信じている技術者が多い）せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。
正しくは、local-part を quoted-string (") で囲えば、" と \ を除く すべての記号 （印字可能 ASCII 記号）が利用できます。 さらに、quoted-string の中では quoted-pair が利用できると書かれているので、" と \ でさえも、直前に \ を配置すれば利用できます。
つまり
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
はRFC準拠の正しいメールアドレスです。これが弾かれるシステムは糞ですので、試してみると良いと思います。糞システムを検出するリトマス試験紙になります。
[参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
Re: (スコア:0)
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
> https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
この記事のコメントによるとSMTPに限定しているようだが、それなら参照するのはRFC 5321のほうがいいと思うの(間違っているまとめに言えという話かもしれんが)。FWSとかコメントとか考えなくてよくなるし。
で、RFC 5321には
> While the above definition for Local-part is relatively permissive,
> for maximum interoperability, a host that expects to receive mail
> SHOULD avoid defining
Re: (スコア:0)
むしろE-mailアドレスについては、アドレスの方が糞仕様，又は仕様バグだよねとしか。
仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。
JavaScriptが糞言語であるのと同じような物．
Re: (スコア:0)
態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。
# フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。
Re: (スコア:0)
もはや昔話だけど、日本にはNTTドコモっていう、
「仕様で認められないアドレスが選べて、スパムが来なくて便利」
というのをウリにしていた恐ろしい大企業があったんだぞ。
「正しいE-mailアドレス」に準拠することの無意味さを教えられました。
＃IE6の残した教訓：無理が通れば道理が引っ込む.
Re: (スコア:0)
逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。
RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。
Re: (スコア:0)
でも今更変えようとなると、折角だからUTF-8に対応させようとか、
アプリケーション固有の拡張ができるようにメタ構造を作ろうとか、
余計なこと言い出すやつが現れるに決まっている。
そしてセキュリティの話になって、そもそも論が始まる。
Re: (スコア:0)
+ をはじくのは糞システムだというのはわかるけど
" をはじかないシステムに出会ったことがない
Re: (スコア:0)
「弾く糞サイト」というのは、どういう状況なのだろう？たとえばWebメールで宛先に入力すると拒否されるというのならそれは確かに問題だが、メールアカウントを新規作成するときにRFCよりも厳しい基準にすることはサービス提供者の自由だし、問題はないと思うが。
Re: (スコア:0)
問題ないから糞扱いなんだろ。
直しようがないんだから。
Re: (スコア:0)
エイリアス使って無限にアカウント作られるのを防止する目的もありそう。
Re: (スコア:0)
gmailは「.」を無視するので、
gmail特化でユーザ名を正規化してるのでない場合は
どこに「.」を入れるかによって2^(文字数-1)個のアドレス使い分けができるかもです。