[Mimedefang] Comments on mimedefang.plL
David F. Skoll
dfs at roaringpenguin.com
Mon May 27 11:46:20 EDT 2002
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
> 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;
> 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
> 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
Also, are the rate-limiting switches in the multiplexor (-w and -W) useful
under heavy loads?
More information about the MIMEDefang