[Mimedefang] RE: Multiplexor Issue

[Jesus Martinez Rubio]

> David wrote:
>
>Well, there is an easy way around this:
>
>Do all your work in filter_begin.  You have all the info you
>need there, and it's only called once for each message.  The sender is
>in $Sender, and the recipients are in @Recipients.
>
That you say is not totally true for a total control solution. I rejected
some recipients depending of some rules and I want to have them correctly
linked with the mail. As you say is impossible to do because the Recipients
array has not the rejected recipients and their causes (I have some of
them). Also I want to have the more early timestamp possible in order to
have statistical data about how long time each mail is processed by
mimedefang, and with your manner, Mimedefang forget it (I have mimedefang.pl
patched in the main loop to create as soon as possible a variable named
$jmrMailStartTime)

>However, I've been thinking about this same problem, and agree that it
>would be nice to keep state.  The next beta release will solve it as
>follows: The MIMEDefang spool directory will be created before
>filter_relay gets called.  All of the filter_* functions will be able
>to access this directory in the global $CWD variable, and the Perl
>filter will chdir() to that directory before calling the filter_*
>functions.  That way, you can store state directly in files in the
>spool directory, or just use the directory name as a unique key for
>database lookups.  (Though on very busy mail servers, a name might be
>reused, so be careful.)

This sounds very good!!!, except for very busy servers as they will be mine?
|-( : 20000 emails each day, analysis of files using File::Magic, 3
antivirus running for each attachment, spamassasin, uncompressing files
until level 10 while control space used in disk to avoid zip crash for
example and doing the previous File::Magic for each already decompressed
file, rules in a configuration file that define what kind of tests to run
for (using eval's), etc. As you can see, Mimedefang is my solution
(congratulations to roaring-penguin) and my headache.

I can't understand why you say "except in busy servers". Please, could you
explain me?
Maybe is this? I don't know too much (better said nothing) about
sendmail+milter api but I don't know if maybe the multiple-sending in the
same thread without fork that it can do in the new releases is the cause. If
this is truth, the workaround should "fork" sendmail for each mail as it's
possible to do defining it in sendmail.cf