The original idea behind Sender Policy Framework, SPF, was very simple. While Domain Name Systems hold the records for where to send mail to for a given domain name, they have never held information pertaining to where mail from that domain should come from.
So, an e-mail purporting to come from Telstra.com, for example, would have to actually come from Telstra's servers to get accepted by an SPF-enabled server. As the telco has shown in the past, this isn't beyond the realms of possibility, but spammers who log on to major ISPs to do their worst aren't the real scum, they're just the low-hanging fruit.
Microsoft's caller-ID incorporates SPF -- they merged in May 2004 -- and a few nifty header inspection tricks, while Yahoo's DomainKeys uses domain name servers to spit out cryptographic keys used to verify messages are coming from where they say they are.
The owner of a DomainKeys server generates a cryptographic key pair, one public and one private. The private key is used by the outgoing mail server to sign all outbound messages, while the public key, which is published to the domain name's DNS record, is used by recipients to verify that mail was signed by the private key.
While these tricks all sound cool, time will tell if it actually makes a difference. Yahoo's system seems great, but could it just encourage spammers to get more desperate? Junk mailers may start breaching DomainKeys -- enabled servers to spread their bad grammar, and with all these systems what's to stop spammers registering legitimate domain names with valid name server records, just as they do today?
These systems may not kill off spam entirely, but they will make it easier to identify bad domains. Perhaps the solution is simpler than we ever imagined. All that's needed may be a list of the 20 worst spammers, 12 elite SAS soldiers, 20kg of plastique, a box of assault rifles, and a helicopter.
|
|
13%
1%
