[ietf-dkim] Re: SSP + SPF records in DNS
julian at mehnle.net
Tue Jan 1 16:04:49 PST 2008
Douglas Otis wrote:
> On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:
> > Nobody proposed to use SPF to "validate a DKIM domain in some
> > manner". SPF validates envelope sender addresses, it allows "accept
> > and bounce" after a PASS. SPF is for SMTP, not for DKIM. If you
> > reject a SSP FAIL at your border you don't need SPF, neither the
> > protocol(s), nor the record(s).
> > I proposed to put the SSP info into a separate DNS record in the
> > existing SPF RR set. You don't need to look at any v=spf1 or spf2.0/
> > * record after a query=spf, you'd look for the v=ssp1 record.
> Original proponents failed to limit per message name evaluations.
> What prevents DKIM misuse when SPF includes DKIM policy? Why wouldn't
> a DKIM specific domain be evaluated using SPF, and seen as analogous
> to that of the PRA?
First, you seem to be completely missing Frank's point. In the above he
is talking about sharing the "SPF" (code 99) RR typespace among v=spf1/
spf2.0 and v=ssp1 records, not about applying any v=spf1/spf2.0/v=spf3
semantics to SSP or DKIM.
Second, your analogy (which as I said misses Frank's point) to the re-use
of v=spf1 records for PRA evaluation (as propagated by Microsoft) is
broken. Even if some v=spf3 came along and defined a new "dkim:"
mechanism, there would be no general risk of confusion whatsoever with a
separate SSP record scheme, because any additional and potentially
conflicting semantics would be entirely up for domain owners to declare!
IOW, if a domain owner published some "v=spf3 dkim:..." record according
to whatever specification of v=spf3 or "dkim:", it would be that domain
owner's decision. The problem with the v=spf1/PRA fiasco was that the
Sender ID specification (and any implementations thereof) did NOT leave
it up to domain owners what their existing v=spf1 records were supposed
I am not going to discuss the details of your FUD about SPF being a threat
to the livelihood of DNS and the internet as a whole, but let me summa-
rize the SPF project's conclusion as follows for the benefit of others:
> > Let's say that there are still more pressing problems with DNS
> > attacks than your idea to abuse SPF to query addresses in ten MX
> > sets.
> This concern extends to macro expansions using the local-part of the
> email-address. It is extremely difficult to determine whether a DDoS
> had been sourced by SPF.
And that determination is of academic interest at best, because there are
indeed other ways for DNS-traffic-based DoS attacks that are just as
suitable as, if not more than, SPF:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20080102/3d714c01/attachment.bin
More information about the ietf-dkim