#language en
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;
 1. 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.