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
to mean.
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:
http://www.openspf.org/auth/draft-otis-spf-dos-exploit_Analysis#rebuttal
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html