> > -----Original Message-----
> > From: David MacQuigg [mailto:[email protected]]
> > Sent: Tuesday, November 17, 2009 10:56 AM
> > To: Ned Freed
> > Cc: Tony Finch; [email protected]; 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
