Would it be possible to create an outgoing mail filter like
"add header" -> "X-Hashcash" -> value: $(hashcash -mb24 $RECIPIENT) ?
Then it would be very easy to use the hashcash command line tool. 

The pipe through filter action and advanced option apply this filter 
to sent messages are your friends, I hear them calling you now.

As far as I understand, the "apply to sent messages" option makes the filter apply to messages after they are sent, not before. So this could not add a hashcash stamp.

On Thursday 24 June 2004 21:59, Martin Hans wrote:
> As far as I understand, the "apply to sent
> messages" option makes the filter apply to messages after they are
> sent, not before. So this could not add a hashcash stamp.

Well that's a very good point, sorry for replying too hastily.

I could implement a pre-sending filter and lobby for it to be accepted 
into CVS. But that work would have to be scheduled on the same 
commercial basis as the other features I plan to work on as described 
on http://kontact.org/shopping/

Don.

hashcash v1 is going into the debian distribution.  spamassassin 3.0 which will be released soon now also has support for hashcash v1.

Any progress on getting hashcash support in kmail?

Being able to apply filters to messages before they are sent sometimes really makes sense. But does hashcash support really make sense? My problem with spam is that spamassassin still doesn't catch all of it. Usage of hashcash can't improve this. The usage of hashcash can only help lower the percentage of false positives. But so far no message which was sent with KMail (i.e. User-Agent: KMail/x.y.z) was falsely classified as spam. So I think the usage of hashcash will have exactly no effect.

I will close this wish as duplicate of wish 48938 because once pre-sending filtering is implemented it can easily be used to add HashCash headers to your outgoing messages. I don't think it makes sense to add any hashcash specific code to KMail.


*** This bug has been marked as a duplicate of 48938 ***

I would like to reopen this bug.

The claims about hashcash ineffectivness appear wrong.  Please read http://www.hashcash.org/faq/

hashcash is not _just_ spamassassin, though spam assassin is one filtering system that includes hashcash support as a means of avoiding false +ves.  There are many types of false positives.  Mail config enforcement bounces, DNS config bounces, IP blacklists, bayesian filter false +ves, etc etc.  Hashcash can and should be used to reduce the false positives in all of these to restore reliability to email.

> My problem with spam is that spamassassin still doesn't catch all of it.

Specifically the _reason_ SA is not catching all of spam is because it is configured to be conservative to avoid losing mail.  As spam levels increase (many claim as high as 10% a month!) spam filters will commonly be made less descriminating to try reduce the volume reaching ISP users.  

Another example bayesian filter: the one in mozilla routinely gives non-negligible numbers of false positives.  (We are also working on mozilla hashcash accept and send support).

When hashcash reaches wider deployment on the filtering side sending stamps will become increasingly important to achieve mail sending reliability.

I do not think this warrants closing as a duplicate of a filtering bug.

Direct support was the wish topic.

Additionally: For good support of hashcash it is not so easy to just add to an outgoing filter.  Some UI progress indicator would be ideal as it can be time consuming.

Also some smarter things would make it much easier to use: precomputed stamps pool, and hooks to trigger precomputing (on clicking reply, or as recipients are entered) would be required for good integration.

as the creator of camram (www.camram.org), a rather full featured anti-spam system featuring hashcash, I would also welcome support for hashcash in any e-mail user agent.  I recommend however slightly different support based on my experiences.

At a raw, bare bones minimum, send and recognize stamps.  It is incredibly important however to generate stamps in background where the user will not notice the computation time.  It's also important to nice the process so that other things can be done during stamp generation. 

on the next level of sophistication, I would recommend looking closely at replicating the camram filter sequence.  Specifically having a chain of filters hashcash, automatically generated white list, and then content filter.  The important detail about the automatically generated white list is that it is simply white listing who you send e-mail to.  reason for this logicis if you send e-mail to someone, you probably want to get e-mail back from them.  It's been extremely successful within camram if you're careful about filling the white list.  Another advantage of this white list is that it allows you to minimize stamp generation and also improve user experience.

I would also recommend building in support directly for hashcash.  It's hard to get output stamping right especially if you're preserving a good user experience.  You need to connect the send button to the SMTP agent via a queue.  inbound filtering is somewhat easier but it's still different from previously seen plug-in environments.

I think the this wish need be reopened. Its NOT only a outgoing special filter issue.

I think this is a good idea actually, and I'm very tempted to start implementing it.  If KDE developers and users start using it, I can easily alter my spamassassin rules to be more effective.

Any news on this wishlist item? I would really like to see this feature in kmail... It's a real bonus to have in the war against spam ;)

This bug should really be reopened -- I'd like to see this feature in Kmail (it's the only thing making me consider switch mail clients)

the close note on this bug is totally bogus.  The bug listed as a "duplicate" isnt even remotely related!!  Please reopen this bug.

I still think that using the not-yet-implemented pre-sending filtering is the correct solution for this. We didn't hard-code support for any spam filters in KMail so why should we hard-code Hashcash support. Anyway, patches are welcome.

> I still think that using the not-yet-implemented pre-sending filtering is the 
> correct solution for this. We didn't hard-code support for any spam filters in 
> KMail so why should we hard-code Hashcash support. Anyway, patches are welcome. 

Pre-filters may very well be the right way to implement hashcash...if so, this becomes a wishlist for a hashcash pre-filter.

Thanks,

Lance

I agree with Lance and Igno on this one.  I'll take a look at the code, but I suspect it's not going to be something I can deal with.

what about an option for adding the output of a program as header?
This may also solve other feature requests or at least provide a walk around.

Reassigning to kmail2, please any reporter check the validity of this report and add a comment, thanks in advance

I don't have any idea of the source code of kmail2, but I guess that this would be a nice junior job:

- add a checkmark option to the mail editor dialog (tab meta data) to enable the hashcash challenge.
- optionally: provide a spin to determine the work load (how many zeros to find)

- study the hashtag code from existing projects and 'copy'n'paste' it to the right place in kmail2's code.

If I find a free day, I could even imagine to do it my self (I haven't made yet my hands dirty with kmail development).

a kmail related resource of the hashcash project: http://www.hashcash.org/mail/mua/kmail/