DMARCの学習とテスト

 (learndmarc.com)
2 ポイント 投稿者 GN⁺ 2023-10-02 | 1件のコメント | WhatsAppで共有
  • LearnDMARCは、メール認証の中核である SPF、DKIM、DMARC を1つの画面で学習・テストできるようにするもので、全体の視覚的な説明はデスクトップで確認できる
  • 結果画面では、まず Source IP address、Hostname、Sender などの接続情報が表示され、認証判定の出発点を確認できる
  • SPFとDKIMは、それぞれ認証対象ドメインと結果を示し、DMARC判定に必要な Alignment の有無も併せて表示する
  • DMARC領域では、RFC5322.From domain と Policy(p=)、SPF、DKIM の結果をまとめ、最終的な DMARC Result につなげる
  • 最後に Final verdict で全体の判定を確認でき、結果の匿名化とDMARC学習リンクも提供される

LearnDMARCの目的

  • SPF、DKIM、DMARC を学習し、テストするためのページ
  • DMARCの動作方式に関する全体の視覚的な説明は、サイトをデスクトップで開くと見られる

結果画面で確認する項目

  • Connection parameters

    • Source IP address
    • Hostname
    • Sender

  • SPF

    • Domain
    • Identity
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DMARC

    • RFC5322.From domain
    • Policy(p=)
    • SPF
    • DKIM
    • DMARC Result

最終判定と補助機能

  • 結果画面は Final verdict で全体の判定を表示する
  • Anonymize results で結果を匿名化できる
  • Learn more about DMARC リンクが提供される

関連記事

