For a simple mailserver I don't think groupware is required.

Looking at the what packages are available there doesn't seem to be one that does everything.  The usual approach seems to be to pick best of breed.  This is OK but it then becomes a tough excercise in system integration and that seems to be a big enough problem without throwing groupware into the mix.  There would be a number of possible requirements:

1.  Getting the mail.  Whatever the method there might be a need to consolidate multiple external IDs to a local user ID. e.g. if I buy from some web vendor I set up an address just for them to email me; this is then forwarded to my regular local mail account but after the transaction I close down their address so if they try to spam me it will bounce.

1.1 Retrieving mail from an ISP's POP3 or IMAP server.  Server might be singledrop or multidrop.  Candidates include Fetchmail, Retchcmail and Getmail.

1.2 Providing an SMTP server on the internet.  Candidates include Postfix, Exim, Sendmail and Courier.

1.2.1 Server with a FQDN

1.2.2 Server hidden behind a NAT.  Postfix configuration instructions are unclear as to whether this needs special handling.

2. Storing the mail.

2.1 Real user mail boxes. Candidates include mbox & maildir.

2.2 Virtual users. Candidates include physical mailboxes as per 2.1 (but not in $HOME) and databases.

3. Delivering the mail.

3.1 Just logging in & reading the mailbox direct.  Probably inadequate.

3.2 POP3 or IMAP server. Candidates include Dovecot & Courier.

3.3 Webmail. Candidates include Squrrelmail & Roundcube.

3.4 Full-blown groupware.  See comment above but I see that TKL Zimbra server manifest includes Fetchmail so possibly the two servers could be hosted on separate VMs and work together with Zimbra using Fetchmail to grab from the mail server.

4. Sending mail.  Need to be careful not to create an open relay.

4.1 Not provided, user mail client sends directly to ISP's outbound server.

4.2 User mail client sends to mail server which relays to ISP's outbound server. Candidates as in 1.2 above.

4.3 Mail server includes own MTA.  Candidates as in 1.2 above.

5. Security.

5.1 Authentication.

5.2 Spam & AV filtering. Spamassassin & ClamAV seem to be the standard way to go for these but then they have to be integrated.  Candidates for integration are Amavis and Procmail.  There are also policy issues such as use of blacklists, greylists & whitelists to be considered.

6. Management.

6.1 Low level configuration.  All packages have some sort of config files but some can also be configured by other means such as SQL databases.  Which to choose? Choice may interact with database option for 2.2, also with 6.2

6.2 Configuration wizard.  Depending on the choices in 1 to 5 various packages need to be enabled or disabled and those enabled need to have a coherent set of config files to enable them to work together properly.  Sysadmin needs to be able to set up the overall structure and possibly users need to be able to set up their requirements, e.g. consolidation of external IDs as in 1.

Ian

Zimbra, Zarafa & eGroupWare seem to be gaining ground as turnkey alternatives to exchange, which is what I'd expect is what many users @ admins will come to expect.

With the exception of the ActiveSync (& possibly BlackBerry) protocols, which are propietary extras, the rest seem pretty well geared to go "mainstream"

If I'm not mistaken, these groupware systems require some form of direcory service, like LDAP, to enfore group policy contol, which may complicate configuration

All of this is even before we get to CRM systems, like SalesForce & SugarCRM