Jeremy,
> > As you have indicated, a likely culprit is the C code for parsing HTML:
> > Razor2-Preproc-deHTMLxs/_deHTMLxs.c, or maybe the glue in deHTMLxs.c .
>
> Just to follow up on this issue (from some time ago), upgrading to the
> latest Razor solved one problem.
Good to know. I hope it's not just a lucky outcome.
> The other problem turned out to be a
> bug in Sophos SAVI in its handling of PDF files. Sophos put in a fix
> in the March release. The bug appears to be in allocating memory
> based on a PDF object's meta-data rather than its actual size, leading
> to a classic buffer overrun, with the side-effect of leaving the
> message in the pre-scan postfix queue, as well as leaving a rather
> large temporary file - and eventually filling up the filesystem. We
> had 4 different emails triggering the problem in a few months, leading
> to a denial-of-service on each occasion. Improvements in monitoring
> (checking the age of AMaViS temp files) mean that we are now able to
> detect a problem before it starts to affect mail. Thanks very much
> for your assistance in resolving these problems.
Are we talking about an external av scanner (like sophie, savdi, clamd),
or a linked-in internal scanner like Mail::ClamAV and SAVI-Perl).
In case of the former (external), this shouldn't be happening, as long
as you have at least one still-working av scanner. A crashing external
scanner should not be able to bring down amavisd.
I advise against using a scanner like Mail::ClamAV and SAVI-Perl
running in the context of the same process as amavisd. A bug in such
scanner will crash the amavisd process, resulting in tempfailed
mail messages and a pile-up of leftover temporary files.
> I still don't quite understand why AMaViS can't do something about
> handling a scanner that fails in this way, including not being able to
> report a problem. Can you explain why? Is it because AMaViS
> pre-forks its children and the master can no longer detect when they
> die ungracefully? Is this something that the "nanny" utility can help
> me detect?
A crashing amavisd process is detectable through amavisd-nanny,
or through SNMP monitoring as introduced with amavisd-new-2.6.4
(AMAVIS-MIB.txt) :
procGone OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of registered amavisd child processes that were
abnormally terminated (crashed or killed) since the last
start of amavisd-snmp-subagent."
::= { amavisProc 1 1 }
A crashing process leaves its trace in the nanny.db. The event is
not logged by the child process (which no longer exists and can't log it),
nor by its parent unfortunately, as we have no control over Net::Server
master process.
> Would it perhaps be possible for a child to wrap a fork/exec around
> its call to the scanner, and if the eval() fails, log the failure, or
> preferably send an appropriate SMTP response code?
Yes, that is currently possible for calling SpamAssassin
($sa_spawned=1), but the price is doubling the virtual memory in use,
so it is not particularly popular, except as a temporary measure
while investigating some instability in SpamAssassin.
Similar mechanism is not available for calling integrated AV scanners,
as there are plenty of other effective external scanners available,
so there is no real need for such a workaround - the downsides
just overweight the benefits.
Mark
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
