A.2. Method Exclusion
It was suggested that DMARC include a mechanism by which a Domain
Owner could tell Message Receivers not to attempt validation by one
of the supported methods (e.g., “check DKIM, but not SPF”).
A.2 認証方法の除外
ドメイン所有者が、サポートする方法の片方で認証を試みない(例えば、「DKIM判定は行うがSPF判定は行わない」)ようにメール受信者に伝えることが可能なメカニズムをDMARCに含めることが提案されてきた。
Specifically, consider a Domain Owner that has deployed one of the
technologies, and that technology fails for some messages, but such
failures don’t cause enforcement action. Deploying DMARC would cause
enforcement action for policies other than “none”, which would appear
to exclude participation by that Domain Owner.
具体的には、あるドメイン所有者が、その技術の1つを採用し、一部のメッセージがその技術による判定に失敗しても、その失敗によってメッセージに対して特に処理を行わないケースを考える。ここでDMARCを展開すると、「none」以外のポリシーに対して処理を行うことになり、ドメイン所有者による認証方法の適用が除外されるように見える。
The DMARC development team evaluated the idea of policy exception
mechanisms on several occasions and invariably concluded that there
was not a strong enough use case to include them. The specific
target audience for DMARC does not appear to have concerns about the
failure modes of one or the other being a barrier to DMARC’s
adoption.
DMARC開発チームは、ポリシーの除外メカニズムの考えについて何度も評価したが、このメカニズムが必要になるほどの強力な使用事例は存在しないという結論に常に至った。DMARCの特定の対象者は、一方または他方の失敗モードがDMARCの採用の障壁となることについて懸念しているようには見えない。
In the scenario described above, the Domain Owner has a few options:
1. Tighten up its infrastructure to minimize the failure modes of
the single deployed technology.
2. Deploy the other supported authentication mechanism, to offset
the failure modes of the first.
3. Deploy DMARC in a reporting-only mode.
上に記載するシナリオでは、ドメイン所有者にはいくつかの選択肢がある。
1. インフラを強化して、採用した単一の技術の失敗モードを最小限に抑える。
2. サポートするもう一方の認証メカニズムを展開して、一方の失敗モードを補完する。
3. 報告のみのモードでDMARCを展開する。
A.3. Sender Header Field
It has been suggested in several message authentication efforts that
the Sender header field be checked for an identifier of interest, as
the standards indicate this as the proper way to indicate a
re-mailing of content such as through a mailing list. Most recently,
it was a protocol-level option for DomainKeys, but on evolution to
DKIM, this property was removed.
A.3. Senderヘッダフィールド
RFC標準が、メーリングリストなどによって内容の再配信を指示する適切な方法としてSenderヘッダフィールドを指示していることから、対象の識別子に関してSenderヘッダフィールドの判定を行うことがいくつかのメッセージ認証の取り組みで提案されてきた。これはごく最近まで、DomainKeysのプロトコルレベルのオプションであったが、DKIMの進化によってこの属性は削除された。
The DMARC development team considered this and decided not to include
support for doing so, for the following reasons:
1. The main user protection approach is to be concerned with what
the user sees when a message is rendered. There is no consistent
behavior among MUAs regarding what to do with the content of the
Sender field, if present. Accordingly, supporting checking of
the Sender identifier would mean applying policy to an identifier
DMARC開発チームは、これを検討した結果、以下の理由でこのチェックを行うことをサポートしないと決定した。
1. ユーザーを保護する主な手法は、メッセージを受信した際にユーザーが目にするものに注意を払うことである。Senderフィールドが存在している場合、その内容で何をすべきかに関して、MUAは一貫した動作をしない。したがって、Sender識別子の判定をサポートすることは、
[Page 53]
| 《PREV》 |