Launchpad Entry: integrated-mail-stack
Created: Dec 10, 2008
Packages affected: postfix, dovecot, amavisd-new, openldap, clamav, spamassassin
Provide an easy to use set of common mail servers (both a set of packages and integrated package configurations) in a policy compliant way (Since packages can't modify conffiles of other packages this is actually quite tricky). Make it easy to get a basic configuration for a particular purpose up and running that a mail server admin can then tweak to their needs. 1. All in one small domain stack (Postfix, Dovecot, Amavisd-New, Spamassassin, Clamav, backup solution) 2. Departmental mail store (Postfix, Dovecot, Amavisd-New, Spamassassin, Clamav, LDAP, backup solution) 3. Lightweight MX front end (Postfix, LDAP) 4. "Spam firewall" MX front end (Postfix, Amavisd-New, Spamassassin, Clamav, LDAP)
Easy RBL configuration would need to be supported for all Internet facing configurations. The "Spam firewall" front end would need to be easily integrated with MS Exchange for proper recipient validation. Need to support mail box backups on servers that hold mail. Need to decide what solution and how to set it up.
As a new feature for Jaunty, Ubuntu Server now includes easy to configure standard mail server configurations. These cover the most common use cases and will make it easy to get up and running quickly. Supported for Jaunty are:
1. Complete Domain Mail Server in a Box (Postfix, Dovecot, Amavisd-New, Spamassassin, Clamav, backup solution) 2. Departmental mail store (Postfix, Dovecot, Amavisd-New, Spamassassin, Clamav, LDAP, backup solution) 3. Lightweight MX front end (Postfix, LDAP) 4. "Spam firewall" MX front end (Postfix, Amavisd-New, Spamassassin, Clamav, LDAP)
While these configurations will likely need some tweaking for your local requirements, they are designed to get you up and running with a functional configuration quickly and easily.
Integrating all the pieces for a modern mail stack is a major piece of work that inhibits penetration of Linux in general and Ubuntu Server specifically in this market. This is a step towards making Ubuntu Server more for Human beings.
Bob runs a small engineering consulting company. He is increasingly frustrated with his ISP's inability to keep spam out of his inbox and get his messages into his customer's inboxes. He'd like to try running his own mail server, but while he's interested, and willing to tinker with it, he's not a full time admin. He needs something his small business can get up and running quickly.
Jane is a departmental IT person in a large corporation that's opening a new office. She'd like to build the new facilities mail system around Linux, but knows it has more moving parts than she has time to really work through. She's pleasantly surprised to find that with Ubuntu Server she can now easily roll out MX servers that catch mail from the outside world and do SMTP time spam checks and final deliver servers that sort the mail to user's mail boxes and into appropriate spam folders.
Aloysius is in trouble. His Exchange server is bogging down under an increasing load of spam, but his department just can't afford a new high end Quad Core system to absorb the increasing load. Aloysius looks around and discovers Ubuntu Server has a mail server configuration designed to be a spam filter front end for his Exchange server. He gives it a try and finds it easy to get up and running and able to perform well on existing hardware he has available.
We have a scalable way to present more server install options so that we can add several more.
This is mostly going to be a matter of package selection (mostly done), identifying the configuration changes needed to integrate the packages, and then writing scripts to effect the needed configuration changes. Where a package does not offer an adequate interface for an external package to make the needed changes, an interface will have to be developed and added. Then the various use cases will have to be documented.
To be discussed at UDS.
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.