amavisd-new chokes on all tar files?

[Mark Martinec]

John,

> My current amavisd-new installation is buggy with respect to tar files. 
> Specifically, I sent myself a test message with a VERY SMALL tar file, of
> 92 bytes (which tars into 2048 bytes). It's so small, in fact, that I can
> quote the whole thing below (and I've done so, just so you can check the
> message ID to see I'm not crazy). Sending this message to myself generates
> this sequence of log messages:
> 
> May 25 10:09:20 computer amavis[28459]: (28459-19) (!)Exceeded storage
> quota 5352500 bytes by do_pax_cpio/pre; last chunk 4294967388 bytes May 25
> 10:09:20 computer amavis[28459]: (28459-19) (!)NOTICE: HOLD reason:
> Exceeded storage quota 5352500 bytes by do_pax_cpio/pre; last chunk
> 4294967388 bytes May 25 10:09:20 computer amavis[28459]: (28459-19)
> (!)Inserting header field: X-Amavis-Hold: Exceeded storage quota 5352500
> bytes by do_pax_cpio/pre; last chunk 4294967388 bytes May 25 10:09:20
> computer amavis[28459]: (28459-19) Passed UNCHECKED, [67.18.186.127]
> [129.65.198.222] <clements at brinckerhoff.org> ->
> <granitemon at computer.csc.calpoly.edu>, Message-ID:
> <F3ABA43C-47D2-482A-BE9A-2D818190037D at brinckerhoff.org>, mail_id:
> MictXWeexZRl, Hits: -1.901, size: 10705, queued_as: C4322137D17, 813 ms
> 
> So apparently, amavisd thinks that the attached tar file expands to
> something *really big*, when in fact the whole bundle expands into a
> single file of 92 chars. Basically, it just looks like this software
> doesn't correctly handle .tar archives. This seems to be true of all .tar
> attachments. This could be a bug in amavisd, or perhaps in the pax
> library; I haven't examined the amavisd sources carefully enough to see
> which of these is the problem.
> 
> So: is this a known bug? Is it a bug in amavisd, or in pax?
> 
> I'm using debian, where this version of amavisd-new has version
> "1:2.6.4-3". My machine's version of "pax" is 1:20090728-1.

Looks to me like a bug in your pax.

Try listing the contents of your tar sample file from a command line.
On my host it gives:

$ pax -v <foo.tar 
-rw-r--r--  1 501              wheel         92 May 25 19:09 foo
pax: ustar vol 1, 1 files, 2048 bytes read, 0 bytes written.

$ cpio -i -t -v <foo.tar 
-rw-r--r--   0 clements wheel          92 May 25 19:09 foo
4 blocks

$ tar tvf foo.tar 
-rw-r--r--  0 clements wheel      92 May 25 19:09 foo


If that does not show any anomaly, try rising the $log_level to 5
and re-send your test message through amavisd and check the log
to see what is happening during decoding.

  Mark