> In my above example, SPF did nothing useful. And, my example shows > exactly why SPF does not help at all with the spambot > problem. If I'm a > spambot wrangler, I create a group of throw-away domains, put in SPF > records for them that say +all, and then send out my storm of spam. > Then I abandon those domains, and create a new batch of them for the > next go-round. > > IMO, SPF is a liability when fighting spambots.
So perhaps SPF should consider removing +all as an option. Realisticly anyone that has to say "my e-mail might come from anywhere" is contributing to the problem and probably deserves to have e-mail bounced. OTOH, I can see where a spammer could easily register a bunch of domains, and then update the SPF records to include the specific spambots that are delivering e-mail from each domain. I'm not sure there IS a solution that works for fighting this. ISPs contribute to the problem by dinging businesses for everything from number of messages relayed, bytes relayed, reverse DNS setup, ... It took me almost 2 months to get all the issues straightened out after we moved and changed ISPs. Everything's an "extra cost option". But I have a nice list now, so next time they all get negotiated as "included" before we sign the contract. Either that, or we find someone else. Then there's the wonderful ISPs that assign static Ips in the middle of dynamic IP blocks. I really hate confirmation-based antispam systems, but I don't really have a better solution to stopping this. If I have to manually approve every person/list I want to send to me, then at least I have control over it. Right now, our server's having trouble keeping up with the load. I honestly don't know how long before I decide it isn't worth the effort to host our own e-mail. Bret
