I have several problems with the James' post below. However, let me
start by saying that I spent more than 20 years administering large
sites using sendmail. In fact, I used to be one of only 3 accredited
instructors in "sendmail Administration" for Learning Tree International
(for whom I no longer work, and they long-ago retired that course, as
well as most of their other "advanced" UNIX/Linux courses). The point
being, I'm not trying to get into a sendmail vs. QMail war here. I am a
FIRM believer that no single tool is appropriate for all problems (which
is a major argument I use with clients who want an "all windows"
environment).
Next, I'll admit that my assumptions (which may be false, or at least
may be different from James') include that the filter-MTA (sendmail or
QMail) is on a different machine than the end-user-MTA (which could be
almost anything, but in my experience is usually an MS Exchange server),
and that the original sender is a relatively new Linux System
Administrator who had sufficient difficulty getting QMT operating to his
satisfaction that a decision was made to drop it (again, probably in
favor of MS Exchange -- but that is purely MY guess).
So, that being said, there are some "claims" made be James that I
definitely don't follow on:
To begin with, at first glance I reject the notion that sendmail is
categorically faster and has overall lower-overhead than QMail. They
each have a very different programming approach: sendmail is a
"monolithic" mail handling program that "does it all in one process",
whereas QMail follows a more "UNIX-y" approach: create several small
programs that each do one thing well, then connect them with pipes
and/or sockets. As a result, my experience has been that QMail has an
overall file-I/O superiority, and sendmail has an overall CPU
utilization superiority. Still:
a) as a "simple" front-end processor, neither program (sendmail or
QMail) is going to have knowledge of valid mailbox names (at least not
directly from the the other MTA), so both should accept all messages
for any properly-configured domain & send them on to the appropriate
end-user-MTA
b) if you're going to do something more "fancy", like configure
mailboxes in BOTM MTA's (the end-user MTA & the filter-MTA), then doing
so shouldn't be too much harder for QMail or sendmail - either one, so
that would be a "push"
c) if you assume that your system will have a CPU resource issue in
handling your inbound message-load (suggested 200k per day would be too
much), then you're apparently not looking at the configuration options
of QMail (/var/qmail/control/concurrency*) or are ignoring the effects
of adding relatively cheap RAM to your system to offset those effects.
Again, in my experience sendmail's CPU load is not /THAT/ significantly
lower than QMail's.
NOTE: In the above case, I am making those comparisons on "basic" QMail,
not QMT -- which adds clamav, spamassassin, and (in this users case)
spamdyke -- all of which are CPU intensive. IMHO, if being used as a
SPAM filter, I would disable the clamav scans in QMT, allowing only the
spamassassin & spamdyke filters. The end-user MTA (or even the end-user
system!) could be relied upon to perform AV scanning. (In the case of MS
Exchange, I would ASSUME than an appropriate AV program is running on
the server. As AV scanning would naturally occur AFTER the message
receipt and mailbox validation, it would be the naturally better choice
to do the AV scan THERE vs. in the filter -- which would have to scan
ALL messages)... but this applies evenly to QMT/spamdyke and to
sendmail/mimedefang!
Next, I equally reject the notion that you would get "backsplash" from
the end-user MTA. That would assume that the end-user MTA is setup to
"bounce" invalid mailbox messages, or that said rejections would come
back to the filter-MTA. The practice of BOUNCING invalid email addresses
has been increasingly ill-advised for more than a decade ( I personally
remember reading how it was becoming a "bad idea" as far back as 1999 --
so maybe I heard it early and it's only been 9 years). I admittedly
assumed (perhaps wrongly) that the end-user MTA would accept and drop
invalid messages. However, even IF the end-user MTA DID BOUNCE invalid
mailbox messages, it will be doing so at one of 2 times:
a) During the initial exchange (pre-full-message delivery), in which
case QMail can be programmed to retry only a very limited number of
times (after all, virtually ALL of QMail's outbound messages will be to
the end-user MTA -- not various "real" MTA's on the Internet as is
assumed in the default configs), or
b) Post message receipt, in which case, the response goes back to the
sender directly (presumably straight out the Internet connection & not
through the filter-MTA system). Now this DOES assume that you're not
trying to filter outbound messages on the filter-MTA system. I've
already argued that point earlier -- see my original post!
So, regardless of the behavior of the end-user MTA, any "back-splash"
would be directed to the Internet, not back to the filter-MTA (our QMail
or sendmail server). Ironically the rationale for DROPPING vs. BOUNCING
mail addressed to non-existent mailboxes is because of SPAM issues...
SPAM producers long-ago figured out how to "address harvest" from mail
servers that bounce erroneous addresses. Messages that DON'T bounce from
said poorly configured servers are then SOLD as "confirmed, valid user
addresses" to other spammers -- thus helping you, the poor novice mail
administrator, get the word out that you are ill-equipped to prevent
SPAM, and thus increasing the amount of SPAM your soon-to-be-pitied
end-users receive exponentially!
FINALLY, if you take into consideration the original poster, (Mike?),
who had difficulty in getting a QMT setup and working, and so abandoned
that as an end-user MTA, the idea that using a sendmail/mimedefang
approach would work "better" seems to ignore his admitted limitations
(no offense, Mike!). Recall how I mentioned above that I used to TEACH a
4-day course in sendmail Administration! I will freely admit that, after
4 full action-packed days, our students were STILL not
fully-ready-for-prime-time sendmail administrators (but they COULD do
some fancy stuff in sendmail -- certainly enough to get them in REAL
trouble!) However, that being said, I would doubt that it would take
more than a day, perhaps stretched into 2, to teach the same
capabilities in QMT. Naturally, one of the REASONS is that sendmail is
infinitely more configurable than QMT -- but it is also infinitely more
COMPLEX than QMT -- which is why I would NOT recommend a
sendmail/mimedefang configuration to the original poster. At least not
without professional Linux Admin help!
sendmail has its place -- and I still administer ONE sendmail site. But
when you consider that I administer well over 100 email domains on more
than 30 systems -- I have to say that, in my opinion, QMT is to mail
administration what XWindows was to making *nix an end-user friendly
system! (That is, it makes things MUCH easier than the traditional
"guru-friendly" *nix approach!)
These are just my thoughts and opinions, and although I named James
herein, I offer him no ill-will. I simply disagree with his advise on
purely technical grounds.
Also, it's Saturday, it's raining outside, and I'm BORED out of my SKULL
today... and I have just successfully survived an hour of opera by
concentrating instead on writing this LONG message!!!
Here's to hoping the weather (and your sanity) is better wherever YOU are!
Dan
Daniel McAllister, President
IT4SOHO, LLC
224 - 13th Avenue N
St. Petersburg, FL 33701
877-IT4SOHO: Toll Free
727-647-7646 In Pinellas
813-464-2093 In Hillsborough
727-507-9435 Fax Only
"When did you do your last backup?"
Ask me about unattended offsite backup solutions...
to protect your business, not just your data!
James E. Pratt wrote:
Hi,
If your network processes a lot of mail (i.e over 200k messages per
day), this could really kill your front-end box, as qmail will accept
mail for non-existent users by default and you will be wasting cpu
cycles scanning worthless messages that will just end up bouncing and
sending lots of backscatter out, essentially worsening the overall "spam
problem" in general :\ ...
I use sendmail and mimedefang here at work and I have way more control
than qmail-toaster could ever give us for a front-end to exchange, as
qmail-toaster is really built more for backend storage of multi-domains.
You can get much better performance on a spamassassin relay using a
different MTA like sendmail or exim/postfix along with
procmail/mimedefang etc... I mean, Qmail is definitely great, but has
certain issues that make it somewhat unsuitable for large, single-domain
environments... :\
(just my 2 cents!) :)
Regards,
jp
Dan McAllister wrote:
I have implemented this, using QMT as a front-end filter for an Exchange
Server...
It's actually simple...
a) Install QMT -- but do NOT add ANY domains (much less users)
b) Add your domain to the /var/qmail/contol/rcpthosts file, eg:
mymaildomain.com
c) Add the address of your exchange server to the file
/var/qmail/control/smtproutes, eg:
mymaildomain.com:10.1.1.50
NOTE: In my experience, it was a worthless exercise to try to route
outbound mail through the toaster as well... let exchange deliver the
outbound mail, but QMail sit in front of Exchange on the inbound side.
In other words, Exchange should be sitting behind a firewall (or NAT
router), and the inbound mail ports (namely 25) should be directed to
your QMT system, NOT the Exchange system. (You'll also want to point
some type of web interface to the Exchange Server for remote mail
access. I use an advanced router to redirect different ports for that
purpose).
I hope this helps.... SOMEONE!
Dan
[EMAIL PROTECTED] wrote:
One thing is that spam went way way down while I was using QMT.
Are there any documents out there on perhaps using QMT simply as
a pre-processing host? All email coming into the network would go though
that first, get cleaned, then continue on to the mail server.
Mike
