BenM

Thanks everyone for the feedback. It looks like more or less unanimous agreement that Exim is the right tool for the job. I had suspected the same myself but didn't want to bias opinions.

One of my concerns with our current arrangement is that we do everything in the same boxes, so we can't do maintenance on one part of the system, without affecting unrelated features. Having everything in one box also goes against KISS, because you end up trying to cater for completely unrelated types of e-mail in the same configuration files. Hence I'm looking to split our mail servers into 3 clusters with specific jobs:

inbound MX - these will only accept mail for our domains and the domains we relay for. They will do the spam filtering and a/v filtering, adding headers to possible spam and rejecting definate spam, and then pass the scanned mail onto the POP/IMAP servers, possibly doing some recipient rewriting or expansion first.

POP/IMAP servers will only accept SMTP from our own servers, and will not do any scanning of their own.

outbound relays - these will only accept mail from trusted IPs and authenticated users, and will do virus and spam filtering. These can be tuned differently as the intention of filtering here is to stop ISPs blacklisting us rather than keep our users mailboxes clean. We could possibly send spam bounces to the authenticated user rather than a non-local (and thus presumably forged) sender address, if I can figure out how to do this with Exim.

My concerns with doing this is I'm unsure how the rest of the world is going to react. We've had a few problems when changing our servers in the past causing us to fall foul of other organisations anti-spam techniques, some of which are just plain stupid. Is it going to be a problem if our inbound and outbound mail servers are different, and the outbound ones don't accept incoming email?

racksense

1. SQL servers don't cope too well (without lots of tuning and careful configuration) with large influxes of email and can easily overload a system - imagine if your primary MX is off-line and then you have to dequeue a lot of mail from the backup MX in one go.

2. If your SQL server is down, has any form of corrupted data files, or you need to do an upgrade etc, then you have to take down every service that relies upon it.

Building flat file (which are then converted to dbm) from SQL is a much safer and more scalable option IMO.

__________________
Paul Civati
Rack Sense Ltd
Views expressed are my own and not those of the company.
Company reg no. 05115163, VAT reg no. GB 912 5238 45