The error is in incorrectly wrapped Content-Type header field,
where the continuation line does not start with a space or tab,
so the broken MIME part does not get base64-decoded.
Thank you. Somehow, I overlooked that.
Wouldn't it be possible for Amavis to still check the attachment, despite the error?
It seems that MIME::Parser, while complaining about the bad header is still able to
extract it:
$ perl -MMIME::Parser -e 'my $p=MIME::Parser->new( ); $p->output_under("/tmp/x/"); my
$m=$p->parse(\*STDIN); warn $p->last_error(), "\n";' </tmp/badmail
error: couldn't parse head; error near:
Content-Transfer-Encoding: base64
$ ls -Al /tmp/x/msg-1459435568-17408-0/
total 8
-rw-rw-r-- 1 root root 3378 Mar 31 16:46 hostmaster_document_4876E9.rar
-rw-rw-r-- 1 root root 246 Mar 31 16:46 msg-17408-1.txt
So it would be nice if Amavis could still check the attachment if it could be
extracted.
In the meantime I will try your other suggestions.
Thank you,
MI
Content-Type: application/octet-stream; x-unix-mode=0600;
name="hostmaster_document_4876E9.rar"
Content-Transfer-Encoding: base64
Is there a way to ask amavis to check a single mail from the
command-line with debugging output?
Not really, although you can use the amavisd-submit utility
to feed a mail directly to an amavisd socket, and you may
use a policy bank to rise a log level on a mail submitted
through such dedicated socket.
I don'twant to just blindly block any email with a bad header, from
fear of blocking too many normal mails sent by a stupid client
program.
You may use a SpamAssassin rule like the following to
capture such invalid wrap:
full L_INV_NAME_WRAP /^Content-Type:.*\nname="/mi
score L_INV_NAME_WRAP 20
Also, the SaneSecurity 3rd party rules to ClamAV seem to be
able to catch these.
Mark
