On Wed, 2004-03-10 at 14:58, Mark C. Langston wrote: > Imagine for a second that almost every MX on the planet implemented rDNS > checks. Now imagine that your ISP suddendly botched their rDNS zones, > and didn't fix them. Your mail starts bouncing, you weren't expecting > it to, you weren't aware that the problem existed, and you're powerless > to change the situation (except to change providers).
Stuff like that happens all the time. If someone on my subnet spams and gets our class C listed in a RBL, my mail starts bouncing. I'm powerless to stop it unless I change providers. > THAT scenario is very much like the one SPF will create: end-user > ignorance of the change, violation of end-user expectation w.r.t. > delivery, and complete end-user powerlessness over the situation, except > to change providers. Again, this already happens every day with RBLs. So why is SPF being criticized as a poor solution to a non-existent problem, but RBLs are okay to use? > What I'm against is the nave assumption that once SPF is > deployed, people will simply, quietly, and willingly go to the > (sometimes rather great) lengths necessary to upgrade their servers to > accomodate these, and change the configuration of all their deployed > clients to take advantage of these changes.) SPF won't cause people to go through the great lengths necessary to upgrade their servers and clients, but spam, viruses, and forgeries will. There are studies that claim spam makes up 60%+ of the Internet's e-mail traffic. As that number continues to increase, people will *have* to upgrade their servers to support anti-spam/virus/forgery measures, or else the signal to noise ratio will continue to drop until e-mail is useless. Again, it isn't a magic bullet, but SPF helps. Don't write it off as nothing just because it isn't perfect in every scenario. - Jon -- [EMAIL PROTECTED] Administrator, tgpsolutions http://www.tgpsolutions.com
signature.asc
Description: This is a digitally signed message part
