mrt - Mail Relay Test
mrt [-v] [-V] [-p] [-i] [-P num] [-s addr] [-r addr] [-F addr] [-T addr]
[-t num[:num]] patterns message [ip-spec...]
The mrt program performs an e-mail relaying security test on every
member of a set of SMTP mail servers whose IP addresses are specified
on the command line or, alternatively, supplied via stdin. Note that
either individual IP addresses (or hostnames) or entire IP address
ranges may be selected for testing by mrt. (See below.) In the
latter case, each IP address within each specified range is tested.
The test performed on each IP address selected for testing by mrt
is a test for e-mail relaying capability. Whenever one of the
servers selected for testing is found to be listening on the
standard SMTP port (25), mrt attempts to enter into an SMTP dialog
with that server, and attempts to feed it a test message, asking
the server to send the message on to some user-specified destination
envelope recipient address. The server being tested will either
accept or decline this request, but even if it seems to accept it,
the test message may in fact be bounced back later on, and not de-
livered to the specified envelope recipient address. (This fact
should be taken into account when performing mail server relay test-
ing with mrt.)
The `patterns' command line line argument should be the name of a
file containing a set of desired test specifications. Each line
within this file should either be a comment line (beginning with a
`#' character) which is ignored, or a blank line (also ignored), or
else a test specification line.
Each test specification line consists of two SMTP command argument
specifications, separated by an arbitrary number of whitespace
characters. Each of the two SMTP command argument specifications on
any given line in the patterns file is itself composed of an arbi-
trary sequence of non-whitespace characters and macro names. (See
below regarding pre-defined macro names). For any such pair of
SMTP command argument specifications, the left-hand specification
describes the general form of an argument to be supplied in an SMTP
`MAIL FROM' command during a relay test, and the right-hand specifi-
cation describes the general form of an argument to be supplied for
the SMTP `RCPT TO' command during the same test. A simple example
of a test specification is as follows:
(See the description of the built-in macros $s, $S, $r, and $R, below
for more information on the interpretation of this test specification.)
Note that if the patterns file contains multiple lines (i.e. multiple
test specifications) each independent test specified by a line in the
patterns file will be run, sequentially, against each mail server
selected for testing. (Multiple tests of any given server are never
run in parallel, regardless of any -P option supplied. See OPTIONS
The `message' command line argument should be the name of a file
containing the text of the test message to be used for all tests. If
the first line of this file is non-empty, it and all subsequent lines
up until the first empty line are assumed to be user-specified mail
Unless they are already present within the set of user-specified mail
header lines, mrt will, just prior to each test, automatically gene-
rate the following mail headers and append them to the existing user-
specified mail headers (if any) contained within the message file:
Subject: E-Mail Relay Test of [$i]
(See the descriptions of the $F, $T, and $i macros below.)
These automatically-generated mail headers will be inserted into a
temporary in-memory copy of the test message text just after all of
the user-specified mail headers and just before the message body text.
In addition to the automatic header generation and appending described
above, the entire contents of the temporary message text, both headers
and body, are subjected to macro substitution just before the message
is transmitted to each server being tested. (See BUILT-IN MACROS
The resulting message text, after automatic header appending and macro
substitution, is used as the actual test message for the current test.
Each `ip-spec' argument given on the command line must consist of one
of the following:
o An IP address range in the form `start-end' where both
`start' and `end' are IP addresses expressed in the
customary ``dotted quad'' notation used for IPv4 addresses.
o A single IP address (in customary ``dotted quad'' notation).
o A valid DNS host name (e.g. `mail.example.com').
If no ip-spec arguments are found on the command line, mrt will in-
stead attempt to read a sequent of ip-spec arguments, one per line,
Note that the result of each ``successful'' test will be a mail
message which is delivered back to the specified (or defaulted)
envelope recipient e-mail address. Common sense rules should apply
to both the recipient addresses and also the sender addresses used
for all tests - BE VERY CAREFUL not to mail bomb either yourself or
anyone else, either with relayed test messages or bounce messages.
Mrt automatically pre-defines the following fixed set of macros, just
prior to each e-mail relay test. The macro names listed below will be
automatically replaced by their corresponding values whenever any one
of these macro names appears either (a) in the text of a test specifi-
cation, or (b) in the text of the test message.
$i - the dotted-quad representation of the IP address
of the server being tested
$d - the all-lower-case version of the inverse DNS name
of the server being tested, or else a null string
the server doesn't have an inverse DNS name
$g - the all-lower-case version of the self-identification
domain name, if any, given by the server being tested
in its SMTP greeting banner, or else a null string if
the server doesn't provide its domain name in its
SMTP greeting banner
$s - the userid part of the envelope sender address
$S - the domain part of the envelope sender address
$r - the userid part of the envelope recipient address
$R - the domain part of the envelope recipient address
$F - the message sender address
$T - the message recipient address
$a - the argument of the SMTP `MAIL FROM' command being
used for the current test (including the outer <>
brackets, where applicable)
$A - the argument of the SMTP RCPT TO command being
used for the current test (including the outer <>
brackets, where applicable)
The default envelope sender and destination addresses for each
relaying test are constructed from the current user's own local user
name (obtained via `getpwuid(getuid())') suffixed by an at-sign
(@) and then the name of the local host (obtained via `uname()').
Note that when mrt is used on non-UNIX platforms, these defaults
are unavailable, and thus, on non-UNIX platforms, the envelope sender
address address and envelope recipient address MUST be explicitly
specified via the -s and -r command line options, respectively.
The default envelope sender address and envelope recipient address
may be explicitly overridden by specifying alternative values as
arguments to the -s and -r command line options, respectively.
The default message sender address (i.e. the one that will be used,
by default, in the automatically-generated From: header, as noted
above) is whatever the current envelope sender address is set to
(either via the -s command line option, or defaulted). This default
may be overridden on the command line by providing a -F option,
along with a following e-mail address argument.
The default message recipient address (i.e. the one that will be used,
by default, in the automatically-generated To: header, as noted
above) is whatever the current envelope recipient address is set to
(either via the -r command line option, or defaulted). This default
may be overridden on the command line by providing a -T option, along
with a following e-mail address argument.
The -P option may be used, as with the GNU xargs(1) program, to
specify the maximum degree of parallelism desired. By default,
the maximum level of parallelism is set to `1' and this allows
only one test connection to be active at any one time. Multiple
tests can be run in parallel simply by specifying the -P option
with some positive integral argument greater than one, for example
`-P 20'. Note that it is imperative that you make sure that what-
ever level of parallelism you run the program at does not exceed
the `maxproc' soft limit current set for your account. (See limit(1)
if you are a csh or tcsh user.) Be advised also that Perl processes
are quite ``heavyweight'' in the sense that they use up a LOT of
resources. It is very easy to bring a server to its knees, almost
immediately, by running mrt with a -P option that sets the parallel-
ism level too high.
The -t option can be used to specify the connect timeout for SMTP
connection attempts, in seconds, and optional also the timeout for
SMTP command responses, in seconds. To specify only the connect
timeout, the argument of the -t option should just be a single number.
To specify both the connect timeout and the SMTP command response
timeout, the desired connect timeout period (in seconds) should be
followed by a colon and then by the desired SMTP command response
timeout (in seconds).
If no -t option is specified, the default connect timeout is 20
seconds, and the default SMTP command response timeout is 180
seconds (3 minutes).
Note that the SMTP command timeout applies also to the time period
between the time a connection is first established and the time that
the remote mail server under test finishes sending its initial SMTP
Note also that as long as the remote mail server sends at least one
complete response line within each SMTP command response timeout
period, the timeout is not triggered. This is true even if the
response line sent is not a ``final'' response line (i.e. one with
a space in the fourth character position of the line). However in
order to forestall the possibility of teergrubing (i.e. sending an
endless stream of non-final response lines) of mrt by the remote
mail server, an SMTP command response timeout will be triggered if
a final response line is not received within T * 3 seconds (where T
is the currently set SMTP command response timeout) even if a non-
final response line is being received from the remote mail server
every T seconds.
The -v option causes a one-line summary of the final results of each
test to be written to stderr. In cases of ``succeeding'' tests, i.e.
those where the test message is accepted by the remote mail server,
the summary line will give the IP address of the remote mail server
followed by ``Message accepted''. In all other cases, the cause of
the test ``failure'' (e.g. connection refused, timeout, or some SMTP
protocol failure or error) will be noted on the summary line.
The -V option will cause all SMTP commands sent and all SMTP responses
received during testing to be printed to stderr. This option is pri-
marily for debugging. Note that this option should NOT be used in
conjunction with the -P option. (See above.)
The -p option puts mrt into `preview mode'. In this mode, macro re-
placed test specifications will be written to stderr, but no actual
tests will be executed. This mode is primarily useful for debugging
your test specification strings. For example, to view a macro-replaced
version of all of your test specifications, try:
mrt -p test-specs test-message 127.0.0.1
Note that even though the -p option suppresses all actual tests,
a connection will still be made to each mail server selected for
testing (127.0.0.1 in the example above) and a brief, incomplete
SMTP dialog will be executed, just so that the value of the $g macro
may be obtained (from the greeting banner of the remote server).
The -i option puts mrt into `incomplete testing mode'. In this mode,
mrt does everything that it would normally do EXCEPT for initiating
the DATA portion of each relay test, which includes the part of the
SMTP transaction where the (munged) test message text is actually
sent to the remote mail server.
This option can be used to emulate the operation of the abuse.net
tester, and/or by shy folks who want to check mail servers to see
if they can PROBABLY be made to relay for outside parties without
actually sending test messages and (perhaps) thereby annoying the
local postmaster of the remote mail server.
Mrt will automatically skip certain tests if they seem either redun-
dant or impossible to execute. For example if the only difference
between two test specifications is that one refers to the macro $d
where the other refers to the macro $g, and if both of these macros
have the exact same value, then the second test will be automatically
(and silently) skipped. Also, if any test specification mentions
either the $d or $g macros and the values of the macros mentioned is
not defined (for the current mail server under test) then that test
will be automatically (and silently) skipped.
Mrt has the ability to pump (potentially) quite a lot of mail
messages through quite a lot of remote mail servers in parallel.
It is thus potentially dangerous, because the number of messages
that will subsequently be sent back, either to the envelope recip-
ient address (relayed messages) or to the envelope sender address
(bounce messages) or both may in fact overwhelm and crash the servers
which ordinarily handle mail for these e-mail addresses. Careless
use of mrt may, in effect, setup a debilitating Distributed Denial
Of Service (DDOS) attack on the mail servers handling mail for the
envelope recipient address, the envelope sender address, or both.
Care should be taken to avoid such outcomes. Use with caution.
This Perl script assumes the presence of the Time::Object module,
Version 0.11 or better. This module is available from:
The current version of mrt has not yet been ported to run on anything
other than UNIXish systems. If you port it, e.g. to Windows or to
Mac, please send me a copy of your ported version.
Generation of the time zone part of the automatically-generated Date:
headers will be fubar if you are unfortunate enough to live in one
of those weird time zones that is not an integral number of hours
offset from UTC.
Ronald F. Guilmette <firstname.lastname@example.org>
Copyright (c) 2001 Ronald F. Guilmette; All rights reserved.
The author and copyright holder of this software specifically and
explicitly DISALLOWS any and all uses of this software, or any
compiled and/or derivative version thereof for any and all commercial
purposes without the express written permission of the copyright
Requests for permission to use this software, or any compiled and/or
derivative work thereof, either in a commercial context or for com-
mercial gain or for any commercial purpose should be e-mailed to the
copyright holder at the e-mail address given above.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF