DMARCポリシーの設定 ＜reject設定推進派の人＞

結論：DMARCのreject推進派の人は、とりあえず自組織の経営層やシステム担当を説得してみてはいかがだろうか?

---

DMARCについては政府やセキュリティ団体が導入を推進していたが、なかなか受け入れられなかった。
ところが、googleがDMARCの導入を決めて、対応する企業・団体が増えてきた。
さらに、メールサービスを提供する事業者は、Rejectに設定する事業者も増えてきた。
これに気を良くしたのか推進派はRejectに設定することを勧めているようだ。

DMARCは
なりすましメールを防止する枠組みで、なりすましを検知したときに、詐称されたドメインの設定を見て処理を決める仕組みだ。
処理のレベルは、
・none: 何もしない(レポートだけ)
・quarantine: 隔離(多くの場合迷惑メール判定)
・reject: 配送しない
が設定できる。

導入時は noneに設定する。
この設定では配送に影響を与えないので、DMARCレポートを確認して、正規のメールが認証エラーになっていないか確認する。

問題がなければ reject に設定する。
認証エラーがあると、たいてい迷惑メールフォルダに配送されるので、届くはずのメールが届かない場合は迷惑メールフォルダを探すことで対応できる。

次に、rejectに設定すると、
認証エラーのメールは配送されなくなる。

設定は、DNSの知識があり、管理していていれば難しくないし費用も発生しない。

誘導型の詐欺メールは、
有名な企業や組織を騙った、なりすましメールで送られることが多く社会問題になっている。
Reject設定を推進する人たちは、犯罪対策をしている人たちやセキュリティ村の人たちが多いようだ。

経営層の人たちは、
メリットとデメリットを考えるはずだが、DMARCのメリットとデメリットは明確でない。

推進派の人たちは、
「設定しないことで、セキュリティに関心がない組織だと認知される」のような、間接的なデメリットを強調するのだが、ちょっと胡散臭いなぁ。

システム担当としては、
設定の不備で正規のメールが届かないトラブルが発生した場合の対応が難しいので心配だ。
メールが届かないことは、そもそも検出できないから、トラブルが発生してしていても気がつかないことがある。
「noneやquarantineに設定している間に対策しているだろう」という指摘もあるだろう。
原理的には、おっしゃる通りだが、現実は理論通りにならないことはある。

DMARCに関連して、受信側のシステム管理担当としてトラブルを認知したことがあるが、先方のシステム管理者に伝えるルートがない。
たいていは、ユーザが別の方法で回避するので、送信側のシステム管理者は設定の不備に気が付かないままだ。

つまり、自組織の設定の不備は気付かない可能性が高い。

だからだろうか、rejectに設定している政府機関や団体は少ないようだ。

推進派の人は、とりあえず自組織の経営層やシステム担当を説得してみてはいかがだろうか?
なぜ、 多くの組織が rejectに設定しないか分かるかもしれない。

---

DMARC関係で、トラブルを認知した例

1. DMARCレポートが届かない
   大手IT企業で、メールサービス事業も展開しているドメイン名からのDMARCレポートがDMARCの認証エラーで届かない。
   DMARCレポートを送るホストがsfpリスト含まれていないので、迷惑メールフォルダに配送されていた。
   そのドメインがDMARCポリシーをrejectに変えたら届かなくなった。
    
2. ファイルを添付するとメールが届かない
   金融系企業からのメールで、ファイルが添付されていると、迷惑メール判定される。
   PPAPのパスワードは送られれくるが、添付ファイルのメールが送られてこないというトラブル。
   添付ファイルがあると、外部のメールセキュリティサービスでチェックするようになっていた。
   添付ファイルをチェックしたことを示すキーワードを Subject に追加する設定なっていたため、DKIMのシグネチャが変わり、DKIMの認証エラーになっていた。
   内部向けならば、Subjectを変えても問題はないのだけれど。

これらのトラブルはメールを受信する側のシステム管理者として気ついたのだが、先方のシステム管理者に伝えるルートがない。
また、ユーザが別の方法で回避するので、先方のシステム管理者は気が付かないままだ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】