Mail Server Plans for Jaunty

I got asked about this on IRC today. Here’s what I suggested:
I think in Intrepid we got to a ‘complete’ set of packages by adding clamav and spamassassin and took some first steps in Intregration.
The goal for Jaunty would be to be able to script installation of postfix, amavisd-new, spamasassin, and clamav in an integrated, working configuration with no hand editing of config files needed.
I can see three standard use cases that I suspect are common enough to support:
1. All in one mail server. Serves for sending and receiving mail and stores the user mail boxes. Includes virus and spam filtering.
2. MX Gateway server. Receives mail from the outside world, does spam and virus checks, and then relays to an internal server for final delivery.
3. Mailbox Serer. Internal box that holds user mailboxes. Supports IMAP and POP3.
With the work we did in Intrepid, we’ve got all the hooks to automate postfix setup and integration with amavisd-new and integration of amavisd-new with spamassassin and clamav. I’m not sure about what needs to be provided for integration with dovecot.

Advertisements

3 Responses to “Mail Server Plans for Jaunty”


  1. 1 Joshua Kugler November 4, 2008 at 00:41

    Not a lot needs to be done for Dovecot. A little config if using Maildir, but other than that, not much.
    Suggestion: doing some legwork so SASL authentication “just works” on postfix so you don’t have to go through the (long and painful) process of setting authentication in Postfix if you want users to be able to send using your mail server from anywhere.
    Yes, I’ve done it. No, it’s not a terribly fun process.

  2. 2 Ian Barton November 4, 2008 at 06:44

    That would be very useful. I have recently stopped using Ubuntu server, having used it since Dapper, and gone back to Debian. One of the problems was amavis failing repeatedly, even though it’s config hadn’t been changed and it had worked perfectly for a long time previously.
    From my perspective Ubuntu don’t seem to support their server product particularly well. It would be good to see this change.
    Ian.

  3. 3 EtienneG November 5, 2008 at 11:21

    The problem I have with auto-configuring spam filtering is that everybody want it done in a different way. Some want them discarded, some want the subject mangled with ugly ***SPAM***, and yet other want to use the (rather standard) SpamAssassin mail headers. I personally prefer to have spam delivered to a specific mailbox (using + addressing) and left there. Settling on one specific way of handling spam is bound to be contentious.
    Re: SASL authentication, I think the easiest path to integration is to use the Dovecot SASL implementation in Postfix (smtpd_sasl_type = dovecot). It require a very small block of config on the Dovecot side, and then you get consolidated login between Postfix and Dovecot, and manage authentication on the Dovecot side. I just started using it on my own mailserver, and I am quite happy about it.
    Another problem we will have is settling on a user and authentication database. By default, Dovecot authenticate using PAM, which mean that local user will have an IMAP account. It is a fine assumption for small scale mail server, but a more common use-case is virtual user. Again, settling on a specific mechanism (LDAP, SQL database, flat file, etc) to store these virtual users is bound to be contentious.
    And we haven’t even touched virtual mail domain hosting yet … ouf!
    PS: the comment textbox of your blog is way too small. It is really painful to write in..


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: