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

[Tony Nugent]

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