[ANNOUNCE] contrib/hashcash.el spam fighter

[ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Pay Hashcash
============

   A novel technique to fight spam is to require senders to do something
costly for each message they send.  This has the obvious drawback that
you cannot rely on that everyone uses this technique, since it is
optional, but it may be useful in smaller communities.

   The "something costly" is to burn CPU time, more specifically to
compute a hash collision up to a certain number of bits.  The resulting
hashcash cookie is inserted in a `X-Hashcash:' header. For more
details, and for the external application `hashcash' you need to
install to use this feature, see
`http://www.cypherspace.org/~adam/hashcash/'.  Even more information
can be found at `http://www.camram.org/'.

   If you wish to call hashcash for each message you send, say something
like:

     (require 'hashcash)
     (add-hook 'message-send-hook 'mail-add-payment)

   The `hashcash.el' library can be found at
`http://users.actrix.gen.nz/mycroft/hashcash.el', or in the Gnus
development contrib directory.

   You will need to set up some additional variables as well:

`hashcash-default-payment'
     This variable indicates the default number of bits the hash
     collision should consist of.  By default this is 0, meaning
     nothing will be done.  Suggested useful values include 17 to 29.

`hashcash-payment-alist'
     Some receivers may require you to spend burn more CPU time than the
     default.  This variable contains a list of `(ADDR AMOUNT)' cells,
     where ADDR is the receiver (email address or newsgroup) and AMOUNT
     is the number of bits in the collision that is needed.  It can also
     contain `(ADDR STRING AMOUNT)' cells, where the STRING is the
     string to use (normally the email address or newsgroup name is
     used).

`hashcash'
     Where the `hashcash' binary is installed.

   Currently there is no built in functionality in Gnus to verify
hashcash cookies, it is expected that this is performed by your hand
customized mail filtering scripts.  Improvements in this area would be
a useful contribution, however.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[David Masterson]

>>>>> Simon Josefsson writes:

> Pay Hashcash
> ============

Interesting.  Is this technique any better than TMDA (tmda.sf.net)?

-- 
David Masterson
dsm@rawbw.com

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* David Masterson <dsm@rawbw.com>  on Sat, 22 Jun 2002
| Interesting.  Is this technique any better than TMDA (tmda.sf.net)?

No.

The way hashcash works is quite simple.  Your MTA contacts my MTA because
you want to deliver mail to me.  Me (my MTA) picks two random numbers,
multiplies them, and mashes the result through MD5.  That gives me 128 bits
of fairly random data.  I say, "you must find two numbers that when
multiplied together and have their product mashed through MD5 generate a
hash that has 70 bits in common with this hash.  Give me those numbers."
You go through the effort of picking random numbers, multiplying them,
mashing them through MD5, and comparing the hashes.  As I understand it, 64
bits of match is a 50% chance of a hit the first attempt, and each increase
of 1 bit of match approximately doubles the number of iterations.

The hashcash system works at the MTA level becuase the recipient can say,
"this is your postage due".  Hashcash can be tuned, adjusting the number of
matched bits based on whatever criteria the server manager wants, such as a
scoring algorithm that uses the DCC.  The system needs everyone to adopt
it, or it will not work.

Hashcash cannot work at the MUA level because the receiving MUA cannot tell
the sender, "this is your price of doing business with me".  The sender
sets whatever "postage" rate he wants, which can be as negligible as using
the same data again and again, or simply incrementing a number by 1 and
hashing it, or picking data randomly from a pregenerated table, and make
any claims it wants about the postage it is paying.

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[David Masterson]

>>>>> Stainless Steel Rat writes:

> The way hashcash works is quite simple.  Your MTA contacts my MTA
> because you want to deliver mail to me.  

This right here sounds like a problem.  My limited reading of the
references made me think it was more of a signature methodology like
TMDA.  I didn't realize there was a side connection between the people
that must happen even before the mail can be sent.  This would seem to
be more of a penalty to the email remailer (ie. the ISP) than the
spammer himself (but if the ISP's work goes up, I suppose he'd kick
the spammer out).

> The system needs everyone to adopt it, or it will not work.

Because, until everyone adopts it, the MTAs cannot just kick out
messages that do not have the proper "postage", correct?

> Hashcash cannot work at the MUA level because the receiving MUA
> cannot tell the sender, "this is your price of doing business with
> me".  

Why not?  And, if the MUA can't, what part does this hashcash.el
package (which, I assume, hooks into Gnus) play in things?

-- 
David Masterson
dsm@rawbw.com

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

David Masterson <dsm@rawbw.com> writes:

>>>>>> Simon Josefsson writes:
>
>> Pay Hashcash
>> ============
>
> Interesting.  Is this technique any better than TMDA (tmda.sf.net)?

It is different.  Today, it is probably not "better", but in limited
communities it could be effective.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* David Masterson <dsm@rawbw.com>  on Sun, 23 Jun 2002
| Why not?  And, if the MUA can't, what part does this hashcash.el
| package (which, I assume, hooks into Gnus) play in things?

Because it relies on the good faith of the sender.  Spammers have none.

I do not see what purpose hashcash.el can possibly serve, other than to
penalize legitimate senders while doing nothing to spammers.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * David Masterson <dsm@rawbw.com>  on Sun, 23 Jun 2002
> | Why not?  And, if the MUA can't, what part does this hashcash.el
> | package (which, I assume, hooks into Gnus) play in things?
>
> Because it relies on the good faith of the sender.  Spammers have none.
>
> I do not see what purpose hashcash.el can possibly serve, other than to
> penalize legitimate senders while doing nothing to spammers.

If you send mail to people that you know only accept mail with a
X-Hashcash: of a certain bit size, you can make Gnus generate that
header (see `hashcash-payment-alist').  If the community that uses
Hashcash grows to include most of the Internet, spammers will have
problems.

But you don't have to use it if you don't want to.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Mark Milhollan]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>* David Masterson <dsm@rawbw.com>  on Sun, 23 Jun 2002
>| Why not?  And, if the MUA can't, what part does this hashcash.el
>| package (which, I assume, hooks into Gnus) play in things?
>
>Because it relies on the good faith of the sender.  Spammers have none.
>
>I do not see what purpose hashcash.el can possibly serve, other than to
>penalize legitimate senders while doing nothing to spammers.

Hashcash is a rate-limiting tool -- forcing a compute intensive operation
delays every message by some amount of time -- primarily useful to the
anonymous remailer and Usenet posting networks.  Most people only send a
few dozen or hundred messages per day so they have more time to compute the
hash than a spammer who is trying to deliver as fast as possible.  MTA's
that demand Hashcash are likely to drop connections that won't provide them
(so far as I know none of these exist) or discard messages without them
(these exist).  Without code to handle it Gnus users will be at a
disadvantage.

The main down-side, which has kept it from being widely deployed for the 6+
years that the technique has been discussed, is that the bit length has to
be set high enough so that spammers using high-end systems are impeded, yet
that same setting tends to take a very long, perhaps intolerably so, time
on an older system.

I agree with you that it's a futile move, spammers will throw cycles at the
problem and keep on spewing, while people with P90's will be limited to a
few messages a day (as long as their system isn't doing anything else).


/mark

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Sun, 23 Jun 2002
| If you send mail to people that you know only accept mail with a
| X-Hashcash: of a certain bit size,

If I send mail to people that only accept mail with a X-Hashcash of a
certain bit size, I can pick a hash out of a small table of pregenerated
hashes of that size or larger, circumventing the "security" of the scheme.

No anti-spam scheme that relies on good faith will ever work, because
spammers have none.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Simon Josefsson <jas@extundo.com>  on Sun, 23 Jun 2002
> | If you send mail to people that you know only accept mail with a
> | X-Hashcash: of a certain bit size,
>
> If I send mail to people that only accept mail with a X-Hashcash of a
> certain bit size, I can pick a hash out of a small table of pregenerated
> hashes of that size or larger, circumventing the "security" of the scheme.

Pregenerated or not, the computation of the field requires someone to
burn CPU time, if the limit is set sufficiently high spammers will
find it costs too much to send spam, which is the point.

I'm not saying it is a perfect scheme.  Spamming is a social problem
and cannot be eliminated completely by technical means.  But
experimenting with different technical solutions could perhaps
eventually improve the situation.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Sun, 23 Jun 2002
| Pregenerated or not, the computation of the field requires someone to
| burn CPU time, if the limit is set sufficiently high spammers will
| find it costs too much to send spam, which is the point.

For the sake of argument, say that hashcash.el users want a 128 bit hash.
Today I calculate a 128 bit hash and send out a million messages using that
hash in the X-Hashcash header.  Tomorow I generate a new 128 bit hash so
that the old one is no longer useful as filter bait, and send out another
million messages.  I repeat this cycle indefinitely.

Please explain to me where in this scheme I am burning any significant CPU
time generating hashes, or how it forces the spammer to do more work than
the recipients, because I cannot see it.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[David Masterson]

>>>>> Stainless Steel Rat writes:

> * Simon Josefsson <jas@extundo.com>  on Sun, 23 Jun 2002

> | Pregenerated or not, the computation of the field requires someone
> | to burn CPU time, if the limit is set sufficiently high spammers
> | will find it costs too much to send spam, which is the point.

> For the sake of argument, say that hashcash.el users want a 128 bit
> hash.  Today I calculate a 128 bit hash and send out a million
> messages using that hash in the X-Hashcash header.  Tomorow I
> generate a new 128 bit hash so that the old one is no longer useful
> as filter bait, and send out another million messages.  I repeat
> this cycle indefinitely.

> Please explain to me where in this scheme I am burning any
> significant CPU time generating hashes, or how it forces the spammer
> to do more work than the recipients, because I cannot see it.

Is that the method of using hashcash?  It would seem for it to be used
as postage, the hash would have to be calculated for each person you
(the spammer) want to send email to (assuming everyone was requiring
postage).  Therefore, it's not compute 1 128-bit hash and send out a
million messages, but rather compute a million 128-bit hashes to apply
to each message.

-- 
David Masterson
dsm@rawbw.com

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Kai Großjohann]

David Masterson <dsm@rawbw.com> writes:

> Is that the method of using hashcash?  It would seem for it to be used
> as postage, the hash would have to be calculated for each person you
> (the spammer) want to send email to (assuming everyone was requiring
> postage).  Therefore, it's not compute 1 128-bit hash and send out a
> million messages, but rather compute a million 128-bit hashes to apply
> to each message.

How do the spam recipients know whether the hash has been reused?  If
they can tell the hash has been reused, then they can refuse the
message.  But probably, they can't tell and so they think everything
is fine and dandy.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

On Sun, 23 Jun 2002, Stainless Steel Rat wrote:

> * Simon Josefsson <jas@extundo.com>  on Sun, 23 Jun 2002
> | Pregenerated or not, the computation of the field requires someone to
> | burn CPU time, if the limit is set sufficiently high spammers will
> | find it costs too much to send spam, which is the point.
> 
> For the sake of argument, say that hashcash.el users want a 128 bit hash.

That's probably impractical for most people, even a ~30 bit collision can
take about 10 minutes to find on a PC.

> Today I calculate a 128 bit hash and send out a million messages using that
> hash in the X-Hashcash header.  Tomorow I generate a new 128 bit hash so
> that the old one is no longer useful as filter bait, and send out another
> million messages.  I repeat this cycle indefinitely.

This is not how X-Hashcash works.  The sender must generate a X-Hashcash
specific for each recipient.  The recipient keeps a database of received
coins to prevent double spendings.  There are some descriptions and links
at http://www.cypherspace.org/~adam/hashcash/.

> Please explain to me where in this scheme I am burning any significant CPU
> time generating hashes, or how it forces the spammer to do more work than
> the recipients, because I cannot see it.

The sender must burn CPU or the receiver will not accept the message, for 
some user defined value of "accept".

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Mon, 24 Jun 2002
| That's probably impractical for most people, even a ~30 bit collision can
| take about 10 minutes to find on a PC.

Well, yes.  That is the point of the hashcash system: to make delivery more
expensive in CPU cycles than spammers are willing to pay.

[...]
| This is not how X-Hashcash works.  The sender must generate a X-Hashcash
| specific for each recipient.  The recipient keeps a database of received
| coins to prevent double spendings.  There are some descriptions and links
| at http://www.cypherspace.org/~adam/hashcash/.

So, the recipient must keep a list of -all- hashes he has received?  And
must search that ever-increasing database for every message he receives?
This puts more work on the recipient than on the sender.  And what happens
when a legitimate sender accidentally generates a hash that has been used
already?

The more I learn about X-Hashcash, the more I see that it is doomed to
fail.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | This is not how X-Hashcash works.  The sender must generate a X-Hashcash
> | specific for each recipient.  The recipient keeps a database of received
> | coins to prevent double spendings.  There are some descriptions and links
> | at http://www.cypherspace.org/~adam/hashcash/.
>
> So, the recipient must keep a list of -all- hashes he has received?  And
> must search that ever-increasing database for every message he receives?
> This puts more work on the recipient than on the sender.  

No, it does not work like that.  Each coin has a limited life length
(e.g., 28 days), the receiver only has to keep track of valid ones
within the time window.  This is explained on the web page...

> And what happens when a legitimate sender accidentally generates a
> hash that has been used already?

If you have good random number generator, this won't happen in practice.

> The more I learn about X-Hashcash, the more I see that it is doomed to
> fail.

Do you have a better idea?

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Jason R. Mastaler]

Simon Josefsson <jas@extundo.com> writes:

>> Interesting.  Is this technique any better than TMDA (tmda.sf.net)?
>
> It is different.  Today, it is probably not "better", but in limited
> communities it could be effective.

I would say today it is definitely not "better".  TMDA can be deployed
immediately because it doesn't require infrastructure and MUA support
to work.

In an ideal world though, hashcash would be pretty nice I think.

-- 
(http://tmda.sourceforge.net/)

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Mon, 24 Jun 2002
| No, it does not work like that.  Each coin has a limited life length
| (e.g., 28 days), the receiver only has to keep track of valid ones
| within the time window.

I-the-spammer generate a new hash every hundred thousand messages or so.
I-the-spammer easilly circumvent the X-Hashcash system, and without even
trying hard.

| This is explained on the web page...

I looked.  The X-Hashcash scheme is fundamentally flawed.  It relies on the
sender being honest when he says that he spent the time generating the hash
when he puts it in his headers.  It does not stop spam.  It only gives the
end user a useless header and an fHuge database of signatures.

[...]
| > The more I learn about X-Hashcash, the more I see that it is doomed to
| > fail.
| Do you have a better idea?

Hashcash at the MTA level.  That is enforceable because the recipient says
"find X bits of collision with this hash or your message will not be
accepted".  It does not rely on the good faith of the sender, it forces the
sender to solve a problem in real time.

Or make spam a federal crime like junk faxes and then enforce it.

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Simon Josefsson <jas@extundo.com>  on Mon, 24 Jun 2002
> | No, it does not work like that.  Each coin has a limited life length
> | (e.g., 28 days), the receiver only has to keep track of valid ones
> | within the time window.
>
> I-the-spammer generate a new hash every hundred thousand messages or so.
> I-the-spammer easilly circumvent the X-Hashcash system, and without even
> trying hard.

How?  The coin is specific for each recipient, and you can only use
each coin once.  To create a new coin, you need to burn CPU time.  If
you send the same hash in more than one message to the same recipient,
the double spending database will notice and reject it, and if you
send the same hash to another recipient, the other recipient cannot
verify the coin and rejects it.

> | This is explained on the web page...
>
> I looked.  The X-Hashcash scheme is fundamentally flawed.  It relies on the
> sender being honest when he says that he spent the time generating the hash
> when he puts it in his headers.

From how I understand it, the receiver verifies that the sender spent
time generating the coin by verifying the coin, it is not simply
trusting the sender about that.

> | > The more I learn about X-Hashcash, the more I see that it is doomed to
> | > fail.
> | Do you have a better idea?
>
> Hashcash at the MTA level.  That is enforceable because the recipient says
> "find X bits of collision with this hash or your message will not be
> accepted".

This would slow down my mail server a bit, but is otherwise good.  One
good thing with doing hashcash in the MUA is that only my own machine
is slowed down.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Mon, 24 Jun 2002
| the double spending database will notice and reject it, and if you
| send the same hash to another recipient, the other recipient cannot
| verify the coin and rejects it.

That is a digital signature, not hashcash.  No wonder I have been confused.

Err... calculating digital signatures is computationally trivial.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

Wait.  I see how it is supposed to work.  And I was right: it is useless as
a general purpose spam fighting tool, but for different reasons than I had
previously thought.

X-Hashcash is intended for sending mail to big mail-to-news gateways,
mailing list, and such.  It requires that the recipient -- the gateway or
list -- publish a challenge phrase and number of collisions bits that are
required for sending messages through it.  These published challenges take
the place of the randomly generated numbers -- session keys -- that MTA
hashcash uses.

The system is not so useful for end users simply because many (most?) have
no means of publishing challenges or informing legitimate senders that they
even exist.  The whole thing falls apart if recipients cannot challenge
senders.

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

undo mail catchup w .snapshot .[mumble]rc ?

[Yeoh Yiu]

I have an archived filesystem.
If I accidently caught up news, I could delete my current
.newsrc and replace it with a day / 4 hour etc old .newsrc.
and I would once again know which news was new to me,
and what was already read.

What if I accidently catch up a mail group ?

(Oh, I never run any expires.)

My mail groups are fed as follows:

(setq gnus-secondary-select-methods
      '((nnml "private")))

(setq nnmail-split-methods
      '(
   ("red-hat.general"   "^Resent-From: redhat-list@redhat.com")
        ("ding"       "^To: ding@ifi.uio.no")
...

YY
squid@panix.com

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> X-Hashcash is intended for sending mail to big mail-to-news gateways,
> mailing list, and such.

Not only, it works in peer 2 peer as well.  Frankly, hashcash has some
problems in big mailing lists (do you mint the coin to the mailing
list or to each member?  The latter probably requires the mailserver
to do it, which is impractical, the former require some additional
intelligence in clients (it knows which email lists it is a member
of)).

> It requires that the recipient -- the gateway or list -- publish a
> challenge phrase and number of collisions bits that are required for
> sending messages through it.  These published challenges take the
> place of the randomly generated numbers -- session keys -- that MTA
> hashcash uses.
>
> The system is not so useful for end users simply because many (most?) have
> no means of publishing challenges or informing legitimate senders that they
> even exist.  The whole thing falls apart if recipients cannot challenge
> senders.

hashcash.el uses the recipients email address as a challenge.  If you
know the recipients email address, you know the hashcash challenge, so
this should work.  A spammer could compute these, but he could only
use it once.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Tue, 25 Jun 2002
| Not only, it works in peer 2 peer as well.

Yeah, but PGP works better.  Three words: web of trust.  X-Hashcash cannot
have a web of trust.  And PGP can work without prior contact through PGP
key servers.  X-Hashcash cannot do that, either.

| hashcash.el uses the recipients email address as a challenge.  If you
| know the recipients email address, you know the hashcash challenge, so
| this should work.  A spammer could compute these, but he could only
| use it once.

No, he could only use it once every 28 days by default.  Still, there may
be a way of exploiting the Bcc mechanism or RCPT TO at the SMTP level, both
common spam tactics.  If a spammer were to generate a hash against a bogus
To header (like most of the spam I get), he could blindly send his spam to
millions of recipients with only one hash.  Yes, you could check the
X-Hashcash coin against your known address, but that leads you directly
into a false negative if a legitimate sender Bccs you something.

The system is also vunlerable to false positives.  The likelyhood of an
accidentally duplicated coin increases with the number of users.  And it is
potentially vulnerable to denial of service by the same mechanism.

I'll take back what I said about hoping it dies, because it does serve a
useful function within its limited scope.  DCC and Razor are vastly
superior mechanisms for filtering spam for end users.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.
       That and five bucks will get you a small coffee at Starbucks.

Re: undo mail catchup w .snapshot .[mumble]rc ?

[Paul Jarc]

Yeoh Yiu <squid@panix.com> wrote:
> I have an archived filesystem.
> If I accidently caught up news, I could delete my current
> .newsrc and replace it with a day / 4 hour etc old .newsrc.
> and I would once again know which news was new to me,
> and what was already read.
>
> What if I accidently catch up a mail group ?

With 5.8.8, restore ~/.newsrc.eld.  That file contains all the
information from .newsrc, as well as marks for mail groups.


paul

Re: undo mail catchup w .snapshot .[mumble]rc ?

[Yeoh Yiu]

prj@po.cwru.edu (Paul Jarc) writes:

> > What if I accidently catch up a mail group ?
> 
> With 5.8.8, restore ~/.newsrc.eld.  That file contains all the
> information from .newsrc, as well as marks for mail groups.

Great, thanks that worked.
Now to finish synchronizing my ~/.newsrc.eld files.

YY

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | A spammer could compute these, but he could only use it once.
> 
> No, he could only use it once every 28 days by default.

No.  I think you still do not fully understand the hashcash scheme...

The hashed value includes both the recipient's address and the date.
The hash is valid only if the recipient address is correct *and* the
date is recent.  "Recent" can be 28 days, 1 week, 1 day, or whatever
you like; it depends on how long you want to allow the coin to be
valid (for the convenience of the sender) versus how long you want to
keep old coins listed in your local database.

> Still, there may be a way of exploiting the Bcc mechanism or RCPT TO
> at the SMTP level, both common spam tactics.  If a spammer were to
> generate a hash against a bogus To header (like most of the spam I
> get), he could blindly send his spam to millions of recipients with
> only one hash.  Yes, you could check the X-Hashcash coin against
> your known address, but that leads you directly into a false
> negative if a legitimate sender Bccs you something.

The sender must include a separate hash for every recipient, whether
CC'd or BCC'd.  Depending on the structure of the hash, this may or
may not directly reveal to whom you BCC'd.  (It certainly makes it
possible for someone else to *guess* to whom you BCC'd, which is a
downside.  I doubt you can correct this deficiency without public-key
crypto, though.)

> The system is also vunlerable to false positives.  The likelyhood of
> an accidentally duplicated coin increases with the number of users.
> And it is potentially vulnerable to denial of service by the same
> mechanism.

It does not matter if two duplicated coins appear somewhere in the
world; what matters is whether somebody can exploit them.  With any
reasonable number of bits, they cannot.  One false positive out of a
million messages, or a billion messages, is certainly a ratio I could
tolerate.

I do not think hashcash will catch on because it is too complex.  But
it is technically sound, your half-dozen misinformed messages on the
topic notwithstanding :-).

 - Pat

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* "Patrick J. LoPresti" <patl@curl.com>  on Fri, 28 Jun 2002
| The hashed value includes both the recipient's address and the date.
| The hash is valid only if the recipient address is correct *and* the
| date is recent.  "Recent" can be 28 days, 1 week, 1 day, or whatever
| you like; it depends on how long you want to allow the coin to be
| valid (for the convenience of the sender) versus how long you want to
| keep old coins listed in your local database.

Okay.  That can be problematic if you set it to be too long or too short.
It would really suck to have important, legitimate mail tagged as spam
because of sending delays.

| The sender must include a separate hash for every recipient, whether
| CC'd or BCC'd.

But how can you, the recipient, know which hash in a BCC hash list is
"yours" if there is no disclosure of the recipients list?  You can't.  But
like trying to abuse POP as an IMAP server, if you have a problem trying to
use a saw to drive nails then the problem is you, not the saw.  If you try
to use X-Hashcash as an authentication mechanism then you deserve what you
get.


| It does not matter if two duplicated coins appear somewhere in the
| world; what matters is whether somebody can exploit them.  With any
| reasonable number of bits, they cannot.  One false positive out of a
| million messages, or a billion messages, is certainly a ratio I could
| tolerate.

What about one false positive out of 100 messages?  Can you say "denial of
service"?  X-Hashcash does not scale.

| I do not think hashcash will catch on because it is too complex. 

Hashcash and X-Hashcash are not the same thing.  Please do not confuse the
two.

| But it is technically sound, your half-dozen misinformed messages on the
| topic notwithstanding :-).

Oh, I am hardly misinformed -now-.  I see X-Hashcash for what it is, what
it is intended to accomplish, and what some might try to misuse it as.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | The sender must include a separate hash for every recipient, whether
> | CC'd or BCC'd.
> 
> But how can you, the recipient, know which hash in a BCC hash list is
> "yours" if there is no disclosure of the recipients list?  You
> can't.

Right, so you have to try them all.  Checking the validity of a coin
is "fast", so this is OK, in theory.  You also need to try every
address which the sender might have used to BCC you, which assumes you
know all of them...  I suppose there might be some hints in the
Received headers to speed all this up, but yeah, it is not pretty.

Then again, it is not disastrous if you miss a message.  It will be a
long time (ha ha) before everybody is using X-Hashcash, so you will
occasionally have to sift through the rejects folder to find some
legitimate messages anyway.

> What about one false positive out of 100 messages?  Can you say "denial of
> service"?  X-Hashcash does not scale.

Well, you get to decide how many bits you require the sender to match,
so you can make it one out of however many you like.

Or am I misunderstanding what you mean?

> Hashcash and X-Hashcash are not the same thing.  Please do not
> confuse the two.

Yup; I apologize.

I think X-hashcash is a creative attempt at a technological solution
to spam.  And for some applications, like a public mailing list, it
might even be practical.  Who cares whether you can BCC ding@gnus.org,
for instance?

It seems unlikely to catch on as a user-to-user filtering scheme;
digital signatures are probably a better approach for that.

 - Pat

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* "Patrick J. LoPresti" <patl@curl.com>  on Fri, 28 Jun 2002
| Right, so you have to try them all.  Checking the validity of a coin
| is "fast", so this is OK, in theory.

Not even in theory.  It is a linear problem, and linear problems do not
scale.

[...]

| Then again, it is not disastrous if you miss a message.

And if that lost message is the job offer I am expecting?  -Anything- that
causes loss of legitimate mail is BAD.  Really bad.  Unacceptably bad, in
my opinion and that of the 350 employees in my company who expect mail not
to be lost.

[...]
| Well, you get to decide how many bits you require the sender to match,
| so you can make it one out of however many you like.

| Or am I misunderstanding what you mean?

You are misunderstanding.  Say that you (not necessarilly "you" personally,
but anyone or thing that relies on X-Hashcash headers) want 20 bits
collision (that is a 1:2^20 probability of any two hashes of the same total
length meeting the criteria, or approximately 1 in 1 million, just so you
know).  And say that I use something like Sub7 to distribute my X-Hashcash
DoS system to a mere five thousand machines, which can calculate hashes at
a rate of 1 every 10 seconds, just to pull some numbers out of my behind
(10 seconds is rather slow by today's standards, anyway).  That is 1.8
million hashes per hour.

All those hashes being dumped into your spent coin database.  And five
thousand Sub7 variant infections is a very conservative number.

Do you begin to see the vulnerabilities in X-Hashcash?

| I think X-hashcash is a creative attempt at a technological solution
| to spam.

It is an attempt at blocking or preventing spam from being sent to
mail2news gateways.  It has a -very- narrow focus.

| And for some applications, like a public mailing list, it might even be
| practical.  Who cares whether you can BCC ding@gnus.org, for instance?

Ask the spammers who's mail has recently been sent here. :)

BCC has legitimate uses for legitimate mail.  Today I used it to inform a
number of people who were using excessvie ammounts of disk space on one of
my machines without embarrassing them by revealing their identities.

| It seems unlikely to catch on as a user-to-user filtering scheme;
| digital signatures are probably a better approach for that.

Or a real hashcash system.

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Patrick J. LoPresti" <patl@curl.com>  on Fri, 28 Jun 2002
> | Right, so you have to try them all.  Checking the validity of a coin
> | is "fast", so this is OK, in theory.
>
> Not even in theory.  It is a linear problem, and linear problems do not
> scale.

The number of email addresses a person has is usually a constant, so
the problem is O(1).

> | Then again, it is not disastrous if you miss a message.
>
> And if that lost message is the job offer I am expecting?  -Anything- that
> causes loss of legitimate mail is BAD.  Really bad.  Unacceptably bad, in
> my opinion and that of the 350 employees in my company who expect mail not
> to be lost.

I wouldn't reject failed hashcash, I would treat it as mail that don't
have hashcash.  Hashcash improves the situation in most cases, and in
the remote cases where it fails, it doesn't make things worse than it
was before.

> [...]
> | Well, you get to decide how many bits you require the sender to match,
> | so you can make it one out of however many you like.
>
> | Or am I misunderstanding what you mean?
>
> You are misunderstanding.  Say that you (not necessarilly "you" personally,
> but anyone or thing that relies on X-Hashcash headers) want 20 bits
> collision (that is a 1:2^20 probability of any two hashes of the same total
> length meeting the criteria, or approximately 1 in 1 million, just so you
> know).  And say that I use something like Sub7 to distribute my X-Hashcash
> DoS system to a mere five thousand machines, which can calculate hashes at
> a rate of 1 every 10 seconds, just to pull some numbers out of my behind
> (10 seconds is rather slow by today's standards, anyway).  That is 1.8
> million hashes per hour.
>
> All those hashes being dumped into your spent coin database.  And five
> thousand Sub7 variant infections is a very conservative number.
>
> Do you begin to see the vulnerabilities in X-Hashcash?

Not at all, it seems to work fine, if in your example hashcash forces
spammers to invest in knowledge to get a cluster with 5000 machines to
work.  Making it expensive to spam is the whole point of hashcash.

Also, in practice the collision size people will use will be close to
30 bits though, and is increased over time as CPUs gets faster.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Fri, 28 Jun 2002
| The number of email addresses a person has is usually a constant, so
| the problem is O(1).

And in a list of 500 hashes, which one is yours?  Remember, this is a BCC
list, so there is no association of hashes to addresses.


| I wouldn't reject failed hashcash, I would treat it as mail that don't
| have hashcash.  Hashcash improves the situation in most cases, and in
| the remote cases where it fails, it doesn't make things worse than it
| was before.

This makes no sense to me.  If the purpose of X-Hashcash (not hashcash,
they are NOT the same thing) on a personal level is a spam filtering
mechanism, and you receive a message that has a "spent" coin, you treat
that message as a message that has no coin at all?  If so, then what is the
point of keeping a database of spent coins?


| Not at all, it seems to work fine, if in your example hashcash forces
| spammers to invest in knowledge to get a cluster with 5000 machines to
| work.  Making it expensive to spam is the whole point of hashcash.

You seem to be unaware of what Sub7 is.  Look it up on Symantec's
anti-virus web site.  They describe it better than I can.  It would take me
(as DoS attacker) very little effort to assemble a network of many
thousands of machines, secretly stealing CPU cycles from all over the world
to generate hashes with which to cripple someone's mail server.  The
X-Hashcash spent coin database is a fundamental weakness that can be
exploited.

Real hashcash uses no spent coin database because every attempt to send a
message causes the recipient server to generate a new, random challenge.
Think of it as a one use session key, like an S/Key or SecurID system.
Challenges are never predictably reused so a spammer or DoS attacker can
only generate hashes against challenges in real time.  And the way that
real hashcash scales is that the receiving server can adjust the minimum
collision size based on simple criteria.  For example, a server with a
default of 19 bits could have a rule that says "26 bits for anything in the
korea.services.net block list".  Adaptive servers could automatically
adjust minimum collision size for particular sending servers that appear to
be much faster or slower than the default collision size.

| Also, in practice the collision size people will use will be close to
| 30 bits though, and is increased over time as CPUs gets faster.

30 bits?  You must be joking.  A 30 bit collision is a 1:2^30 probability
At a rate of 200,000 hashes per second (which is pretty fast for a desktop
machine today, actually) it would take on average 5,368 seconds to find
just one collision.  That's 1.5 HOURS.

30 bits?  No way.  Not for another 5 years at least.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | The number of email addresses a person has is usually a constant, so
> | the problem is O(1).
>
> And in a list of 500 hashes, which one is yours?  Remember, this is a BCC
> list, so there is no association of hashes to addresses.

I try them all, which doesn't take more than a few ns.  OTOH I rarely
see mail with 500 direct recipients, so this isn't a typical scenario.

> | I wouldn't reject failed hashcash, I would treat it as mail that don't
> | have hashcash.  Hashcash improves the situation in most cases, and in
> | the remote cases where it fails, it doesn't make things worse than it
> | was before.
>
> This makes no sense to me.  If the purpose of X-Hashcash (not hashcash,
> they are NOT the same thing) on a personal level is a spam filtering
> mechanism, and you receive a message that has a "spent" coin, you treat
> that message as a message that has no coin at all?  If so, then what is the
> point of keeping a database of spent coins?

To put mail with valid hashcash in a separate, supposedly spam-free,
mailbox.

> | Not at all, it seems to work fine, if in your example hashcash forces
> | spammers to invest in knowledge to get a cluster with 5000 machines to
> | work.  Making it expensive to spam is the whole point of hashcash.
>
> You seem to be unaware of what Sub7 is.  Look it up on Symantec's
> anti-virus web site.  They describe it better than I can.  It would take me
> (as DoS attacker) very little effort to assemble a network of many
> thousands of machines, secretly stealing CPU cycles from all over the world
> to generate hashes with which to cripple someone's mail server.  The
> X-Hashcash spent coin database is a fundamental weakness that can be
> exploited.

I don't understand this argument, the whole point of hashcash is that
you need to spend CPU to overcome it.  How you aquire that CPU is
irrelevant.  If all spammers were required to acquire it using sub7,
people would start to fix the sub7 problem, not stop using hashcash,
and things would be fine.

By the same argument, all cryptography has a weakness because you can
brute force it using sub7.  It is not a weakness to me, but a design
goal.

> | Also, in practice the collision size people will use will be close to
> | 30 bits though, and is increased over time as CPUs gets faster.
>
> 30 bits?  You must be joking.  A 30 bit collision is a 1:2^30 probability
> At a rate of 200,000 hashes per second (which is pretty fast for a desktop
> machine today, actually) it would take on average 5,368 seconds to find
> just one collision.  That's 1.5 HOURS.
>
> 30 bits?  No way.  Not for another 5 years at least.

30 bits would allow a desktop PC to send 16 mails per day, that's
probably more that I need.  If you use too few bits (like anything
under 23-24), spammers will have it to easy to acquire that amount of
CPU.  29 bits have been suggested as a value to use in practice.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Sat, 29 Jun 2002
| To put mail with valid hashcash in a separate, supposedly spam-free,
| mailbox.

But since spammers can generate hashes themselves, your supposedly
spam-free X-Hashcash (not hashcash!) mailbox will not be spam-free.


| I don't understand this argument, the whole point of hashcash is that
| you need to spend CPU to overcome it.  How you aquire that CPU is
| irrelevant.  If all spammers were required to acquire it using sub7,
| people would start to fix the sub7 problem, not stop using hashcash,
| and things would be fine.

Using Sub7 for generating hashes is not a mechanism for sending spam, it is
a Denial of Service attack against the X-Hashcash database, to make it grow
to unweildly size and to fill it with hashes that cause false positives.
All the words matter.

You also still seem not understand what Sub7 is.  I suggest you read up on
in just as I read up on X-Hashcash.


| 30 bits would allow a desktop PC to send 16 mails per day, that's
| probably more that I need.

Yes, well, this is not about -you-.  16 messages in a 24 hour period for me
would basically make it impossible for me to do my job as a Unix admin.

| If you use too few bits (like anything under 23-24), spammers will have
| it to easy to acquire that amount of CPU.  29 bits have been suggested as
| a value to use in practice.

Funny, the defaults I have seen for both X-Hashcash and hashcash are 18-22
bits.

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Jan Rychter <jan@rychter.com>  on Sat, 29 Jun 2002
| I guess this discussion is a bit off-topic, but since it continues
| anyway, I'll drop in: I don't think I will use hashcash in any
| foreseeable future. The reason is quite simple: the price I have to pay
| is too high. CPU time is _expensive_, if you work on a laptop computer
| where battery life and power (heat!) are valuable commodities. Laptops
| are not made for continuous CPU usage.

Actually, hashcash -- not X-Hashcash -- is transparent to the end user.  It
runs at the MTA level, entirely behind the scenes, with no user interaction.
And if you do not run a local MTA then you will not see even that.

Real hashcash -- NOT X-Hashcash!!!! They are not the same thing! -- does
not force senders to spend hours and hours calculating a single hash
collision.  The idea is to make him spend 5 or 6 seconds calculating a
single collision.  That is negligible for most legitimate uses, but for
spammers sending out bulk, that 5 seconds times 5 million is thousands of
hours of CPU time.  That is where hashcash works... and X-Hashcash does
not, so PLEASE! do not confuse the two or treat them as the same thing.

Thank you.

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Patrick J. LoPresti" <patl@curl.com>  on Fri, 28 Jun 2002
> | Right, so you have to try them all.  Checking the validity of a coin
> | is "fast", so this is OK, in theory.
> 
> Not even in theory.  It is a linear problem, and linear problems do not
> scale.

Sure, it is linear in the number of recipients times the number of
addresses you have.  But this product for a typical message is not
increasing over time, so there is no scalability problem.

> [...]
> 
> | Then again, it is not disastrous if you miss a message.
> 
> And if that lost message is the job offer I am expecting?

Do you usually have job offers BCC'd to you?  :-)

You are correct that you cannot combine BCC's with X-Hashcash without
risking the privacy of the BCC.  (All someone else has to do is guess
that you were a recipient, then check the X-Hashcash header to confirm
it.)  So BCC'd messages would have to go into your "has no X-Hashcash
header" folder for later perusal.  You will need such a folder anyway
as long as you have correspondents who are not using X-Hashcash.

> -Anything- that causes loss of legitimate mail is BAD.  Really bad.
> Unacceptably bad, in my opinion and that of the 350 employees in my
> company who expect mail not to be lost.

Tagging mail as potential spam, then perusing it later, is not
"losing" it.  In fact it is precisely how many (perhaps most) existing
spam-filtering implementations work.

> That is 1.8 million hashes per hour.
> 
> All those hashes being dumped into your spent coin database.  And five
> thousand Sub7 variant infections is a very conservative number.

You do not record invalid coins as "spent", because you can always
recognize them as being invalid.  Only valid coins need to be
remembered, and creating even a single valid coin is computationally
expensive.  How expensive is up to the recipient to choose.

> Do you begin to see the vulnerabilities in X-Hashcash?

I have yet to see you present any.  Yes, it does not combine well with
BCC.  But so far, that is the only correct argument you have made...

 - Pat

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Real hashcash -- NOT X-Hashcash!!!! They are not the same thing! --
> does not force senders to spend hours and hours calculating a single
> hash collision.  The idea is to make him spend 5 or 6 seconds
> calculating a single collision.  That is negligible for most
> legitimate uses, but for spammers sending out bulk, that 5 seconds
> times 5 million is thousands of hours of CPU time.  That is where
> hashcash works... and X-Hashcash does not, so PLEASE! do not confuse
> the two or treat them as the same thing.

If those 5 million recipients all use X-Hashcash, the spammer has to
compute a distinct hash for each of them.  Sounds like it works to me.

X-Hashcash is just hashcash implemented by the end user.  You seem to
think that this is somehow fundamentally different than having the MTA
do it, but you have yet to give a very good argument why.  (Other than
failing to work with BCC, but I suspect many people would consider
that fairly minor.)  Having to keep a database of spent coins is the
only extra cost of a non-challenge-response implementation, but that
database is cheap.  Ever use nnmail-treat-duplicates?

If all you want to do is cost the sender 5 or 6 seconds at the MTA
level, why not just stall the TCP connection for 5 seconds per
envelope recipient?  It would be much simpler than hashcash :-).

 - Pat

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* "Patrick J. LoPresti" <patl@curl.com>  on Sat, 29 Jun 2002
| If those 5 million recipients all use X-Hashcash, the spammer has to
| compute a distinct hash for each of them.  Sounds like it works to me.

No, it does not, because the every X-Hashcash recipient needs to keep a
database of used hashes for the system to be effective, and as I already
described -three- times in detail that is a fundamental weakness in the
system that can be exploited by spammers and denial of service attackers.

| X-Hashcash is just hashcash implemented by the end user.  You seem to
| think that this is somehow fundamentally different than having the MTA do
| it, but you have yet to give a very good argument why.

Then you failed to read my posts describing the differences in detail.  In
summary:

X-Hashcash uses a single insecure challenge or a limited number of insecure
challenges that may be used many times by many senders.  X-Hashcash coins
are manually generated by the user "off line" before the message is sent.
X-Hashcash requires the recipient keep a database of spent coins and scan
it for every message received to detect when a coin is respent.  This
database is vulnerable to denial of service attacks in the form of database
flooding, bogus data injected by spammers or attackers (spoofing), false
positives (legitimate mail being tagged as spam due to reused coins from a
spoof or other attack), and false negatives (spam not being tagged because
of coins that appear legitimate).

Hashcash generates a cryptographically secure one-use challenge for every
message sent, much like S/Key and SecurID challenges.  Hashcash coins are
generated automatically in real time by the sending MTA at the time it
attempts delivery; the system is transparent to the end user.  Hashcash
needs no spent coin database -- and thus no overhead to maintain or search
it, and no vulnerabilities due to it -- because coins cannot be reused.

| (Other than failing to work with BCC, but I suspect many people would
| consider that fairly minor.)

Your assumpion is flawed, partially because it is in direct violation of
RFC 2822, partially because "many" is not "all".  See my previously posted
contradictory example.

| Having to keep a database of spent coins is the only extra cost of a
| non-challenge-response implementation, but that database is cheap.  Ever
| use nnmail-treat-duplicates?

Straw man.  .nnmail-cache is a one dimensional table that removes entries
as messages are expired.  X-Hashcash spent coin database is a two
dimensional table -- hashes and time stamps -- that needs to be regularly
pruned based on time stamps and can grow many times larger than stored
messages would indicate, depending on the individual's expiry settings.
They are not comparable either in composition or use.

| If all you want to do is cost the sender 5 or 6 seconds at the MTA
| level, why not just stall the TCP connection for 5 seconds per
| envelope recipient?  It would be much simpler than hashcash :-).

Because it makes the recipient vulnerable to denial of service attacks.

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* "Patrick J. LoPresti" <patl@curl.com>  on Sat, 29 Jun 2002

Speaking of spam filtering stupidity, I cannot send you mail because SPEWS
is turd-stupid.  Just so you know.

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

[snip!]
> BCC has legitimate uses for legitimate mail.  Today I used it to
> inform a number of people who were using excessvie ammounts of disk
> space on one of my machines without embarrassing them by revealing
> their identities.

Note that if I had been one of those, your message would have ended up
in my spam folder, since I let everything not addressed to one of my
addresses, or a mailing list I subscribe to, "fall through" and end up
in nnimap+mymachine:INBOX.SPAM.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Mon, 01 Jul 2002
| Note that if I had been one of those, your message would have ended up
| in my spam folder, since I let everything not addressed to one of my
| addresses, or a mailing list I subscribe to, "fall through" and end up
| in nnimap+mymachine:INBOX.SPAM.

True, Bcc to a mailing list is dumb.  But blanket dropping Bcc'd mail is
also not the smartest thing to do.  Humans make mistakes, and accidentally
delete mail they do not want to delete.  That scheme makes it very easy to
for humans to do so and not relize it.

Remember, I am looking at this from the perspective of anything that leads
to lost mail as being the Worst Thing Imagineable.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> * Steinar Bang <sb@dod.no>  on Mon, 01 Jul 2002

>> Note that if I had been one of those, your message would have ended
>> up in my spam folder, since I let everything not addressed to one
>> of my addresses, or a mailing list I subscribe to, "fall through"
>> and end up in nnimap+mymachine:INBOX.SPAM.

> True, Bcc to a mailing list is dumb.  But blanket dropping Bcc'd
> mail is also not the smartest thing to do.

Which is why I read that folder occasionally to pick up false matches.

But the folder doesn't have high priority.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Mon, 01 Jul 2002
| Which is why I read that folder occasionally to pick up false matches.

Wouldn't it be better if you didn't have to worry about false positives?

| But the folder doesn't have high priority.

Which makes it more likely that you will subconsciously miss something
legitimate hiding in all the junk, yes?

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> * Steinar Bang <sb@dod.no>  on Mon, 01 Jul 2002

>> Which is why I read that folder occasionally to pick up false
>> matches.

> Wouldn't it be better if you didn't have to worry about false
> positives?

It would.

Do you have a solution?

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Tue, 02 Jul 2002
| > Wouldn't it be better if you didn't have to worry about false
| > positives?

| It would.

| Do you have a solution?

Three: a real hashcash system, DCC, and Vipul's Razor.

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Steinar Bang <sb@dod.no>  on Tue, 02 Jul 2002
> | > Wouldn't it be better if you didn't have to worry about false
> | > positives?
>
> | It would.
>
> | Do you have a solution?
>
> Three: a real hashcash system, DCC, and Vipul's Razor.

Approaches like DCC and Vipul's Razor seems a little more pragmatic,
yes, while *hashcash is more of a experiment.  After reading more on
the stuff, I'm now using SpamAssassin connected via SpamAssassMilter
to Sendmail which seems to be quite effective (well, for the last 20
minutes I have been running it, that is :-)).  It also doesn't have
the negative consequences that TMDA has (funny looking email address).

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Karl Kleinpaste]

Simon Josefsson <jas@extundo.com> writes:
> the stuff, I'm now using SpamAssassin connected via SpamAssassMilter
> to Sendmail which seems to be quite effective

Could you show us your configuration bits for both Gnus and sendmail?
A cookbook would be appreciated.

I have extensive anti-spam split rules which are reasonably effective,
but the spammer crowd is working diligently to come up with
ever-harder cases to trap.  The days of simply tossing "anything
lacking To or Cc naming myself" are long gone.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Karl Kleinpaste <karl@charcoal.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> the stuff, I'm now using SpamAssassin connected via SpamAssassMilter
>> to Sendmail which seems to be quite effective
>
> Could you show us your configuration bits for both Gnus and sendmail?
> A cookbook would be appreciated.

I recompiled sendmail with milter support, installed spamassassin from
RPM and compiled and installed spamassassin-milter, started
spamassassin and spamassassin-milter, and added

INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass/spamass.sock, F=, T=C:15m;S:4m;R:4m;E:10m')

to sendmail.mc.  I then use Cyrus Sieve to move X-Sam-Flag: YES
messages into a separate mailbox.  Voila.

http://savannah.gnu.org/projects/spamass-milt/
http://www.sendmail.org/~gshapiro/8.10.Training/milter.html
http://www.sendmail.org/~gshapiro/8.10.Training/milterconfig.html
http://www.milter.org/
http://www.spamassassin.org

> I have extensive anti-spam split rules which are reasonably effective,
> but the spammer crowd is working diligently to come up with
> ever-harder cases to trap.  The days of simply tossing "anything
> lacking To or Cc naming myself" are long gone.

Yup, I have started to realize this as well...

The neat thing with SpamAssassin is that it incorporates many
anti-spam measures; it uses the various DNS-based black lists I used
to use (mostly useless) and Razor's Vipul and many other mechanisms as
well.

The only thing I dislike is that SpamAssassin-Milter rewrites message
bodies, but I'll contribute a patch to fixes that as soon as I've
written it.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> * Steinar Bang <sb@dod.no>  on Tue, 02 Jul 2002
>> > Wouldn't it be better if you didn't have to worry about false
>> > positives?

>> It would.

>> Do you have a solution?

> Three: a real hashcash system, DCC, and Vipul's Razor.

What makes DCC and Vipul's Razor superior to SpamAssassin?  Emails to
my current sender address goes through SpamAssassin, and spam still
gets through.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Tue, 02 Jul 2002
| What makes DCC and Vipul's Razor superior to SpamAssassin?

Orthogonal issue.  SpamAssassin uses DCC and I think Razor.

| Emails to my current sender address goes through SpamAssassin, and spam
| still gets through.

The only 100% effective mechanism for stopping spam is to get it listed
under the junk fax laws.  Short of that, some spam will always get through.

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not taunt Happy Fun Ball.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> The only 100% effective mechanism for stopping spam is to get it
> listed under the junk fax laws. 

I'm in Norway.  We don't have the US junk fax laws, I think.

And how would I sue, or file a complaint against, a spammer situated
in the Fiji Islands?

> Short of that, some spam will always get through.

Which is why I'll continue with my drop-through technique.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Oystein Viggen]

* [Steinar Bang] 

> I'm in Norway.  We don't have the US junk fax laws, I think.

But we do have a law of marketing that lets us sign up on a central
opt-out list for all kinds of addressed unsolicited commercial mail, be
that e-mail, snail mail, GSM SMS, or telemarketing.  (however, I'm not
100% sure of the last one.)  If you are registered on the list, they
can't contact you unless you ask them to or you are already a customer.

For any interested Norwegians, or others that can read the language:
<URL: http://www3.brreg.no/oppslag/reservasjon/index.jsp >

> And how would I sue, or file a complaint against, a spammer situated
> in the Fiji Islands?

Which is exactly the reason why the Norwegian legislation on this matter
isn't really doing anything useful, either.

Such a law in the US _might_ stop the US spammers, though..

Oystein
-- 
This message was generated by a horde of attack elephants armed with PRNGs.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Wed, 03 Jul 2002
| I'm in Norway.  We don't have the US junk fax laws, I think.

| And how would I sue, or file a complaint against, a spammer situated
| in the Fiji Islands?

Well, then, anti-spam legislation needs to be international, like
copyright.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.
       That and five bucks will get you a small coffee at Starbucks.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Kevin Ryde]

Simon Josefsson <jas@extundo.com> writes:
>
> The only thing I dislike is that SpamAssassin-Milter rewrites message
> bodies, but I'll contribute a patch to fixes that as soon as I've
> written it.

I get a bit nervous about modifying mail, so I've just been doing a
straightforward fancy-split on what spamc says,

	(defun my-spamassassin ()
	  (save-excursion
	    (let ((buf (or (get-buffer " *nnmail incoming*")
			   (get-buffer " *nnml move*"))))
	      (if (not buf)
		  (progn (message "Oops, cannot find message buffer") nil)
		(set-buffer buf)
		(if (eq 1 (call-process-region (point-min) (point-max)
					       "spamc" nil nil nil "-c"))
		    "spam")))))

Is there a kosher way to look at the whole message?  I know the manual
shows *nnmail incoming*, but for a respool it seems to be *nnml move*.

This isn't very fast, but I don't know where the hold-up is.  Maybe
having emacs speak down a pipe to a Mail::SpamAssassin script would be
an improvement, or more likely it's just spamassassin itself taking
the time.

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Henrik Enberg]

Kevin Ryde <user42@zip.com.au> writes:

> This isn't very fast, but I don't know where the hold-up is.  Maybe
> having emacs speak down a pipe to a Mail::SpamAssassin script would be
> an improvement, or more likely it's just spamassassin itself taking
> the time.

I'd say the holdup is spamassassin.  It is really slow, and it gets
slower with every new release.  I've stopped using it because it eats
to much resources.

That said, spamc is probably the best way.  It will keep the perl
process running as a daemon.  Otherwise you need to spawn a new perl for
every message. 

-- 
Booting... /vmemacs.el

Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson]

Kevin Ryde <user42@zip.com.au> writes:

> Simon Josefsson <jas@extundo.com> writes:
>>
>> The only thing I dislike is that SpamAssassin-Milter rewrites message
>> bodies, but I'll contribute a patch to fixes that as soon as I've
>> written it.

Btw, the patch is written.  I've been using it for 4-5 days and it
seems to work.

http://savannah.gnu.org/patch/?func=detailpatch&patch_id=385&group_id=1083

> I get a bit nervous about modifying mail, so I've just been doing a
> straightforward fancy-split on what spamc says,
>
> 	(defun my-spamassassin ()
> 	  (save-excursion
> 	    (let ((buf (or (get-buffer " *nnmail incoming*")
> 			   (get-buffer " *nnml move*"))))
> 	      (if (not buf)
> 		  (progn (message "Oops, cannot find message buffer") nil)
> 		(set-buffer buf)
> 		(if (eq 1 (call-process-region (point-min) (point-max)
> 					       "spamc" nil nil nil "-c"))
> 		    "spam")))))
>
> Is there a kosher way to look at the whole message? 

I think this was discussed earlier, and the answer was no.

> I know the manual shows *nnmail incoming*, but for a respool it
> seems to be *nnml move*.

Respooling is a bit ad-hoc, yes.

> This isn't very fast, but I don't know where the hold-up is.  Maybe
> having emacs speak down a pipe to a Mail::SpamAssassin script would be
> an improvement, or more likely it's just spamassassin itself taking
> the time.

Disabling the DNS based spam checks improves speed as well.

Thanks for your code snippet, I'm working on extending the spam
chapter in the manual and I'll include it unless you object.