On Fri, 11 Feb 2000, Len Budney wrote:
> I'd be fascinated to know whether that's _ever_ a good idea. In the
> situations you describe, the MTA _must_ stall the sender until it
> finished processing the message.
It is a good strategy if and only if the time needed to pass the message
to the next stop is comparable to the time needed to store the message in
a safe way. (Otherwise, it would be a rather stupid strategy.)
> If the MTA is forwarding via SMTP, then senders will typically suffer
> a delay of over ten seconds.
If the next MTA is on my LAN, the next MTA will deliver it locally, and I
start piping the message to it as soon as the sender starts sending it to
me, the resulting additional delay might be negligible.
> If the MTA is filtering through a program, then senders will suffer an
> unpredictable delay which can easily be manipulated by a malicious
> recipient.
This depends on the program. :)
> As an added bonus, you get all the code bloat which goes into deciding
> whether to forward, filter or queue messages.
This decision must be made. Sooner or later. The fact that a certain piece
of code is executed sooner does not make that code bigger. The bloat
(compared to qmail) would go elsewhere.
> The examples which you gave don't look like viable alternatives, though.
Well, look at...ehm...certain existing pieces of software with millions
of installations. The world's notion is viability is very flexible,
isn't it? :)
BTW: mini-qmail is an example of a trivial single-purpose MTA (or quasi
MTA) that does never save messages to disk. Should it be thrown away
etc.? :)
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
