mechanism because it is a required message header field and therefore
guaranteed to be present in compliant messages, and most Mail User
Agents (MUAs) represent the RFC5322.From field as the originator of
the message and render some or all of this header field’s content to
end users.
また、ほとんどのメールユーザーエージェント(MUA)がメッセージの発信元としてRFC5322.Fromフィールドを提示し、このヘッダフィールドの内容の一部または全部をエンドユーザーに表示するので、DMARCのメカニズムの主な識別子として選定された。
Thus, this field is the one used by end users to identify the source
of the message and therefore is a prime target for abuse. Many
high-profile email sources, such as email service providers, require
that the sending agent have authenticated before email can be
generated. Thus, for these mailboxes, the mechanism described in
this document provides recipient end users with strong evidence that
the message was indeed originated by the agent they associate with
that mailbox, if the end user knows that these various protections
have been provided.
このため、RFC5322.Fromフィールドは、メッセージの発信元を識別するためにエンドユーザーによって使用されるため、不正使用の主な対象となる。電子メールサービスプロバイダなどの多くの重要な電子メールの発信元では、電子メールの生成前にメール送信エージェントで認証していることが必要である。したがって、このような発信元のメールボックスに対して、受信者のエンドユーザーがさまざまな保護が与えられていることを知っている場合、本文書に記載するメカニズムは、エンドユーザーがそのメールボックスに関連付けたエージェントによってメッセージが実際に生成されたという有力な証拠をエンドユーザーに提供する。
Domain names in this context are to be compared in a case-insensitive
manner, per [DNS-CASE].
ここで言うドメイン名は、[DNS-CASE]に従って大文字と小文字を区別しない方法で比較される。
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per [MAIL], particularly one with a
malformed, absent, or repeated RFC5322.From field, since in that case
there is no reliable way to determine a DMARC policy that applies to
the message. Accordingly, DMARC operation is predicated on the input
being a valid RFC5322 message object, and handling of such
non-compliant cases is outside of the scope of this specification.
Further discussion of this can be found in Section 6.6.1.
[MAIL]では有効でないメッセージ、特に、RFC5322.Fromフィールドが変形、欠落、重複しているメッセージに対しては、メッセージに適用するDMARCポリシーを決めるための信頼できる方法がないため、識別子アライントは成立しないことに留意することは重要です。したがって、DMARCの運用において入力が有効なRFC5322メッセージオブジェクトであることが前提となり、この前提が満たされない場合の処理は、本仕様の範囲外である。詳細は、6.6.1節を参照していただきたい。
Each of the underlying authentication technologies that DMARC takes
as input yields authenticated domains as their outputs when they
succeed. From the perspective of DMARC, each can be operated in a
“strict” mode or a “relaxed” mode. A Domain Owner would normally
select strict mode if it wanted Mail Receivers to apply DMARC
processing only to messages bearing an RFC5322.From domain exactly
matching the domains those mechanisms will verify. Relaxed mode can
be used when the operator also wishes to affect message flows bearing
subdomains of the verified domains.
DMARCが入力として取り込む基本の認証技術ではいずれも、認証に成功した場合に、認証されたドメインが出力として得られる。DMARCの観点からすれば、基本の認証技術を「strict」モードまたは「relaxed」モードでそれぞれ運用することができる。メール受信者には、基本の認証技術のメカニズムが検証するドメインと完全に一致するRFC5322.Fromドメインのメッセージに対してのみDMARC処理を適用してもらいたい場合、ドメイン所有者は通常、strictモードを選択する。また、運用者は、検証したドメインのサブドメインのメッセージフローに適用したい場合は、relaxedモードを使用することができる。
3.1.1. DKIM-Authenticated Identifiers
DMARC permits Identifier Alignment, based on the result of a DKIM
authentication, to be strict or relaxed. (Note that these are not
related to DKIM’s “simple” and “relaxed” canonicalization modes.)
3.1.1. DKIM認証識別子
DMARCでは、DKIM認証結果に基づいて、識別子アライメントの判定モードをstrictまたはrelaxedにすることが可能である。(DKIMの「simple」および「relaxed」の正規化モードとは無関係であることに留意していただきたい。)
[Page 9]
| 《PREV》 |