> You do not seem to grasp the basic concepts of parallelism.

Excuse me? You're just repeating a case that I already mentioned: ``In
the exceptional cases where the bandwidth loss wipes out the latency
gain (e.g., a 2400bps link to a nearby smarthost), I suggest using a
transport protocol with _good_ compression, such as gzipped UUCP.''

> > He continues to claim that there is no security problem with throwing
> > out messages that have duplicate Message-IDs.
> That's what we have Message-ID:'s for.  Read the RFC.

I _have_ read it. Have you? It doesn't suggest throwing out duplicates.

Message-IDs are _supposed_ to be unique, but _assuming_ that they are is
a security problem.

> The fact that an RCPT takes several minutes means you have a constrained
> pipe;

Occasionally, but usually not. The most common reason for extremely long
RTTs is route flapping. The second most common reason is a dead DNS
server somewhere else---it's an unfortunate fact that most servers don't
respond to RCPT until they've finished several DNS queries.

Anyway, when bandwidth is the problem, you should profile your traffic.
You'll find that most of it is Web use, not mail.

> Internetworks in general are not unlimited, latency-free or low-latency
> systems.  They usually are filled up to the rim,

That's one of the advantages of qmail over sendmail: qmail uses less
bandwidth.

> If you were to stop bashing and actually presenting an argumentation, I
> think people would be a little more relaxed about it.

If there are some points that I could clarify for you, I'd be happy to
do so.

---Dan
Sick of sendmail? Don't get mad; get qmail. http://pobox.com/~djb/qmail.html