サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

page-59


The Domain Owner accomplishes this by constructing a policy record
indicating that:


o The version of DMARC being used is “DMARC1″ (“v=DMARC1″)


o Receivers should not alter how they treat these messages because
of this DMARC policy record (“p=none”)

これらは、ドメイン所有者が、以下のことを示すポリシーレコードを構成することによって実現する。

o 使用するDMARCのバージョンは「DMARC1」(「v=DMARC1」)である。

o メール受信者は、このDMARCポリシーレコード(「p=none」)によって、これらのメッセージの処理方法を変更するべきでない。


o Aggregate feedback reports should be sent via email to the address
“dmarc-feedback@example.com”
(“rua=mailto:dmarc-feedback@example.com”)


o All messages from this Organizational Domain are subject to this
policy (no “pct” tag present, so the default of 100% applies)

o 集約フィードバックレポートは、電子メールでアドレス「dmarc-feedback@example.com」(「rua=mailto:dmarc-feedback@example.com」)に送信するべきである。

o この組織ドメインからのメッセージはすべて、このポリシーが適用される(「pct」タグが存在しない場合、デフォルトで100%適用される)。


The DMARC policy record might look like this when retrieved using a
common command-line tool:


     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

DMARCポリシーレコードは、一般的なコマンドラインツールを使用して読み出すと、以下のようになると思われる。

     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"


To publish such a record, the DNS administrator for the Domain Owner
creates an entry like the following in the appropriate zone file
(following the conventional zone file format):

このようなレコードを公開するために、ドメイン所有者のDNS運用者は、適切なゾーンファイルに以下のようなエントリを(既存のゾーンファイル形式の後に)生成する。


; DMARC record for the domain example.com


     _dmarc  IN TXT ( "v=DMARC1; p=none; "
                      "rua=mailto:dmarc-feedback@example.com" )

; ドメインexample.comのDMARCレコード

     _dmarc  IN TXT ( "v=DMARC1; p=none; "
                      "rua=mailto:dmarc-feedback@example.com" )

B.2.2. Entire Domain, Monitoring Only, Per-Message Reports


The Domain Owner from the previous example has used the aggregate
reporting to discover some messaging systems that had not yet
implemented DKIM correctly, but they are still seeing periodic
authentication failures. In order to diagnose these intermittent
problems, they wish to request per-message failure reports when
authentication failures occur.

B.2.2. ドメイン全体、監視のみ、メッセージ毎にレポート

上記の例のドメイン所有者は、集約報告を使用して、DKIMを正しく実装していないメッセージシステムをいくつかを検索するが、一定周期で認証失敗となる。これらの断続的な問題を診断するため、認証失敗の場合はメッセージ単位失敗レポートの要求を望むとする。


Not all Receivers will honor such a request, but the Domain Owner
feels that any reports it does receive will be helpful enough to
justify publishing this record. The default per-message report
format ([AFRF]) meets the Domain Owner’s needs in this scenario.

メール受信者がすべてそのような要求を受け付けるわけではないが、ドメイン所有者は、どんなレポートでも受信すれば、このレコードの公開を正当化するのに十分有用なものではないかと思うようになる。メッセージ単位レポートのデフォルトフォーマット([AFRF])は、このシナリオでのドメイン所有者のニーズを満たす。

[Page 59]

《PREV》
1  2  3  5  7  12  15  16  28  39  42  46  49  52  56  60  73

 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先