Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA27246; Wed, 6 Mar 1996 02:30:33 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.4); Wed, 6 Mar 1996 02:30:08 -0500 Received: from koobera.math.uic.edu by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA27181; Wed, 6 Mar 1996 02:30:06 -0500 Received: (qmail-queue invoked by uid 666); 6 Mar 1996 07:31:59 GMT Date: 6 Mar 1996 07:31:59 GMT Message-ID: <19960306073159.13521.qmail@koobera.math.uic.edu> From: djb@koobera.math.uic.edu (D. J. Bernstein) To: drums@cs.utk.edu Subject: Re: re PIPELINING > (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, These are _insignificant_. If you go through your logs you will find that the _maximum possible_ benefit of multiple RCPTs for your host is under 1% of your CPU time, under 1% of your processes, under 1% of your network bandwidth, and under 1% of your storage, compared to your normal resource use for mail. Latency is different. EVERY SINGLE MESSAGE has to have low latency. It is completely unacceptable to a user that he received an important message six hours late because he was at the end of a long mailing list. Even if this happens for only one message out of every ten thousand, it's a disaster. Sometimes the disaster was somebody else's fault---a host went down--- but if it's your mailer's fault then your mailer is poorly engineered. > (5) lose the ability to eliminate duplicate messages Wrong. This is trivially handled by the LDA---where you get the added benefit of applying it to messages that came in through different paths, messages that were duplicated because of network burps, etc. > (6) lose the ability to optimize storage of the Wrong. This is trivially handled by the LDA---where, once again, you get to apply it to messages that came in through different paths. ---Dan