Customizing your Configuration file

spamradar keeps a number of important configuration parameters in the spamradar.conf file. Some parameters are in spamradar.conf as a matter of convenience – saving you the trouble of having to use the corresponding command-line switches every time the program executes. Other parameters are required and must be set to appropriate values for your installation before spamradar will run.

In general, if a parameter is in CAPS, this value is not modified or overrideable while spamradar is running. Parameters in lower case can be modified by command-line switches.

Parameter	Default Value	Description
ACCESSFILE	None – program will not run unless set	spamradar needs to be aware of any relays that you are manually rejecting in sendmail’s native access file (usually /etc/mail/access).
ALLOWFILE	/etc/spamradar.allow	The full path to the list of hosts, domains, and networks that are allowed to relay through your mailservers (or are your own mailservers) and that should never be blocked.
DBFILE	None – program will not run unless set	Location of the DB file that spamradar uses to store testing history and results. The recommended location is the same area as your mail software’s other database files are kept.
debug	1	The level of debugging information that you want to see. See the “Debugging” section later in this document for a list of possible values.
hard_unknown_limit	300	How many delivery attempts we’ll tolerate, even if a relay is listed in the `spamradar.ignore` file.
HOST	None – program will not run unless set	This value should be set to the fully-qualified domain name of the host on which spamradar is running. If there are multiple network interfaces on the system, HOST should be set to the interface from which most tests will be performed. You may need to examine the results of open-relay tests to determine the best value.
IGNOREFILE	/etc/spamradar.ignore	The full path to the list of hosts, domains, and networks that shouldn’t be tested even though they might pop up in spamradar’s reports for other reasons (high volume, old listservers, etc.)
lastlines	8000	How many lines to pull from the end of your mail log for analysis. Larger values mean better accuracy and more spam detection. Smaller values mean more speed of processing.
LOCAL_CONTACT	None – program will not run unless set	The email address of an actual person that can act on messages received about spamradar’s activities
LOCAL_TEST_DOMAIN	None – program will not run unless set	The primary administrative domain in which spamradar is operating.
log	/var/log/mail.log	The location of your mail log.
logstring	‘sendmail’	If the log that you are monitoring also contains non-mail-delivery information, any log records that do not contain this string will be ignored.
MAILER	/usr/lib/sendmail	The location of your mailer program. This is used to send reports of open relays to ORBS or notify LOCAL_CONTACT of activities.
MAX_FIRSTCHAR_RATIO	2	Ratio of username guesses to unique first letters we'll tolerate. For example, if someone tries to send email to 30 unknown users, and half of the usernames begin with "a" and the other half begin with "b", this number is ( 30 / 2 ) = 15. The bigger the number, the more likely it is to be spam attack.
max_recipients	200	This is the maximum number of successful email deliveries that spamradar will tolerate before reporting and/or testing the server. Be aware that this parameter is closely related to the “lastlines” parameter and they need to be evaluated together for best performance.
MAX_TEST_AGE	7	How long to wait before reevaluating the status of a relay (in days). During this time period, attempts to manually test this relay will fail.
MAX_UNKNOWN_RATIO	.3	The tolerable percentage of deliveries that are bad. If this threshold is exceeded, spamradar will be more likely to test the relay. Valid values range from 0 (test everyone) to 1 (test no one).
max_username_guesses	2	This is the maximum number of username guesses that spamradar will tolerate before reporting and/or testing the server
mylogfile	/var/log/spamradar.log	This is the location of spamradar's log file. It must be writeable by the user running spamradar.
POPHOST	‘pop’	The name of the pop server that has the account that will receive test results. If not defined, spamradar will search any domains listed in your domain suffixes.
POP_PWD	None – program will not run unless set	The password to use to pop test results. Note that the `spamradar.conf` file should be secured so that only authorized personnel can view this password.
PRG_EXEC_PATH	'/usr/bin:/usr/sbin'	This is the list of paths that are in the program execution path. This needs to be set for security purposes.
REJECTDBFILE	None – program will not run unless set	Location of the Berkeley DB file that sendmail references to block relays that have tested as open.
RLYTEST	None – program will not run unless set	The full path to the location of the rlytest.pl binary that spamradar will call to test a relay.
show_all_hosts	0	Boolean flag to indicate whether or not we will display hosts that we would normally suppress in our output.
TAIL	/var/log/spamradar.log	This is the location of your external 'tail' program. spamradar needs to use 'tail' to efficiently pull the last lines from the mail log.
TEST_RECIPIENT	None – program will not run unless set	This value should be set to the address of the mailbox you set up to be the recipient of relay tests. For maximum security, choose a name that is difficult to guess.
TEST_SENDER	None – program will not run unless set	This value should be set to the address of the mailbox you set up to be the recipient of relay tests. This address will also receive error messages if the relay is rejected internally.
TEST_SERVICE_ADDR	None	The email address to which relays can be automatically submitted upon detection. If this parameter is not set, open relays will not be submitted to such a service. If spamradar is configured to only report confirmed open relays (its default behavior), you can submit those relays to relays@orbs.org by using that address for this parameter. Also, note that only services that accept relay nominations without an actual attached spam will accept this type of submission.

