----- Original Message ----- From: ned+ietf@xxxxxxxxxxxxxxxxx [mailto:ned+ietf@xxxxxxxxxxxxxxxxx] Sent: Wednesday, May 07, 2014 01:01 AM To: Dave Crocker <dhc@xxxxxxxxxxxx> Cc: IETF <ietf@xxxxxxxx> 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