アカウント名:
パスワード:
もともと脆弱なのに何が問題？と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。
DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁそもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、という論理でしょうね。
いや、全然違うでしょ。DKIMのチェックを通過していれば送信者（ドメイン）の表示は信頼できるはずなのに、DKIMのチェックを通過したドメインとは違うメールアドレスに偽装できてしまう脆弱性があったという話。
「サーバーの問題である」というのは、この脆弱性を突くメールがRFCに従っていないからサーバで弾くべきという原則論に基づく話で、「そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ」などという話ではない。
いや、送信（クライアント）側は脆弱性があろうがなかろうが偽装しようと思えばできるし思わなければしないんだから関係ないでしょ結局のところ問題になるのは受信側検知能力検知の仕様がないというのならプロトコルの問題まあ、メールなんてそんなものだし、どうしても本人確認必要なら暗号化した署名を忍ばせるしかないわな
送信元ドメインの管理者は、SPFとDKIMの両方の認証に失敗したメールに対して、「そのまま通す（none）」、 「隔離する（quarantine）」、「受信拒否する（reject）」というように、受信時の処理方法をDMARCポリシーとして宣言できる。
この宣言や公開鍵の公開は DNS の TXTレコードでやる。
SPFと違ってDKIMは電子署名方式なので仮に受信側がメール転送をかけてもメールの中身（Fromとかのヘッダーも改変禁止）を改変しなければPASSするから reject の宣言をしても利便性は落ちない
仮に reject の設定していないドメイン（DKIMには対応）を偽装しても受信ボックスに行かずに迷惑メールボックスに行くだろう。
もう「メールのFromはいくらでも偽装できる」なんて時代はとっくに終わってる。だから、Fromを偽装できるのは「脆弱性」です
これはこれで正論だけどさ。
From: somebody@foo.com <dareka@hoge.com>
みたいな記述で、送信者欄がデフォルトだと somebody@foo.com しか表示しないメーラーが普通にある昨今、脆弱性と言い切れるかというと・・・うん、すごく微妙な問題だと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
メールの送信者は普通に偽装できるよね？ (スコア:3, すばらしい洞察)
もともと脆弱なのに何が問題？と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。
Re: (スコア:0)
DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。
「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁ
そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、
という論理でしょうね。
Re: (スコア:0)
いや、全然違うでしょ。DKIMのチェックを通過していれば送信者（ドメイン）の表示は信頼できるはずなのに、
DKIMのチェックを通過したドメインとは違うメールアドレスに偽装できてしまう脆弱性があったという話。
「サーバーの問題である」というのは、この脆弱性を突くメールがRFCに従っていないからサーバで弾くべきという原則論に基づく話で、
「そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ」などという話ではない。
Re: (スコア:0)
いや、送信（クライアント）側は脆弱性があろうがなかろうが偽装しようと思えばできるし
思わなければしないんだから関係ないでしょ
結局のところ問題になるのは受信側検知能力
検知の仕様がないというのならプロトコルの問題
まあ、メールなんてそんなものだし、どうしても本人確認必要なら暗号化した署名を忍ばせるしかないわな
Re: (スコア:2, 参考になる)
送信元ドメインの管理者は、SPFとDKIMの両方の認証に失敗したメールに対して、「そのまま通す（none）」、 「隔離する（quarantine）」、「受信拒否する（reject）」というように、受信時の処理方法をDMARCポリシーとして宣言できる。
この宣言や公開鍵の公開は DNS の TXTレコードでやる。
SPFと違ってDKIMは電子署名方式なので仮に受信側がメール転送をかけてもメールの中身（Fromとかのヘッダーも改変禁止）を改変しなければPASSするから reject の宣言をしても利便性は落ちない
仮に reject の設定していないドメイン（DKIMには対応）を偽装しても受信ボックスに行かずに迷惑メールボックスに行くだろう。
もう「メールのFromはいくらでも偽装できる」なんて時代はとっくに終わってる。だから、Fromを偽装できるのは「脆弱性」です
Re:メールの送信者は普通に偽装できるよね？ (スコア:1)
もう「メールのFromはいくらでも偽装できる」なんて時代はとっくに終わってる。だから、Fromを偽装できるのは「脆弱性」です
これはこれで正論だけどさ。
From: somebody@foo.com <dareka@hoge.com>
みたいな記述で、送信者欄がデフォルトだと somebody@foo.com しか表示しないメーラーが普通にある昨今、脆弱性と言い切れるかというと・・・うん、すごく微妙な問題だと思う。