Sorry I'm late joining this discussion.


1. Here's the idea behind the envelope sender addresses.

Suppose you're running a mailing list. One day you start receiving
bounce messages: joe@af.mil no longer works for the Air Force.

You check the list, and joe@af.mil isn't there. Apparently one of your
subscription addresses is being forwarded to joe@af.mil. Which one?
Unfortunately, this question can be very difficult to answer.

qmail offers a solution: variable envelope return paths (VERPs). The
message to you@yourhost is sent with a return path of

   current-users-owner-you=yourhost@netbsd.org

If you forward the message and it bounces, the bounce will come back to
current-users-owner-you=yourhost@netbsd.org.

It's very easy to set up outgoing VERPs, and it's easy to feed all the
bounces to a program that extracts the you@yourhost information. I'm
pleased to see mailing list managers taking advantage of this feature.


2. I recommend filtering mail with the envelope _recipient_ address, if
your local mailer supports it.

For example: subscribe to the netbsd mailing lists with an address of
you-netbsd@yourhost. Direct you-netbsd to a separate mailbox.

This is invulnerable to changes in the format of mailing list messages.
The messages are sent to the right address, so the filter works.


3. SMTP offers a simple compression algorithm: ``send Joe this message,
send Bill this message'' can be abbreviated ``send Joe and Bill this
message.''

A few people have noticed that qmail doesn't use this algorithm. It
makes two parallel connections instead.

The reason is that, except in extreme cases, qmail's approach is faster.
(With a single connection, you have to wait for an extra acknowledgment
between ``Joe'' and ``Bill.'' With parallel connections, you don't.)

There's a new PMDF release with the same feature---it can be configured
to deliberately make several parallel SMTP connections to a single site.
The reason, presumably, is the same. Perhaps sendmail will catch up
someday.

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.


4. Finally, I'd like to correct a few erroneous statements about qmail.

``qmail's extra bandwidth use will destroy the Internet'': Nonsense.
Profiling has proven that qmail uses _less_ bandwidth than sendmail.
The maximum benefit of SMTP's simple compression algorithm is under 1%
of the Internet's mail traffic; this is outweighed by qmail's savings in
other areas, notably DNS lookups.

``qmail beats remote SMTP servers to death'': Nonsense. The concept of
this type of overload is ludicrous. Even the _maximum theoretically
possible_ burst---which will never actually happen outside controlled
tests---won't hurt a remote 486 running qmail.

``sendmail's SMTP server will be changed to allow only one connection
from any given remote host'': Nonsense. The reason that this won't work
is blazingly obvious. Brad Knowles made the same claim months ago, and
subsequently realized what an idiot he was being. Paul Vixie actually
went so far as to implement the same thing for HTTP, but he turned it
off (and admitted his mistake in public) when he saw the problem.


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