Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Alessandro Vesely <[e-mail]>]

Todd,

does your message assume that the relevant tickets are all accepted as valid 
indications to alter the spec?  In particular, tickets #52 and #75 have never 
been discussed on list. I'd guess they'll have to be discussed in their own 
threads.

Discussing the resulting text before those tickets entails, for example, noting 
the cumbersomeness of the locution "severity of concern" where something like 
"desired disposition" might seem more immediate.  In fact, ticket #85 was only 
discussed as a side effect of ticket #39, where the consensus, IIRC, was to 
keep the existing policy names while wavering about how to describe them.

The term RFC5322.From is consistently used, notwithstanding ticket #96.  For an 
alternative, let me attempt to define DMARC in terms of its acronym:

    The Domain-based Message Authentication, Reporting, and Conformance (DMARC)
    protocol recognizes the prevailing importance of the domain appearing in the
    From: header field of email messages.  That domain name will be called the
    Main Identifier in this document.  DMARC leverages the Sender Policy
    Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols
    by focusing the authentication mechanisms they provide toward the Main
    Identifier.  The Domain Owners corresponding to the Main Identifier are
    endowed with the possibility to receive feedback reports about
    authentication results at receivers.  Finally, receivers are provided with
    the Domain Owners' desiderata about messages that fail authentication, which
    receivers may or may not decide to conform to.

jm2c
Ale
-- 



On Wed 05/May/2021 20:48:51 +0200 Todd Herr wrote:
> Greetings.
> 
> This thread will be used to track discussion of the proposed text for the 
> Introduction section of draft-ietf-dmarc-dmarcbis-01.
> 
> The proposed text was influenced not only by the original text from 
> draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and 108. 
> Rather than trying to track changes to the Introduction section through all six 
> of those tickets, a new one (Ticket 113 
> <https://trac.ietf.org/trac/dmarc/ticket/113>) has been opened.
> 
> The request from the design team/editors for this ticket is as follows:
> 
>     If you object to some or all of the proposed text, please communicate the
>     part(s) to which you object, and propose replacement text for those part(s).
> 
> We would like to achieve rough consensus on this section of text by Friday, May 21.
> 
> Current proposed text follows, and side-by-side diffs with version -00 can be 
> found here 
> <https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-dmarcbis-00&url2=draft-ietf-dmarc-dmarcbis-01&difftype=--html> 
> 
> 
> ------------------------------------begin current proposed text 
> -----------------------------------
> 1. Introduction
> 
> 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, state their level of concern for mail that fails
> 
> authentication checks, and request reports about email use of the
> 
> domain name.Similarly, Public Suffix Operators (PSOs) may do the
> 
> same for PSO Controlled Domain Names and non-existent subdomains of
> 
> the PSO Controlled 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 RFC5322.From
> 
> domain.In the DMARC protocol, two domains are said to be "in
> 
> alignment" if they have the same Organizational Domain.
> 
> 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
> 
> severity of concern expressed by the Domain Owner or PSO for
> 
> authentication failures 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 and/or any, some, or all of the
> 
> Authenticated Identifiers.Therefore, reputation assessment of that
> 
> stream by the mail-receiving organization does not need to be
> 
> encumbered by accounting for unauthorized use of any domains.A
> 
> message that fails this validation cannot reliably be associated with
> 
> the Domain Owner's domain and its reputation.
> 
> DMARC, in the associated [DMARC-Aggregate-Reporting] and
> 
> [DMARC-Failure-Reporting] documents, 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 one or
> 
> more addresses as requested by the Domain Owner's or PSO's DMARC
> 
> policy record.
> 
> 
> 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.
> -------------------------------------end current proposed text 
> -----------------------------------
> 
> Thank you for your time.
> 
> -- 
> 
> *Todd Herr*| Sr. Technical Program Manager
> *e:*[e-mail] <mailto:[e-mail]>
> *m:*703.220.4153
> 
> This email and all data transmitted with it contains confidential and/or 
> proprietary information intended solely for the use of individual(s) authorized 
> to receive it. If you are not an intended and authorized recipient you are 
> hereby notified of any use, disclosure, copying or distribution of the 
> information included in this transmission is prohibited and may be unlawful. 
> Please immediately notify the sender by replying to this email and then delete 
> it from your system.
> 
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>