Hello, thanks for getting back. You're effectively saying that splitting the stamp into short portions on individual lines is not a bug but a feature. Having read the source you quoted and having run a few more checks I strongly agree with you. But why is procmail then not verifying the stamp? Well, it's apparently the way procmail deals with line breaks in header lines. If I set up a trivial provmail recepie VERBOSE=yes #hashcash :0 Hfh * ^X-Hashcash: * $? cat > /tmp/zzz |sed 's/\(^Subject:\)\(.*\)/\1<HC OK> \2/' it should, one would assume, simply pipe the complete header into a file. The content is however <SNIP> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Hashcash: 1:20:110629:lvzwlcykh5uctsy5.t.hadvabvobs@xxxxxxxxxxxx::MukaRTmGN+xq J5RO:00000000000000000003lEb X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p6hEpf6ttqws02bSs/CL6nBCZcAzW/pD0kbT/BaZcLmAWMxrJq35NjII8ZYU X6M6dwR6Ld/uk+5aGcGL8xTX1Cl/Uh1R+vjLtpoaQbFzoPu8EETGu03jarAu/l2iyZz9smJc5lih xkatzETLXnSyLsDWmnxz3m1lJvMVJSJXatjcwrZzxGUPS7Rz22x8xy81Kh5NFAk5xgnqRNapFZyC cbrAqiptWKyQ40fy/o7xI1R+w==V1; X-Virus-Status: No <SNIP> whereas the true header is <SNIP> Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Hashcash: 1:20:110629:lvzwlcykh5uctsy5.t.hadvabvobs@xxxxxxxxxxxx::MukaRTmGN+xq J5RO:00000000000000000003lEb X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p6hEpf6ttqws02bSs/CL6nBCZcAzW/pD0kbT/BaZcLmAWMxrJq35NjII8ZYU X6M6dwR6Ld/uk+5aGcGL8xTX1Cl/Uh1R+vjLtpoaQbFzoPu8EETGu03jarAu/l2iyZz9smJc5lih xkatzETLXnSyLsDWmnxz3m1lJvMVJSJXatjcwrZzxGUPS7Rz22x8xy81Kh5NFAk5xgnqRNapFZyC cbrAqiptWKyQ40fy/o7xI1R+w==V1; X-Virus-Status: No <SNIP> Watch the spaces/tab in the procmail-generated variant - looks like procmail tries to stuff all lines of a header item into one line, substituting <whitespace><tab> for the split. Of course hashcash can't recognise this crap any more, and comes back with examining stamp: X-Hashcash: 1:20:110629:lvzwlcykh5uctsy5.t.hadvabvobs@xxxxxxxxxxxx::MukaRTmGN+xq J5RO:00000000000000000003lEb skipped: stamp invalid since it can't deal with the spaces. Way out: wipe out the <whitespace><tab> with sed before feeding this to hashcash: #hashcash :0 Hfh * ^X-Hashcash: * $? sed 's/ \t//g' |hashcash -cqXdp 1d -b20 -f $HOME/hashcash.db -Er \ '.**whatever' |sed 's/\(^Subject:\)\(.*\)/\1<HC OK> \2/' this works then reliably even for very long stamps. So, no problem with hashcash or hashcash-sendmail, but with the way procmail does business with multi-line header items. I'm sure a procmail-guru would firmly claim his ground by stating that there are "many good reasons for doing it that way" - to the humble end user who doesn't have a Ph.D. from the Faculty of Procmail this is a bit hard to swallow. The problem only arises when the stamp is broken into more than one line, but still funny no one else has stumbled over this yet, apparently. Regards Andreas -- BAXTER: Can't reach anyfin' with them little arms. RIMMER: That's probably why they're always a bit grumpy...