アカウント名:
パスワード:
もともと脆弱なのに何が問題?と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。
DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁそもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、という論理でしょうね。
いや、全然違うでしょ。DKIMのチェックを通過していれば送信者(ドメイン)の表示は信頼できるはずなのに、DKIMのチェックを通過したドメインとは違うメールアドレスに偽装できてしまう脆弱性があったという話。
「サーバーの問題である」というのは、この脆弱性を突くメールがRFCに従っていないからサーバで弾くべきという原則論に基づく話で、「そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ」などという話ではない。
いや、送信(クライアント)側は脆弱性があろうがなかろうが偽装しようと思えばできるし思わなければしないんだから関係ないでしょ結局のところ問題になるのは受信側検知能力検知の仕様がないというのならプロトコルの問題まあ、メールなんてそんなものだし、どうしても本人確認必要なら暗号化した署名を忍ばせるしかないわな
受信側で偽装を検知できるはずなのに、偽装を許してしまうということなんですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
メールの送信者は普通に偽装できるよね? (スコア:3, すばらしい洞察)
もともと脆弱なのに何が問題?と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。
Re: (スコア:0)
DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。
「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁ
そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、
という論理でしょうね。
Re: (スコア:0)
いや、全然違うでしょ。DKIMのチェックを通過していれば送信者(ドメイン)の表示は信頼できるはずなのに、
DKIMのチェックを通過したドメインとは違うメールアドレスに偽装できてしまう脆弱性があったという話。
「サーバーの問題である」というのは、この脆弱性を突くメールがRFCに従っていないからサーバで弾くべきという原則論に基づく話で、
「そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ」などという話ではない。
Re: (スコア:0)
いや、送信(クライアント)側は脆弱性があろうがなかろうが偽装しようと思えばできるし
思わなければしないんだから関係ないでしょ
結局のところ問題になるのは受信側検知能力
検知の仕様がないというのならプロトコルの問題
まあ、メールなんてそんなものだし、どうしても本人確認必要なら暗号化した署名を忍ばせるしかないわな
Re:メールの送信者は普通に偽装できるよね? (スコア:0)
受信側で偽装を検知できるはずなのに、偽装を許してしまうということなんですが。