Re: Suggestions for a mail server...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 21, 2005, at 12:13 PM, Ken Morley wrote:

My customer needs a mail server that will support a few hundred remote
clients who will connect using POP3 or IMAP. The clients don't need any
webmail access, but will need the ability to send and receive email via the
internet, not just amongst themselves.


A key requirement is that administration of the mail server must simple and
preferably via a GUI interface. I don't want the semi-technical people
responsible for adding, removing and otherwise managing accounts and
mailboxes to have to do it from the Linux command prompt or to have to use
multiple utilities.


I plan on using RedHat ES3 and I am very familiar with Sendmail, ClamAV,
MIMEDefang, SpamAssassin, etc. So, I plan on using those products for the
"core" of the mail server.


Can anyone recommend a component to handle the POP3/IMAP part of this?
Should I maybe use procmail instead of sendmail? What about the management
issues?

Personally, I suggest a combination of Postfix, Courier-IMAP, MySQL, Postfixadmin, SASL2, ClamAV, Amavisd-new, and SpamAssassin. Postfix is a drop-in replacement for Sendmail and is much simpler to learn and administer. You didn't mention which MRA you wanted to use, but I've been very happy with Courier-IMAP. I usually administer virtual accounts stored in the MySQL database using Postfixadmin, written in PHP and simple to use. Also allows you to create other admin accounts for the purpose of delegating account administration to other admins (on a per-domain basis). The SASL2 library is used for SMTP AUTH, which works great with the virtual accounts. Amavisd-new provides the modular plug-in architecture which also allows us to use SpamAssassin and ClamAV easily.


I've installed various combinations of the aforementioned software on a number of RHEL servers (and clones), and it all works beautifully. Most of the parts are optional yet complementary, so you only need to use them if your customer deems that feature as a necessity.

HTH.

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net


-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux