malware with BAD HEADER, MIME error not blocked
MI
mi.lists at alma.ch
Thu Mar 31 17:14:19 CEST 2016
> 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
More information about the amavis-users
mailing list