 | | | Suggestions for a mail server... | Suggestions for a mail server... 2005-02-21 - By Jason Dixon
Back
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@(protected)?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
|
|
|