Hi
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):
X-Hashcash:
1:23:150729:c...@a.christianjaeger.ch::BIsU5nVO5XGrvOIr:00000000000000
0000000000000000000000006t75
Now another thing I notice is that this format is longer than the examples
shown in the code, e.g.
X-hashcash: 1:20:040803:a...@cypherspace.org::a1cbc54bf0182ea8:5d6a0
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:
https://github.com/apache/spamassassin/commit/a95d2cfd2cc07deac9842cfaf10d6d9a85365b12
# 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.
Christian.
