Sheldon Hearn wrote:
>>20000 messages should not be a problem. I have heard of people having
>>larger volumes with exiscan. However, those are all using daemon scanner
>>types (which is a lot faster).
>
>
> As a data point, my staff mail server handles over 60,000 messages a
> day, and it's using exiscan for a daemon AV scanner, the regexp scanner
> and also the painfully slow spamd scanner (over 3 seconds per message).
>
> I'm not seeing the problem, unless my find_exim_bogons script is broken
> with exim4:
>
> #!/bin/sh
> #
> # Find orphaned data spool files, which have no corresponding envelope
> # files.
> #
> # Requires a POSIX shell.
> #
> # Not recommended on hosts with very large Exim queues.
> #
> spool=/var/spool/exim/input
>
> for i in `find ${spool} -name '*-D'`; do
> dir=${i%/*}
> fnm=${i##*/}
> mid=${fnm%-D}
>
> if [ ! -e ${dir}/${mid}-H ]; then
> # Confirm that the envelope file still exists to close a
> # race condition that could result in false hits.
> #
> if [ -e ${dir}/${mid}-D ]; then
> echo $mid
> fi
> fi
> done
Hmmm, maybe I'm wrong, but this could show up false positives, which
could be bad, if you use this directly for removing the files from the
spool (like script|xargs rm)
With sa-exim I often saw that -D files are on the disk, if you are using
blackholeing, as it called exit() after the blackhole.
My conclusion is, exim first saves the body, and holds the header in
memory, until the local_scan is done.
So, if you have some long-running local_scan-process (5-10 secs), or
some extensive check in your data_acl, it could happen that you delete a
-D file, where the -H files just isn't written to disk yet (a
race-condition).
You SHOULD at least check the modify-time of the file, and only
delete/show if it's older than 5 minutes or so.
Please don't blame me if I'm wrong ;)
ciao
