アカウント名:
パスワード:
もともと脆弱なのに何が問題？と思ったけど、リンク先を見ると、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を偽装できるのは「脆弱性」です
それこそメールサーバの問題でメールソフト（クライアント）の問題ではないよね？
何言ってんだかメールサーバーでDKIM認証されたメールアドレス(From)のドメインが srad.jp なのにクライアントの脆弱性(BASE64エンコードに含んだヌルバイトを使用)で hoge.go.jp にできるってのが今回の脆弱性つまりクライアントの問題
能動的に偽装するやつはクライアント自体を偽装する偽装しないようなやつはそもそもそんな脆弱性を使おうともしない別のプログラムが勝手に情報を偽装するんならそれはマルウェアよって、クライアント側のただの不具合であって脆弱性というのは何か違う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
メールの送信者は普通に偽装できるよね？ (スコア: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: (スコア:0)
それこそメールサーバの問題でメールソフト（クライアント）の問題ではないよね？
Re: (スコア:0)
それこそメールサーバの問題でメールソフト（クライアント）の問題ではないよね？
何言ってんだか
メールサーバーでDKIM認証されたメールアドレス(From)のドメインが srad.jp なのに
クライアントの脆弱性(BASE64エンコードに含んだヌルバイトを使用)で hoge.go.jp にできるってのが今回の脆弱性
つまりクライアントの問題
Re:メールの送信者は普通に偽装できるよね？ (スコア:0)
能動的に偽装するやつはクライアント自体を偽装する
偽装しないようなやつはそもそもそんな脆弱性を使おうともしない
別のプログラムが勝手に情報を偽装するんならそれはマルウェア
よって、クライアント側のただの不具合であって脆弱性というのは何か違う