spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Jaeger>
Subject Hashcash not working
Date Wed, 29 Jul 2015 18:55:55 GMT

I've implemented (or at least so I thought) Hashcash for my outgoing mail (in a Perl wrapper
around qmail-remote that I already had to do DKIM), using the `hashcash` tool as provided
by Debian, using the `-X` command-line option. This tool returns multi-line headers if the
email address the hash-cash is minted for is long enough. This might be the reason that Mail-SpamAssassin-3.4.1
ignores those, I guessed, so I delved into the code.

Here's an example header it generates (you could also check the source of this email):


Now another thing I notice is that this format is longer than the examples shown in the code,


Anyone knows if that is already a problem?

Then I noticed that the following regex disallows \n in the header value; do decoded header
values have a \n where they wrap, or not?

Then I notice in this commit:

    # untaint the string for paranoia, making sure not to allow \n \0 \' \"
 -  $hc =~ /^([-A-Za-z0-9\xA0-\xFF:_\/\%\@\.\,\= \*\+\;]+)$/; $hc = $1;
 +  if ($hc =~ /^[-A-Za-z0-9\xA0-\xFF:_\/\%\@\.\,\= \*\+\;]+$/) {
 +    $hc = Mail::SpamAssassin::Util::untaint_var($hc);
 +  }
    if (!$hc) { return 0; }

This looks like it isn't correct: before the patch, it would assign undef to $hc if the regex
fails (right?), now it leaves the tainted original $hc value in place. Surely not what was
meant, right?

I'm planning to debug this further (hm, debugging a live daemon is always painful, actually
writing a tool for that now, will defer my work here), but would welcome feedback.


View raw message