Author: Kai Engert
Document version 3, 2010-09-27:
Abstract: 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.
Other pages linking here:
Known issues and proposed improvements:
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 shown that a domain owner ignores spam reports. If spam email messages still verify correctly, despite many users having reported spam messages, then the domain owner doesn't follow the rules of the Spam Salt infrastructure. 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 if messages contain valid hash values.