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 _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