Customizing Your Allow and Ignore Files

spamradar tests servers to determine whether or not they relay for the domain that you specify. There are some servers (such as your own mail servers, for example) that you want to be able to relay by design. Therefore, spamradar needs a list of relays that you do not want to test – the spamradar.allow file.

There are also mail servers that you probably don’t need to bother testing. For example, AOL probably doesn’t have any open relays. The spamradar.ignore file that ships with spamradar has a number of these domains already listed. Do not accept this list as a given, however. It is recommended that you use the reporting features of spamradar to learn what domains should be placed in both the spamradar.ignore andspamradar.ignore files.

Both files can contain IP addresses, classful networks, domain names, and full hostnames (Unfortunately, CIDR notation is not yet supported, but is planned). For example, your spamradar.allow file might contain the following:

# spamradar.allow file for myisp.int

#

# all the servers in my mail farm are here

192.168.254

mydomain.com

mymailserver1.mydomain.com

mymailserver2.mydomain.com

10.0.0.4

The contents of your spamradar.ignore file might look something like this:

# spamradar.ignore file for myisp.int

#

# big mail-producing domains listed here

aol.com

bigfoot.com

egroups.com

email.com

freelotto.com

geocities.com

lsoft.com

lyris.com

lyris.net

mail.com

msn.com

netscape.net

onemain.com

securityfocus.com

webtv.net

yahoo.com

zdlists.com

Make certain that all of your own mail servers are listed in spamradar.allow. A good way to double-check this is to use spamradar’s –o option to manually test one of your own mail servers for relaying. If properly configured, spamradar should refuse to perform the test:

> spamradar.pl -o myserver.myisp.int

Skipping test of myserver.myisp.int - it is allowed to relay.

If spamradar does not refuse to test the relay, use the –x option to remove the relay from your testing database, fix the problem, and try again.

To test an entry in your spamradar.ignore file, perform a test similar to the one outlined above. Unlike relays found in the spamradar.allow file, spamradar will not refuse to manually test a relay in the spamradar.ignore file — but it will issue a warning. If you do not see that warning, adjust the contents of the file accordingly.

Relay Reporting

If the TEST_SERVICE_ADDR parameter is set in spamradar.conf, confirmed open relays will be automatically submitted to that email address. Relays are listed one per line and are in the format accepted by ORBS:

Relay: 192.168.254.1

Relay: 192.168.254.2

Relay: 192.168.254.3

If a relay is already marked as having been reported in the database, it will not be reported again.

If a relay is already listed in ORBS, it will not be submitted to ORBS. On spamradar’s next pass through the database, relays that are marked as blocked by ORBS will be removed. In this way, only those relays not yet listed by ORBS will remain in your local database.

Sendmail Interaction

You will need to make a small addition to your sendmail.mc file if you want sendmail to be able to use spamradar's database. This change instructs sendmail to check the spamradarreject.db file and to reject connections from any host. The changes required can be found in the spamradar.mc file in the spamradar distribution. They are also reproduced here for reference.

# Add this to your local sendmail.mc file.

# If you have other local rulesets, you will have to integrate spamradar's

# rules with your own.

Kspamradar hash -a<MATCH> /etc/mail/spamradarreject

R$+ $| $+ $: $>LookUpDomain < $1 > <?> < $2 >

R<?> < $+ > $: $>LookUpAddress < $1 > <OK> < $1 >

R<OK> < $* > $: $1

R<RELAY> < $* > $: $1

R<REJECT> $* $#error $@ 5.7.1 $: "550 Server " $(dequote "" $&{client_addr} $) " blocked as possible open relay - see http://your.url.here/"

R<DISCARD> $* $#discard $: discard

R<$+> $* $#error $@ 5.7.1 $: $1

You will need to change the “Kspamradar” line to match the path to your preferred location for the spamradarreject.db file (though note that the “.db” extension should not be included in this parameter). Also note that the “REJECT” line wraps onto the next line due to limitations of the size of this document. Every line in a .mc file should begin with either a letter directive (in this case, K or R) or a comment. For more information on adding local rulesets to your sendmail.mc file and using m4 to produce the corresponding sendmail.cf file, consult your sendmail documentation.

Administration and Operation

To run spamradar in its most basic mode, simply execute it:

> spamradar.pl

Typical output will look something like the following:

> spamradar.pl

ADVISORY mode - will NOT modify database.

relay IP relay name sent tries guesses

-----------------------------------------------------------------------------------------

168.96.144.20 B idecom.unsj.edu.ar 1 4 td wgz vong

194.154.180.98 B 194.154.180.98 0 6 roes whitis

194.98.103.10 B 194.98.103.10 1 23 jeffryn jej

196.36.168.206 B 196.36.168.206 0 10 smoss wcore

200.198.51.162 B 200.198.51.162 0 4 allex awolf

203.194.162.80 B 203.194.162.80 1 4 pjb1 k-garn

203.231.6.193 B 203.231.6.193 28 50 mace madcat

210.200.168.129 B 210.200.168.129 13 25 stanton tru

211.192.178.50 B 211.192.178.50 6 29 wyldcld wiz

211.22.13.198 B 211.22.13.198 0 6 glydie glyd

211.47.153.130 B 211.47.153.130 1 7 cmcgrath he

211.47.57.3 B 211.47.57.3 3 7 robmck grv

211.72.162.226 B 211.72.162.226 1 7 robob whar

212.182.119.154 B upp.poczta.lublin.pl 0 3 gifcom joth

213.210.25.122 B 213.210.25.122 0 5 gobo rmurra

62.110.89.150 B 62.110.89.150 0 3 medge koerb

62.116.50.34 B 62.116.50.34 1 11 vangoe fhbr

62.172.163.98 B www.tarmachbm.co.uk 0 13 bdavidso di

62.2.115.95 B dclient115-95.hispeed.ch 0 7 asilva kjor

64.42.73.133 B great4.greatlifetoday.com 9 13 blh wolfs

NOTE: the last column (“guesses”) has been truncated to fit the page.

spamradar’s behavior can also be modified on the command line. Command-line parameters supersede most options in the configuration file.

Command-line Switches

-a	consider all hosts, even "allows" and already-blocked
-c	use alternate configuration file
-d [0..5]	increase debugging verbosity. default is 1
-e	export full database to STDOUT as CSV text
-f [filename]	mail log to analyze. default is /var/log/mail.log
-h	print a help message
-I[filename]	import data from colon-delimited file
-m [string]	manually search mail log for "string"
-o [host]	test host for open relay (by name or by IP) (results will be mailed to TEST_RECIPIENT)
-O	test any suspicious relays found
-r	generate REJECT data for sendmail
-s [integer]	# of lines to pull from end of mail log
-t	look for recent username-guessing attempts
-u [integer]	# of username guesses to tolerate
-v	display program version information
-w	watch and test (rather than just printing a report)
-x	manually remove a relay from the database

These switches are explained in greater detail below.

-a: Display Information about All Hosts

By default, spamradar only shows information about relays that it feels are eligible for possible further testing. If you would also like to see statistics and delivery information about the relays in your ignore and allow files, use the –a option.

NOTE: Use of the –a option automatically disables writes to the database and automatic testing. This is to prevent inadvertent testing and blocking of your own servers.

-c: Specifying a Different Configuration File

If you would like to use a configuration file different from the one in the default location, it can be specified with the –c option.

-d: Debugging

spamradar lets you adjust what level of detail you see while it operates.

Debugging Levels

spamradar has five levels of output, depending on what information is needed. Each level also includes the output of all previous levels.

0	At this level, only warnings and errors are displayed. Level 0 is appropriate for running spamradar from cron or in some other automated fashion.
1	This is spamradar's default verbosity level. At this level, the standard relay report is displayed.
2	At Level 2, spamradar displays high-level diagnostic information. This includes information about extracting records from the mail log, opening and closing the database, loading configuration files, and relay testing. Starting at this level, spamradar also displays its current debugging level and displays summary information about the data collected. During development, this was referred to as “chatty” debugging.
3	At this level, spamradar displays the handling of each record. As each record-parsing subroutine is called, its name is displayed. Level 3 will generate roughly the same number of records as the number that you have asked spamradar to analyze.
4	At Level 4, spamradar shows the information extracted from each record at this level. This information varies with each record type.
5	At this level, spamradar also displays its comparison of relay IPs and hostnames to the list of relays that are already blocked and should not be blocked. spamradar will also show other miscellaneous low-level debugging information that is useful during development. During development, this was referred to as “mother-in-law grade” debugging.

For example, if you run spamradar with the command-line option to increase debugging to level 2, and specify no other options, you will see output like:

> spamradar.pl –d 2

Debugging is set to level 2

ADVISORY mode - will NOT modify database.

/var/log/spamradar.log appears to be OK for writing.

Attempting to create lockfile /etc/mail/spamradar.db.lock ... success.

Attempting to lock lockfile /etc/mail/spamradar.db.lock ... success.

Opening database /etc/mail/spamradar.db ... success.

Loading relays we should never block from /etc/spamradar.allow ...

Loading currently rejected hosts from /etc/mail/access ...

Pulling last 6000 lines from /var/log/mail.log ...

Extracting data from log ...

ADVISORY mode - will NOT modify database.

relay IP relay name sent tries guesses

-----------------------------------------------------------------------------------------

178.96.144.20 B idecom.unsj.edu.au 1 4 td wgz vong

194.154.180.98 B 194.154.180.98 0 6 roes whitis

194.98.103.10 B 194.98.103.10 1 23 jeffryn jej

196.36.158.206 B 196.36.168.206 0 10 smoss wcore

201.198.51.162 B 200.198.51.162 0 4 allex awolf

202.194.162.80 B 203.194.162.80 1 4 pjb1 k-garn

202.231.6.193 B 203.231.6.193 28 50 mace madcat

213.182.119.154 B upp.poczta.dublin.pl 0 3 gifcom joth

214.210.25.122 B 213.210.25.122 0 5 gobo rmurra

61.110.89.150 B 62.110.89.150 0 3 medge koerb

61.116.50.34 B 62.116.50.34 1 11 vangoe fhbr

61.172.163.98 B www.larmachbm.co.uk 0 13 bdavidso di

61.2.115.95 B dclient115-95.lospeed.ch 0 7 asilva kjor

64.42.78.133 B great4.greatlifetoday.org 9 13 blh wolfs

Closing database /share/home/royce/bin/spamradar/dev/spamradar.db ... success.

