Incorrect content identification

[Mark Martinec]

Gabor,

> A few times a week I find amavis logs like these:
> 
> Oct 19 21:02:23 cirkusz amavis[5594]: (05594-20-2)
>   (!)Exceeded storage quota 314572800 bytes by do_pax_cpio/pre;
>   last chunk 347994408774 bytes
> Oct 19 21:02:23 cirkusz amavis[5594]: (05594-20-2)
>   NOTICE: Virus scanning skipped: Exceeded storage quota 314572800 bytes
>   by do_pax_cpio/pre; last chunk 347994408774 bytes
> Oct 19 21:02:26 cirkusz amavis[5594]: (05594-20-2)
>   (!)NOTICE: HOLD reason: Exceeded storage quota 314572800
>   bytes by do_pax_cpio/pre; last chunk 347994408774 bytes
> Oct 19 21:02:26 cirkusz amavis[5594]: (05594-20-2)
>   (!)Inserting header field: X-Amavis-Hold: Exceeded storage quota
>   314572800 bytes by do_pax_cpio/pre; last chunk 347994408774 bytes

> These mails actually do not contain any pax or cpio archives.
> So I do not understand what happens here... :-(
> Any idea what to check?
> 
> Amavisd-new is installed from a Debian package version 1:2.6.4-3.

Apparently the file(1) utility misqualifies some part of these messages
as something (a tar or cpio by default) that could be decodeable by a
pax or cpio, which then reports some silly number when it attempts to
extract an archive size from the given garbage (a non-tar mail part).

If you still have such sample message, try exploding it to its parts
and check what a file(1) command has to say about each.
Alternatively, at log level 2 or above you'd see logged a structure
of each mail message.

So either the file(1) utility is mistaken (try upgrading it), or the
mail part is indeed something decodeable by pax or cpio according
to your setting of @decoders, but it fails to list a proper archive size,
or indeed the mail part given to pax or cpio is a garbage (may or
may not be malicious) and the reported archive size is correct.

  Mark