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:*todd.h...@valimail.com <mailto:todd.h...@valimail.com>
*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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
