アカウント名:
パスワード:
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、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 (") で囲えば、" と \ を
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を> 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が糞言語であるのと同じような物.
より多くのコメントがこの議論にあるかもしれませんが、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: (スコア:1)
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
皆がRFC5322を守れば良いのに (スコア:1)
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。
Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。
あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった(何故か信じている技術者が多い)せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。
正しくは、local-part を quoted-string (") で囲えば、" と \ を
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:皆がRFC5322を守れば良いのに (スコア:0)
むしろE-mailアドレスについては、アドレスの方が糞仕様,又は仕様バグだよねとしか。
仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。
JavaScriptが糞言語であるのと同じような物.