Re: OmniMix with recipient related Hashcash

Christian Danner wrote:

>=20
> I only had to add a few lines of code, nothing spectacular to be
> impressed about.

actually, yes there is.  You did something constructive with this=20
technique.  That's worth a lot.  The next stage will be PR.  When I=20
finish up twopenny blue, I'm planning on writing up and sending out a=20
press release via one of the free channels or one of the cheap channels.=20
  I'm going to also include references to all the other folks that are=20
compatible to make it look like a huge movement.  :-)

> Above all OmniMix is a privacy tool. So if you only run an IMAP client
> and don't rule over the server your privacy is irretrievably gone.
> OTOH if you run both it may be possible to employ OmniMix at the
> outbound side and control it with header directives, one of which now
> is a Hashcash activation switch ('O-HashcashRecipient-Active: Yes)'.
> But this would imply all the problems that come with server side
> minting.

I assume this isn't a problem with pop three?  It seems to me that if=20
you leave the traffic encrypted or what ever and only decrypt on=20
read/display, IMAP shouldn't be a problem even if the server is not=20
under your control.  Interesting.  I need to look at your tool more close=
ly.

> It wasn't my intention to bore you or revitalize ancient discussions.
> I'm aware of the strategies you developed since then to optimize spam
> filtering and appreciate the work you've done.

I didn't mean to imply that you are boring us.  Apologies if I'd did=20
come across that way.  As a friend pointed out to me, I accidentally=20
solved a big chunk of the mailing list problem with the hybrid system I=20
had developed.  The first message to a new user gets a stamp.  Then the=20
logos back to normal.  Jonathan pointed out that if we implemented the=20
opportunistic signature technique than mailing list could sign their=20
messages which would make it easier for users to not get spoofed with a=20
by address white list.

Yes.  I know.  This is not part of the simple hash cache implementation.=20
  :-)


> The main problem I see with this 'hybrid' approach, which adds the
> element of some 'entry key information', is, that it requires a large
> amount of advance efforts:
>=20
> - for every addressee there has to be a depository on the net to
> provide the sender with the required information. The necessary stamp
> size isn't static but has to be adjusted in reaction to the behavior
> of the spammers.

quite true.  The feedback mechanism is not simple.  you need to use the=20
source IP address of the message for the postage test and the query for=20
postage uses the "from" address.  If the two match up, then the postage=20
is successful.  If they don't match up (i.e. spammer spoofing) then the=20
postage will fail and that adds negative score.

In reality, all were talking about is a simple DBM indexed by IP address=20
with a postage field.  This creates a blacklist with more nuances than a=20
simple binary test.

> - the client software has to be designed to perform network lookups
> and create Hashcash before it sends messages.

Yes.  No doubt about it.  But with a library encapsulating whatever=20
complexity, this shouldn't be a problem.  I don't see as having more=20
than one method which would be "who I am, who I'm looking for" query=20
yielding "this many bits, every time"

> - The spam filter has to be extended to look up on the net or in a
> built-in cache to get the required recipient specific parameters
> before it evaluates the Hashcash token and decides on filtering.
> Moreover it has to keep records of senders with valid Hashcash in past
> mails to be able to permit (PDA) messages without a token.

Again, the DBM described above works for the first query and the second=20
query is my friends white list maybe with a slight extension.  Again, a=20
simple DBM.  Now we could make things more complex and stick the data=20
into something like sqllite but I like DBM files.  This simple, they're=20
easy, and the only problem is I can't do sharing of a single instance in=20
memory between multiple processes.  The lock, open, read/write, close=20
cycle gets really old.
>=20
> To me it seems like trying to sell a high-tech Ferrari a hundred years
> ago, where the infrastructure mainly consists of bumpy country lanes.
> Some time later this may work out well, but in the beginning it's
> suitable at best for some test tracks.

It's actually more like selling an ATV in the days of horse and wagon.=20
Both can run over bumpy roads but horse owners get really upset if you=20
try to tell them about new ways of doing things.

