Murray S. Kucherawy wrote:
-----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.
--> Buffer --> Filter#1 --> Filter#2 -->
I don't understand how running the filters in series requires that the
entire message be in a buffer. In the example above, filter #1 scans
the headers and decides immediately to replace the body with something
tiny. It could abort the transfer, saving a ton of work not just by
filter #2, but also in the original data transfer to the buffer.
************************************************************ *
* David MacQuigg, PhD email: macquigg at ece.arizona.edu * *
* Research Associate phone: USA 520-721-4583 * * *
* ECE Department, University of Arizona * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
************************************************************ *