Sam <[EMAIL PROTECTED]> wrote:
>... Qmail will also do
>pretty well when the mail volume is low, although there are certain
>pathological situations where Qmail will fail miserably with low mail
>volume.
What situations are you referring to?
>Also, Qmail will do poorly in the extreme upper end of the range,
>where your mail volume goes through the roof.
All MTA's do poorly in the extreme upper end.
>That's mostly a result due
>to a combination of factors: namely excessive amounts of DNS queries,
You continue to make this claim, but I've yet to see any
evidence. ``Profile, don't speculate.''
>and a
>lot of excessive TCP/IP traffic because Qmail does not recycle TCP/IP
>connections, nor does it batch same-domain recipients in any way.
"Excessive" is a value judgement. The fact is that qmail was
specifically designed to sacrifice bandwidth for simplicity and
performance. If you want/need an MTA that's miserly with bandwidth,
use one.
>Also, the fact that its limited to 255 concurrent qmail-remotes also
>comes into play, at one point.
1) There's a patch that raises that limit.
2) You can run multiple qmails per system.
3) qmail 2, if/when it's available, will undoubtedly remove that
limit.
>Sure, you can argue that all you have to do is to put
>in a dozen of OC-3s to handle the excessive amounts of bandwidth, and solve
>the 255 qmail-remote issue by instead splitting the mail traffic across
>multiple servers, in parallel. However, multiple servers still adds up to
>the same amount of bandwidth via your pipes, and no amount of bandwidth
>will affect the fact that a few hops away, most your traffic gets squeezed
>through a single T-1, or even a T-3.
Engineering is the art of balancing tradeoffs. No MTA can maximize
delivery speed, reliability, security, and flexibilty while
simultaneously minimizing bandwidth, disk I/O, memory usage, etc.
-Dave
