Reducing Spam

The first problem that is often encountered is how to concretely identify mail servers (especially when using blacklists/whitelists) as they could be using dynamic IPs, etc. So, for that, I propose this solution:

• Every mail server has a PPK pair.
• Whenever connecting to send mail, a mail server can send the other party its public key, which can then be used to validate that the connecting server has the associated private key, and the server being connected to can save the public key to use for future identification (effectively, that public key is the connecting server's 'name' or 'id'). This allows you to establish an identity and store information on a specific mail server.
• Next, (and optionally), allow the public key to be published in DNS as a TXT record at a standardized subdomain (eg: _spam.senderdomain.com). When the sending server sends the "MAIL FROM" command, the domain it purports to be from can be looked up, the public key retrieved from DNS and checked against the public key the sending server is using, ensuring that the connecting server is authorized to 'speak' for that domain.

Next, implement a trust system:

• For example, server A trusts server B with a weight of 0.8, server B trusts server C with a weight of 0.4. By extension, A trusts C with a value of 0.8*0.4=0.32.
• Major mail providers play a vital role in the trust system so that it doesn't become heavily segmented.
• For example, if I were to trust Google, and if Google were to automatically increase the trust of a sending server slightly for each 'good' message received, and then decrease the trust by a slightly larger value for every message received which was subsequently marked as spam, then I am effectively using Google's user base as a spam filter.
• There is no benefit to generating a new identity for your server, as it would not increase your trust at all, only ever lower it. - This is a fundamental concept of this proposal, and if it is changed the whole thing becomes useless.

Implementation notes:

• Can be easily bolted on as an extension to existing systems, including doing things like feeding the trust value directly into existing systems (like SpamAssassin), not using it as a binary trusted/not trusted value.
• As it becomes more popular, and the trust networks become more established, the trust value can be given greater weight up to the point of only allowing mail with a certain amount of trust through.

Thoughts:

• This system provides a great incentive for people who intentionally or inadvertantly create an open relay to fix it quickly.
• It also creates a great incentive for upstream providers who are relaying mail (possibly because of a more established trust value) to ensure that their customers/relayees are not spamming, and to end it quickly if they start.