>On 2004-06-04 01:29:10 -0400, Topaz M. Bott wrote:
>> James Craig Burley wrote:
>> >>Glancing at the ORDB.org nameservers I fail to see how the SPF DNS=20
>> >>usage can be so intense as to be a problem or a weak link.
>> >
>> >Do they use IP addresses or domain names as keys?
>
>Irrelevant. SPF doesn't employ a central server, and my DNS cache isn't
>large enough for all possible in-addr.arpa. domains.
Again, not the point.
Or, maybe it is: what is your DNS cache hit rate *today*?
What will your DNS cache hit rate be after you expose (via SPF lookups
for every incoming email) it to lookups based on arbitrary host names
submitted by potentially-hostile SMTP clients?
>> domain in the world in the DNS. Besides that I don't know about you but
>> I have a check before SPF check that checks to C if the domain exists.
>> Now you are going to say that checking it C if a domain exist is still
>> DNS.
>
>Right. And this check is exactly as expensive as an SPF lookup.
It's pretty close. And it's pretty much the same kinda thing that
I've been talking about.
But it differs from SPF in two important ways:
- It's easy for spammers to forge existing domains, thus defeating
the utility of the check for all except old-school spamware and
vermin.
- Having determined that a domain exists via such a lookup, one
really hasn't learned anything useful. (The email could still be
forged; the site might not even accept bounces!)
Therefore, spammers have little or no incentive to attack this
particular exposure: these domain-exists checks are easy to fool and
thus don't represent enough of a problem to try to convince sysadmins
to disable them.
(And, since they're so easy to fool but do cost upstream DNS caches
some amount of resources, lots of sites don't bother doing these
checks -- their own local processing catches that sort of spam and
vermin without hitting those DNS caches.)
>This is where I think James' argumentation falls down. Checking for MX
>and A records for the reverse-path domain has been in the standard
>configuration of sendmail and other mailers for at least 5 years or so.
True, but some admins disable it for performance reasons, and, as I
point out above, spammers have little or no incentive to *attack*
these checks -- they can merely forge existing domain names.
>James may have turned it off, but I guess most mail-admins haven't and
>90+% of all mail servers are performing such checks. So spammers can
>already (and could for the last several years) use exactly the DOS
>attacks James outlined. AFAIK, they haven't.
Right. But once they decide SPF has upped the ante sufficiently that
they can no longer easily forge existing domain names that
"SPF-permit" their spam, they *will* attack it.
And, if we never reach that point, then SPF will do nothing in the
long run but give spammers incentive to buy newer, better spamware
from the black hats -- spamware that either finds, or comes with data
bases containing, existing domain names that do not publish SPF
records or publish overly permissive SPF records.
>PS: I don't think SPF will make even a dent in spam. It will cut down on
>the misrouted bounces, if it ever gets off ground, which would be nice,
>too.
I think SPF will make a dent in spam, much like pushing sand around on
a beach makes a dent in the ocean.
But, oh, please, I *hope* you're right about misrouted bounces; SMTP's
(badly designed) bounce system is responsible for a substantial
portion of the resources wasted on spam and vermin. (I know this
firsthand as a longtime victim of joe jobs.)
In that sense, I have a selfish basis on which to advocate SPF
adoption: assuming I can publish my own SPF records, it'd be great if
sites like AOL would use SPF to refuse email forging my domain names
in the envelope-sender fields, rather than deliver tons of useless
bounces to my server.
(And of course I'll hardly care if AOL wants to beat up on its own DNS
caches as a result...at least until/unless their problems reach the
root servers, or my own DNS servers. ;-)
--
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>
