Testing Different Mail Server Configurations? 35
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 (Score:4, Informative)
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 (Score:2)
Now I have NEVER used SJESMS6, but are you telling me that Sun has a "utopian" integrated messaging server that doesn't totally suck ass like every other integrated messaging server? And I can afford it for my non-profit? And I can run it on Linux?
Re:Call Sun (Score:4, Informative)
Re:Call Sun (Score:2)
(I Am A Mail Administrator, In A Sun Shop)
Re:Call Sun (Score:2)
How many different ways can things be done? (Score:5, Informative)
Anyway, what we're currently doing where I work is, we have a Barracuda [barracudanetworks.com] 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.
Re:How many different ways can things be done? (Score:1)
Re:How many different ways can things be done? (Score:1)
Re:How many different ways can things be done? (Score:1)
Re:How many different ways can things be done? (Score:2)
Other than a couple of software bugs in the 2.x version range it's been fine.
Re:How many different ways can things be done? (Score:1)
Re:How many different ways can things be done? (Score:2)
Ah, that would be a whole different animal. The spyware filter is a relatively new addition to their product line. My post above was referring to the spam filter which has been around for some years now.
Re:How many different ways can things be done? (Score:1)
Easy Way (Score:4, Funny)
hmmm (Score:2, Informative)
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 coul
Re:No flak jacket required (Score:3, Informative)
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 MDae
Use of qmail - simple solution (Score:3, Interesting)
Re:Use of qmail - simple solution (Score:4, Funny)
Well. Yes. That's nice...
Since nobody's actually answering your question... (Score:5, Interesting)
If you're stuck on sendmail, these might help:
http://www.nber.org/copy-out.html [nber.org]
http://www.milter.info/sendmail/milter-bcc/ [milter.info]
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
Re:Since nobody's actually answering your question (Score:1)
Re:Since nobody's actually answering your question (Score:2)
Re:Since nobody's actually answering your question (Score:2)
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 ;)
Exim (Score:5, Informative)
Exim [exim.org] 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 [exim.org] 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:Exim (Score:2)
As for testing, tossing the full email feed at it and dealing with all the problems may not be the best course of action for the reasons the poster above went into. I usually setup a test sub-domain for testing.
Re:Exim (Score:1)
Nitpickers university (Score:4, Interesting)
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
procmail? (Score:1)
using procmail.
I assume your test server isnt going to do anything with the mail but crunch it.
This is a test (Score:1)
Yes, I know it was already posted... (Score:1)