----- Original Message -----
From: ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
[mailto:ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com]
Sent: Wednesday, May 07, 2014 01:01 AM
To: Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
Cc: IETF <ietf(_at_)ietf(_dot_)org>
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