On Thu, 6 Jul 2006, B. Cook wrote:
> From: B. Cook <bcook@???>
> To: Exim users list <exim-users@???>
> Date: Thu, 06 Jul 2006 10:28:40 -0400
> Subject: [exim] Why does this happen?
>
> I have a message that is about 7M and it gets split up into
> something that is *many* times larger.
>
> [/var/spool/exim/scan]# 120 > du -sh *
> 57M 1FyUH7-000NAG-Ka
> 3.4M 1FyUj7-000GvR-PB
> 18K 1FyUkw-000LfM-7P
> [/var/spool/exim/scan]# 121 > cd 1FyUH7-000NAG-Ka/
> [/var/spool/exim/scan/1FyUH7-000NAG-Ka]# 122 > ls
...
> Opening up the 1FyUH7-000NAG-Ka.eml (6.9M) it looks as if it's some
> message that has been forwareded to dozens of people again and again..
>
> Subject: Fw: THINGS YOU DON'T SEE EVERY DAY
>
> 89048 mailnull 1 121 0 139M 137M RUN 0 14:56 60.21%
> exim-4.62-0
>
> This is the process that is dealing with the message..
>
> Exim version 4.62 #0 (FreeBSD 6.1) built 06-Jul-2006 10:21:06
> Copyright (c) University of Cambridge 2006
> Probably Berkeley DB version 1.8x (native mode)
> Support for: iconv() use_setclassresources Perl OpenSSL Content_Scanning
...
> Anyone have any suggestions or clues what could be the problem or
> how I could fix it?
I'd guess you're content scanning (virus checking etc) messages
and you've hit something that has been highly compressed. Highly
compressed attachments can get *LARGE* when virus checkers try to
unravel them. I don't think there's much that can be done about
this[1]. Other than buy bigger, faster mail servers with bigger,
faster discs :-(
[1] If you're using clamd, see the description for
ArchiveMaxCompressionRatio in the man page for clamd.conf.
You *could* reduce the default value and see what happens.
I've never done this so can't say how it'll behave. Note that
reducing the value sharply does have the potential for creating
false positives.
--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@??? Phone: +44 1225 386101
