[hashcash] Re: OmniMix with recipient related Hashcash
- From: Christian Danner <hashcash_list@xxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 05 Dec 2006 15:53:20 +0100
Hello Eric,
on Mon, 04 Dec 2006 09:56:34 -0500, you wrote:
>Christian Danner wrote and I rearranged:
>> Hi!
>> >
>> That's why I added a simple Hashcash minter to OmniMix (v0.9.9.2), a
>> Windows based NNTP/SMTP/POP3 proxy server used to anonymize messages
>> by means of onion routers. It now allows to equip all mails, whether
>> sent the normal way or through the remailer network, with tokens based
>> on the recipients' ('To:'/'Cc:') mail addresses ('abc@xxxxxxx').
>
>this is fantastic. I am impressed
I only had to add a few lines of code, nothing spectacular to be
impressed about.
> but I do hope you'll add IMAP to that
>one of these days.
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.
>> The
>> size has to be set within the program. To prevent from exaggerated
>> computation times there's an option to reduce it on a
>> message-by-message basis dependent on the number of tokens to be
>> calculated. So even longer mailing lists don't 'cost' more time and
>> shouldn't overload the system.
>
>I don't mean to be too denigrating because I really appreciate the work
>you've done but you hitting the same problems we had about eight years
>ago (if memory serves). This is why stamp generation is more
>complicated than it seems it should be.
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 followed the recent discussion about methods to use Hashcash for
>> spam protection. I have to admit that most of those strategies appear
>> to me much too complex to achieve a better acceptance. IMHO in order
>> to raise the approval rate deployment and practical operation have to
>> be less complicated in the first place. Keep it simple! And later on,
>> if it stands the test, add further gadgets or even build a dedicated
>> infrastructure.
>
>The simple is naïve sender-pays. It's been around since the days of
>Penny Black which is well over a decade. Hash Cash, if I remember
>correctly, it's coming up on its 10th birthday in a year or two. All of
>the problems with naïve sender pays (high load on everyone, unusable on
>small devices (cell phones, PDAs), unfair load on older devices, reduced
>damage on spammers, almost mandatory requirement to place damp
>generation on end-user devices) have triggered significant decreases to
>and kept it from widespread adoption.
>
>The strategies for reducing the problems with naïve sender pays are not
>difficult. You send a stamp when:
>
> o you have never sent mail to the user before
> o the site has a DNS TXT record stating:
> o baseline size of required stamp
> o type of s-p (naïve, conditional/hybrid)
> o URL of address->Stamp size server (optional)
>
>I've implemented the first element but the second is going to have to
>wait for a future release.
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:
- 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.
- the client software has to be designed to perform network lookups
and create Hashcash before it sends messages.
- 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.
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.
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.
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ïve way, which
however isn't general knowledge yet.
>> The presence of a recipient specific token itself already qualifies a
>> message, so that spam recognition systems have to rate it in their
>> evaluation process, considering the value (bits) it represents as
>> well. More bits - better rating.
>
>I'm assuming this is as a front-end or part of a content filter. I
>again my concern with that model is that it won't eliminate false
>positives and second, it may give spammers an easy way through for a
>fairly small/low-cost stamp. Have you done any modeling that could help
>put my mind at rest?
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.
Kind regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
Other related posts:
