Debugging check_* in sendmail 8.8

Last Update 1997-10-01

Some suggestions to debug the check_* rules

After you have installed the new check_* rules to avoid misuse of your system and spam from well-known sites, you need to test them. Or you can blindly trust the guys who wrote them... (never do that, someone may have made a mistake!).

First, you can use conventional debugging by testing the rewrite rules directly with sendmail -bt . If you want to test those rulesets which use the $| token, you should introduce the following ruleset first:

SStart
R$* $$| $*		$: $1 $| $2		fake for -bt mode, remove for real version
since you can't enter the token $| . You have to enter then
> Start,check_compat from_addr $| to_addr
to check your rules. Thanks to Bryan Costales and Eric Allman for this tip.

A small note for Solaris 2 users from the 8.8.6 Beta Release Notes:

Solaris: a bug in strcasecmp caused characters with the
	high order bit set to apparently randomly match
	letters -- for example, $| (0233) matches "i" and "I".
	Problem noted by John Gregson of the University of
	Cambridge.

Debugging check_mail

Let's assume you implemented the rules to block mail from spammers. Checking these is fairly simple. Let's assume you have millions@millions.com and cyberpromo.com in your class (or map) of spammers/spamdomains. Then run:
sendmail -bt
> check_mail <millions@millions.com>
> check_mail <anyone@cyberpromo.com>
In both cases you should get an error code back, like:
rewrite: ruleset 196 returns: $# error $@ 5 . 7 . 1 $: "551 You are banned, contact your local admin."
rewrite: ruleset 196 returns: $# error $@ 5 . 7 . 1 $: "551 This domain is banned, contact your local admin."
If it doesn't work as expected you can have a look at the class you defined:
sendmail -bt
> $={Spammer}
> $={SpamDomains}
or check the map you use:
sendmail -bt
> /map junk cyberpromo.com
map_lookup: junk (cyberpromo.com) returns JUNK (0)

Debugging check_rcpt

check_rcpt makes use of the macro ${client_name} or ${client_addr} . You can set the value like this:
sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> .D{client_addr}1.2.3.4
> .D{client_name}domain.com
You should try the following tests:
  1. e-mail from internal to external,
  2. e-mail from external to internal,
  3. e-mail from external to external.
Let's assume the following: you use {LocalIP} , one of the entries in it is 134.245.15.1 , and external IP address is 1.2.3.4 , a local hostname is informatik.uni-kiel.de , and an external name is aol.com . So you have to perform these tests:
  1. e-mail from internal to external:
    sendmail -bt
    > .D{client_addr}134.245.15.1
    > check_rcpt <a@aol.com>
    
    (sample output)
  2. e-mail from external to internal,
    sendmail -bt
    > .D{client_addr}1.2.3.4
    > check_rcpt <a@informatik.uni-kiel.de>
    
    (sample output)
  3. e-mail from external to external.
    sendmail -bt
    > .D{client_addr}1.2.3.4
    > check_rcpt <a@aol.com>
    
    (sample output)
Only the last test should produce an error:
rewrite: ruleset 195 returns: $# error $@ 5 . 7 . 1 $: 551 we do not relay

Note 1: You have to set ${client_addr} for HACK(use_ip) and ${client_name} for HACK(use_names) . If you use both, you have to set both!

Note 2: the code to remove those hostnames or domains for which you accept incoming mail as relay relies on DNS to canonicalize these names. The code in S96 add a trailing dot to the names which is required for matching. So if you test the rules, make sure you use real names with entries in the DNS.

check_rcpt and entries in the logfile

Blocked relay attempts can be found in the logfile, like this one:

QAA02454: <ESCAPEFOUR@AOL.COM>... we do not relay
QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
	relay=170-51-209.ipt.aol.com [152.170.51.209], reject=551
	<ESCAPEFOUR@AOL.COM>... we do not relay
QAA02454: from=<Anonymous>, size=0, class=0, pri=0, nrcpts=0,
	proto=SMTP, relay=170-51-209.ipt.aol.com [152.170.51.209]
If you have a problem with check_rcpt denying relaying which should be allowed, you can use the entries from the logfile to check your rules and classes/maps. The relay= should be used for ${client_name} , i.e.,
> .D{client_name}170-51-209.ipt.aol.com
or ${client_addr} , i.e.,
> .D{client_addr}152.170.51.209
and arg1 for the ruleset, i.e.,
> check_rcpt <ESCAPEFOUR@AOL.COM>
This way you can see which classes/maps you have to modify.

Running sendmail as daemon with debug flags

To check the rules which refer to special macros such as ${client_name} or ${client_addr} you can run sendmail in debug mode: sendmail -bd -d21.4 (or other debug flags, see src/TRACEFLAGS in the actual source). Do this testing only on a special machine of course, don't put it on a production machine, if there is a mistake in your rules, you may receive no mail at all...
BTW: sendmail uses internally only numbers for the rulesets, so you won't see: ruleset check_mail or something similar, but numbers just below 200 for the check_* rulesets.

Now you can connect from another machine either by hand telnet test.machine smtp or use the -v flag of Mail to see the actual SMTP dialogue.

A script to test mail relaying capabilities

Andrew Daviel wrote a nice script to check whether e-mail can be relayed through your system. (It requires PERL 5). Make sure you read the

 DISCLAIMER: This script is intended to test mail relaying capabilities.
 Unauthorized use of this script on non-local hosts may be interpreted as 
 a network attack.
 Each copy of this script is identified by a unique serial number and  
 may be traced back to the user.   

A script to analyze the logfile

smreject: A perl script written by Ted George which analyzes the sendmail logfile for rejected messages based on the check_* rules. Shows rejected message counts for each junk file entry. Also shows counts of failed messages for the top mail relay hosts and email addresses attempting to use your mail server.

Suggestions?

If you have other proposals to debug the new rules, please let me know.


[(links)] [Hints] [Avoiding Spam] [FAQ] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca@informatik.uni-kiel.de>