Unlocking lockfile /share/home/royce/bin/spamradar/dev/spamradar.db.lock ... success.

Removing lockfile /share/home/royce/bin/spamradar/dev/spamradar.db.lock ... success.

Using A Local `spamradar.conf` file

If you need to experiment with the settings in spamradar.conf, you can create a separate spamradar.conf file and keep it in a separate directory. As long as you execute spamradar while you are in that directory, the local spamradar.conf will take precedence. spamradar first checks the current directory and uses any local spamradar.conf file that it finds there, and then falls back on the system-wide spamradar.conf (usually located in /etc).

If you specify an alternate configuration file with the –c option, the –c option takes precedence and any local spamradar.conf file will be ignored.

-e: Exporting The Database

The entire database can be exported directly to your screen (STDOUT) with the –e option:

> spamradar.pl –e

12.10.196.183:12.10.196.183:2:987363786::0:2:2gFPBrfGuGOZ4z2gWEz1Qbna:987363786:

12.10.198.140:12.10.198.140:2:987363793::0:2:049100BImHDeSq9HhuI9pyTS:987363786:

12.2.115.69:mail.ltcps.com::::0:1::986790595:

12.25.228.194:194-228-25-12.user.darwin.net::::0:1::986812212:

12.26.165.85:mail.photoengravinginc.com::::0:1::986859758:

12.26.20.243:mail.cmgweb.net::::0:1::986859758:

12.26.72.99:12.26.72.99::::0:2::986812212:

12.27.232.252:12.27.232.252::::0:2::986824999:

12.27.37.235:12.27.37.235::::0:1::986800244:

12.27.8.2:12.27.8.2::::0:16::986787706:

12.29.40.67:12.29.40.67::::0:1::986868985:

The output is colon-delimited, and has this layout:

Relay_IP:reverse_DNS:relaystatus:testdate:testrecdate:testcounter:activity_counter:cookie

The data can be exported to a file by redirecting the output into a file on the command line.

For more information about the data format, see the document entitled spamradar Technical Notes.

-f: Reading From a Different Mail Log File

spamradar can be instructed to process a log file other than the current file. For example, you might want to examine a log file from a previous day.

> spamradar.pl -f /var/log/log_archives/mail.log.20010324

-i: Importing Delimited Data

If you would like to import a list of relays from some other source, you can do so with the –i option.

IMPORTANT: While data is being imported, only the first field (the IP address of the relay) is validated. All other data is accepted as is. Perform your own data checks and make a backup copy of the existing database before importing. You may wish to export data with the –e option and study it before importing.

-m: Manually Search for an Arbitrary String

If something is happening to your mail servers, sometimes it is something that spamradar is not prepared to detect. Sometimes your interest in a particular relay is piqued when you see it in spamradar’s output, and you would like to examine it more closely. In these circumstances, it is sometimes handy to use the –m option to do the searching for you.

-o: Manually Testing A Relay

To manually test to see whether or not a relay is open, use the -o switch:

> spamradar.pl -o 192.168.254.1

Testing 192.168.254.1 for open relay ...

Connecting to 192.168.254.1 ...

<<< 220 spamhoundz.int SMTP Server SLmail 5.0.0.4342 Ready

>>> HELO spamtest.tycho.org

<<< 250 spamhoundz.int

>>> MAIL FROM:<relaytest@tycho.org>

<<< 250 OK

>>> RCPT TO:<relaytest@tycho.org>

<<< 250 OK

>>> DATA

<<< 354 Start mail input; end with <CRLF>.<CRLF>

>>> (message body)

<<< 250 OK, submitted and queued. (6FB9F84C305411D5B55200400552AA80.SKM)

>>> QUIT

<<< 221 spamhoundz.int Service closing transmission channel

rlytest.pl: relay accepted - final response code 221

spamradar remembers the test results and will not retest the same server again by default:

> spamradar.pl -o 208.63.68.73

