Slashdot Mirror
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."
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.
"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.
rooooar
Assign both servers the same IP and then you just plug and unplug the network cable real fast...
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.
I use qmail for my servers and it can do this quite easily in a number of ways. There are lots of good online documents about qmail as well as the official qmail site. The simplest method is probably a default install with a .qmail-default file in the alias directory which has two entries in it. Each entry could be a different destination email address or local account. This would certainly duplicate the email coming through, but may not be the best way to do your job. Working with the qmail-smtpd program may get you a solution closer to your needs. Good luck!
Helping with organizational effectiveness is our job.
Yeah, so nobody actually read your question. Welcome to slashdot and sorry about that. You really need to understand how email and the internet work a bit better if you thought DNS could do this for you. What you're asking for is a slightly more difficult problem than just "sendmail | tee -a foo".
If you're stuck on sendmail, these might help:
http://www.nber.org/copy-out.html
http://www.milter.info/sendmail/milter-bcc/
If you want to give other MTA's a whirl for this purpose, google "tee postfix" and see the postfix mailing list thread or try that qmail foo suggested by another poster.
Basically, there are different "problems" with each method, but it's late and I want to go home so you'll have to do your own homework. A few likely complications: recipient checks, source IP checks, header munges interfering with spam filtering
-Isaac
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
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:
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
I think Mauve has the most RAM. --PHB (Dilbert Comic)
Hey, thanks for replying to my question. I'm not sure what I was thinking with DNS actually. I must have been thinking of something particular to how our network is or how servers are setup, but I'm not sure. Either way, I may just been absent minded at the time, but I can't think of anything would be logical. =)
Sorry? It's just another desperate attempt to get slashdot to do someone's job. You linked to an 8 year old solution yourself. And besides, he lost me just after the fourth, "different." Then I saw he had two linux servers getting the mail first and I knew he'd be just fine ;)
Sorry to be annoying, but i consider your approach - while intuitive - basically flawed. If you are testing with constantly changing input data, it is very hard to determine the effect of any changes to your configuration. What you would do instead is capture a days worth of data, or maybe more, and hack together some script that lets you replay the day against you test configuration. thus you can always make suer that any changes you made haven't messed up the configuration. you can also vary replay speed to do some stress testing, and you might want to consider building up a set of "interesting" mails to use as testcases.
testing with an unknown and essentially random input set has its values, but i consider it incomplete.
cheers, Stefan
This opinion is mine, you can't have it.
You could try to forward all your mail (perhaps using an external program)
using procmail.
I assume your test server isnt going to do anything with the mail but crunch it.
For a set of test users, sendmail can duplicate messages using the aliases file. Give each of those users two destinations. There may be a way to wildcard all users, but I'm a sendmail novice of only 5 years.
Intron: the portion of DNA which expresses nothing useful.
I don't use Sendmail anymore but, I'm sure you can still do it. I use Postfix now and to duplicate my mail traffic I simply use a bash script with tee that sends one copy of the message to the production server and another copy to the archive/test server. Works great and it's dead simple. The Postfix content_filter option pipes to:
/usr/bin/spamc | tee alt-transport | /usr/sbin/sendmail -i "$@"
#!/bin/bash
exit $?
As for performance testing and methodologies I would recommend that you look at this rather old 2001 document from Dell. It goes into great detail on what to do, how to do it and what tools to use. It is an excellent document and it is Sendmail specific.
BE E E P
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
...but I am told that the Barracuda boxes are hardened linux of some flavor, the rep(that sold us ours) was either closed lipped or didn't know more than that.
Sig Hansen?
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.