On Tue, 4 Feb 2003, Les Mikesell wrote:
> >From: "Andre Joanisse" <[EMAIL PROTECTED]>
>
> >> I was just browsing the qmail site and noticed that there has been
> >> basically no development on Qmail in quite some.
>
> >If it ain't broke, don't fix it.
>
> Qmail by design delivers separate copies of every message even when the
> destination host is the same while all other major MTA's group them with
> multiple addresses in the SMTP envelope. This is very inefficient, especially
> when your typical communication is to business groups at different locations
> connected by slow and expensive private lines or even if you have a slow
> internet connection. Also, when you add spam and virus scanning, that
> must be repeated for each recipient as well, plus you are imposing this load
> on everyone else compared to grouped messages. Sendmail allows much
> easier control over allowed traffic with database lookups in several phases
> and the new 'milter' interface allows separate programs like MimeDefang
> to control processing with spam/virus scanning done concurrently with the
> SMTP reception. With qmail you have to accept the message before you
> can look at the content, then if you decide to reject you are obligated to
> construct and send a bounce copy.
Have a good long read of RFC 821. You must accept the entire message
before you can examine the content, no matter what you use as your SMTP
daemon. You can _only_ do envelope filtering in an SMTP transaction. Once
you begin to accept the data you MUST accept all of the data.
To quite Dan Bernstein, qmail's author, "Profile, don't speculate".
You may think it is inefficient to send messages to single recipients but
have you proved it? The inherent latencies in the SMTP protocol add more
to the delivery time than the potential savings from multiple receipts
for a large proportion of general mail traffic.
Here's someone who has done the profiling for his circumstances.
From [EMAIL PROTECTED] Tue Feb 4 09:56:43 2003
Date: Fri, 24 Jan 2003 11:57:55 +1000
From: Richard Lyons <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Alexander Skwar <[EMAIL PROTECTED]>
Subject: Re: Are messages to recipients of the same domain "grouped"?
On Thu, 23 Jan 2003, Alexander Skwar wrote:
> Richard Lyons wrote:
>
> > Keep in mind that qmail is a generalized MTA and the typical traffic
> > through a mail server doesn't benefit all that much from multi-rcpt.
While this seems like a reasonable statement, I had no relevant stats,
so I pulled some logs from one of our relay servers and crunched the
figures.
Of 334322 messages injected, 9012 (2.7%) had more than one recipient.
There were 377444 remote deliveries. Messages with more than one
recipient accounted for 52134 deliveries, about 14%. As we are
primarily a web hosting company, a lot of the mail is from mailing
lists on the hosted domains; I would expect the fan-out to decrease
for servers that are more general purpose.
If this server used multi-rcpt, the number of SMTP connections
would drop to 361173, a saving of about 4.3%. Taking into account
the commands sent to the remote server, data transmitted would be
reduced 7.8%.
Filtering some of the list traffic (ignoring records with #rcpts > 10),
SMTP connections drop by 1.8% and data by 3%.
Rick.
So, the overhead is very low and the reliability is very high for this
person. Unless you've got a delivery profile that is very different (ie
weighted heavily on the side of multiple receipts) I don't believe
you'll benefit greatly from an MTA that supports multiple receipts.
If you really want to take advantage of multiple receipts, write a
program of your own that calls qmail-remote directly - did you know it
can support mutliple receipts? There are pointers on how to do this in
the qmail mailing list archives. You can even read the man page for
qmail-remote.
As for traffic over low speed lines, that's a business decision rather
than a technical decision (most of the time). If your business has a
definite need to send lots of email then your business should invest
in a higher speed link (I do realise this can be difficult in some
areas, this is not a perfect world after all). You do the same with
couriers vs the post office don't you?
>
> If you look at the qmail license, you'll see why it hasn't been improved...
Nothing is stopping you using Dan's code and modifying it. You can
distribute patches. You can even distribute modified binaries - you just
can't call it qmail. Have a good look at the qmail mailing list
archive and you'll see that this topic has been beaten to death many
times. His license in not open source and it is restrictive however it
does not preclude third part modifications in any way. I have done
this myself - I modified part of daemontools and released it as
tai64nunix, which has been included with SME Server since 5.0.
As for development of qmail - Dan doesn't announce vapour ware. He
says he's working on qmail-2.0 but no-one knows how much has been
done. A lot of other infrastucture for qmail-2.0 has been developed
(most of which we ship with SME Server). Projects such as, ucspi-tcp,
daemontools, cdb, djbdns, etc. So development is being done, just not
the way you may want it done. I did say it wasn't a paerfect world
didn't I?
--
Regards
Peter
----------
Peter Samuel, Senior Systems Administrator [EMAIL PROTECTED]
http://www.e-smith.org (development) http://www.mitel.com (corporate)
Phone: +1 613 592 2122 Fax: +1 613 592 1175
Mitel Networks, 350 Legget Dr, Ottawa, ON K2K 2W7 Canada
"If you kill all your unhappy customers, you'll only have happy ones left"
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
