Sender Policy Framework
The recent increase of junk e-mail messages have fake sender addresses. That means that the email says that it comes from a particular domain (website address), but it doesn't. The victims whose addresses are being faked suffer the consequences as website reputations are diminished, and domain name owners have to disclaim liability for the abuse to those who identify them as the culprits. The additional waste of time sorting through spam and misdirected bounce messages is growing exponentially.
Chances are that you have experienced one kind of abuse or another of your e-mail address yourself, for instance, when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.
"Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact" (from OpenSPF.com).But it does not have to be this way!
Known as SPF, Sender Policy Framework is a software protocol that is attached to a domain name and serves to identify the domain name (www.whatever.com) with the hosting IP address. Why? Because the sending IP address for email cannot be faked, while the domain name can. By associating the one with the other the receiving email server program can check to see if the incoming email has been sent from the correct IP address. If not, it is considered to be junk and handled appropriately (trashed). Multiple IP addresses can be associated to cover the cases where email may legitimately come from more than one IP address.
WebProper.com has added SPF to all hosted domains. We believe that such action should be mandatory across the Internet as a way to reduce the growing junk email problems.
The Next Step
While this protocol is used exclusively on the receiving end of emails, I don't see why the same kind of cross checking between domain name and related IP address could not be more widely employed. Why not have every server require such a check at every Tracerout bounce point to insure authenticity. I'm not near enough of a geek to understand whether or not such a scheme would actually work. But it sure seems potentially viable. It might require an SPF record for every domain name, and in the interim it may result in some none delivery of email, but surely a routine could be built in to bounce failed messages back to their source with instructions about how to implement an SPF protocol. If it would take a serious bite out of junk email, people may be very willing to jump on the bandwagon. The rest of this discussion is for the appropriate geeks.
| 
