Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[Dave Crocker <[e-mail]>]

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