Modern anti-spam and E2E crypto (2014)
That&#x27;s an excellent history and summary of the spam situation.  It adds a few pieces I&#x27;m not familiar with (I&#x27;d gotten out of the fight by the late 2000s), but validates a few approaches I&#x27;ve also considered.<p><i>Reputation is a crucial element</i>, and ultimately <i>the</i> crucial element in large networked systems.<p>I&#x27;d make one correction about new accounts:  if a new entity (email address, domain, IP) starts peering, SMTP actually offers a really good options for limiting:  a non-permanent rejection.  If new traffic shows up from an unknown source, you can simply tell it &quot;not right now&quot;.  In theory, the sending server is supposed to follow a back-off protocol, with a few minutes delay initially.  This gives time to start building up reputations through other means.  And failure to follow the retry schedule is a strong sign of misbehavior itself.  Teergrubing uses this mechanism.<p>The idea of vouched reputations is another one.  If all peers or senders need to have someone vouch for them, then even new agents can engage in email.<p>The one resource all clients, regardless of compute power, access uniformly, is time.  A protocol <i>mandating</i> a specific time interval (say, by requesting a specific future NIST randomness server value), might be interesting.<p>Another element that&#x27;s helpful to the spam-fighters is that <i>most</i> communications patterns follow a strong frequency curve -- most comms are well-established, whilst less-frequent comms are often spam.  Whitelisting based on established comms (and overriding those with specific blacklists), and treating <i>all</i> novel comms as suspect until some token of merit is received (a vouch, time delay, earned reputation elsewhere) should help.<p>The idea of multiple levels of encryption, with an outer envelope which an email server can read, with an inner envelope for the actual recipient, is another option.  Here trust information can be placed in the outer envelope, but contents are protected.  Possibly a protocol might request contents <i>must</i> be readable by the server for certain classes of sender.