[Mimedefang] Does MIMEdefang 'remember' variable values between successive invocations?

[Kevin A. McGrail]

> Now I wonder: does MIMEdefang keep state between successive runs? Is 
> there a way I can 'clean up' (= undefine) all variables before a run? 
> The workaround I now use is, that the variables in the config file are 
> defined without a value and then in the script I set the variable to 
> an empty string and check the variable for an empty value:
>
> I would prefer to be able to remove or comment out a variable in the 
> config file and not having to do a 'reread' of mimedefang.
> Any ideas? 

My understanding is that MIMEDefang is a daemonized process with 
multiple children.  So a single email can actually be processed by 
multiple children.  So just because filter_begin ran in one child, I 
believe the email can run filter_end on a completely different child.

This is covered in the man page for mimedefang-filter under MAINTAINING 
STATE (included below).

If I understand your question correctly, you need either a function that 
reads a text file/db file/SQL database every time you need to confirm state.

Regards,
KAM

MAINTAINING STATE
        There are four basic groups of filtering functions:

        1      filter_relay

        2      filter_sender

        3      filter_recipient

        4      filter_begin, filter, filter_multipart, filter_end

        In  general, for a given mail message, these groups of functions 
may be called in completely different Perl processes.  Thus, there is no 
way to maintain state inside Perl between groups of functions.  That
        is, you cannot set a variable in filter_relay and expect it to 
be available in filter_sender, because the filter_sender invocation 
might take place in a completely different process.

        However, for a given mail message, the $CWD global variable 
holds the message spool directory, and the current working directory is 
set to $CWD.  Therefore, you can store state in  files  inside  $CWD.   If
        filter_sender stores data in a file inside $CWD, then 
filter_recipient can retrieve that data.

        Since filter_relay is called directly after a mail connection is 
established, there is no message context yet, no per-message mimedefang 
spool directory, and the $CWD global is not set. Therefore, it is not
        possible to share information from filter_relay to one of the 
other filter functions. The only thing that filter_relay has in common 
with the other functions are the values in  the  globals  $RelayAddr  and
        $RelayHostname. These could be used to access per-remote-host 
information in some database.

        Inside  $CWD,  we  reserve filenames beginning with upper-case 
letters for internal MIMEDefang use.  If you want to create files to 
store state, name them beginning with a lower-case letter to avoid clashes
        with future releases of MIMEDefang.