To: djb@koobera.math.uic.edu (D. J. Bernstein)
cc: drums@cs.utk.edu
Subject: Re: re PIPELINING 
In-reply-to: Your message of "06 Mar 1996 03:18:33 GMT."
             <19960306031833.11466.qmail@koobera.math.uic.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 05 Mar 1996 22:50:32 -0800
From: michael.derrico@software.com (Michael D'Errico)
Message-ID: <19960306065032.AAA1749@rome.software.com>

[Sorry Keith....]

> > It is important that "efficiency" not be confused with "real time
> > performance."  These are two very different things.
> 
> Bullshit. Low latency---i.e., speed, from the user's point of view---
> is most certainly a form of efficiency. It is dishonest to refer to
> something as an ``efficiency feature'' when it SLOWS DOWN DELIVERY.

Look.  You are focusing on only one aspect of efficiency at the expense of 
all others.  When you send the same message N times to the same host, you:

	(1)  require N processes with most existing MTAs,
	(2)  require N times the CPU cycles on the server,
	(3)  require N times the network bandwidth,
	(4)  require N times the storage for the queued
	     messages as they are received by the MTA,
	(5)  lose the ability to eliminate duplicate messages
	     when the same recipient is listed multiple
	     times (often with different aliases), and
	(6)  lose the ability to optimize storage of the
	     message in users' mailboxes -- some MTAs store
	     only one copy of each message on filesystems
	     that support hard links.

I'm sure there are others as well.  Latency is not the only issue.

> > This last is rather important; there are some non-obvious scaling and
> > denial of service issues associated with not aggregating multiple
> 
> Bullshit. The issues are (1) obvious and (2) already solved.

The issues are (1) enumerated above and (2) solved by using multiple RCPTs.

Mike