Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?

["Doyle, John" <[e-mail]>]

----- Original Message -----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, May 07, 2014 01:01 AM
To: Dave Crocker <[e-mail]>
Cc: IETF <[e-mail]>
Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?

> On 5/5/2014 5:37 PM, Fred Baker (fred) wrote:
> >>> I guess we’re running it. I was hoping to avoid the “everything
> >>> around broke” part.
> >>
> >> Well.. I can certainly tell you that, as someone who supports a
> >> couple of dozen email lists, an awful lot broke
> ...
> > And what comes quickly to mind is the comment, earlier in this
> > thread, that “we have been running it for nine years.”
> >
> > Running it, perhaps, but not learning from it. Kind of “Really Not
> > The Point”.


> I might be a bit confused about the 'it' being referenced, so it's worth
> ensuring some clarity:

>      1.  DKIM and SPF have been fielded for perhaps 12 years.  DKIM in
> its original-but-similar form, DomainKeys, and then its initial
> 'consortium' form, preceded the 2006 published DKIM RFC by several
> years.  SPF appeared around that time too.  So the reference to 6 years
> of operational experience is really on the very low side.

The relationship of time to operational experience is far from obvious, even
for specifications we view as successfully deployed.

>      2.  Use of DKIM and SPF is reasonably well understood and does not
> cause interesting email operations problems.  I'm starting to hear some
> unfortunate stories about DKIM signature breakage in scenarios that I'd
> have hope would not have it, but the breakage of the signature is not
> breaking legitimate email scenarios.

That's incorrect. The obvious counterexample is MIME downgrading, which was a
core MIME capability from the start.

I note in passing that DKIM could have been engineered to accomodate
this by canonicalizing to binary and removed CTEs, but wasn't.

>      3.  DMARC's functions and limitations have been reasonably well
> understood since it's inception.  It works comfortably in specific
> scenarios and causes problems in others.  Again, there are no surprises
> about these now.  They've been clearly understood by those working on
> the spec.

I can't speak to what was in the minds of the developers, but I view the fact
that the specification is noticeably lacking in describing these limitations 
as problematic.

I haven't had time to do a careful review of the DMARC specification, but I do
note one obvious omission: Wouldn't it have been helpful to define an enhanced
status code for a p=reject failure which mailing lists could detect and take
appropriate action, i.e. counting this as a failure of the sender, not the
recipient?

>      4.  SPF actually has the potential for causing similar operational
> problems.  It has a strict mode that will cause receiver-side rejections
> if honored, and they will occur for any multi-hop sequence.  In the case
> of SPF, multi-hop means /any/ sequence that produces a new client smtp
> IP address, presented to the evaluating receiver.

All very true, but SRS and similar schemes provide a reasonable way to address
SPF issues.

> In the case of DMARC,
> given the use of DKIM, the problem is multi-hop for scenarios that break
> DKIM signatures.

And AFAIK no mitigation strategy comparable to SRS is possible with DMARC as it
is presently constituted.

>      5.  The reason SPF's strict mode hasn't been problematic is that
> virtually no one uses it.

The customers we have who have been forced to deploy SRS are just a figment of
my imagination then.

I'll also note that strict mode is sufficient but not necessary to cause
problems to forwarders. A lot of places factor SPF failures into spam scores.
An increase in those scores may result in an overall higher failure rates.

> So what's different now is not technical, its operations policy.

Operations policies aren't technical in nature? They sure seem technical to me.

				Ned