[hashcash] Re: hashcash-sendmail breaks up long stamps@@sig

Andreas Mattheiss <please.post@xxxxxxxxxxxxxxxx> writes:

> hashcash-sendmail appears to struggle with long stamps.
>
> When i issue
>
> hashcash -m -b20 -r andreas.mattheiss@xxxxxxxxxxxxxxxx
>
[...]
> Tue Jun 28 22:11:09 2011 hashcash-sendmail[6304]: made token X-Hashcash:
> 1:20:110628:andreas.mattheiss@xxxxxx::ZD6WiVAJVEPAJCs6:0000000000000
> 0000000000000000000000005QGb
[...]
>              
> Asking hashcash-sendmail for invoking hashcash with -Z 1 appears to solve
> the problem; there are no spaces in the thus generated stamp in the
> logfile and the procmail-recepie checks ok, but the overall length of
> the stamp is uncomfortably close to where the break used to occur.
>
> Can someone please have a look as to what may be going on there;
> unfortunately I am not a perler.

If you read the source for hashcash you find that `-Z' option
corresponds to compression. If the compression is set then hashcash
generats shortest possible stamps, otherwise it inserts some zeros to
align the input for the hash function and make calculations faster
(that's what I've read in a FAQ or somewhere else).

Try running this bash script and notice the stairs it produces

--8<---------------cut here---------------start------------->8---
for f in `seq 11 64`; do \
    hashcash -b4 -qm $(seq -w 11 $f | tr -d '\n'); \
done | less -S
--8<---------------cut here---------------end--------------->8---

then add -X to hashcash.

The newline and the space characters are means to split long mail headers
into several lines reasonable of reasonable length. Take a look at
Received headers in any mail you receive and the RFC[1]

[1] http://tools.ietf.org/html/rfc2822#section-3.2.3
-- 
Miłego dnia,
Łukasz Stelmach


Other related posts: