[Mimedefang] Comments on mimedefang.plL

[David F. Skoll]

On Mon, 27 May 2002, Clayton, Nik [IT] wrote:

> In sendmail() and resend_message(), the exec() call can fail.  If this
> happens the child doesn't explicitly exit, and bad things will happen.

I have fixed this in CVS; fix will be in the next release.  Thanks.

> >From an efficiency point of view, the code in serverloop() that parses the
> SENDER, HOSTIP, HOSTNAME, RECIPIENTS, and other files isn't always
> necessary.
> It's there to ensure that some global variables are populated properly.
> However, if the end user's filter*() procedures don't use these variables,
> this work is for nothing.  IMHO, these variables ($Sender, et al) could
> either be wrapped inside subs that the filter has to call to get the values,
> or (neater) turned in to tie()'d variables.  Either way, the performance
> hit is only taken if you need the value.

That's a good idea, but I doubt it has much of a performance impact compared
to calling SpamAssassin.  In the Great Reorganization which should be done,
these will be fixed.

>     -f 'SUSPICIOUS-CHARS-IN-HEADERS' && $SuspiciousCharsInHeaders = 1;
>     -f 'SUSPICIOUS-CHARS-IN-BODY' && $SuspiciousCharsInBody = 1;

OK, done.

> Is there any interest in allowing filter_begin() to abort processing
> the rest of the message?  If I've used SpamAssassin to determine
> that the message is spam in filter_begin(), I don't want filter() to
> be called for the rest of the parts in the message.

You can put this code right at the top of filter():

	# Don't do work for nothing
	return if (message_rejected());

which helps a bit.  Again, this will be fixed when (if?) I reorganize
the code.

> Now for a more general muse -- how do people feel about the 'interface' that
> the filter*() procedures have to the rest of the code?

It's bad. :-)  MIMEDefang accreted features; it's become pretty messy now.
I agree with you (and others have suggested) that a proper Perlish OO
interface is needed.  If anyone wants to pay me to do it... :-)

> How about putting the user supplied filter subs in their own package, so
> they've got their own namespace to play with?

You can do that in your filter.  Only filter, filter_begin, filter_end,
filter_multipart and defang_warning need to be in 'main'; you could
use your own package for everything else.

The API needs reworking.  Your example was an interesting starting point.
One thing, though -- backward-compatibility might be an issue.  So I'm
hesitant to do anything quickly, but it will get done eventually.

Questions for you:  Are you able to release any more details of how
you handle such a high volume of e-mail?  Number and configuration of
machines, etc?

Also, are the rate-limiting switches in the multiplexor (-w and -W) useful
under heavy loads?

Regards,

David.