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...
Specification of DMARC improvements to support indirect
1. Besides ARC, are there other wg efforts that should be pursued to
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.
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
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.
dmarc mailing list