Revert to this revision

Distributed Spamikaze has a number of goals:

  • Block a spam source before it has spammed me, by knowing that it already spammed some other Spamikaze installations.
  • Figure out that many people get legitimate email from a certain IP address, so it should not be listed.
  • When in doubt about an IP address, get a second opinion.
  • Make it harder for a real spammer to get his/her IP addresses removed from all the lists.
  • Make Spamikaze invulnerable to the DDoS attacks that sometimes take out centralised DNSBLs.

There is not yet a design that would fulfill all these criteria. The main problem seems to be that "block a spam source that spammed other Spamikaze instances" requires a push model, while getting a second opinion on an IP address is more suitable to be implemented as a pull model. If you have an idea on how to get this fixed, please write it down here:

Proposal by Walter:

Push versus pull do not necessarily exclude each other. Imagine a Spamikaze message-bus on which it is possible to push spam-trap hits and additional details and requests about a certain IP-address' reputation. This requires additional design goals that have to be met:

  1. prevent spammers from either tarnishing a certain IP's reputation (Joe Job) or from getting a handle on the survivability of their spam-run, as often happens with SpamAssasin and;
  2. maintain anonimity of the involved nodes.

Messages that announce spam-trap hits could have a format as follows:

  • <public key_id>a hash of the public RSA-key of the announcing node</publc key_id>
  • <unix_time_of hit>the unix time+timezone of the hit</unix_time_of_hit>
  • <type_of_hit>SMTP</type_of_hit> (for the time being only SMTP, but distributed Spamikaze could potentially be enhanced for other malicious attempts to use a TCP/IP based service, for example exploits of HTTP-server vulnerabilities)
  • <hitter_id>a cryptographic hash of the type_of_hit+IP-address of the source</hitter_id>
  • <hit-characteristics class:SMTP-message-body>a hash of the message body</hit-characteristics>

The message also should be be cryptographically signed by the sender node.