On Wed, 2005-03-23 at 14:43 -0500, Scott Kitterman wrote:
2) Adding an IP address to authentication queries, allowing *all* SPF
processing to be done by the sender's domain.
At this point, it's really not SPF anymore, it's a different design.
Not at all. SPF currently supports this through macros and would as
simple as:
v=spf1 exists:%{i}._spf.%{d2} -all
This is a single query for the SPF evaluator, and pushes all processing
to the SPF publisher's DNS server (in as much as that necessarily is
"processing" -- these could all be static records, eminently cachable.
While we're talking about one of the channels open for abuse, one of
them is that macros other than %{d} can appear right-most in domain-
spec. I'm sure this has already been discussed -- does anyone have
pointers? I'm not sure what could be done about this, other than in
mechanisms and modifiers (other than include and redirect) not allow the
RHS of domain-spec to not match %{d} (or some subset of). This would,
unfortunately, limit using another domain's MX record in YOUR SPF
record, but as (I believe it was) Radu pointed out, if you're doing
that, then you're making a guess at someone else's network topology, and
you should just be including their SPF record.
Consider example-spammer.com's record:
v=spf1 mx:%{l} -all
Now, all I need to do is commandeer a bunch of machines with access to
aol.com's or comcast.net's MTAs and send through them with MAIL FROM set
to:
aol(_dot_)com(_at_)example-spammer(_dot_)com
comcast(_dot_)net(_at_)example-spammer(_dot_)com
I'm not seeing where this is disallowed, but I'm just skimming now and
have not looked over the spec in detail in a while.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>