Mailing List Archive

> > - find a solution to the annoying explosion method (group of mails to the
> > same host are sent in paralel by separate processes/TCP connections
> > instead of more efficiant delivery)
>
> But it *is* more efficient in terms of the only cost that is
> increasing -- the time of the people using the computers. Every other
> cost of email delivery is dropping through the floor -- even in
> PTT-dominated and third-world countries. CPU, disk, and bandwidth are
> all getting cheaper. There is no reason for an MTA, being written in
> the late 90's, to attempt to conserve these resources at the cost of
> human time.
>
> There may be rare circumstances in which bandwidth is more expensive
> than human time. In that case, it makes sense to batch, compress, and
> transport the email to a relay point where the bandwidth is cheaper.
> If bandwidth is truly a concern, then address that concern in an
> effective manner, rather than taking half measures like aggregating
> mail to like hosts.

The original poster's argument is that the cost of opening lots
of TCP connections is quite high. Your argument is that cost of bandwidth
is getting cheaper, and is not a conern. Comparing cost of _opening_
lots of TCP connections to cost of bandwidth seems to me like comparing
apples to oranges.

For example, when you stumble upon a web page with a Java applet, it is
much better for you (the user) to open one connection to the sever
to retrive a tar (JAR) of all the class files needed to run the applet,
then to initiate a connection per class file you need to get.
I think this is a good parallel, since Java _applet_ files tend to be small,
and their size is usually in the same order of magnitude as mail messages.
If you compare "total download time" (which includes the overhead time
for opening/closing tcp sockets), you'll see that JAR format has an
advantage over lots of little class files.

Also, here's some subscriber data from the mailing list I run:

scam:~alias> grep -i sun .qmail-advanced-java-outgoing | wc -l
80
scam:~alias> grep -i netcom .qmail-advanced-java-outgoing | wc -l
16
scam:~alias> grep -i ibm .qmail-advanced-java-outgoing | wc -l
14
scam:~alias> grep -i microsoft .qmail-advanced-java-outgoing | wc -l
13

For a miling list like mine, an MTA opening one tcp socket per unique
MX host would definitely be great.


http://www.xcf.berkeley.edu/~yaroslav

On 23 Feb 1997, Russell Nelson wrote:

> > - RPM and deb packages becoming a standard official distribution format,
> > right next to the .tar.gz file, to help Qmail spred faster
> > - stick to FSSTD and kick the binaries/manpages out of /var in the default
> > installation
>
> Kind of Linux-specific, aren't these?

Well, not the kicking binaries/manpages out of /var one. In fact,
putting binaries/manpages in /var is universally considered very bad
taste. What qmail needs is a way for the user to configure where things
end up, and then they can fit it to whatever scheme they're comfortable with.

Evan
--
Evan Champion * Director, Network Operations
mailto:evanc@synapse.net * Directeur, Exploitation du reseau
http://www.synapse.net/ * Synapse Internet

On 23 Feb 1997, Russell Nelson wrote:

> > - find a solution to the annoying explosion method (group of mails to the
> > same host are sent in paralel by separate processes/TCP connections
> > instead of more efficiant delivery)

> cost of email delivery is dropping through the floor -- even in
> PTT-dominated and third-world countries. CPU, disk, and bandwidth are
> all getting cheaper.

Cheaper, yes; finite, no. *Some* sort of connection caching (not
necessarily holding the connection open, but at least bundling messages
to the same host) would improve bandwidth efficiency.

I can think of one very specific case where connection caching is
nearly mandatory. At a place I used to work, there were several mail
"servers" which were single-threaded MS-Windows SMTP-MSMail "gateways".
Only one connection at a time could be made; the remainder were rejected.
Now obviously this is not qmail's problem, but nevertheless the behavior
of a non-connection-caching MTA was predictably bad -- during a queue
run, about 1/20 of the messages would squeeze through, and the rest
would be delayed, sometimes for days. (This problem was compounded by
the instability of these "servers". Blech.) (Actually, qmail couldn't
have been used at that place, because qmail doesn't handle DECNet and
UUCP mail address formats, but that's not the point.)

>There is no reason for an MTA, being written in
> the late 90's, to attempt to conserve these resources at the cost of
> human time.

I think there's always a place for efficiency. If you wanted something
inefficient, there's always that other MTA. :-)

------------ Greg Wooledge -------------
------- <wooledge@kellnet.com> -------
--- <http://kellnet.com/wooledge/main.html> ---

Excerpts from internet.computing.djb-qmailbeta: 23-Feb-97 qmail 1.00
born. wish list .. by Russell Nelson@crynwr.co
> > - find a nice solution for people used to using .forward
>
> .forward is badly documented. In most cases .forward can be renamed
> to .qmail.

Except in this annoying case where the .forward file is
"|/path/to/forward/to/file"

That worked under Sendmail but had to disappear under .qmail...
I'd blame that on .forward, however, rather than .qmail

Aveek Datta _ _ _ _
_ __ ___ _ _ ___| (_) |_| |_ Network Admin, Monolith @ www.ml.org
_| ' \/ _ \ ' \/ _ \ | | _| ' \ _ SysAdmin, ITC @ www.itc.cmu.edu
(_)_|_|_\___/_||_\___/_|_|\__|_||_(_) Personal Homepage @ datta.ml.org
# All opinions are personal unless stated otherwise.