> SPF is a failure. The forgot the key component that would have made > it work... registration with a central database. The way it stands > anybody can create any valid SPF record they choose. Spammers can > create them just as easily. Since there's no checking against a > central database it makes the whole thing worthless in my opinion.
That's by design and seems to show that you don't really get what an SPF policy is. > About the only thing SPF does is increase DNS traffic. Uh, do you have SPF enabled? Or are you just spouting off on the theory -- without really understanding the theory? > You can't count SPF failure against a message or you'd be blocking a > LOT of valid messages. No. That is categorically untrue and represents the most common misconception of what an SPF policy is, and thus what an SPF FAIL represents. Since the terms of the discussion have not changed in the past couple of years, I will "reprint" a couple of my earlier thoughts on the topic. There is no such thing as a "valid" message that does not comply with a domain owner's SPF policy. SPF is designed for domain owners to prevent people from forging their domains whenever and wherever they want. If a domain owner publishes a strict sender policy for mail using their registered domain, if I do anything but follow that policy, I am defying the wishes of the legal owner of the domain. To accept and deliver mail as legitimate that is known to be illegitimate -- it's their SPF policy, not my subjective notion of message content, that dictates validity/legitimacy -- is putting your faith in the wrong place. You're confusing the _obligations_ of those who want to publish SPF records, and the related customer relationship management, for a problem in published SPF records. If you want to prevent people from forging your domain whenever and wherever they want, you have to prevent people from forging your domain whenever and wherever you want--Q.E.D. Your "own" users need to conform to your policies. Of course, it's incumbent upon the domain owner to make sure that their SPF policies, their AUP, and their customer relationships are in order. But I _must_ trust that they are, or I am behaving most illogically. We reject messages on SPF FAIL -- yes, on that single test -- because we want to honor the domain owner's right to control their domain, and to enable their swift notification if their SPF policy is not producing the results they may desire (or if it _is_ producing desirable results, despite what an uninformed user might have thought when they sent something from an insecure webmail box or used their business address on a greeting-card site). Tens of thousands of messages have been rejected across the sites we administer. There has not been a single complaint to us to which we could not swiftly send out a well-worded redirection to the sender's admin. It is not for us to change the rules set down by a sender's IT administration. I think that it is presumptuous and ignorant to attempt to do otherwise. I d**n sure hope that nobody is both testing for SPF and delivering mail for the domains for which I have published policies, especially without contacting us. We work, for example, with regulated companies who must archive all mail to and from their domain, by federal law. SPF is so valuable in such an effort, it proves its worth on that "outbound" point alone. I think SPF has stalled in part because people have software that has SPF support, but they think they're smarter than the system. That, along with the arrogance of the SPF community on linked matters (such as forwarding), has frozen the protocol's adoption. But the blame falls on both sides. > You can't accept SPF pass as anything good. A LOT of spam passes > > SPF. That is true. An SPF PASS is not employable as an anti-spam method. This is understood by SPF advocates as well. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
