On Second Thought, Why Not Just Ditch Sender Authentication Altogether
from the just-ditch-'em-all dept
ZaneK writes “The SPF Council has requested that the IETF revoke its support for the Sender ID SMTP authentication experiment because Sender ID conflicts with SPF in ways that can cause false positives. Because of their bickering, the IETF may pull support for both proposals. This may not matter, since, so far, spammers are the biggest beneficiaries of both SPF and Sender ID.” What? A standards battle over pretty much useless technology? Who could have predicted that?
Comments on “On Second Thought, Why Not Just Ditch Sender Authentication Altogether”
SPF is better than nothing
In particular, it makes life more difficult for mass-mailing worms. Unfortunately it’s *not* a perfect guarantee that email comes from the alleged sender, despite claims that is is. My understanding is that email malware can bypass SPF by spoofing both the sending domain and the sending IP address. However it then won’t receive the SMTP replies from recipients, which makes mail-sending more complex and less certain.
How SPF Works, Why Sender ID is a non-starter, Analysis of Microsoft’s MARID Patent Applications.
Buy a clue?
Duh, authentication is only useful in conjunction with a reputation service. Large ISPs run their own; smaller mail receivers use public ones like cloudmark’s or senderbase’s.
CSV makes this clear; the reputation check is part of the protocol.