Ranga Nathan wrote:
I am strongly advocating someone to get off Microsoft Exchange and move to
a Linux based mail server.
I think the two easy answers are:
1. Use whatever is bundled with your Linux distribution. If it is for a
small site, and they don't require anything beyond the basic features
that Exchange provided, any of the popular MTAs should do the job.
Likewise for the bundled IMAP/POP3 server.
Even if you don't like Sendmail's configuration, you might not have to
adjust much. Although thanks to spam, there really is no such thing as a
simple mail configuration these days. Unless you are using a spam
filtering service or appliance, plan on eventually needing to get under
the hood.
2. Use a commercial alternative to Exchange, as someone else mentioned
on the list. That way adherence to Exchange functionality is someone
else's problem. I don't have experience with this approach, but I hear
there are some good commercial solutions in this space.
For the less easy answers, read on...
Looking at this Qmail seems OK to me.
I had been a long time Sendmail user, but I set up qmail about a year
ago on the recommendation of colleagues. The initial experience is sort
of like fitting a square peg in a round hole. Qmail has a lot going for
it, but Dan Bernstein definitely has an atypical view of how things
should work in the UNIX environment. He has some good ideas, but until
there is a "DJB" distribution of Linux, you face a learning curve and a
bit of a cascading upgrade as you install one of his products and all
the support tools that go along with them.
This alone, though, isn't enough of a reason not to use qmail. The more
significant issue I faced was that qmail's code is essentially frozen
back in 2000 (give or take a year), and as a result is way behind the
times with respect to the current day challenges faced by spam. The
typical response to this problem is to replace qmail's SMTP daemon with
a more modern and flexible one, such as the Perl-based qpsmtpd
(http://develooper.com/code/qpsmtpd/).
OK, so now you've replaced the front-end, applied security patches, then
applied a bunch of other unofficial patches to get MySQL support for a
virtual user database, and now qmail starts to seem less appealing. (On
top of that, qmail has a somewhat restrictive license, which was a
problem for my situation, which was prototyping a solution to be used in
an appliance.)
I went back to the research drawing board and the next viable candidate
was Postfix (http://www.postfix.org/). The word is that it doesn't have
as rigorous of an approach to security as qmail, but its architecture
comes quite close, and it was similarly designed expressly to address
security.
Postfix had all the features I was looking for right out of the box. It
installs easily on a generic Linux platform; is familiar for someone
used to Sendmail; has a fairly logical configuration language; but where
it is really like night and day compared to qmail is the documentation.
Postfix is professionally packaged and quite consistently documented.
Also, important with any open source product, the Postfix community is
quick to help out. It is a very popular product with a high volume
mailing list, so the gurus tend to be curt and have a low tolerance for
discussing details or dealing with newbies that haven't read the FAQs. I
didn't spend much time checking out the qmail community, but if what I
hear is true, Postifix's author is a tad more agreeable than Dan Bernstein.
To round out the virtual user solution I implemented, I used MySQL for
the back-end database, Dovecot (http://www.dovecot.org/) for IMAP server
(I'd recommend avoiding POP3 if you can), and maildrop
(http://www.courier-mta.org/maildrop/) as the local delivery agent.
Though I'm not satisfied with maildrop and am working on a Perl-based
local delivery agent.
Later I'll be adding amavisd-new (http://www.ijs.si/software/amavisd/, a
Perl-based SMTP proxy that interfaces to spam and virus filters),
SpamAssassin, and ClamAV.
This collection of tools, with the exception of Dovecot, which is fairly
new to the scene, seems to be a popular combo.
But I believe there are some perl based mail servers too.
I'm not aware of any dedicated, stand-alone, Perl-based SMTP servers.
Though I can't say I've specifically gone looking for one, and
applications tend not to show up on CPAN.
There certainly are several Perl-based SMTP proxies available. I ended
up writing my own before finding some of the better ones.
I can say that if there was a Perl-based SMTP server, it probably
wouldn't be based off of Net::Server::Mail::SMTP (the best, if not only
SMTP server choice on CPAN) as I don't think that code is production
quality.
With all the effort put into benchmarks and performance optimizations of
modern MTAs, you wouldn't think a Perl-based SMTP server would be a good
idea, but thanks to spam, most sites end up running every message
through Perl-based processing code (a proxy or spam filter), so they're
taking the performance hit anyway.
Hmmm...email processing may have replaced the web as the "killer app."
for Perl.
Your experience and recommendation?
Jonathan de Boyne Pollard, a qmail fan, wrote reviews of all the major
MTAs. I found them useful, even if a bit biased. Here's the one for Postfix:
http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html
which contains links to the other reviews.
-Tom
|
