-----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.