Some comments and suggestions...
On 11/19/2020 2:55 PM, Todd Herr wrote:
This thread hasn't generated any discussion or momentum yet, and I
know that's not because y'all have found the proposed text for the
Abstract and Introduction to be acceptable, so I'm going to add the
text to this thread and see where the discussion leads.
----------------------------------------------- cut here
----------------------------------------------------
Abstract
This document describes the Domain-based Message Authentication,
Reporting, and Conformance (DMARC) protocol.
DMARC is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting.Mail-receiving
organizations can in turn use these expressions of policies and
preferences to inform their mail handling decisions should they
choose to do so.
Alternative second par, to improve focus and provide more complete,
initial description:
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 disposition choices for incoming mail.
I suggest this introductory text focus less on low-level technical
details or references, and more on setting the stage, by characterizing
functional benefits and, perhaps, very general statements about the
approach. This is the place to build market demand, by focusing on the
why and what, not the how.
This document obsoletes RFC 7489.
[...]
1.Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
<https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis>
(https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
<https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis>)
The Sender Policy Framework ([RFC7208]) and DomainKeys Identified
Mail ([RFC6376]) protocols provide domain-level authentication, and
...authentication, which is not directly associated to the rfc5322.From
field domain name, and DMARC...
DMARC builds on these protocols.DMARC is designed to give
ADminstrative Management Domains (ADMDs) that originate email
theability to publish in a DNS TXT record their email authentication
policies, specify preferred handling for mail that fails
authentication checks, and request reports about mail purportedly
originated by the ADMD, as determined by the RFC5322.From header in
the message.
Repeating from the Abstract:
DMARC Builds on these protocols. 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 disposition choices for
incoming mail.
The 'domain' in ADMD is not the same as in 'domain name' and, arguably,
DMARC has nothing to do with ADMDs, but only with domain names. This is
an important distinction. The linkage between the two comes from
operational arrangement, not anything inherent in DMARC. I'm not sure
how to reflect this fact in the text. /d
btw, use of vocabulary like ADMD changes the requirement for the
reference to RFC 5598, in the Terminology section. The current text is
a casual suggestion. It needs to be something like:
References and terminology that are not defined in this
specification are drawn from RFC 5598.
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
perhaps add reference to Section 3.1, for definition of alignment,
rather than do a definition here. Having something defined more than
once in a specification can get problematic.
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 verdict asserts only that the RFC5322.From domain has
verdict -> resut
asserts -> indicates
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 DMARC validation checks
on inbound mail can choose to use the results and the preferences
expressed by the originating domain for message disposition to inform
its mail handling decision for that message.For messages that pass
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 disposition to inform
its mail handling decision for that message.
trying to move away from policy or directive
(also changed to singular; it seems to make specification language
easier to write...)
DMARC validation checks, the mail-receiving organization can be
confident in applying handling based on its known history for
similarly authenticated messages, whereas messages that fail such
checks cannot be reliably associated with a domain with a history of
sending DMARC-validated messages.
For mail-receiving organization supporting DMARC, a message that
pass 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 also describes a reporting framework in which mail-receiving
domains can generate regular reports containing data about messages
seen that claim to be from domains that publish DMARC policies, and
send those reports to the ADMD as requested by its DMARC policy
record.
ADMD -> address
While another use of ADMD is appealing, the construct in this part of
DMARC is really just an address. Any address.
Experience with DMARC has revealed some issues of interoperability
with email in general that require due consideration before
deployment, particularly with configurations that can cause mail to
be rejected.These are discussed in Section 9.
d/
--
Dave Crocker
[email protected]
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
[email protected]
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
