FEATURE
s
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 (check_relay, check_compat) which use the $| token, you should introduce the following ruleset first:
SStart R$* $$| $* $: $1 $| $2 fake for -bt mode, remove for real versionsince you can't enter the token $|. You have to enter then
A hint: nearly all of these rules require a working hostname canonicalization. They don't work if you use FEATURE(nocanonify) in your .mc file. For check_rcpt the option _NO_CANONIFY_ can overcome this problem.
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.
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 $: "550 You are banned, contact your local admin." rewrite: ruleset 196 returns: $# error $@ 5 . 7 . 1 $: "550 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)or
map_lookup: junk (cyberpromo.com) returns "some error text"@JUNK (0)
sendmail -bt -d21.4 ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > .D{client_addr}1.2.3.4 > .D{client_name}domain.comYou should try the following tests: Let's assume the following: you use {LocalIP} , one of the entries in it is 134.245.15.1 , and extern IP address is 1.2.3.4 , a local hostname is informatik.uni-kiel.de , and an extern name is aol.com . So you have to perform these tests:
sendmail -bt -d21.4 > .D{client_addr}134.245.15.1 > .D{client_name}informatik.uni-kiel.de > check_rcpt <a@aol.com>(sample output from 8.8, 8.9 (and later))
sendmail -bt -d21.4 > .D{client_addr}1.2.3.4 > .D{client_name}aol.com > check_rcpt <a@informatik.uni-kiel.de>(sample output from 8.8, 8.9 (and later))
sendmail -bt -d21.4 > .D{client_addr}1.2.3.4 > .D{client_name}aol.com > check_rcpt <a@aol.com>(sample output from 8.8, 8.9 (and later))
rewrite: ruleset 195 returns: $# error $@ 5 . 7 . 1 $: 550 we do not relayor (8.9 (and later)):
rewrite: ruleset 181 returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied"
Notes:
sendmail -bt > /map access 1.2.3.4 > /map localip 1.2.3.4You probably need to check the nets too, depending on the entries in the map:
sendmail -bt > /map access 1.2.3 > /map localip 1.2.4etc. The mapname access is for sendmail 8.9 (and later) , localip is for my check_rcpt HACK.
sendmail -bt > $=R
# pass to name server to make hostname canonical R$* < @ $* $~P > $* $: $1 < @ $[ $2 $3 $] > $4in S96 adds 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. (this doesn't apply to 8.9 (and later)).
sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > .Dfuser@some.domain
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=550 <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.comor ${client_addr} , i.e.,
> .D{client_addr}152.170.51.209and arg1 for the ruleset, i.e.,
> check_rcpt <ESCAPEFOUR@AOL.COM>This way you can see which classes/maps you have to modify. For this example,
152.170.51.209would have to be added to the class {LocalIP} or
170-51-209.ipt.aol.comto the class {LocalNames} (if the standard configuration is used, otherwise one of this entries needs to be added to the used map).
sendmail -bt -d21.4 > .D{client_addr}from_IP_addr > Start,check_relay from_host $| from_IP_addrDon't forget to set ${client_addr} because otherwise the test of the DNS based rejection lists won't work.
makemap hash /etc/mail/access </etc/mail/access
sendmail -bt > /map access ENTRYwhere ENTRY is something which is on the LHS of the map. It should return the RHS, e.g.,
map_lookup: access (ENTRY) returns "550 no mail from ENTRY" (0)
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.
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.
The CIAC Email Relay Problem Test uses a script written by Chip Rosenthal.
If you have other proposals to debug the new rules, please let me know.