Open source e-mail scalability

August 26, 2005 6:38 PM

I am responsible for setting up and maintaining a mail server for small web-hosting type business. We currently host about 75 domains, around 100 mailboxes and due to the efforts of our sales team, we are wanting to get ready for some great increases in those numbers. I am worried about my current configuration and ease of administration. More importantly (well, at least to the customers) is email deliverability -- it seems that messages delivered to some big players are being marked as SPAM or disappearing altogether. I am asking for insight and advice on 1) if my current choice of software/configuration is a good match for this situation and 2) if there any additional measures I might take to ensure email deliverability?

Here is an overview of our current setup:

* We lease servers at ev1servers.net.
* The servers are running RHEL ES3.
* We chose to use Postfix and have it configured to support virtual users and domains mapped in MySQL tables. The reference I used to configure this setup is located here. We initially chose Postfix over qmail because it was open and over sendmail because the config files are actually readable.
* I have added in SQLGrey grey-listing for Postfix to provide a simple level of SPAM detection for our users. We are not wanting to deal with the customer service and higher box loads of mail scanning at this time. We might choose to use a 3rd party vendor to do this as needed.
* Messages are delivered locally via maildrop in maildir format.
* Courier IMAP is running to support both IMAP and POP access to the mailboxes.
* Postfix Admin was setup for easy mailbox administration.

For deliverabilty, I have/am taking the following steps:

* I have verified that our reverse IP records are correct
* I have created SPF records for all of the domains
* I have verified that our server is not listed in any blacklists (great scanner at dnsstuff.com)
* I have started to install DomainKeys for Postfix

In doing all of that, I have found that our IP is listed in the BlarsBL. Do I need to be concerned about this rogue list? The IP was there before I even began to setup the box.

I have not yet been able to get DomainKeys to work with Postfix. It was during my configuration attempts that I started to question this setup and wondered if this was the best setup for our situation.. this inquiry has lead to this posting.

In a perfect world, I would have an email server that

* is easy to administer,
* supports automated mailbox setup/removal (currently I can just insert rows into my tables and the mailbox setup is done)
* supports current technologies, like grey-listing, DomainKeys, etc
* is secure
* makes the best use of system resources -- I want to get the "best bang for the buck"

So what do you think? Should I stick with this setup and life will be grand? I am open to something new AND even taking the time to learn a new setup. If I do need to switch to something different, my only concern would be the ability to migrate existing mailboxes and messages over to the new setup.

Are there any other technologies or configurations that I need to implement to support the best deliverabilty rates?

[question posted for a 'friend']

posted by id to Computers & Internet (1 answer total)

Best answer: Given your current list of technologies, I think it's very safe to assume that you're looking for a non-commercial solution.

In that vein, I'd recommend:
exim for smtp
postgres for configuration storage
cyrus for imap

This can make for an extremely scalable solution, on a budget. exim is wildly configurable (the conf file is *almost* a programming language). You can usually implement anything in exim before the official support exists, if you're so inclined.

Greylisting... be careful. Every single publicly available graylisting system I've seen is "not quite automatic". Namely, they usually can't deal with email servers that resend from different IPs (common with the big webmail providers), and they can't deal with emails that have tracking tags on the envelope sender (common with some of the automated info delivery services). You'll either need to get very clever and develop three smart mechanisms for greylisting that all work together, or handle the exceptions manually.

Also, if you do greylisting, put together a system to ask each domain/user (whatever is appropriate in your case) whether or not occasional short delays are acceptable. Some people think that Email is just another IM client and freak out of something is delayed a bit.

Domainkeys: no reason not to, but almost nobody checks them. Still, no reason not to.

SPF: same as Domainkeys, though a few more people check them.

IP/DNS Setup: double check it at http://www.dnsreport.com/. it checks for more than just matching PTR and A records.

Linux: I hate Linux from the heart of my soul, but at ev1 it's the easiest choice. We've gotten FreeBSD 5.x on boxes at their Dallas facility but it's a bit of a nightmare and I don't think it's a generally available option.

Particularly useful ways to stop incoming spam: deferring on incoming floods, using the more reasonable RBLs (SBL, and possibly XBL), checking the sender user against major spam address formats, verifying that the helo address matches, and isn't local.

Header and envelope sender verification are effective, but break a lot unless you engage in a whole lot of tricky hackery... I'd suggest not using them unless you enjoy pain.

If you're doing virus scanning, clamav is the best option at the moment, even if you're willing to pay. It's quite reasonably fast, and you can always toss relatively cheap hardware at it if you need additional capacity. (a dedicated scan box really just needs a GigE link, and a decent amount of RAM, nothing sexy or expensive).

My reason for suggesting cyrus over courier is mostly scalability. We've found that we can handle a lot more users with a murder of cyrus imap servers than we can on courier.

My reason for suggesting postgres over mysql is that mysql is a well-polished piece of shit. That being said, it will work for your current application, but if you ever decide to do anything significantly fancy, it will fall apart long before postgres does.

My primary reason for suggesting exim over postfix is ease of configurability, especially if you ever get the urge to try the Next Big Thing in spam filtering.
posted by mosch at 8:24 PM on August 26, 2005 [1 favorite]