Spam salt proposing


My friend kaie is publishing this invention in the hope that it makes sense and can contribute to solve the Spam" problem.

In a nutshell, the idea is to assign an additional secret key (salt) to each email user account. The email sender uses the salt and the message contents to calculate a hash value and adds that hash value as a new email header. For each email domain a verification server is registered in the DNS that can be contacted to verify the authenticity of messages that contain a hash value in the email headers. An email recipient can contact a verification server and filter incoming messages based on the verification response. As soon as multiple email recipients report that a sender is sending spam, the sender's salt gets changed, and future verification requests for messages that used the older salt will fail and such messages can be rated as Spam.

For a full description of how this could work please see
kaie is looking forward to your feedback.


Dear unwesen, thanks a lot for taking the time to read the ideas in detail and your reply.

You proposed that instead of having the verification server respond with a verification result, the verification server should reply with the correct hash for the given message. Unfortunately I believe this won't work. With your proposed approach, a spammer could use a verification request prior to sending a spam message, in order to retrieve valid message hash values, and finally send the spam message containing a correct message hash header.

I agree that there is one detail that has not yet been solved with the Spam Salt proposal. It isn't (yet) a solution against spammers who register their own MX/MSALT servers, who don't care that they can be identified as the originators of spam, who will ignore spam reports and will not take action for spam reports.

However, I believe the ability to identify the originators of email is an important first step towards a real spam solution. If we had established an environment where spammers are required to provide the MX/MSALT infrastructure, required in order to get their spam through to user's eyes, because messages without spam salt hash values won't be looked at by most users, then, I believe, we would have made a huge step forward.

It can be easily verified that a domain owner doesn't react to spam reports. If spam email messages still verify correctly, despite many users having reported spam messages, it can be shown that a domain owner doesn't follow the rules of the Spam Salt systen. Maybe this behaviour might even be sufficient proof to justify to sue a domain owner for sending lots of spam? Evidence can be easily collected by having some spam fighting organization run multiple honeypot email boxes, have a human identify a spam message, and send multiple spam reports for every message having identical contents, received at each of the honeypot mailboxes.

Even if it were not possible to sue domain owners, we'd still have the option that recipients could use a blacklisting feature in an email application to backlist a single sender, or even blacklist a complete sender domain.

An email application could be enhanced to detect that the user has reported multiple emails from a sender domain as spam, and after a while (e.g. next day) could automatically repeat the earlier verification requests. If the requests still succeed, the application could notify the user that the domain is not well maintained, and propose to sort any email from that domain as spam, even when having valid message hash values.

Cute, but how does it solve the spam problem? What it avoids is that spammers can use open relays to fake sender addresses, if and only if the MSALT server can be trusted.

You can still send spam easily, you just need to have a pool of domain names with MSALT servers that return success for every request they get. That's not a high enough hurdle to stop spam in it's tracks.

One small improvement with huge impact would be to NOT send the hash you received, and let the server return the hash it calculates, sending some random data (a fake hash) when no salt/user is found. Then let the client compare the hash the server returned with the hash you had attached to your email. That's not as easily faked.

Of course you can still circumvent that by running legitimate MX and MSALT server combinations for which you sell one-time-use email accounts to spammers. Again, the technical hurdle to overcome that isn't that high.

But those legitimate MSALT computations might be just costly enough to dissuade spammers a bit... after all, it's the negligible cost of each spam mail sent that makes spam profitable. I'll let someone else run the numbers on that, though.

Recent Entries

Mozilla Camp Eu 2011
Last week-end I had the pleasure to attend MozCamp Europe 2011 in Berlin, Germany. As always those events are for…
Test event centered around Thunderbird 10 and Lightning 1.0
It's been a while since we had a testing event. Some of it was probably my fault as I needed…
Free met à jour son infrastructure de mail et offre plus de sécurité
ça y est c'est officiel et c'est testé ! Le fournisseur d'accès à Internet Free, vient de déployer une infrastructure…