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.
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.
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.
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. In the case of DMARC,
given the use of DKIM, the problem is multi-hop for scenarios that break
DKIM signatures.
5. The reason SPF's strict mode hasn't been problematic is that
virtually no one uses it.
So what's different now is not technical, its operations policy. A
couple of large providers chose to apply DMARC to scenarios known to
cause problems for some of their users and groups their users work with.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net