Skipped: 208.63.68.73 tested on Sun Jan 15 08:58:20 2001 (0 days ago) with status RELAY_ACCEPTED

NOTE: While testing both hostnames and IP addresses is supported, spamradar attempts to convert hostnames to IUP addresses before testing. If this fails, the test will not execute. Since the mapping of hostnames to IPs (“forward” DNS records) and the mapping of IPs to hostnames (“reverse” DNS records) are not guaranteed to match, testing with IP addresses exclusively is recommended.

-O: Testing All Suspicious Relays

To automatically test all relays that show up in spamradar’s report, use the –O option:

> spamradar.pl –O -w

Note: testing multiple relays are always written to the database, even if the –w option is not specified.

-r: Generating Sendmail Reject Data

If you make sendmail aware of spamradar by adding awareness of spamradarreject.db to your sendmail.mc file, any relay marked as an open relay can be automatically blocked. If you would like spamradar to simply regenerate spamradarreject.db and then exit, use the –r option.

NOTE: The creation of the spamradarreject.db file occurs automatically if you use the –w option.

-s: Adjusting the Number of Log Lines to Analyze

Sometimes it is useful to analyze a chunk of mail logs that is different from the default. The larger the chunk, the more data spamradar has to work with, and the more relays will show up in the report. You can manually override the number of log lines to analyze with the –s option, like so:

> spamradar.pl –s 16000

-t: Showing All Suspicious Activity in the Raw Mail Log

To manually display all activity in your mail log that indicates username guessing or invalid domains, use the > spamradar.pl –t option:

> spamradar.pl -t

All records corresponding to username guessing and From-name obfuscation (domains that do not exist or do not have MX records) are displayed.

-u: Adjusting the Username-Guessing Threshold

One of spamradar’s most important statistics is the number of deliveries attempted from a particular relay to users that don’t exist (username “guesses”). If you would like to change the threshold at which spamradar begins to consider such guessing to be a concurrent indicator of spam attack, use the –u option. This temporarily overrides the value in spamradar.conf.

-v: Displaying Version Information

Information about the current version of spamradar can be displayed with the –v option:

> spamradar.pl -v

spamradar.pl v0.9.8a by Royce Williams royce@tycho.org

-w: Watch and Act

This switch turns spamradar from a reporting tool into an active agent of spam prevention. In this mode, after the standard statistics are collected and a report in generated, the following additional duties are performed:

· spamradar walks through the database. If a relay is marked as queued for retesting or has no previous test status, it is added to the pending test list.

· Relays that are more than MAX_TEST_AGE old are removed from the database if they are listed in ORBS.

· The TEST_RECIPIENT mailbox is popped to check for test results. If any results are not listed in TEST_SERVICE_ADDR, they are queued for reporting and then emailed to TEST_SERVICE_ADDR in chunks of 10.

· The spamradarreject.db file is updated, populated with all relays that are currently marked as blockable in the database.

Introduction

Installation

System Requirements

Setup Requirements

Customizing your Configuration file

Parameter

Default Value

Description

Customizing Your Allow and Ignore Files

Installing Relaydata.pm

Relay Reporting

Sendmail Interaction

Administration and Operation

Command-line Switches

-a: Display Information about All Hosts

-c: Specifying a Different Configuration File

-d: Debugging

Debugging Levels

Using A Local `spamradar.conf` file

-e: Exporting The Database

-f: Reading From a Different Mail Log File

-i: Importing Delimited Data

-m: Manually Search for an Arbitrary String

-o: Manually Testing A Relay

-O: Testing All Suspicious Relays

-r: Generating Sendmail Reject Data

-s: Adjusting the Number of Log Lines to Analyze

-t: Showing All Suspicious Activity in the Raw Mail Log

-u: Adjusting the Username-Guessing Threshold

-v: Displaying Version Information

-w: Watch and Act

Troubleshooting

Deinstallation

References

Parameter

Default Value

Description

Using A Local spamradar.conf file

Using A Local `spamradar.conf` file