>Ok, Lets say that you are correct about the DOS.
>Please explain the possible problem. Given my solution already in place.
Looks like you've got a pretty solid solution in place.
So, only two ways I can think of that'd make a headache for you if you
used SPF, targeting your system itself (rather than a dDOS on your
upstream DNS caches, DNS root servers, or other authoritative server
by attacking not so much your system as other systems that share your
upstream caches):
1. Use widespread zombie machines to inject lots of email with
suitably forged MAIL FROM:<[EMAIL PROTECTED]>, so you do lots of
SPF lookups on arbitrary data.
2. Use intermediate relays to do the same thing, except now the
emails come from systems you "trust" to not try to exploit you
(though those relays presumably can't be using SPF to reject
incoming email that appears to be forged).
If your incoming email flow is kept low enough, #1 won't pose much of
a problem, since your solutions already will respond by reducing
incoming email flow even more during the attack.
And #2 is more of a policy matter, which can be addressed once the
problem is noticed.
Therefore, this does indeed remain primarily a theoretical concern
with the architecture of SPF for someone like yourself.
The reality is likely to be that spammers will just forge domain names
that either don't publish SPF records, or that publish overly
permissive SPF records, just as they shifted from not forging to
forging random domain names, and later from forging random domain
names to forging random *existing* domain names, in response to the
various anti-UBM countermeasures that were deployed in the past.
As long as spammers can find enough domain names to get them past SPF
checks, they'll have little incentive to attack SPF per se.
Still, I'd feel better if there were assurances that DNS lookups based
on arbitrary data supplied by potentially hostile entities (which
includes SPF lookups in response to SMTP clients saying "MAIL
FROM:<...>") were "firewalled", or kept separate, from traditional
(outreaching) DNS lookups by, say, using a separate set of caches and
servers on port 54 (or some other new reserved port) instead of port
53.
But that's probably better discussed on the pertinent SPF and DNS
mailing lists. Certainly qpsmtpd wouldn't care!
--
James Craig Burley
<http://www.theburleys.net>