1件のコメント

 
GN⁺ 2023-10-02
Hacker News の意見

  • スパムを減らすために必要な中核的なメールサービスを推進する、よい方法だと思う。これまで一緒に仕事をした企業には、SPF、DKIM、DMARC だけでも十分な動機になってほしいといつも願っていたが、評判だけでは投資の優先順位を上げるには足りないことが多かった。
    幸い、顧客と信頼できる形でコミュニケーションしたい企業には、マーケターが好みそうな標準である Brand Indicators for Message Identification（BIMI） がある。これでセキュリティだけでなく、見栄えのよいロゴも手に入る: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    複数の企業で、「顧客体験」を名目に BIMI を使って DMARC をきちんと、つまり P=Reject で実装させたことがある。

    • DMARC にもまだ問題はある。数年前の資料: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      SPF も DKIM も、メールのスプーフィング防止を完全には解決しない。SPF は HELO/MAIL FROM 識別子を認証し、DKIM は DKIM-Signature ヘッダーの d= フィールドを認証するが、どちらもエンドユーザーに表示される From ヘッダーを認証しない。そのため、SPF と DKIM の検証に通っても、From アドレスは依然として偽装され得る。
      メールドメインに DMARC+ がないのは明らかに問題だが、DMARC+ だけで「本当の送信者か」という問題が解決するわけでもない。
    • 攻撃者の立場からすると、同じロゴを使うフィッシングドメインを作って BIMI を設定することを、何が妨げるのか気になる。
    • BIMI は年間 1000ドルくらいかかるのでは？

  • 関連資料: DMARC、SPF、DKIM がどのように動作するかをインタラクティブに見る - https://news.ycombinator.com/item?id=29869266 - 2022年1月、コメント108件

  • DMARC レポートを処理するオープンソース、あるいは少なくとも無料の方法を知っている人がいるか気になる。
    SPF、DKIM、DMARC を有効にしたメールドメインがいくつかあり、動作はしているが、DMARC には厄介な問題が2つある。
    (1) サイトによっては「あなたはメッセージを3通送信し、すべて正常で、すべての検査に合格した」といった DMARC レポートを送ってくる。
    (2) ときどき別のサーバー経由で自分のドメインを使ってスパムを送ろうとする試みがあり、「誰かが HELO/FROM にあなたのドメインを入れてスパムを試みたが、検査に失敗したためブロックした」というレポートを受け取る。
    どちらも自分には役に立たない。自分のユーザーが @gmail.com や @mail.ru にメールを送ったという事実は知りたくないし、2つ目の場合も自分のサーバーの IP ではないのでできることがない。
    XML を自分で展開して確認するのは面倒すぎるので、フィルターやダッシュボードがあると非常に便利そうだ。

    • 自分用に作ったスクリプトがある: https://github.com/hannob/rpter
      レポートの要約と失敗の詳細を表示する。そこまで洗練されてはいないが、拡張するには十分シンプルだと思う。SMTP-TLS レポートもパースする。
    • parsedmarc（https://github.com/domainaware/parsedmarc）は後で見るためにスターを付けてあるが、まだ自分では使っていない。
    • dmarcian には無料の personal ティアがある: https://dmarcian.com/pricing/

  • 「DMARC が通るには DKIM および/または SPF の検査に合格し、ドメインがアラインされている必要がある」という説明は、私の理解では間違っている。
    「and/or」ではなく or だ。DKIM または SPF のどちらか一方だけ通ればよく、両方を要求する方法はない。

    • これに関連して、Cloudflare と MailChannels の提携で最近問題があり、メールのスプーフィングが可能だった。
      根本的な問題は、MailChannels が認証を要求していなかったことだ。Cloudflare Workers が MailChannels の API エンドポイントを呼び出してメールを送信でき、MailChannels は SPF ポリシーに include: レコードを追加するよう求めていた。その結果、MailChannels がすべてのドメインの有効な送信者となり、誰でも誰かになりすませる状態になっていた。
      ホスティングされている200万ドメインのうち DKIM を設定していたのは約400だけだったが、たとえ DKIM があっても SPF の通過だけで DMARC は通っていた。
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • 構文を誤って解釈しているように思う。ここでの and/or は包括的 ORを意味していると見るべきだ。「and」が必ず可能な選択肢だという意味ではない。
    • なぜダウンボートされているのか分からないが、or だけが正しいという指摘は正確だ。
    • ドメイン費用を払わずにIP アドレスリテラルを使えば、SPF を無料で得られる。
      From:/Reply-To: フィールドに IP アドレスリテラルが入ったメールアドレスだけがあれば「SPF」を得られ、最初のトランザクションでグレーリスティングを避けるためにはるかによいスコアを得る。本文に URL がなければなおよい。
      ただし、これは常識だ。

  • プロセスを反復的にたどれるようにしている方式が本当にいい。数年前、以前の会社で適切なセキュリティ対策とともに自前ホスティングのメール送信へ移行しようとしたとき、こういうものがあれば大いに助かったはずだ。

  • Appleの「Hide My Email」サービスでメールを送ったところエラーが発生した: https://support.apple.com/en-us/HT210425
    Unhandled Promise Rejection:
    TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
    dist.min.js:3:32767
    インターフェイスが「Here are the message headers and message body:」と DKIM-Signature: d=icloud.com s=1a1hai を表示し始めた後に発生した
    このWebサイトがHacker Newsで紹介されてから1年以上経っているので、JavaScriptコードが古くなって動かなくなったようだ。そもそもSafariをサポートしていなかった可能性もあるし、両方かもしれない。それでもDMARCテストの第1部と第2部で多くを学べたし、その後の段階で何が起きるのか感覚をつかめた
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • 偽装メールをテストすると、Chromeでも同じエラーが出る
      telnet learndmarc.com 25
      Trying 87.239.13.42...
      Connected to learndmarc.com.
      Escape character is '^]'.
      220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
      HELO there
      250 allspark.uriports.com Hello []
      MAIL From: me@example.com
      250 OK
      RCPT To: ld-49101f55f6@learndmarc.com
      250 Accepted
      DATA
      354 Enter message, ending with "." on a line by itself
      .
      250 OK id=1qn4QF-00CUhd-5j
      入力している間に「ラブレターまで書く必要はない」という感じで面白かった。違うかもしれないが、データ区間では From: と To: ヘッダーを繰り返す必要があるようだ
      何年もの間、ホスト名の代わりに HELO there でどれだけ多くのメールを送ってきたかを思い出すと、今でも笑ってしまう。また、インターネットトラフィックのうち Enter message, ending with . on a line by itself が占める割合がどれくらいなのかも気になる
    • from フィールドなしでメールを送ったので壊れたのだ。プログラマーが悪いユーザーが悪いことをするケースをテストしようと思いつかなかっただけで、特別な陰謀はない
    • DMARCは RFC5322.Fromアドレス に依存しているため、このアドレスが欠けるとエラーになる。こうしたエラーを避けるため、現在はそのアドレスがないメールを無視している

  • 30年ほど前には善意と理想にかなっていた技術を21世紀でも動かそうとして、互換レイヤーとハック を幾重にも積み重ねて依存しているのは本当に驚きだ
    VOIP/通信の世界も同じだ
    Microsoftも最近メール到達性の問題を抱えていて、私たちのO365テナントの大半にSPF、DKIM、DMARCを確認するよう通知が出た。こちらはすでに正しく設定されていたが、一部のテナントでは小規模なメールプロバイダー（ISPレベル）にメールを送る際に問題があった。同じIPアドレスやメールサーバーからスパムが出ているため、小規模プロバイダーがIPやIPレンジを丸ごとブロックしていたからだ

  • 面白い事実: sns.amazonaws.com にはまだDMARCレコードがない。カスタムドメインを使わない場合、AWS SNSのメッセージはここから届き、すべてのCloudWatch通知も no-reply@sns.amazonaws.com から届く

  • メールは本来こう動作すべきだが、現実には 許可リスト がある

    • そしてブロックリストもある。略奪的なブロックリストもあれば、組織的なゆすり同然のブロックリストもある
    • 何のための許可リストなのか分からない。自分のドメイン宛てに送信できるドメインをあらかじめ許可リストで決めておくのは一般的ではない。そんなことをすると メールの目的 が崩れてしまう

  • DNSフェイルオーバーでも、こうしたチェックを正しく設定するのを忘れてはいけない
    Exchange Onlineのデフォルト設定を使っていて詐欺に遭った会社を見たことがある
    攻撃者がDNSを一時的に「利用不可」状態にすると、すべてのフィッシングメールが通ってしまった。MSのサーバーがDNS temp error で応答し、すべてのメールをスパムではないものとして通過させたからだ
    詳しくは received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout) で、DKIMは送信者のSMTPサーバードメインで検査されるが、この場合はフィッシングに使われた攻撃者のサーバーだった
    その後、MSのIT/セキュリティサポートと素晴らしい時間を過ごしたが、彼らはメールがどう動作するのかも理解していなかった。非常に笑えると同時に悲しい経験で、アウトソーシングが彼らにうまく合っていることを願う