existing privacy policy provisions. For some providers, aggregate
reporting and failed-message reporting are viewed as a function
similar to complaint reporting about spamming or phishing and are
treated similarly under the privacy policy. Report generators (i.e.,
Mail Receivers) are encouraged to review their reporting limitations
under such policies before enabling DMARC reporting.
一部のプロバイダーに関して、集約報告と失敗メッセージ報告は、スパミングまたはフィッシングに関する苦情報告と同じような機能とみなされ、プライバシーポリシーに基づいて同じように処理される。レポート作成者(すなわち、メール受信者)には、DMARC報告を適用する前に、そのようなポリシーによる報告の制限を検討することを推奨する。
9.2. Report Recipients
A DMARC record can specify that reports should be sent to an
intermediary operating on behalf of the Domain Owner. This is done
when the Domain Owner contracts with an entity to monitor mail
streams for abuse and performance issues. Receipt by third parties
of such data may or may not be permitted by the Mail Receiver’s
privacy policy, terms of use, or other similar governing document.
Domain Owners and Mail Receivers should both review and understand if
their own internal policies constrain the use and transmission of
DMARC reporting.
9.2. レポート受信者
DMARCレコードは、ドメイン所有者の代わりに管理する代理者にレポートを送信すべきであることを指定することができる。これは、ドメイン所有者が不正使用および性能問題に関してメールストリームを監視する契約をエンティティと結ぶ場合に行う。そのようなデータのサードパーティによる受信は、メール受信者のプライバシーポリシー、利用規約または同様の他の管理書類によって許可してもよいし、許可しなくてもよい。ドメイン所有者およびメール受信者は、自身の内部ポリシーによって、DMARC報告の使用および送信を抑制するか否かを検討し、把握するべきである。
Some potential exists for report recipients to perform traffic
analysis, making it possible to obtain metadata about the Receiver’s
traffic. In addition to verifying compliance with policies,
Receivers need to consider that before sending reports to a third
party.
レポート受信者がトラフィック解析を実行する何らか可能性がある場合は、レポート受信者のトラフィックに関するメタデータを取得することが可能となる。メール受信者は、ポリシーへの準拠を検証するほか、レポートをサードパーティに送信する前にデータ漏洩について検討する必要がある。
10. Other Topics
This section discusses some topics regarding choices made in the
development of DMARC, largely to commit the history to record.
10. その他
本節は、主に履歴を記録するために、DMARCの開発で行われた選択に関するテーマについていくつか記載する。
10.1. Issues Specific to SPF
Though DMARC does not inherently change the semantics of an SPF
policy record, historically lax enforcement of such policies has led
many to publish extremely broad records containing many large network
ranges. Domain Owners are strongly encouraged to carefully review
their SPF records to understand which networks are authorized to send
on behalf of the Domain Owner before publishing a DMARC record.
10.1. SPF特有の問題
DMARCは、SPFポリシーレコードのセマンティクスを本質的には変更しない。歴史的にSPFポリシーを緩く実施することによって、大規模ネットワーク範囲を含むきわめて範囲の広いレコードが多く公開されるようになっていた。ドメイン所有者には、DMARCレコードを公開する前に、どのネットワークにドメイン所有者の代わりに送信を許可しているのかを把握するために、SPFレコードを慎重に検討することを強く推奨する。
Some receiver architectures might implement SPF in advance of any
DMARC operations. This means that a “-” prefix on a sender’s SPF
mechanism, such as “-all”, could cause that rejection to go into
effect early in handling, causing message rejection before any DMARC
processing takes place. Operators choosing to use “-all” should be
aware of this.
一部のメール受信者のアーキテクチャは、DMARC処理の前にSPFを実行する可能性がある。これは、「-all」などの送信者のSPFのメカニズムの接頭文字「-」によって、メッセージ拒否を処理の早い段階で実行できることを意味し、DMARC処理を行う前にメッセージが拒否される。「-all」の使用を選択する運用者は、これに注意するべきである。
[Page 39]
| 《PREV》 |