-----Original Message-----
From: David MacQuigg [mailto:macquigg(_at_)ece(_dot_)arizona(_dot_)edu]
Sent: Tuesday, November 17, 2009 10:56 AM
To: Ned Freed
Cc: Tony Finch; ned+ietf-smtp(_at_)mrochek(_dot_)com; Murray S. Kucherawy;
IETF
SMTP list
Subject: Re: Abort data transfer?
So I'm as puzzled as Ned about the claims of efficiency. It might make
sense for SpamAssassin to wait for the end of data, but I can't see how
buffering all the data, and not actually running each milter routine at
the time it appears to be called, I can't see how that does anything
but open a door for abuse.
I believe the intent, or at least an intent, is to make it possible for an
upstream filter (in the sense that there's a ordered set of filters an
instance
of Sendmail is using) to make changes that a downstream filter will see.
Doing
them all in parallel would mean all filters get the same data, making upstream
changes invisible. So if, for example, filter #1 is a header-based content
scanner and #2 is a body-based content scanner, and a gigantic message
arrives,
filter #1's decision to replace the body with something tiny means #2 doesn't
have to do a ton of work on a body that's going to be discarded anyway.
OK, that's a claim that makes a lot more sense. However, I would argue that
you've made a pretty large sacrifice to get this ordering capability.
FWIW, we support both modes in our implementation. The default is to run all
milters concurrently and with as much processing concurrency between the MTA
and milters as we can eke out. If you want a strict milter cascade, it's a
simple matter to configure one more more intermediate channels and run a
different set of milters on each.
Ned