[Mimedefang] MIMEDefang 2.57-BETA-1 is available

Jan-Pieter Cornet johnpc at xs4all.nl
Wed Jun 14 17:20:45 EDT 2006


On Wed, Jun 14, 2006 at 12:10:26PM -0400, David F. Skoll wrote:
> > Would it possible to think about to _save_ the state between all the
> > functions?
> 
> It's complex and I think has too much overhead.  In addition, pretty much

Perl doesn't really offer that level of introspection. It's better to
explicitly save the state in your program by pointing to the variables
that you want to save, anyway.

> all the interesting information available at earlier stages is *also*
> made available to later stages, so there's usually no need to save state
> between callbacks.  (In fact, I have never encountered a situation in
> which it's necessary.)

A real-life example that we are currently using in production:

In filter_recipient, we perform DNS blacklist lookups, which might
result in a reject, or in a redirect to a spambox. In case of a
redirect, we save the result of the DNS lookup. We also save some
state to set a header later.

(which reminds me: there is no real reason why you can't set a
header in MIMEDefang at filter_recipient time. MD can just delay
passing the information to the milter until smfi_eom() time,
and simply store the change-header command in the RESULTS file, as it
does anyway... or can't it?) (on the gripping hand: never mind,
we have to consolidate all calls to filter_recipient in one header
anyway).

> > The man page itself tells what to do, however, when the SMTP dialogue is
> > rather straigth forward, I mean, when the client does not pause before
> > sending the next data, the probability is high, that the same slave is
> > still idle and can be passed to request to.

Not really. We usually see somewhere like 50 active incoming sendmail
processes, and only a handful (5 to 10) non-idle mimedefang processes.

This is because getting from the last "filter_recipient" to the next
"filter_begin" call, requires several TCP roundtrips, plus the upload
by the client of all the data, which is not trivial over a DSL line,
given the average (outgoing) mail size of 100Kbyte.

So it isn't likely that the same MD client gets all consecutive
calls belonging to the same SMTP session. Unless you have a really
quiet mail server that only processes one incoming mail at a time.

> results later on in filter_begin, you can just save to a file.  I can
> definitely see a use for library functions to save/restore a hash full
> of state.

use Storable;

$hashref = retrieve "filename";
...
store($hashref, "filename");

(or $arrayref, or $AnyComplexObjectYoudLikeToStoreExceptOpenFilehandles)

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disc lamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please  !!
!! archive this message indefinitely to allow verification of the logs.   !!



More information about the MIMEDefang mailing list