Example from Kenneth Herron

Last Update 1997-04-26
From: kherron@campus.mci.net (Kenneth Herron)
Newsgroups: comp.mail.sendmail
Subject: Re: check_mail & DNS checking
Date: 25 Apr 1997 17:42:50 GMT
Organization: CampusMCI
Message-ID: <5jqqeq$rfn$1@news.campus.mci.net>
References: <5jic3o$pho@library.airnews.net> <5jid9q$pho@library.airnews.net> <5jimuu$22k$1@news.cmc.net>

I won't directly address the original question, but let me present what
I've developed.  I'm doing all of the filtering in the check_mail rule.

  # Verification at the SMTP MAIL FROM: stage
  Scheck_mail
  R$*                     $: $>3 $1               Standard format
  R$* <@ $=w .> $*        $>3 $(dequote $1 $) $3  Repeatedly strip local domains
  R$* <@[ $- . $- . $- . $- ]> $* $@ OK           user@[ip] currently accepted
  R$* <@ $+ > $*          $: $>remote_check $2
  R<OK>                   $@ OK                   Remote good
  R< $- $+ >              $# error $@ $1 $: $2    Remote bad
  R<@>                    $@ OK                   Mailer-daemon envelope addr
  R$+                     $: $>local_check $1
  R<OK>                   $@ OK                   Local good
  R< $- $+ >              $# error $@ $1 $: $2    Local bad

Essentially, this shunts remote sender addresses through another rule
called "remote_check", while local addresses go through "local_check".
Both rules return either <OK> or an error code and message.

Local_check makes sure that local addresses are in either /etc/passwd
or the aliases db:

# Maps to look up user names in local_check
Kpasswd user -m -a@
Kalias implicit -m -a@ /etc/mail/aliases
Klocal sequence alias passwd

  # Determine if a local address exists or not.
  Slocal_check
  R$+                     $: $(local $1 $)
  R$+ @                   $@ <OK>
  R$*                     $@ <NOUSER "550 Unrecognized username '" $1 "'" >

Remote_check is more complicated.  Hostnames which resolve (and pseudo-
domains like .uucp) are automatically accepted.  Hostnames which don't
resolve are checked in a map; based on the map the address is either
accepted or permanently rejected.  Names which aren't in the map are
accepted if they're from a list of low-risk top-level domains (most
spammer bogus addresses are either in .com or have a completely invalid
TLD).  Hostnames which fail the TLD test are rejected with a 400-series
error, in case it's a true DNS error.

  # Database of domain names which aren't in DNS.  Value should be "OK" ->
  # accept mail with this in the From address, or "UNK" -> reject mail
  # with this in the From address.
  Kbaddb hash -O -a@ /etc/mail/bad-domains

  # Top-level domains which are accepted even when DNS fails.
  C{tlok} net org mil gov us ca mx jp

  # Determine if a remote address is acceptable or not
  Sremote_check
  R$* $=P                 $@ <OK>                 DNS worked; presume good
  R$*                     $: $1 $| $(baddb $1 $)  Check db
  R$* $| UNK@             $@ <NOHOST "551 Unrecognized domain '" $1 "'" >
  R$* $| OK@              $@ <OK>                 DB says take it
  R$* $| $*               $: $1                   Lookup failed or unrecognized
  R$+ . $={tlok}          $@ <OK>                 Low-risk TLD
  R$*                     $@ <NOHOST "451 Unrecognized domain '" $1 "'" >

If you have a lot of users running self-configured POP readers, you'll
find that these rules are *very* aggressive about catching user
mistakes.  If they misspell their account name or include spaces in it,
it'll probably be caught.  If they misspell their hostname (including
using commas instead of dots) it'll be treated as remote and probably
rejected.

As for bugs in DNS lookups, so far I haven't seen any.  I've been
spot-checking many of the legitimate-looking addresses which we've been
rejecting, and found neither A nor MX records in every case.  I'm
seeing a lot of probably-legitimate mail being bounced for various
addressing problems (unknown hostnames, no hostname part & not from a
local user, not-fully-qualified names, misspellings), along with the
likes of "earn@money.now".  The baddb map lets me override bad DNS for
any of these, whether to accept or reject it.

[As I noted, we're currently accepting anything which resolves.  This
is just a local policy decision (basically, we don't have a settled
policy on filtering "valid" mail yet).  It's simple to modify these
rules to consult a map for valid domains as well.  We're using TCP
wrappers to block the major spammers, BTW.]
-- 
Kenneth Herron -- kherron@campus.mci.net
No animals were harmed during the production of this message.


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