Testing Different Mail Server Configurations?

bsaxon asks: "I am looking for advice on methods that would allow the testing and debugging of different mail server configurations, particularly different ways of handling spam and mail filtering. What are different ways that different mail configurations can be tested? Currently, we have two servers running Linux that check all incoming/outgoing mail for viruses and spam, using software that works with Sendmail. After incoming mail is processed, it is relayed to its final destination, in a mailbox on a MS Exchange server. One server handles the actual processing of mail, and the other server just queues mail when the other server is down or overworked. Basically, I would like to have all mail duplicated, before reaching any filters or virus scanners or blocklists, with one copy continuing its normal route to the production server and the other copy of the message going to the test mail server. Can it be done at the DNS level or through Sendmail or are there other ways that this could be achieved? I am only looking for suggestions that deal with different methods of testing different mail server configurations, not actual suggestions for filtering mail."

Comments

Call Sun

[Anonymous Coward]

Call Sun Microsystems. Go to their website and look into Sun Java Enterprise System Messaging Server 6. Complete IMAP, POP, HTTP, SMS solution with SIEVE, Spamassassin, Brightmail, MIMESweeper and other connectibility. They'll even design and deploy the entire layout for you.

Or, you could run your business on a patched system full of about a dozen various components and try to get them all to work properly together.

Re:Call Sun

[saintp]

I do use Sun's JMS. You can run it on Linux, and your non-profit can probably afford it. But it sucks for small deployments. The damn thing is just too powerful for most people; if you can't afford to hire a dedicated employee just to run the mail server, it's not for you. It's not a magical happy land, like the OP described; it's got a UI that makes your eyes bleed, about a bajillion config files, and inconsistencies up the wazoo. We've used it for four years, and now we're switching to Postfix + Courier IMAP + Maildir and a few other free, open-source components.

How many different ways can things be done?

[Evro]

"I want to do a bunch of things. How many ways can I do them?"

Anyway, what we're currently doing where I work is, we have a Barracuda for spam/virus filtering, and that relays mail to our Exchange server for delivery. Barracuda has some nice features, including LDAP validation of recipient email addresses, and it's been working pretty well for us so far. If you're dealing with a large volume of mail, a turnkey solution is a nice time saver.

hmmm

[karearea]

I use Mdaemon for Windows (yes flameproof suit is on) and there is an option to also send all email to another server.

I would go with the idea of sticking another server in front of your live system that can send the email to the different points, I would assume that if a 'dumb-arse' windows app can do it something like sendmail should be able to do.

I can't give you any more than that (as little as it is) but I would be interested in knowing your solution. It sounds like a cunning plan (so cunning you could pin a tail on it and call it a weasel) - something I hadn't considered as part of the process of replacing my current mail server setup.

Exim

[KagatoLNX]

Exim can do this quite simply. I dare say that it is the most flexible mailer in existence (Sendmail might be as flexible, but it can't be done without a PHD in m4). Assuming you want to set up a relay server that mails to both the real server and a test server (I think that was the question), I would try the following.

In an Exim configuration file, you specify a list of routers that deliver the message. At a certain point, you'll usually either use a dnslookup router or some local delivery router to either forward a message to another host or deliver it locally respectively. In your case:

• use the standard dnslookup for remote delivery
• don't do any local delivery
• use the manualroute router to deliver to the main host, set the generic router option unseen=yes
• use another manualroute router to deliver to the test host

The unseen option (detailed here in chapter 15 of the specification) allows the first router to accept the message, but still pass it on to the next router.

I have used this method to do almost the exact thing you are doing here (although it was for logging purposes rather than testing). A word of warning... Your test server may generate bounce messages. Also, your relay server (the exim server in this case) may generate bounces if the test server refuses to accept messages. You can fix the latter by setting the errors_to option to the empty string on the test router (thus indicating bounces be dropped).

Removing the bounce address this way has the undesirable effect of causing the envelope sender on the test server to always be set to the bounce address () which makes it difficult to test things like sender verification.

It is possible to suppress relay bounces but preserve the sender address by saving the current sender in the address_data variable and reinstating it by setting the return_path to that in the transport that the router uses. This is ugly, but exists for this purpose (among others).

Then you only have to suppress bounces on the test server. This problem is inherent in delivering to two servers in parallel. If it is Exim, this is can be done with the errors_to option on your routers as above. This again defeats the purpose, because it is hardly a production configuration for testing purposes (can't test any bounce-related functionality). If the server is not Exim, you'll have to find some other way to suppress bounces.

Keep in mind, no matter what system you put in place for relaying, you will have to suppress bounces if you don't want to confuse your inbound mailers (often customers) with strange bounces on messages that were delivered, but generated a bounce on the test server.

Note that if you are really serious about testing your mail server and doing spamblocking, you'll probably do callouts. Callouts (a nice feature that Exim excels at) go through the initial delivery of a bounce message back to the sender address (but stops short of an actual delivery). This tests whether the return address can receive mail. In the event of common spam with AOL or Yahoo addresses, you stop accepting the address as soon as they close the account (or possibly never accept it if it is a faked account). Callouts are cached to a certain degree, so they are not a very bad performance hit either.

The reason I mention this is that it that effective features like this make it really difficult to block off bounces from your test server effectively. The only way I have been able to test something like this effectively is by moving the IT department (not the support desk though) mail onto a test server completely, bypassing any clever relaying. Make no mistake, a mail server in general, and a well spam-hardened server in particular, will be almost impossible to test effectively (without interfering with regular users) in parallel to your existing mail (i.e. duplic

Re:No flak jacket required

[hlygrail]

So what if it runs on Windows? I've been running MDaemon for many years now (at home) and have had a grand total of > 4 spam messages and zero virus-infected attachments since installation. As long as your network is secure, the host box is tightened down, and you properly configure all the niceties (SpamAssassin, RBLs, Bayesian Filtering, etc.), you're good to go.

Contrast that to the 30-50 per day I was getting before through another ISP (Earthlink). I'm surprised how few people even know about MDaemon (www.altn.com), considering how utterly powerful it is.