On 3/13/2018 9:42 AM, Dave Crocker wrote:
On 3/12/2018 6:57 PM, Barry Leiba wrote:
Not all 25 minutes are for that; that is included in the time slot,
along with anything else we put into "next steps".
...
I do expect that we'll discuss "path toward a Proposed Standard
version of DMARC," and I'll put that into the "next steps" section on
the next update to the agenda.

I suggest broaching this topic here and now, so the agenda entry can show something other than an off-charter draft.

Wise choice. +1



To prime that pump...


   Phase II:

      Specification of DMARC improvements to support indirect
mail flows

1.  Besides ARC, are there other wg efforts that should be pursued to satisfy this?

   ARC targets intermediary action in mail that originated with a DMARC-satisfying configuration.  ARC does not attend to mail that starts without that.  That is, mail starting from an independent third party source, such as a kiosk.


      Draft Guide on DMARC Usage

Current version is -04, so this charter item appears to be satisfied.


   Phase III:

      Review and refinement of the DMARC specification

Is there technical work on the base specification that would improve it?

     One would be a spec revision to deal with ARC.  Does DMARC still 'fail'?  Yet the whole point of ARC is to create the possibility of still getting delivered, in spite of this.

My position on this is that the decision by a validator/mailbox provider to use ARC and accept mail that would otherwise fail DMARC falls under the heading of "local policy". There does not need to be a spec revision to deal with ARC from this perspective. A sending domain publishing a DMARC policy is expressing it's wishes, not making demands (it cannot enforce). This is true with respect to any local policy a validator/mailbox provider implements.


    And from a note I posted last August:  "BTW, the DMARC spec uses the terms 'pass' and 'fail' with respect to the underlying authentication mechanisms of DKIM and SPF. It also uses it within the context of DMARC processing, itself, but it does not define what those terms mean, in that context.  Beyond reference to DMARC 'policy' records, text in the specs that talk about processing DMARC policy is similarly implicit, rather than explicit. The only clear, explicit directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy."


I need to think on this a bit more and go re-read the spec before formulating a response.


      Completion of Guide on DMARC Usage

What will it take to complete this doc?

     One example would be a spec revision effort that targets clarification, based on experience coding and deploying DMARC.


     I'll also suggest that it would help allay public concerns about DMARC to be able to have this document include experience-based text about ARC usage; both discussing how to use it and how effective it is.

If this is the case, I would suggest renaming the document to "Guide on DMARC and ARC Usage" rather than the original title.

Mike

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to