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

Andreas Mattheiss <[email protected]> writes:

> hashcash-sendmail appears to struggle with long stamps.
>
> When i issue
>
> hashcash -m -b20 -r [email protected]
>
[...]
> Tue Jun 28 22:11:09 2011 hashcash-sendmail[6304]: made token X-Hashcash=
:
> 1:20:110628:[email protected]::ZD6WiVAJVEPAJCs6:0000000000000
> 0000000000000000000000005QGb
[...]
>             =20
> Asking hashcash-sendmail for invoking hashcash with -Z 1 appears to sol=
ve
> 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
--=20
Mi=C5=82ego dnia,
=C5=81ukasz Stelmach