On 7/16/2014 11:30 AM, S Moonesamy wrote:
Domain-based Message Authentication, Reporting & Conformance (DMARC)
uses existing mail authentication technologies (SPF and DKIM) to
extend validation to the RFC5322.From field. DMARC uses DNS records
to add policy-related requests for receivers and defines a feedback
mechanism from receivers back to domain owners. This allows a domain
owner to advertise that mail can safely receive differential
handling, such as rejection, when the use of the domain name in the
From field is not authenticated. Existing deployment of DMARC has
demonstrated utility at internet scale, in dealing with significant
email abuse, and has permitted simplifying some mail handling
processes.
There are some mail services who provide mailboxes with mailing lists
impediments.
Yes, but how does (or should) your comment affect the draft charter text?
The existing base specification is being submitted as an Independent
Submission to become an Informational RFC.
In a message dated April 22, I commented as follows:
Section 16 describes IANA registry updates. I suggest contacting the
IETF Application Directors for information about the procedure to be
followed for the registry updates.
My reading of the sentence about "Informational RFC" (quoted above) is
that the IESG concluded that the base specification can be published
without any changes (see Point 4 or 5 in BCP 92).
The draft charter text only notes the fact of submission and says
nothing about the further processing that has, might or will take place.
The IESG assessment is part of the 'will'.
The working group will seek to preserve interoperability with the
installed base of DMARC systems, and provide detailed justification
for any non-interoperability. As the working group develops solutions
to deal with indirect mail flows, it will seek to maintain the
end-to-end nature of existing identifier fields in mail, in
particular avoiding solutions that require rewriting of originator
fields.
The last paragraph above sets a high bar for changes. As a note, some
mailing lists have already implemented a "via" rewrite.
Yes, it does set a high bar.
As for actions already taken by some operators, those certainly should
provide interesting input for consideration. However the mere fact of
those choices having been made does not mean that they are preferred or
even useful. That's what the working group will (I hope) consider.
Working group activities will pursue three tracks:
1. Addressing the issues with indirect mail flows
The working group will specify mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows, including deployed
behaviors of many different intermediaries, such as mailing list
managers, automated mailbox forwarding services, and MTAs that
perform enhanced message handling that results in message
modification. Among the choices for addressing these issues are:
- A form of DKIM signature that is better able to survive transit
through intermediaries.
- Collaborative or passive transitive mechanisms that enable an
intermediary to participate in the trust sequence, propagating
authentication directly or reporting its results.
What is the meaning of "collaborative or passive transitive mechanisms"?
Yes, it's a challenge to figure out how to word that concisely and
helpfully, given that the charter has already been criticized for being
too long.
So, the intent of the phrase is to distinguish between mechanisms that
might provide author-to-recipient utility, either due to a
'collaborative' effort by both the author's operator and the
intermediary, or solely by the author's operator, with the intermediary
instead being 'passive'.
An example would be a mechanism that requires the intermediary to add
its own signature, versus one that might survive the intermediary, even
without the intermediary taking special action.
I'll defer to the DNS experts on the matter of the "public suffix".
That's the intent of the charter, except to the extent that the dmarc wg
might develop some useful input to a separate public suffix effort.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net