SUMMARY: sendmail 8.9.3: stop one host relaying?

From: Marina.Daniels@cs.tas.gov.au
Date: Mon May 17 1999 - 19:35:00 CDT


     Thanks very much to the following (and anyone I have missed while
     cutting/pasting :-)
     
     Jeff Graham
     Pete Schmitt
     James Ford
     Yura Pismerov
     +- Shaun W. Amy - Network Manager
     J.Bern
     <jim@nortx.com
     Joe Pruett <
     bosire
     
     
     It looks like I have to use
     
     FEATURE(access_db)
     or FEATURE(access_db, hash -o /etc/mail/access)
     
     when I set up sendmail on my host and then I can use /etc/mail/access
     to stop relaying from this host in particular, although we still want
     to accept mail from it for our users.
     (See sendmail document at the bottom of this email to see how to set
     up this file)
     
     However, after re-thinking this last night, since I am no longer
     actually required to support "relaying" for these hosts, and was just
     being nice to stop things breaking :-) I am going to stop relaying
     for the whole domain and grant it on an individual basis if people
     convince me it is really necessary, and I can do this with the
     /etc/mail/relay-domains file which I have already got set up.
     
     **********************************************************************
     
     ORIGINAL QUESTION
     I'm sorry but I can't find the info anywhere on the www.sendmail.org
     web-site, (and I can't read the doco that came with sendmail properly
     on my solaris 2.6 machine without spending HOURS trying to format it
     differently) so I'm trying here as I'm running out of time.
     
     I am running Sendmail 8.9.3 and I have "/etc/mail/relay-domains" set
     up to control relaying:
     
     I have listed "tas.gov.au" in this file to allow my host to relay mail
     from all hosts in this domain.
     
     What is the syntax to stop only one host in this domain from relaying
     through my machine?
     
     ie: say I want to block "test1.fictional.tas.gov.au" but allow all
     other "tas.gov.au" to use my machine to relay?
     
     I don't actually know how many hosts out in 'tas.gov.au' are relaying
     through my host, so I can't grant them all permission individually.
     
     Thanks,
     Marina
     
     
     **********************************************************************
     ***********
     SENDMAIL DOCUMENTATION:
     
     ***URL where you can read about access_db
     http://www.sendmail.org/m4/anti-spam.html
     
     ****You want to use /etc/mail/access....
     
     +---------------------------------+
     | ANTI-SPAM CONFIGURATION CONTROL |
     +---------------------------------+
     
     The primary anti-spam features available in sendmail are:
     
     * Relaying is denied by default.
     * Better checking on sender information. * Access database.
     * Header checks.
     
     Relaying (transmission of messages from a site outside your domain to
     another site outside your domain) is denied by default. Note that
     this changed in sendmail 8.9; previous versions allowed relaying by
     default. If you want to revert to the old behaviour, you will need to
     use FEATURE(promiscuous_relay). You can allow certain domains to
     relay through your server by adding their domain name or IP address to
     class 'R' ($=R) using RELAY_DOMAIN() and RELAY_DOMAIN_FILE() or via
     the access database (described below).
     
     If you use
     
     FEATURE(relay_entire_domain)
     
     then any host in any of your local domains (that is, the $=m class)
     will be relayed.
     
     You can also allow relaying based on the MX records of the host
     portion of an incoming recipient address by using
     
     FEATURE(relay_based_on_MX)
     
     For example, if your server receives a recipient of user@domain.com
     and domain.com lists your server in its MX records, the mail will be
     accepted. Note that this will stop spammers from using your host to
     relay spam but it will not stop outsiders from using your server as a
     relay for their site. Along the same lines,
     
     FEATURE(relay_local_from)
     
     will allow relaying if the sender specifies a return path (i.e. MAIL
     FROM: <user@domain>) domain which is a local domain. This a dangerous
     feature as it will allow spammers to spam using your mail
     server by simply specifying a return address of user@your.domain.com.
     It should not be used unless absolutely necessary.
     
     If source routing is used in the recipient address (i.e. RCPT TO:
     <user%site.com@othersite.com>), sendmail will check
     user@site.com for relaying if othersite.com is an allowed relay host
     in either class 'R', class 'm' if FEATURE(relay_entire_domain) is
     used, or the access database if FEATURE(access_db) is used. To
     prevent
     the address from being stripped down, use:
     
     FEATURE(loose_relay_check)
     
     If you think you need to use this feature, you probably do not. This
     should only be used for sites which have no control over the addresses
     that they provide a gateway for. Use this FEATURE with caution as it
     can allow spammers to relay through your server if not setup properly.
     
     As of 8.9, sendmail will refuse mail if the MAIL FROM: parameter has
     an unresolvable domain (i.e., one that DNS, your local name service,
     or special case rules in ruleset 3 cannot locate). If you want to
     continue to accept such domains, e.g. because you are inside a
     firewall that has only a limited view of the Internet host name space
     (note that you will not be able to return mail to them unless you have
     some "smart host" forwarder), use
     
     FEATURE(accept_unresolvable_domains)
     
     sendmail will also refuse mail if the MAIL FROM: parameter is not
     fully qualified (i.e., contains a domain as well as a user). If you
     want to continue to accept such senders, use
     
     FEATURE(accept_unqualified_senders)
     
     An ``access'' database can be created to accept or reject mail from
     selected domains. For example, you may choose to reject all mail
     originating from known spammers. To enable such a database, use
     
     FEATURE(access_db)
     
     The FEATURE macro can accept a second parameter giving the key file
     definition for the database; for example
     
     FEATURE(access_db, hash -o /etc/mail/access)
     
     The table itself uses e-mail addresses, domain names, and network
     numbers as keys. For example,
     
     spammer@aol.com REJECT
     cyberspammer.com REJECT
     206.117.147 REJECT
     
     would refuse mail from spammer@aol.com, any user from cyberspammer.com
     (or any host within the cyberspammer.com domain), and any host on the
     206.117.147.* network.
     
     The value part of thee map can contain:
     
     OK accept mail even if other rules in the
     running ruleset would reject it.
     RELAY Allow domain to relay through your SMTP
     server. RELAY also serves an implicit OK for the other checks.
     REJECT reject the sender/recipient with a general
     purpose message.
     DISCARD discard the message completely using
     the $#discard mailer
     ### any text where ### is an RFC 821 compliant error code
     and "any text" is a message to return for the command.
     
     For example:
     
     cyberspammer.com 550 We don't accept mail from spammers
     okay.cyberspammer.com OK
     sendmail.org OK
     128.32 RELAY
     
     would accept mail from okay.cyberspammer.com, but would reject mail
     from all other hosts at cyberspammer.com with the indicated message.
     It would allow accept mail from any hosts in the sendmail.org domain,
     and allow relaying for the 128.32.*.* network. Note, UUCP users may
     need to add hostname.UUCP to the access database or class 'R' ($=R).
     If you also use:
     
     FEATURE(relay_hosts_only)
     
     then the above example will allow relaying for sendmail.org, but not
     hosts within the sendmail.org domain. Note that this will also
     require hosts listed in class 'R' ($=R) to be fully qualified host
     names.
     
     You can also use the access database to block sender addresses based
     on the username portion of the address. For example:
     
     FREE.STEALTH.MAILER@ 550 Spam not accepted
     
     Note that you must include the @ after the username to signify that
     this database entry is for checking only the username portion of the
     sender address.
     
     If you use:
     
     FEATURE(blacklist_recipients)
     
     then you can add entries to the map for local users, hosts in your
     domains, or addresses in your domain which should not receive mail:
     
     badlocaluser 550 Mailbox disabled for this username
     host.mydomain.com 550 That host does not accept mail
     user@otherhost.mydomain.com 550 Mailbox disabled for this
     recipient
     
     This would prevent a recipient of badlocaluser@mydomain.com, any user
     at host.mydomain.com, and the single address
     user@otherhost.mydomain.com from receiving mail.
     
     There is also a ``Realtime Blackhole List'' run by the MAPS project at
     http://maps.vix.com/. This is a database maintained in DNS of
     spammers. To use this database, use
     
     FEATURE(rbl)
     
     This will cause sendmail to reject mail from any site in the Realtime
     Blackhole List database. You can specify an alternative RBL name
     server to contact by specifying an argument to the FEATURE.
     
     The features described above make use of the check_relay, check_mail,
     and check_rcpt rulesets. If you wish to include your own checks,
     you can put your checks in the rulesets Local_check_relay,
     Local_check_mail, and Local_check_rcpt. For example if you wanted to
     block senders with all numeric usernames (i.e. 2312343@bigisp.com),
     you would use Local_check_mail and the new regex map:
     
     LOCAL_CONFIG
     Kallnumbers regex -a@MATCH ^[0-9]+$
     
     LOCAL_RULESETS
     SLocal_check_mail
     # check address against various regex checks
     R$* $: $>Parse0 $>3 $1 R$+ < @ bigisp.com.
> $* $: $(allnumbers $1 $)
     R@MATCH $#error $: 553 Header Error
     
     These rules are called with the original arguments of the
     corresponding check_* ruleset. If the local ruleset returns $#OK, no
     further checking is done by the features described above and the mail
     is accepted. If the local ruleset resolves to a mailer (such as
     $#error or $#discard), the appropriate action is taken. Otherwise,
     the results of the local rewriting are ignored.
     
     
     You can also reject mail on the basis of the contents of headers.
     This is done by adding a ruleset call to the 'H' header definition
     command in sendmail.cf. For example, this can be used to check the
     validity of
     a Message-ID: header:
     
     LOCAL_RULESETS
     HMessage-Id: $>CheckMessageId
     
     SCheckMessageId
     R< $+ @ $+ > $@ OK
     R$* $#error $: 553 Header Error
     
     --
     
     
     
     ---



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:20 CDT