building a new mail server – planning

it has recently been heavily hinted to me that i might be tasked with building a new mail system soon, which got me thinking about how to do it better than i have before. i haven’t built a mail system from scratch in about a year, and there are some things i want to try that i either didn’t want to do last time, or didn’t have time to implement. my planning, design, and implementation process will be put here so that i have a future reference, and also in case it helps others.

for server builds i’ve been liking ubuntu‘s server distribution for some time now, and see no reason to change for this project. the quick and easy install is nice, and i love the apt package management system. the ‘hidden root’ aspect is nice and gives me a head start on securing things, and the network config is the super-easy and sensical debian style.
the new ubuntu version should be out this month, so i’ll probably try to use it for this project.

postfix is the new in-style MTA for a lot of things lately, which is great as it is a very stable and easy to configure system. luckily i can just use one of my previous postfix configs for this. in the past i’ve always used postfix as the MDA as well, but that’s changing this time.

the dovecot server has a pretty nice looking MDA capability, and the ability to plug filters into it gives me some more flexibility and options for blocking messages i don’t want, and managing the messages i do. this will be the biggest single change to my standard deployment.

dovecot is an option for the MDA if only because i plan on using it for my pop3/imap services. i moved away from courier almost two years ago, and i’ve really enjoyed the simplicity and extensibility that dovecot offers. when it comes down to it, i haven’t seen too big a difference between the two, but dovecot seems to be getting a lot of developer attention lately, so i think in the short term it might work out better.

my least favorite part of deploying mail is setting up sasl. this seems to be one of those things that gets harder each time i do it. thankfully it looks like i might be able to use dovecot for some of this according to some recent docs i’ve seen.

like any modern mail system, users for this one will be stored in a database. i’ll be using mysql for this if only because it is supported by all the packages i plan on using. other databases are, of course, also supported and available, but i’m used to mysql now. and to think that just 9 or so years ago i preferred postgresā€¦

for the last 4-5 years i’ve been using roundcube for my webmail services, and i’ve loved how it has come along. i’ll continue using it this time unless i find something just as easy to implement and offering more to the users.

user management for the database is something that there has never been an obvious package for. i always end up needing something more than most of the packages i look at can do, so i end up using my own. i’ll be using my pigeon mail management interface again here. i might take this opportunity to update the software.

given the expected traffic and performance needs of this service, i’ll be able to go pretty cheap on the hardware specs. none of the services i’ve decided on are massive resource hogs, so i should be able to get away with putting this on any commodity hardware from the past 5 years. as usual i’ll be putting the mail data on a separate drive from the OS, but anything over 500MB of memory and 100GB of drive space should do fine for my expected needs. disks are cheap anyway, and i’ll be duplicating the services onto at least two servers if possible.

building a new mail server – planning

Leave a Reply