Seriously, there has been a huge psychological barrier to hash cash over=20
the years.  The biggest objection has been the stamp on every message=20
model which is what drove me to the level of complexity I am currently=20
implementing.  I'm trying to use code to get past psychological=20
barriers.  Sometimes I think a baseball bat to the knees or ankles might=20
have been more effective.  It's truly frightening that people involved=20
with technology get so emotionally bound up and resistant to new ideas=20
(yes, I know I should talk)

>=20
> Please correct me if I'm wrong, but I see the (pure) principle of
> Hashcash in spending a certain amount of computation time in order to
> supply evidence for the seriousness of my message. If my device (PDA
> etc.) doesn't allow me to support such a strategy, then my mail has to
> be better in other areas to pass spam filters. Hashcash isn't a
> cure-all for spam, however it provides a valuable additional
> characteristic to base a filtering decision on.

Or... my argument for low-power devices is "let the server do it".  It's=20
totally appropriate and is a good example of how one can assign a value=20
to a proof of work stamp.  How much is it worth to you to generate a=20
stamp that will guarantee your message will be delivered to a=20
destination mailbox?  Again this is another reason for the one stamp=20
friends list.  Once the PDA has sent a message and you've paid for that=20
stamp via some other resource, now the PDA is free to send as many=20
messages to that address as you can create.

I agree it's not a cure-all but has the wonderful property that if we=20
can fool spammers into generating lots of stamps, the volume of spam on=20
the net will go down.  And if we can't fool them, we now have a signal=20
for making our own messages much more recognizable.

It wins either way.
>=20
> So why not start at a lower level to bring the developers of MUAs and
> filtering systems as well as mailserver operators on board instead of
> confusing and by that demotivating them with complicated data flows
> right from the beginning. AFAIK widespread SpamAssassin - after some
> configuring - is already capable of handling Hashcash the way OmniMix
> now provides, and it modifies the score value of a mail based on the
> stamp size, which allows the sender to invest as many ressources as
> expendable. So a sender may already experience an advantage in
> equipping her/his mails with Hashcash tokens even the na=EFve way, whic=
h
> however isn't general knowledge yet.

With regards to Spam assassin, I think it's a wonderful that it's been=20
included.  I am sad however that it does not default on.  But as I've=20
said before, I have tried for years to get others to turn on stamp=20
systems and the basic argument circles around the drain this way:

Why should I filter for stamps if nobody's generating them.

Why should I generate stamps if nobody's filtering for them.

Why should I ask my users to sit there and wait for minutes to generate=20
stamps when it's useless because nobody's filtering for them.

generating stamps is going to break my server if I generate them for=20
every message.

and then there's the usual angry retort about to hell with you for=20
assuming that I'm going to burn cycles for your stupid stamp.

Seriously, there is significant psychological resistance to creating=20
stamps.  About half of the resistance goes away if there is some sort of=20
throttle on stamp generation.  The white list technique is one of the=20
better throttling techniques but I accept that is too complex for simple=20
systems.  That's why I think the DNS technique is a good first step.=20
The model I've worked out for DNS doesn't even require a server telling=20
you how much per user.  All it is a static record describing something=20
about the recipient site and the stamp size required.

For example, a static record could tell you the number of bits, the type=20
of interaction (every time, first time, every time till reply), version=20
number, and receive only/bidirectional.

Like I said before, the interpretation could be in a library which would=20
make interpretation uniform across multiple filters.


> No, of course not. Please don't take my words too serious, as on this
> sector I'm a newbie without any experience. I merly considered using
> Hashcash a good strategy to qualify individually sent anonymous
> messages, which among other things don't come with a valid 'From'
> header, over mass-mailed spam, the originators of which would need
> thousandfold my computation power to reach a comparable value of their
> tokens.

Okay.  We are basically on the same page.  If I have the neurons, maybe=20
I'll take a stab at the modeling and see if it yields up something=20
simple.  And yes, the assumption about hash cash and the impact on=20
spammers is quite right.  But the beauty is it have the same impact on=20
any mass e-mail such as commercial advertising.  I think that's wonderful=
.

---eric