"Don Wright" <[EMAIL PROTECTED]> wrote:
> > From: Len Budney [mailto:[EMAIL PROTECTED]]
> > ...qmail writes the envelope at the top of every
> > message...
>
> I'm looking at setting up a qmail server for a midsize corporation. Are
> you saying that all delivery addresses that were supposed to be
> hidden by the BCC and mailing list functions would be exposed to
> all recipients?
Definitely not. As you say, that would be a very bad privacy problem. Each
recipient gets a copy of the message which tells _only_ the final
envelope recipient--in other words, what address resulted in delivery
to that recipient. (The envelope sender is also included, but that has
no security implications.)
> In the case of large mailing lists, that could add hundreds of kilobytes
> to each message being sent, resulting in excessive bandwidth charges.
What qmail does, specifically in order to honor BCC and mailing lists, is
send out one copy of the message per recipient. That's why other MTAs have
leaked BCC information, but qmail never has.
In general, this does not lead to excessive bandwidth consumption over
other mailers, for several reasons. Among them:
1. Other mailers waste so much bandwidth on redundant DNS queries that
they completely negate savings in transferred message bytes.
2. Other mailers are not able to take advantage of multiple envelope
recipients on the same host nearly as often as people imagine.
Except possibly certain scenarios involving mailing lists, a tiny
fraction of all deliveries consist in the same message to many
recipients at one host.
3. Other forms of traffic, particularly HTTP, completely blows away
the much smaller bandwidth consumption of SMTP traffic.
Dan will not change this feature in qmail, despite periodic holy wars,
for all of the above reasons, and more besides. Among them:
1. The pathological case of mailing lists has a much better solution.
Set up a sublist nearer to the cluster of subscribers, and subscribe
the sublist to the main list.
Consider your corporation. If most of your employees are subscribed
to the same foreign mailing list, then setting up a sublist on
your internal mail server lightens the load on the main server,
enhancing throughput. It also moves all of your employees to the
``front of the list'', enhancing perceived performance. Finally,
it means that for each list post, exactly one email passes through
your external connection.
If few of your employees subscribe to a given list, then you can
ignore it. Who cares about the minimal traffic that entails?
For purely internal lists, LAN bandwidth is all you care about--your
Internet connection is involved only minimally, if at all. LAN
bandwidth is hardly touched if your mailing list server is on or
near the mail server box.
(Dan's ezmlm, plus the IDX patches, can even work as a sublist of
non-ezmlm foreign lists. Check <http://www.ezmlm.org/> for details.)
2. Another pathological case is hyper-restricted bandwidth at your
Internet connection. The best solution to that is to use serialmail
with QMTP to store-and-forward outgoing email, and AutoTurn at your
ISP. Since your corporation is ``mid-sized'', your bandwidth concerns
can't possibly be that stringent.
3. If you consider serialmail sending two copies of the same message, and
wish you could shrink the bandwidth even further, then consider an
experiment recommended by Dan himself:
> wc -c MESSAGE
7752
> gzip -c MESSAGE | wc -c
3548
> gzip -c MESSAGE MESSAGE | wc -c
3651
In other words, ganging messages by recipient host is a piddly attempt
to conserve bandwidth which still consumes over twice the bandwidth
that a real solution, i.e. compression, would consume. If bandwidth
were _that_ tight for you, then it would be easy enough to use
compression to achieve some _real_ savings.
Hope this helps,
Len.
--
Do you really expect us to believe that you completely misunderstood
what Henders said, don't know what ``queue'' means, and can't speak
English?
-- Dan Bernstein, author of qmail
