Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt)

[Dave Crocker <[e-mail]>]

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
[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[e-mail]