DMARC受信側の課題
dmarcianのサービスディレクターであるトムキ・キャンプ氏は、20年以上にわたり電子メール認証技術に携わり、2012年からはDMARCの導入支援を行ってきました。本記事では、一部のプロバイダーがDMARCに関するフィードバックを提供する際に一貫性を欠いていることや、場合によってはまったく提供しないことについて語っています。
受信者が提供するDMARCデータは、ドメイン所有者がドメイン認証の問題を理解し、対処する上で非常に有用です。しかし、プロバイダーから送信される「標準化された」データに含まれる差異を正確に把握するには、多大な労力と専門的な知識が必要となります。
同様のサービスを提供するプロバイダーは一つとして同じものはなく、メールやウェブホスティングの環境にはそれぞれ特有の特性があり、その長所と短所は利用者に周知の事実です。しかし、これらの企業が提供するツールは、一般的にその動作や表示を規定するプロトコルによって管理されているわけではないため、サービスごとに大きな違いが見られます。
対照的に、DMARCの用途は、「特定のメッセージが認証プロトコルを通過したかどうかをどのように確認するか」から、「DMARC認証に失敗したメッセージに対してどう対処すべきか」、そして「DMARC認証の統計情報をドメイン所有者が指定したアドレスにどのように通知すべきか」に至るまで、非常に明確に定義されています。
残念ながら、一部のプロバイダーが軽視したり、誤った対応をしたりしている実装上の詳細が依然として数多く存在します。本記事は、既知の問題を網羅的に検証したものではありませんし、ほとんどのエンドユーザー（ドメイン所有者）は、こうした問題の多くに気づくことはめったにありません。しかし、dmarcianのような企業が のような企業が、毎日数十万もの個別のXMLデータファイルを受け取り、数万人の顧客に送られた数十億通の電子メールメッセージを代表するものです。この規模になると、問題の傾向は明らかになり、少数の顧客からの苦情でさえも懸念事項を浮き彫りにしています。本記事は、dmarcianがドメインの保護強化を支援する過程で遭遇する問題のいくつかを解説することを目的としています。
このESPが提供するデータに関する唯一の問題は、実際には送信されるデータの形式や品質にあるのではなく、データの送信先に関するDMARC仕様の制限に準拠していない点にあります。例えば、tomki.comのDMARCレコードを公開し、レポートを[email protected]に送信するよう指定した場合、これは好ましくない行為であり、不適切であるという点で意見が一致するでしょう。
仕様の策定者はこの問題を考慮し、DMARCデータプロバイダー（RUAおよび／またはRUFデータを送信するあらゆる主体）に対し、そのようなレポートの送信を明確に許可することを要件とした。 レポートを自身のドメイン内のアドレスに送信するよう指定するDMARCレコードは、当然のことであり、これ以上の確認は不要です。もしDMARCレコードがそのドメインの*外部*にあるドメイン内の受信者を指定している場合、DMARCレポート生成者は宛先ドメインに特別なレコードが存在するかを確認する必要があります。このレコードが存在して初めて、肯定的な許可が与えられることになります。
Googleがこの確認を行わないことの問題点は、報告が殺到してメールアドレスが溢れかえる可能性があるため、サービス拒否攻撃の手段として悪用される恐れがあることです。
シスコ・アイアンポート ESA
これはよく知られたシステムですが、ホスト型ソリューション環境（IPHMX）側と、クライアント環境におけるハードウェア設置側の双方において、DMARCレポートに関していくつかの深刻な問題を抱えています。
問題の一つは、レポート作成においてドメインとサブドメインが正しく集計されていないことです。ドメインのDMARCレコードは、そのレベルで独自のDMARCレコードを持たないサブドメインすべてに継承されます。つまり、独自のDMARCレコードを持たないすべてのサブドメインにおけるメールの送受信状況を詳細に記録したXMLデータが は トップレベルドメインと同じレポートに含まれるべきです。残念ながら、Cisco ESAはこれを行わないため、毎日多くの（場合によっては数千もの）余分なXMLファイルが生成されてしまいます。
もう1つ、より複雑な問題として、Cisco Email Security ApplianceにおけるDMARCデータの生成タイミングと、レポート内のデータ時刻の整合性が挙げられます。DMARC仕様では、生成され記録用アドレスに送信される日次データは、UTC時間の午前0時から午前0時までの24時間枠に準拠しなければならないと規定されています。 つまり、UTC時間において、同日の00:00から23:59:59までの期間を指します。これにより、ドメイン所有者は世界中のメールトラフィックに関するレポートを適切に管理することができます。Cisco ESAの問題点は、DMARCレポートをUTC時間に合わせる機能がないことです。すべてのレポートデータは、その特定のESAインスタンスで設定された時刻に基づく時間枠でのみ表示されます。
具体例を挙げてもう少し詳しく説明しましょう。ある不正なキャンペーンでは、ある国際企業のメールドメインを悪用し、米国向けの環境に500通、EU向けの環境に200通、さらにインド向けの環境に300通のメッセージを送信しています。ここでは、これらのメッセージがすべて、現地時間の設定が適用されたCisco ESAのホスト環境に受信されたというシナリオを想定します。これは通常通りの動作です。
- EUで受信された200件のメッセージは、主にUTC時間を基準として報告されます。
- 米国で受信された500件のメッセージは、UTC-5からUTC-8までの時刻で報告されます。
- インドで受信された300件のメッセージは、UTC+5:30の時刻で報告されます。
その結果、この詐欺メールキャンペーンは実際には10分未満しか続いていなかったにもかかわらず、UTC時間枠の要件を満たしていないDMARCレポーターから送信されたレポートによると、キャンペーンは2日間にわたり約24時間に及んだように見えた。悪用されたドメインの管理者は、そのドメインについて受け取ったレポートに基づいて、詐欺キャンペーンがどちらの日に実施されたのか、あるいは実際にその全期間にわたって行われたのかについて、判断に苦しむことになるだろう。
受信機が誤ったデータを送信している
想像以上に頻繁に、データの表現が事実上あるいは論理的に誤っている環境からのDMARCレポートを目にします。例えば、SPFの結果が「fail」であるにもかかわらず、DMARC-SPFポリシーの結果が「pass」となっている場合などです。定義上、DMARCポリシーの結果が「pass」となる唯一の条件は、SPFの結果が「pass」である場合のみです。
このような問題には、前述の論理エラーから、必須データの空白や欠落に至るまで、さまざまな種類があります。dmarcianは、ユーザーが認証を強化できるよう支援することを目的として、これらの報告元と連携し、実装上の問題を是正しています。連絡が取れない場合や報告上の問題が解決できない場合などには、当該ソースからのデータ取り込みを完全に停止することがあります。
データを生成しない受信機
受信機の問題点として最後に挙げられるのは、データやデータ生成に関する問題ではなく、むしろデータの欠如に関するものである。
DMARCは公開標準です（RFC 7489）であり、文字通り何百万ものドメイン所有者が、自身のドメインのメール通信の認証を強化するために活用しています。多くの場合、これらのドメイン所有者は、自身のドメインの不正利用に対するポリシー制限を公開するために、DMARCにおいて対策を講じています。こうした取り組みは、そのドメインからのメールであると称するメールを受信するあらゆる環境に多大なメリットをもたらします。メール認証の実績があること、さらに言えば公開された適用ポリシーがあることで、受信者は正当なメール通信と不正なメール通信を、はるかに確実に区別できるようになります。
メールトラフィックに適用されるメール認証基準（SPF、DKIM、DMARC）の設定や修正にドメイン所有者が費やす労力は、受信側の環境からのDMARCフィードバックに大きく依存しています。既知の不確実性はさておき、Google、Yahoo、すべてのCisco ESA環境、Rackspace、Comcast、Mail.ru、および その他 からのフィードバックは、こうした取り組みにおいて極めて貴重なものです。受信側の参加が増えれば増えるほど、メールはすべての人にとってより良いものになります。しかし、一方で、これらの認証基準を悪用し、エコシステムへの貢献を一切行わずに、自社の環境向けに認証サービスを提供している者も存在します。
この非協力的行為の最も顕著な例として、Proofpoint、MIMECast、Symantec.cloudが挙げられます。これらの各環境は、自環境へ送信されるメッセージに対してDMARC認証サービスを提供しているものの、ドメイン所有者に対してDMARCレポートを送信していません。これらの環境で実施されているとされるDMARC認証に関するDMARCレポートがなければ、ドメイン所有者は、自らが検証や強制措置を正しく行っているかどうかさえ確認することができません。
これらのサービスのいずれかをご利用のお客様は、DMARCレポートの提供を希望するドメインについて、各サービス提供者に連絡し、レポートの提供を依頼してください。
dmarcianは、DMARCに関する知識と理解を広めることで、電子メールの安全性向上に努めています。DMARCの導入に関するサポートが必要な場合は、義務や制約のないトライアルにご登録いただけます こちらから、義務や制約のないトライアルにご登録いただけます。
この件について議論を続けたいですか？ぜひdmarcianのフォーラムへお越しください。
