On 5/6/2014 11:59 AM, Dave Crocker wrote:
On 5/5/2014 5:37 PM, Fred Baker (fred) wrote:
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.
9+ years was the reference, not 6. Yes, the original DKIM+POLICY model
was conceived from DomainKeys with its built-in strict policy "o=-"
option. DKIM's policy features was called SSP which included support
for allowing resigners. The problem was how to large scale authorized
resigners.
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.
SPF is a domain policy protocol. DKIM lacks one. DKIM is totally
useless and unsecured without a policy layer. The DKIM Threat Analysis
RFC4686 touches base with this. https://tools.ietf.org/html/rfc4686
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.
But the problem is that the DKIM resigners didn't support it nor its
predecessor ADSP for any use case, large or small.
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.
No, it wasn't a problem because the "YAHOOs" didn't do a -ALL policy
or those domains that did not have a handle on their network of mail
senders. Those that did use -ALL and there are thousands of domains
who are, including ietf.org with its string -ALL SPF policy, had very
little problems with them.
v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56
ip4:64.170.98.0/24 ip6:2001:1890:126c::/56
ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64
ip4:72.167.123.204
-all
But in principle, whether it was YAHOO or another domain, the SPF
network of SPF receivers did support the -ALL rejection semantics.
That wasn't the case with ADSP Discardable and DMARC p=reject until
now with the switch turned on.
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.
Dave, its a technical problem because the DKIM-WG intentionally
deemphasized an author domain policy lookup layer seeking to replace
it with a 3rd party signer domain trust/reputation lookup service
model. The latter hasn't materialized so DKIM was left unprotected
without the author domain policy layer. The removal of policy has
caused interop problems.
The goal now is to give DMARC 3rd party semantics and support within
the DKIM framework where the resigners can coexist cooperatively.
--
HLS