Draft: draft-ietf-dmarc-dmarcbis-01

Commentary: I do n't agree with changing RFC5322.From to " visible From header . " It 's terminology we use in all our mail RFCs these days . 
 Ask   and see what he says ( and stand back . ) 
 Fair enough , but by the time we publish , RFC 5322 may be obsolete due to the work being done in emailcore , to be replaced by RFC XXXXX . This was the point of the change . What do you suggest as a better alternative ? 
 Ask  . Maybe he 'll update his architecture document , maybe we 'll just leave it alone since the From : in RFC whatever will still be semantically as the one in RFC 5322 . Regards ,   ,   , Trumansburg NY Please consider the environment before reading this e - mail . 
 I 'll change it back to RFC5322.From , and open a future ticket to change it when RFC5322bis is released .
DMARC permits the owner of an author's domain name to enable
validation of the domain's use, to indicate the implication of failed
validation, and to request reports about use of the domain name.
Mail receiving organizations can use this information when evaluating
handling choices for incoming mail.
DMARC permits the owner of an email author's domain name to enable
validation of the domain's use, to indicate the implication of failed
validation, and to request reports about use of the domain name.
Mail receiving organizations can use this information when evaluating
handling choices for incoming mail.
The Sender Policy Framework (RFC7208) and DomainKeys Identified Mail
(RFC6376) protocols provide domain-level authentication which is not
directly associated with the RFC5322.From domain, and DMARC builds on
those protocols.  Using DMARC, Domain Owners that originate email can
publish a DNS TXT record with their email authentication policies,
preferred handling for mail that fails authentication checks, and
request reports about use of the domain name.
As with SPF and DKIM, DMARC authentication checks result in verdicts
of "pass" or "fail".  A DMARC pass verdict requires not only that SPF
or DKIM pass for the message in question, but also that the domain
validated by the SPF or DKIM check is aligned with the domain in the
RFC5322.From header.  In the DMARC protocol, two domains are said to
be "in alignment" if they have the same Organizational Domain
(a.k.a., relaxed alignment) or they are identical (a.k.a., strict
alignment).
A DMARC pass result indicates only that the RFC5322.From domain has
been authenticated in that message; there is no explicit or implied
value assertion attributed to a message that receives such a verdict.
A mail-receiving organization that performs a DMARC validation check
on inbound mail can choose to use the result and the published
assessment by the originating domain for message handling to inform
its mail handling decision for that message.  For a mail-receiving
organization supporting DMARC, a message that passes validation is
part of a message stream that is reliably associated with the domain
owner.  Therefore reputation assessment of that stream by the mail-
receiving organization does not need to be encumbered by accounting
for unauthorized use of the domain.  A message that fails this
validation cannot reliably be associated with the aligned domain and
its reputation.
The Sender Policy Framework (RFC7208) and DomainKeys Identified Mail
(RFC6376) protocols provide domain-level authentication which is not
directly associated with the domain in the visible From: header, and
DMARC builds on those protocols.  Using DMARC, Domain Owners that
originate email can publish a DNS TXT record with their email
authentication policies, preferred handling for mail that fails
authentication checks, and request reports about email use of the
domain name.
As with SPF and DKIM, DMARC authentication checks result in verdicts
of "pass" or "fail".  A DMARC pass verdict requires not only that SPF
or DKIM pass for the message in question, but also that the domain
validated by the SPF or DKIM check is aligned with the domain in the
visible From: header.  In the DMARC protocol, two domains are said to
be "in alignment" if they have the same Organizational Domain
(a.k.a., relaxed alignment) or they are identical (a.k.a., strict
alignment).
A DMARC pass result indicates only that the domain in the visible
From: header has been authenticated in that message; there is no
explicit or implied value assertion attributed to a message that
receives such a verdict.  A mail-receiving organization that performs
a DMARC validation check on inbound mail can choose to use the result
and the published assessment by the originating domain for message
handling to inform its mail handling decision for that message.  For
a mail-receiving organization supporting DMARC, a message that passes
validation is part of a message stream that is reliably associated
with the domain owner.  Therefore reputation assessment of that
stream by the mail-receiving organization does not need to be
encumbered by accounting for unauthorized use of the domain.  A
message that fails this validation cannot reliably be associated with
the aligned domain and its reputation.
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email.  In particular, it does not address the
use of visually similar domain names ("cousin domains") or abuse of
the RFC5322.From human-readable <display-name>.
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email.  In particular, it does not address the
use of visually similar domain names ("cousin domains") or abuse of
the visible From: header human-readable <display-name>.
DMARC authenticates use of the RFC5322.From domain by requiring that
it match (be aligned with) an Authenticated Identifier.  The
RFC5322.From domain was selected as the central identity of the DMARC
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.
DMARC authenticates use of the visible From: header domain by
requiring that it match (be aligned with) an Authenticated
Identifier.  The visible From: header domain was selected as the
central identity of the DMARC 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
visible From: header field as the originator of the message and
render some or all of this header field's content to end users.
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per RFC5322, 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 extract-author-domain.
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.
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per RFC5322, particularly one with a
malformed, absent, or repeated visible From: header 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 extract-
author-domain.
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 visible From: header 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.
In relaxed mode, the Organizational Domains of both the RFC6376-
authenticated signing domain (taken from the value of the "d=" tag in
the signature) and that of the RFC5322.From domain must be equal if
the identifiers are to be considered aligned.  In strict mode, only
an exact match between both of the Fully Qualified Domain Names
(FQDNs) is considered to produce Identifier Alignment.
To illustrate, in relaxed mode, if a validated DKIM signature
successfully verifies with a "d=" domain of "example.com", and the
RFC5322.From address is "alerts@news.example.com", the DKIM "d="
domain and the RFC5322.From domain are considered to be "in
alignment".  In strict mode, this test would fail, since the "d="
domain does not exactly match the FQDN of the address.
In relaxed mode, the Organizational Domains of both the RFC6376-
authenticated signing domain (taken from the value of the "d=" tag in
the signature) and that of the visible From: header domain must be
equal if the identifiers are to be considered aligned.  In strict
mode, only an exact match between both of the Fully Qualified Domain
Names (FQDNs) is considered to produce Identifier Alignment.
To illustrate, in relaxed mode, if a validated DKIM signature
successfully verifies with a "d=" domain of "example.com", and the
visible From: header address is "alerts@news.example.com", the DKIM
"d=" domain and the visible From: header domain are considered to be
"in alignment".  In strict mode, this test would fail, since the "d="
domain does not exactly match the FQDN of the address.
In relaxed mode, the RFC7208-authenticated domain and RFC5322.From
domain must have the same Organizational Domain.  In strict mode,
only an exact DNS domain match is considered to produce Identifier
Alignment.
For example, if a message passes an SPF check with an
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
portion of the RFC5322.From field contains "payments@example.com",
the Authenticated RFC5321.MailFrom domain identifier and the
RFC5322.From domain are considered to be "in alignment" in relaxed
mode, but not in strict mode.  In order for the two identifiers to be
considered "in alignment" in strict mode, the domain parts would have
to be identical.
In relaxed mode, the RFC7208-authenticated domain and visible From:
header domain must have the same Organizational Domain.  In strict
mode, only an exact DNS domain match is considered to produce
Identifier Alignment.
For example, if a message passes an SPF check with an
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
portion of the visible From: header field contains
"payments@example.com", the Authenticated RFC5321.MailFrom domain
identifier and the visible From: header domain are considered to be
"in alignment" in relaxed mode, but not in strict mode.  In order for
the two identifiers to be considered "in alignment" in strict mode,
the domain parts would have to be identical.
If in the future DMARC is extended to include the use of other
authentication mechanisms, the extensions will need to allow for
domain identifier extraction so that alignment with the RFC5322.From
domain can be verified.
If in the future DMARC is extended to include the use of other
authentication mechanisms, the extensions will need to allow for
domain identifier extraction so that alignment with the visible From:
header domain can be verified.
DMARC's filtering function is based on whether the RFC5322.From field
domain is aligned with (matches) an authenticated domain name from
SPF or DKIM.  When a DMARC policy is published for the domain name
found in the RFC5322.From field, and that domain name is not
validated through SPF or DKIM, the handling of that message can be
affected by that DMARC policy when delivered to a participating
receiver.
DMARC's filtering function is based on whether the visible From:
header field domain is aligned with (matches) an authenticated domain
name from SPF or DKIM.  When a DMARC policy is published for the
domain name found in the visible From: header field, and that domain
name is not validated through SPF or DKIM, the handling of that
message can be affected by that DMARC policy when delivered to a
participating receiver.
One of the most obvious points of security scrutiny for DMARC is the
choice to focus on an identifier, namely the RFC5322.From address,
which is part of a body of data that has been trivially forged
throughout the history of email.
The absence of a single, properly formed RFC5322.From field renders
the message invalid.  Handling of such a message is outside of the
scope of this specification.
One of the most obvious points of security scrutiny for DMARC is the
choice to focus on an identifier, namely the visible From: header
address, which is part of a body of data that has been trivially
forged throughout the history of email.
The absence of a single, properly formed visible From: header field
renders the message invalid.  Handling of such a message is outside
of the scope of this specification.
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-
effort attempt to adhere to the Domain Owner's published DMARC policy
when a message fails the DMARC test.  Since email streams can be
complicated (due to forwarding, existing RFC5322.From domain-spoofing
services, etc.), Mail Receivers MAY deviate from a Domain Owner's
published policy during message processing and SHOULD make available
the fact of and reason for the deviation to the Domain Owner via
feedback reporting, specifically using the "PolicyOverride" feature
of the aggregate report (see the DMARC reporting documents).
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-
effort attempt to adhere to the Domain Owner's published DMARC policy
when a message fails the DMARC test.  Since email streams can be
complicated (due to forwarding, existing visible From: header domain-
spoofing services, etc.), Mail Receivers MAY deviate from a Domain
Owner's published policy during message processing and SHOULD make
available the fact of and reason for the deviation to the Domain
Owner via feedback reporting, specifically using the "PolicyOverride"
feature of the aggregate report (see the DMARC reporting documents).
Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named "_dmarc".  For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com".  Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an RFC5322.From domain of
"example.com" would issue a TXT query to the DNS for the subdomain of
"_dmarc.example.com".  The DNS-located DMARC preference data will
hereafter be called the "DMARC record".
Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named "_dmarc".  For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com".  Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an visible From: header
domain of "example.com" would issue a TXT query to the DNS for the
subdomain of "_dmarc.example.com".  The DNS-located DMARC preference
data will hereafter be called the "DMARC record".
The domain in the RFC5322.From field is extracted as the domain to be
evaluated by DMARC.  If the domain is encoded with UTF-8, the domain
name must be converted to an A-label, as described in Section 2.3 of
RFC5890, for further processing.
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge.  The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.
The domain in the visible From: header field is extracted as the
domain to be evaluated by DMARC.  If the domain is encoded with UTF-
8, the domain name must be converted to an A-label, as described in
Section 2.3 of RFC5890, for further processing.
The case of a syntactically valid multi-valued visible From: header
field presents a particular challenge.  The process in this case is
to apply the DMARC check using each of those domains found in the
visible From: header field as the Author Domain and apply the most
strict policy selected among the checks that fail.
For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an RFC5322.From field
containing "foo@example.com" that can pass both authentication and
the DMARC check against "example.com".
For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an visible From: header field
containing "foo@example.com" that can pass both authentication and
the DMARC check against "example.com".
A common attack in messaging abuse is the presentation of false
information in the display-name portion of the RFC5322.From field.
For example, it is possible for the email address in that field to be
an arbitrary address or domain name, while containing a well-known
name (a person, brand, role, etc.) in the display name, intending to
fool the end user into believing that the name is used legitimately.
The attack is predicated on the notion that most common MUAs will
show the display name and not the email address when both are
available.
A common attack in messaging abuse is the presentation of false
information in the display-name portion of the visible From: header
field.  For example, it is possible for the email address in that
field to be an arbitrary address or domain name, while containing a
well-known name (a person, brand, role, etc.) in the display name,
intending to fool the end user into believing that the name is used
legitimately.  The attack is predicated on the notion that most
common MUAs will show the display name and not the email address when
both are available.