Receiver Initiated Authentication

Over the weekend, I read a proposal for a new method to combat spam, called receiver initiated authentication.

Read on to learn the pitfalls that the author missed.

First, it depends on changing client code. The author suggests that three companies control 70% of the email clients, which is basically true. What he does not account for is that users also have some choice in this-- they don't have to (or may not be allowed to by IT policy) upgrade to the latest version of Microsoft Outlook, for example.

Second, it assumes that "legitimate" companies would implement it. The spammers implemented SPF faster than any of the "legitimate" companies.

Third, it assumes a database of "authorized" domains. This is a popular anti-pattern to many integration problems, so I got a good laugh. (The anti-pattern is, "Let's build a big database!", and is fraught with scalability issues.)

Fourth, it uses captcha. This is supposed to block spammers, but creates a pain for legitimate users.

Anti-spam solutions are about two things:

1. Convenience for the user (put another way: productivity for the user increases when they don't have to delete 100+ spam messages a day)
   
2. Security (preventing phishing scams, viruses, etc.)
   

When the solution puts burden on the end user, it can never be successful.

Editor's note: I work for a company which is in the Email Governance space (including anti-spam).

Full article here.