Peter Cavender <[EMAIL PROTECTED]> wrote:
>I volunteered to talk about and "defend" qmail at a Linux Users' Group
>meeting where there will be people speaking on 3 or 4 of the main MTAs.
>
>I am competent in setting up and maintaining qmail, but I must say that I
>am unable to respond properly to a lot of the criticism of qmail, mostly
>in comparison to sendmail (which I have never administered).
>
>I would appreciate any and all rebuffings of qmail myths, relevant
>anecdotes, or theoretical analysis that would aid in my presentation.
Tips:
Be honest--don't be afraid to admit qmail's weaknesses or sendmail's
strengths.
Be reasonable--don't claim that qmail is right for everyone.
Be positive--concentrate on qmail's strengths, not sendmail's
weaknesses.
Be calm--project confidence, not mindless advocacy.
qmail vs. sendmail pro's:
security
performance
reliability
modularity
VERP support
extension addresses
qmail vs. sendmail con's:
no connection caching or multiple-RCPT's
no bad address rejection during SMTP
redistribution restricted
sendmail is more widely known
qmail vs. sendmail diff's:
configuration style is very different
logging information is different
qmail myths:
qmail can flood a server that's been down for a while.
Since each message has its own retry schedule, qmail won't
immediately try to drop its backlog on a server. Other MTA's
sendmail *will*, though, through connection caching.
qmail can open too many connections to a server.
There is no way a sending system can know each remote system's
capabilities at each point in time. It has to assume that if the
remote accepts an SMTP connection request, that it can handle the
load.
-Dave
