アカウント名:
パスワード:
Toが不特定多数に公開されているも同然なのに、その To 宛のメールヘッダに記載される From を機械的に信用しちゃうなんて、Facebookの実装があかんですねこれは。っても、S/MIMEやPGPを使うなんて現実的ではないでしょうから、
* Facebook が自前の送信専用SMTPサーバ(もちろん認証必須)を用意して、必ずそこから送信させる(そうでないものは弾く)
(この実装を維持するとした場合)このぐらいしか有効な対策がないと思います。
さくっと、メールとの連携機能をやめてしまうのが吉ではないかと。
# 実装時に、誰かが問題視しなかったのかなあ。
そこまでしなくても、SPF認証するだけで完全ではないけど被害は抑えられそうですね
うーん、SPF程度だとあまり防御になってないのではないでしょうか。gmail.com などはSPFが意味をなさないでしょう。(誰でも簡単に取れるので)
gmail.com などはSPFが意味をなさないでしょう。(誰でも簡単に取れるので)
すません、 SPF は Return-Path (MAIL FROM:)を見るものでしたね。勘違いしました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
実装が悪い (スコア:3, 興味深い)
Toが不特定多数に公開されているも同然なのに、
その To 宛のメールヘッダに記載される From を機械的に信用しちゃうなんて、Facebookの実装があかんですねこれは。
っても、S/MIMEやPGPを使うなんて現実的ではないでしょうから、
* Facebook が自前の送信専用SMTPサーバ(もちろん認証必須)を用意して、必ずそこから送信させる(そうでないものは弾く)
(この実装を維持するとした場合)このぐらいしか有効な対策がないと思います。
さくっと、メールとの連携機能をやめてしまうのが吉ではないかと。
# 実装時に、誰かが問題視しなかったのかなあ。
comutt
Re: (スコア:2)
そこまでしなくても、SPF認証するだけで完全ではないけど被害は抑えられそうですね
Re: (スコア:1)
うーん、SPF程度だとあまり防御になってないのではないでしょうか。
gmail.com などはSPFが意味をなさないでしょう。(誰でも簡単に取れるので)
comutt
Re:実装が悪い (スコア:1)
gmail.com などはSPFが意味をなさないでしょう。(誰でも簡単に取れるので)
すません、 SPF は Return-Path (MAIL FROM:)を見るものでしたね。
勘違いしました。
comutt