[Mimedefang] talking to and changing mimedefang in real-time...

[David T Hollis]

For things that do not happen often like the AV updates (weekly or so), 
you can simply have your cron script tell the multiplexor to reload 
(mimedefang reload if you use the stock initscripts).  It kills of idle 
mimedefang.pl processes and starts them fresh.  The script would then 
pull in the new AV sig version at startup.   Not super snazzy, but real 
easy to implement.  Reloading the rulesets doesn't seem to be a very 
expensive task if it is not done constantly.  If the mail servers are 
processing massive loads of traffic (I can reload on two mail servers 
that each handle 30-40k messages per day at any point with no issues) it 
may be a concern.


Tony Nugent wrote:

>On Fri Aug 30 2002 at 17:17, Tony Nugent wrote:
>
>  
>
>>Subject: Re: [Mimedefang] return values from message_contains_virus()
>>    
>>
>
>  
>
>>Exactly what constitutes a "suspicious" message (or part)?
>>    
>>
>
>(?)
>
>  
>
>>Does calling action_tempfail() result in a positive response from
>>subsequent calls to message_rejected()?
>>    
>>
>
>(sorry, the man page is quite explicit about that, I had meant to
>delete this from my original post).
>
>  
>
>>Is there an easy way to trigger a function call based on a date or
>>timeout alarm?  (It doesn't need to interrupt anything, just flag
>>that the alarm/timeout has occurred when its status is next checked
>>and then reset in the filter).
>>    
>>
>
>  (Backgroud: I put the virus scanner and DAT versions into message
>  headers, obtained from running "uvscan --version".  Doing this for
>  every message that goes by is a very ugly thing to do, especially
>  since the DAT file is changed only once a week or so (cron job).
>  I set it as a global at startup, but when it changes how can I
>  automatically let mimedefang know that it is time to update its
>  idea of the current DAT version number?)
>
>I came up with a very elegant solution to this that works oh so
>sweet.  (One for Jeffrey's tips page?  geeze, there's a few that
>I've posted to this list over the past couple of weeks:)
>
>What I have done allows me to change the runtime behaviour of the
>filter by literally sending it a message...
>
>I (almost) always read the headers in filter_begin().  If a message
>contains a specific header (or any of a number), then that header
>can be used as a flag to do something.  The header itself can
>contain information (like function parameters or environment
>settings) telling mimedefang to change its behaviour somehow,
>runtime.  The body of the message itself could even contain useable
>information.  The header doesn't even need to be specific, $Subject
>can more easily be used instead.
>
>If the message is verified as coming from (say) me (or a system
>daemon), and/or addressed to some weird and possibly non-existent
>local user (or whatever), the trigger action it taken, the event is
>logged, and the message discarded.
>
>Easy, elegantly simple, and it works well.  It initially took very
>few new lines of code to include the basic functionality.
>
>As for getting mimedefang to do cron jobs, all that is needed is to
>set up the action and a tigger in the filter, and periodically
>generate emails that make happen whatever you may want defang to do.
>And because we are using perl, the filter can do all sorts of
>things... the world is our oyster ;)  <sorry>
>
>  Another example use:  for some reason you might want to have
>  defang deny relay to/from certain places/users and at specific
>  times, with the timing and actions controlled from a cron job or
>  manually with an administrative email.
>
>On a production level it would need to be done with some sort of
>secret-sharing for authentication (and encryption?) to make it
>secure rather than obscure (although I'm sure the filter can be made
>to protect itself fairly safely).  Point is, the basic methodology
>works a treat!
>
>way cool.
>
>(or have I re-invented the wheel? :)
>
>  Related to my previous post about testing the filter with test
>  emails... I've just realised that this header trick can also be a
>  way to deliberately pseudo-trigger events on these messags (like
>  suspicious characters) to confirm how these routines behave in my
>  filter.  (Although a test-suite of emails would still be useful).
>
>  
>
>>  (yeah, I know, I'm asking lots of questions here lately... I'm
>>  trying to really streamline my filters and take advantage of some
>>  of the very cool new extra functionality introduced into defang
>>  over the past few months - and with it I am spinning some nice
>>  magic :)
>>    
>>
>
>Magic indeed... I have mimedefang doing all sorts of amazing things
>for me with the email here, it all works exactly as advertised :)
>Wow, it really gives you iron-clasp-with-silk-lining control over
>what happens to just about any mail that goes through the server!
>I am now solving problems, doing tricks and adding functionality
>that would otherwise been almost impossible to achieve :)  David,
>thanks heaps mate...
>
>On a totally off-beat issue... is anyone using perl's ldap module
>(Net::LDAP) with mimedefang?  I have nsswitch and sendmail using
>ldap, defang could get at (and even store) all sorts of useful
>information (user account information, the list of domains for local
>delivery and so on)...
>
>Cheers
>Tony
>_______________________________________________
>MIMEDefang mailing list
>MIMEDefang at lists.roaringpenguin.com
>http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
>  
>