Mrt is quite flexible (see the mrt man page for a list of all of the options), and it can be used in a wide variety of ways to do open relays testing, but our own experience in using this tool has shown us what works and what doesn't, and we will try to illustrate some of that practical usage information here.

First and foremost, if your intent is to perform really exhaustive and comprehensive open relays testing, on some server or set of servers, then you will need to do exactly what Mrt is designed to do, i.e. full blown end-to-end open relay testing. The term end-to-end relay testing, in this context, means that you will arrange to have Mrt inject test messages into the mail server(s) being tested, and then you will wait and see if those test messages are in fact actually relayed back to some destination address that you own, that you control, and that you have specified as the desired recipient address on the Mrt invocation command line.

Pre-Test Preparation Steps

You should begin preparing your testing plan by considering the obvious logistical issues... What machine are you going to use to originate test messages from? (This is the machine where Mrt will be run, so it had better be some kind of UNIX systems.) What machine are you going to use to receive successfully relayed test messages? What machine are you going to use to receive non-relayed test messages that get bounced back to you?

You could, in theory, use three different machines one for each of these three different required functions within the overall testing plan, but that is by no means required, any two out of these three functions may be carried out on a single machine, and in fact all three could be hosted on the same single machine. That's entire your choice, but you do have to decide which machine(s) will handle (a) test origination and (b) relayed test message reception and (c) bounced message reception before you being.

Once you have decided on the basic logistics of your testing plan, you should then decide which individual e-mail addresses you want to use for each of the three testing functions just described (and then create those e-mail accounts, if they do not already exist). As in the case of distribution of these three testing functions across some set of hardware resources (machines) you may elect to combine two or three of the required functions and assign them to the same single e-mail address, but for various reasons, this is not advisable, and if all possible, it is best to obtain three separate e-mail accounts, and to use one for test origination (and also for human interactions with the local postmasters of the mail servers tested), another for relayed test message reception, and a third for bounced message reception. This allocation of testing functions to separate e-mail addresses insures that (without any special effort on your part) your most useful and interesting results data, i.e. the relayed test messages, will be automatically, completely, and cleanly separated from any and all other test-related e-mail traffic. In effect we you will be letting the destination mail server keep all actually relayed test messages, all bounce messages, and all other test-related messages in nice, neat, and separate piles for you. This will come in very handy when it comes time to analyze your test results data.

For the time being, we will assume that you will use two domains, two machines (both of them being configured as mail servers) and three distinct e-mail addresses for your testing process. (In fact this is exactly what we do here at Monkeys.Com.) The first e-mail address you use with be the called (for lack of a better term) your origination address and mail sent to it will be handled by the first mail server. Let's say that your test origination address will be source@machine1.example.com. Given this starting point, you would need to configure your first server (machine1) to accept incoming e-mail for the machine1.example.com domain, and you would also need to create a DNS MX record for machine1.example.com that points to machine1. Now, let's say that the address you have chosen to receive the relayed test messages is sink1@machine2.example.com. Given this selection, you would configured your second mail server (machine2) to accept mail for the machine2.example.com domain, and you would also create an MX record for machine2.example.com that would point to your machine2. Last but not least, you need to select an address to receive any bounce messages generated during testing. So let's say that you select sink2@machine2.example.com. You have already setup machine2 as a server, already configured it to accept incoming e-mail for the machine2.example.com domain, and already setup the necessary DNS MX record for machine2.example.com, so you are basically done. All that remains is for you to create all three of these e-mail accounts that you will be using (on their respective servers)

In order to make sure that you don't miss any of the relayed test messages that are relayed to (i.e. that the remote mail server(s) try to send back to) your selected destination address, it is vital that you arrange things before hand in a way so as to insure that there will be no filtering of any kind applied to e-mail messages that are sent to the mail server responsible for handling mail for your desired test destination domain. Arranging this may not be easy, and it will help a lot if you yourself are the mail administrator for you selected test destination domain, and if you can configure the mail server responsible for receiving mail for your destination domain in any way that suits you.

Assuming that you have this authority, you should begin by carefully reading all of the configuration-related documentation for the destination mail server, and you should turn off or disable as many types of filtering for that server as you possibly can. (Doing so will allow you to, in effect, get a clearer view of what is actually being relayed by the server(s) being tested.)

Another important step you should take before starting your actual test run(s) is to disable any and all secondary MX mail servers for your preferred destination domain. Disabling all of the secondary MX servers for the target domain, and (thus) leaving only one mail server (the primary, highest priority MX) server for your destination domain active will insure that any subsequent automated analysis of the various Received: headers contained in the relayed test messages that you get back (on the destination server) as a restult of your testing will be simple to do, and won't be complicated by the fact that some relayed test messages get delivered directly to the primary MX, while others may take a longer route, passing first through some other (secondary MX) mail server before ending up at the primary.

For mrt usage information please refer to the mrt man page.