NAME
	mrt - Mail Relay Test

SYNOPSIS
	mrt [-v] [-V] [-p] [-i] [-P num] [-s addr] [-r addr] [-F addr] [-T addr]
	    [-t num[:num]] patterns message [ip-spec...]

DESCRIPTION
	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:

	<$s@$S>   <$r@$R>

	(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
	below.)

	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
	header lines.

	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:

		From: <$F>
		To: <$T>
		Subject: E-Mail Relay Test of [$i]
		Date: <>
		Message-Id: <>

	(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
	below.)

	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,
	from stdin.

	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.

BUILT-IN MACROS
	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)

OPTIONS
	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.
	(See below.)

	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
	greeting banner.

	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.

NOTES
	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:

		http://www.cpan.org/modules/by-module/Time/

	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.

BUGS
	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.

AUTHOR
	Ronald F. Guilmette <mrt@monkeys.com>

COPYRIGHT
	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
	holder.

	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.

DISCLAIMER
	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
	SUCH DAMAGE.