Re: [Asrg] Spammer proxies using legitamate mail relays

> > So, we need to devise a scheme which they *can't* adapt to.  That's 
> > what
> > I'm working on.
> I don't believe there ever will be a full prove way.  It will be a
> continuing struggle of measure counter-measure.
Have a think about the following scheme, then, which I'm in the process 
of implementing.  If you can, I'd like you to point out any chinks in 
the armour.
You've heard of hashcash, naturally.  As a proof-of-work system, it is 
simple in concept - physically prevent spammers from being able to 
generate lots of (deliverable) mails per second per host, by chewing up 
their CPU time.  The disadvantage of hashcash, when used on it's own, 
is that it also limits the rate at which legitimate mails can be sent.
There is also the concept of whitelists.  However, addresses can be 
spoofed in today's e-mail, so conventional whitelists can be 
circumvented by plundering the address book from a zombie and doing a 
bit of guesswork.  One solution is to use a cryptographic signature, 
unique to the sender/recipient pair.  This still leaves the 
introduction problem - how do you get on the whitelist and hand over 
the signature verification keys?
The solution is to allow a signature *or* a hashcash token to get a 
message past the filter.  The first messages of an e-mail exchange 
contain hashcash tokens, which are expensive enough to prevent spammers 
from flooding inboxes as they do today (with today's estimated zombie 
population, that means 27 bits or more).
In this first exchange, signature keys are also exchanged, and are used 
for computationally-cheap conversation subsequently.  The protocol 
would ensure that only genuinely two-way conversations would be able to 
set up signature relationships.  The signature relationship involves a 
pair of asymmetric key-pairs, one for each direction of message flow.  
The private key is, of course, used for signing, and the public key for 
verification.  There is no relationship between the body of the message 
and it's signature - the signature merely has to be unique for each 
message, a fact which is enforced using a double-spend database just 
like hashcash.
Because of Moore's Curves, the threshold value of the initial hashcash 
token would have to be increased over time, by approximately 1 bit 
every 18 months if past trends continue.  This can be accomplished 
either by application of an internal date-based formula, or by 
occasional reference to a DNS entry, or else by a manual configuration 
entry (the latter is discouraged).  This factor I believe is 
manageable.
A further problem is that some situations have limited processor power, 
but still need to send mail to a diverse range of recipients with 
tolerably low latency.  Sales and tech-support desks would be good 
examples, as would the low-power mobile phone.  Solutions include a 
"captive zombie" approach where hashcash stamp production is 
intentionally farmed out to all workstations in the department, 
reducing latency but not affecting total throughput - if businesses 
really don't want to subscribe to the thin-client model, they might as 
well harness the benefits of the fat-clients they already have.  The 
solution for mobile and thin-client situations is to have stamp 
production done (possibly for a fee) by a server farm just upstream of 
the client.
The remaining problems centre on mailing lists and legacy users.  I'll 
deal with mailing lists first.  The obvious solution is to have the 
listservs implement the scheme natively, and benefit from the stronger 
subscriber authentication.  A signature relationship can be defined 
during the standard double-opt-in process, obviating the need for the 
listserv to generate hashcash many times for each message it processes. 
 A listserv that doesn't implement the scheme should look just like any 
other legacy user, whom we will now deal with.
Legacy users are a sticky problem - literally.  However, we can 
consider the hashcash and signatures as acting like a bypass mechanism. 
 Messages without valid hashcash or a valid signature are directed into 
a content filter.  Because there is now a foolproof way to avoid being 
processed by that filter, it can be a lot more aggressive than usual, 
thus reducing false negatives.  Eventually, when participation is 
sufficiently high, it could become a straight blackhole.
To help participation figures, Eric and I have been considering how to 
get the ISP involved, seeing as MUA plugin systems are presently highly 
proprietary and thus hard to deploy rapidly.  The easiest solution 
seems to be to install a daemon on the user's machine, which stays in 
contact with software attached to the ISP's MTA.  The latter then 
notifies the former when it receives a message from the user that 
requires hashcash, allowing the user to accelerate delivery far more 
than the ISP would economically be able to do alone.
The software attached to the MTA would take over hashcash production 
(generally at a much slower rate) if necessary, and also handle all 
signature and filtering duties - thus ensuring that all clients of the 
ISP participate in the scheme.  This is, of course, best combined with 
SMTP AUTH to prevent zombies from exploiting other clients of the same 
ISP.
For the avoidance of doubt, the working title is, at present, 
RubberStamp.
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg