Sendmail Web-Admin Tool (SWAT) Help

Based on the README from Eric Allman <eric@Sendmail.ORG>

This document describes the sendmail configuration using SWAT (the Sendmail Web-Administration Tool, which is based on SWAT, the Samba Web-Administration Tool - any similarities between SWAT and SWAT are therefore not accidental). The information has been derived mostly from the README accompanying sendmail.

SWAT is a frontend to the m4 based sendmail configuration. It uses the m4 macro files coming with sendmail to create a sendmail.cf instead of editing sendmail.cf directly. You can view the m4 sendmail macros it uses in the "View"-part, and use the /etc/mail/suse.mc file it creates as a base for your own handmade configuration, if you like.
In addition to creating sendmail.cf SWAT lets you edit all the other files that are part of sendmail configuration, like all the tables (e.g. virtusertable) and the access control database file. It takes care of building the database (.db) files after changes have been made to the text files.

UUCP is not supported by SWAT, sorry. We will gladly include the code if someone would like to contribute it, but for us UUCP has become to rare to justify the effort.

The sendmail configuration abilities of SWAT should work for most people. The few who have a weird network can use m4 manually, or edit sendmail.cf. That's the price of maintaining a non-standard setup.

Globals

smarthost

Send mail that can't be handled locally to a smarthost. For example, if you're behind a firewall and have only limited DNS information, e.g. for your own local domain only, you can handle all mail within the local domain yourself, but all external mail would need to be send to a smarthost that has full Internet DNS/Email connectivity.

mailhub

Use this if you want all local mail sent to a centralized hub, i.e. mail sent to unqualified names (without an '@domain') or mail sent to a domain in the list of local names is sent to that hub instead of being delivered locally. It also means the local mailer is never used for any mail, except for users in local_users (an advanced setting, root is one such user if you didn't change the defaults).

masquerade as

All sender addresses in emails from your local domain are rewritten to this address. For example, if your mail addresses are user@domain.com and you send from hosts named host.domain.com you probably want this feature so that the address on outgoing mail has domain.com after the '@' instead of host.domain.com.

nocanonify

Don't ask the nameserver to canonify addresses. This would generally only be used by sites that only act as mail gateways or which have user agents that do full canonification themselves. Also useful if expensive="Yes" (see below).

expensive

Avoid connecting immediately to mailers marked expensive. If you say "Yes" to this option all mail that is not local (i.e. it has to be sent out via SMTP) will only be queued. In order to send it you have to call "sendmail -q" manually, or you could run this command periodically via cron.
This option is good for dial-on-demand hosts, if you don't want sendmail to cause a dial for every single mail.

nullclient

This is a special case -- it creates a stripped down configuration file containing nothing but support for forwarding all mail to a central hub via a local SMTP-based network. The argument is the name of that hub.
The only other feature that should be used in conjunction with this one is nocanonify (this causes addresses to be sent unqualified via the SMTP connection; normally they are qualified with the masquerade name, which defaults to the name of the hub machine). No aliasing or forwarding (i.e. use of /etc/aliases or .forward files) is done. Also, note that absolutely no anti-spam or anti-relaying is done in a null client configuration.

nullclient with Anti-SPAM and Relay-Control

Normally a configuration using the nullclient feature doesn't use the anti-SPAM and relay control mechanisms. Setting this option creates a configuration that emulates the behaviour of a nullclient while giving back full anit-SPAM and relay control. The limitations of a nullclient apply, though (e.g. no local aliases).

local names

Add here all names we receive mail for, i.e. those for whom we are the end point for all email. It is not enough to specify the domain name, everything after the '@' in emails must match the strings given here exactly in order for the mail to be considered local. Vice versa, don't add any names this host is not the mailhost for. Any mail with a destination address of user@one-of-the-names-you-specify-here will be delivered to 'user' (local user on this system).

If your host is known by several different names, you need to augment the class containing the local names. This is a list of names by which you are known, and anything sent to an address using a host name in this list will be treated as local mail.
Be sure you use the fully-qualified name of the host, rather than a short name.

aliases file (/etc/aliases)

This file describes user ID aliases used by sendmail. The file resides in /etc and is formatted as a series of lines of the form

	name: name_1, name2, name_3, . . .

The name is the name to alias, and the name_n are the aliases for that name. Lines beginning with white space are continuation lines. Lines beginning with `#' are comments.

Aliasing occurs only on local names. Loops can not occur, since no message will be sent to any person more than once.

After aliasing has been done, local and valid recipients who have a ".forward" file in their home directory have messages forwarded to the list of users defined in that file (which by the way has the same syntax except that the left side "name:" is not needed since it's clear at this point who that is, obviously).

Security

Also see the general text Anti-SPAM Configuration Control at the bottom.

Basic Relay Settings (who may use this mailer)

relay_entire_domain

By default, only hosts listed as RELAY in the access db (see next point) will be allowed to relay. This option also allows any host in your domain as defined under local names (in section "Globals").

access_db

Turns on the access database feature. The access db gives you the ability to allow or refuse to accept mail from specified domains for administrative reasons. The format of the database is described below, in help section Anti-SPAM Configuration Control.

Advanced Relay/Anti-SPAM Settings

rbl

Turns on rejection of hosts found in the Realtime Blackhole List. By default, the main RBL server at rbl.maps.vix.com is used, if you have your own RBL-mirror you don't use this tool to create your sendmail configuration anyway but do it manually because you're an expert ;-). This means you must have direct (IP) access to that server if you plan to use this feature.
For details, see http://maps.vix.com/rbl/. Since you need a DNS-lookup to a remote DNS server for each mail you receive this is only for small sites! Also, if you don't get mail via SMTP but use POP or IMAP to retrieve it from an ISP that handles your email (most household-PCs) this is useless.

relay domains

Similar to the access db, except that it is less powerful: all domains you add here are allowed to use this host as mail relay host. Ignore, if you already have them in the access db. For historic reasons you'll find many more overlapping features in sendmail. That is because often a new feature was needed so urgently that a quick hack was added to sendmail. Later a clean solution followed, but the hack persisted, because in the meantime many people had added it to their configuration. Just for your general information how these things happen.
Example for how to write the file:

my-domain.com my-other-domain.net

promiscuous relay

Please don't set this to "Yes" when your mailserver is on the Internet. By default, the sendmail configuration files do not permit mail relaying (that is, accepting mail from outside your domain and sending it to another host outside your domain).
This option sets your site to allow mail relaying from any site to any site. In general, it is better to control the relaying more carefully with the access db and the relay-domains file.

relay_hosts_only

By default, names that are listed as RELAY in the access db and the relay-domains file are domain names, not host names. For example, if you specify foo.com, then mail to or from foo.com, abc.foo.com, or a.very.deep.domain.foo.com will all be accepted for relaying. This feature changes the behaviour to lookup individual host names only.

relay_based_on_MX

Turns on the ability to allow relaying based on the MX records of the host portion of an incoming recipient; that is, if an MX record for host foo.com points to your site, you will accept and relay mail addressed to foo.com. See description below under Anti-SPAM Configuration Control for more information before using this feature.
Enabling this feature does not necessarily allow routing of these messages which you expect to be allowed, if route address syntax (or %-hack syntax) is used. If this is a problem, add entries to the access-table or use loose_relay_check.

relay_local_from

Allows relaying if the domain portion of the mail sender is a local host. This should only be used if absolutely necessary as it opens a window for spammers. Specifically, they can send mail to your mail server that claims to be from your domain (either directly or via a routed address), and you will go ahead and relay it out to arbitrary hosts on the Internet.

accept_unqualified_senders

Normally, MAIL FROM: commands in the SMTP session will be refused if the connection is a network connection and the sender address does not include a domain name. If your setup sends local mail unqualified (i.e. MAIL FROM: <joe>), you will need to use this feature to accept unqualified sender addresses.

accept_unresolvable_domains

Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., DNS). If you are inside a firewall that has only a limited view of the Internet host name space, this could cause problems. In this case you probably want to use this feature to accept all domains on input, even if they are unresolvable.

blacklist_recipients

Turns on the ability to block incoming mail for certain recipient usernames, hostnames, or addresses. For example, you can block incoming mail to user nobody, host foo.mydomain.com, or guest@bar.mydomain.com. These specifications are put in the access db as described below under Anti-SPAM Configuration Control.

loose_relay_check

Normally, if a recipient using % addressing is used, e.g. user%site@othersite, and othersite is in the relay-domains file, the check_rcpt ('check recipient') ruleset (internal sendmail stuff you don't need to understand) will strip @othersite and recheck user@site for relaying. This feature changes that behavior. It should not be needed for most installations.

Tables

mailertable

Include a "mailer table" which can be used to override routing for particular domains.
Keys in this database are fully qualified domain names or partial domains preceded by a dot -- for example, "vangogh.CS.Berkeley.EDU" or ".CS.Berkeley.EDU". Values must be of the form:

	mailer:domain

where "mailer" is the internal mailer name, and "domain" is where to send the message. These maps are not reflected into the message header. As a special case, the forms:

	local:user

will forward to the indicated user using the local mailer,

	local:

will forward to the original user in the e-mail address using the local mailer, and

	error:code message

will give an error message with the indicated code and message.

Using Mailertables

The semantics are simple. Any LHS entry that does not begin with a dot matches the full host name indicated. LHS entries beginning with a dot match anything ending with that domain name -- that is, they can be thought of as having a leading "*" wildcard. Matching is done in order of most-to-least qualified -- for example, even though ".my.domain" is listed first in the above example, an entry of "uuhost1.my.domain" will match the second entry since it is more explicit.

The RHS should always be a "mailer:host" pair. The mailer is the configuration name of a mailer (that is, an `M' line in the sendmail.cf file). The "host" will be the hostname passed to that mailer. In domain-based matches (that is, those with leading dots) the "%1" may be used to interpolate the wildcarded part of the host name. For example, the first line above sends everything addressed to "anything.my.domain" to that same host name, but using the (presumably experimental) xnet mailer.

In some cases you may want to temporarily turn off MX records, particularly on gateways. For example, you may want to MX everything in a domain to one machine that then forwards it directly. To do this, you might use the DNS configuration:

		*.domain.	IN	MX	0	relay.machine

and on relay.machine use the mailertable:

		.domain		smtp:[gateway.domain]

The [square brackets] turn off MX records for this host only. If you didn't do this, the mailertable would use the MX record again, which would give you an MX loop.

Example for how to write the file:

        # default mailhub
        .                      smtp:mailhub.domain.com
        #
        # send all email for a special host to another host or to a specific IP:
        host.sub.org           smtp:host.domain.com
        host.sub.org           smtp:[192.168.0.1]
        #
        # send email for all hosts below .sub.org to another host:
        .sub.org               smtp:host.domain.com
        #
        # send all email for a specific host to one local user called "foo":
        host.sub.org           local:foo

domaintable

Include a "domain table" which can be used to provide domain name mapping. Use of this should really be limited to your own domains. It may be useful if you change names (e.g., your company changes names from oldname.com to newname.com).

The key in this table is the domain name; the value is the new (fully qualified) domain. Anything in the domaintable is reflected into headers; that is, this is done in ruleset 3. An example for how this could be useful is if you have an internal domain name that's different from how your domain is known elsewhere.

Example for how to write the file:

        #
        # map domain names. mail headers are changed as well.
        #
        my-old-domain.com          my-new-domain.com
        my-old-other-domain.net    my-new-other-domain.com

genericstable

This feature will cause certain addresses originating locally (i.e. that are unqualified) or a domain listed in generics-domains (can be edited under "Tables"->"Edit Genericstable") to be looked up in a map and turned into another ("generic") form, which can change both the domain name and the user name. This is similar to the userdb functionality, except that it is much better (more powerful). The same types of addresses as for masquerading are looked up, i.e. only header sender addresses unless the allmasquerade and/or masquerade_envelope features are given. Qualified addresses must have the domain part in the list of names in generics-domains (can be edited under "Tables"->"Edit Genericstable").

The key for this table is either the full address or the unqualified username (the former is tried first); the value is the new user address. If the new user address does not include a domain, it will be qualified in the standard manner, i.e. using the FQDN of the mailhost or the masquerade name. Note that the address being looked up must be fully qualified. For local mail, it is necessary to use always_add_domain for the addresses to be qualified.

Example for how to write the file:

        #
        # map outgoing sender addresse from foo to bar@domain.com:
        # foo           bar@domain.com
        #
        user@my-domain.com            user@other-domain.net
        user@my-other-domain.net      newuser
        user                          postmaster@my-domain.com

virtusertable

A domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine. For example, if the virtuser table contained:

	info@foo.com	foo-info
	info@bar.com	bar-info
	@baz.org	jane@elsewhere.net

then mail addressed to info@foo.com will be sent to the address foo-info, mail addressed to info@bar.com will be delivered to bar-info, and mail addressed to anyone at baz.org will be sent to jane@elsewhere.net. The username from the original address is passed as %1 allowing:

	@foo.org	%1@elsewhere.com

meaning someone@foo.org will be sent to someone@elsewhere.com.

All the host names on the left hand side (foo.com, bar.com, and baz.org) must be in local names (Section "Globals").

Example for how to write the file:

        #
        # map incoming email from foo@domain.com to bar
        # foo@domain.com        bar
        # 
	info@foo.com	foo-info
	info@bar.com	bar-info
	@baz.org	jane@elsewhere.net

userdb

The user database was not originally intended for mapping full names to login names (e.g., Eric.Allman => eric), but some people are using it that way. (I would recommend that you set up aliases for this purpose instead -- since you can specify multiple alias files, this is fairly easy.) The intent was to locate the default maildrop at a site, but allow you to override this by sending to a specific host.

If you decide to set up the user database in this fashion, it is imperative that you not use stickyhost -- otherwise, e-mail sent to Full.Name@local.host.name will be rejected.

You may find out that what you really want is a virtual usertable, which in the end can do the same (and more) as a userdb anyway.

Example for how to write the file:

        bar:mailname                     foo.name@domain.com
        foo.name@domain.com:maildrop     bar
        # (separate with tabs         ^^ !!)

Advanced

masquerade envelope

Normally only header addresses are masqueraded. Set this to "Yes" to also masquerade the envelope.

masquerade_domains

Normally only local domains are masqueraded. Here you can specify additional, non-local domains to be masqeraded. Most people can ignore this feature (leave empty).

allmasquerade

If masquerading is enabled (you entered a value for masquerade as), this feature will cause recipient addresses to also masquerade as being from the masquerade host. Normally they get the local hostname. Although this may be right for ordinary users, it can break local aliases. For example, if you send to "localalias", the originating sendmail will find that alias and send to all members, but send the message with "To: localalias@masqueradehost". Since that alias likely does not exist, replies will fail. Use this feature ONLY if you can guarantee that the ENTIRE namespace on your masquerade host supersets all the local entries.

limited_masquerade

Normally, any hosts listed in local names are masqueraded. If this feature is given, only the hosts listed in masquerade_domains are masqueraded. This is useful if you have several domains with disjoint namespaces hosted on the same machine.

masquerade_entire_domain

If masquerading is enabled (you entered a value for masquerade as) and masquerade_domains is set (contains values), this feature will cause addresses to be rewritten such that the masquerading domains are actually entire domains to be hidden. All hosts within the masquerading domains will be rewritten to the masquerade name (used in masquerade as). For example, if you have:

masquerade_as: masq.com
masquerade_domain: foo.org
masquerade_domain: bar.com

then *foo.org and *bar.com are converted to masq.com. Without this feature, only foo.org and bar.com are masqueraded.

NOTE: only domains within your jurisdiction and current hierarchy should be masqueraded using this.

local_relay

DEPRECATED. Use mailhub instead. The site that will handle unqualified names -- that is, names with out an @domain extension. If not set, they are assumed to belong on this machine. This allows you to have a central site to store a company- or department-wide alias database. This only works at small sites, and only with some user agents.

luser_relay

The site that will handle lusers -- that is, apparently local names that aren't local accounts or aliases (with other words: it handles all unkown users).
Any of these can be either mailer:hostname (in which case the mailer is the internal mailer name, such as smtp and the hostname is the name of the host as appropriate for that mailer) or just a hostname, in which case a default mailer type (usually relay, a variant on SMTP) is used. WARNING: if you have a wildcard MX record matching your domain, you probably want to define these to have a trailing dot so that you won't get the mail diverted back to yourself. local:foo would forward all mail to any-unknown-user@localdomain.com to local user foo.

max_message_size

The maximum size of messages that will be accepted (in bytes). Leave empty if you do not want to impose a limit.

me_too

[False] Include sender in group expansions.

ident timeout

The timeout waiting for a response to an IDENT query. If you have a timeout problem when someone connects to your mailserver and it is not DNS related it's probably the ident lookup that fails. That means, it's only a problem if it times out, not if it fails immediately because the connection was rejected. Set the timeout to 0 and see if that helps.

dial delay

If a connection fails, wait this long and try again. Zero means "don't retry". This is to allow "dial on demand" connections to have enough time to complete a connection.

redirect

Reject all mail addressed to "address.REDIRECT" with a 551 User not local; please try <address> message. If this is set, you can alias people who have left to their new address with ".REDIRECT" appended, so that everyone who sends a message to the old address (on your mailserver) gets a message taht informs them about the address change.

stickyhost

If set, email sent to "user@local.host" are marked as "sticky" -- that is, the local addresses aren't matched against userdb and don't go through ruleset 5. This is used if you want a set up where "user" is not necessarily the same as "user@local.host", e.g., to make a distinct domain-wide namespace. Prior to 8.7 this was the default, and notsticky was used to turn this off.

always_add_domain

Include the local host domain even on locally delivered mail. Normally it is not added on unqualified names. However, if you use a shared message store but do not use the same user name space everywhere, you may need the host name on local names.

bestmx_is_local

Accept mail as though locally addressed for any host that lists us as the best possible MX record. This generates additional DNS traffic, but should be OK for low to medium traffic hosts. The argument may be a set of domains, which will limit the feature to only apply to these domains -- this will reduce unnecessary DNS traffic. THIS FEATURE IS FUNDAMENTALLY INCOMPATIBLE WITH WILDCARD MX RECORDS!!! If you have a wildcard MX record that matches your domain, you cannot use this feature.

local_users

If you forward all local mail to a mailhub but want some users to be delivered locally (e.g. root), specify those usernames you'd like to have delivered locally here.

exposed_users

If masquerading is on there are some usernames (e.g. root, so that you can later trace any error messages sent to you by the system to the machine that caused it) that you might want to exclude from masquerading. Specify them here.

Masquerading and Relaying

You can have your host masquerade as another using masquerade_as

This causes mail being sent to be labeled as coming from the indicated host.domain, rather than the FQDN of the local host. One normally masquerades as one of one's own subdomains (obvious, why would you want to have somebody elses domain in your From:-address?). This behaviour is modified by a plethora of features; in particular, see masquerade_envelope, allmasquerade, limited_masquerade, and masquerade_entire_domain.

The masquerade name is not normally canonified, so it is important that it be your One True Name, that is, fully qualified and not a CNAME (alias). However, if you use a CNAME, the receiving side may canonify it for you, so don't think you can cheat CNAME mapping this way.

Normally the only addresses that are masqueraded are those that come from this host (that is, are either unqualified or in the list of names by which you are known, the list of local domain names). You can augment this list using masquerade_domains. The effect of this is that although mail to user@otherhost.domain will not be delivered locally, any mail including any user@otherhost.domain will, when relayed, be rewritten to have the masquerade_as address.

Normally only header addresses are masqueraded. If you want to masquerade the envelope as well, use masquerade_envelope.

There are always users that need to be "exposed" -- that is, their internal site name should be displayed instead of the masquerade name. Root is an example. You can add users to this list using exposed_user.

You can also arrange to relay all unqualified names (that is, names without @host) to a relay host. For example, if you have a central email server, you might relay to that host so that users don't have to have .forward files or aliases. You can do this using local_relay.

There are some user names that you don't want relayed, perhaps because of local aliases. A common example is root, which may be locally aliased. You can add entries to this list using local_users.

If you want all incoming mail sent to a centralized hub, as for a shared /var/spool/mail scheme, use mail_hub.

If you define both local_relay and mail_hub AND you have enabled stickyhost, unqualified names will be sent to the local_relay and other local names will be sent to mail_hub. Names in local_users will be delivered locally, so you MUST have aliases or .forward files for them.

For example, if you are on machine mastodon.CS.Berkeley.EDU and you have enabled stickyhost, the following combinations of settings will have the indicated effects:

email sent to....	eric	eric@mastodon.CS.Berkeley.EDU
LOCAL_RELAY set to mail.CS.Berkeley.EDU	mail.CS.Berkeley.EDU (no local aliasing)	(delivered locally) (aliasing done)
MAIL_HUB set to mammoth.CS.Berkeley.EDU	mammoth.CS.Berkeley.EDU (aliasing done)	mammoth.CS.Berkeley.EDU (aliasing done)
Both LOCAL_RELAY and MAIL_HUB set as above	mail.CS.Berkeley.EDU (no local aliasing)	mammoth.CS.Berkeley.EDU (aliasing done)

If you do not have enabled stickyhost, then local_relay and mail_hub identically, with mails_hub taking precedence.

If you want all outgoing mail to go to a central relay site, define smarthost as well. Briefly:

local_relay applies to unqualified names (e.g., "eric").
mail_hub applies to names qualified with the name of the local host (e.g., "eric@mastodon.CS.Berkeley.EDU").
smarthost applies to names qualified with other hosts.

For duplicate suppression to work properly, the host name is best specified with a terminal dot: host.domain. (note the trailing dot)

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 promiscuous_relay. You can allow certain domains to relay through your server by adding their domain name or IP address to the relay-domains file (sendmail class 'R') or via the access database (described below).

If you use relay_entire_domain then any host in any of your local domains will be relayed (that is, you will accept mail either to or from any host in your domain).

You can also allow relaying based on the MX records of the host portion of an incoming recipient address by using 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 for relay to domain.com. 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 (that is, they set up an MX record pointing to your mail server, and you will relay mail addressed to them without any prior arrangement). Along the same lines, 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 the relay-domains file, the list of local names if relay_entire_domain is used, or the access database, if enabled. To prevent the address from being stripped down, use 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 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 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.

The table uses e-mail addresses, domain names, and network numbers as keys. For example,

	spammer@aol.com		REJECT
	cyberspammer.com	REJECT
	192.168.212		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 192.168.212.* network.

The value part of the map can contain:

OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable.

RELAY Accept mail addressed to the indicated domain or received from the indicated domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks.

REJECT Reject the sender or recipient with a general purpose message.

DISCARD Discard the message completely using the $#discard mailer. This only works for sender addresses (i.e., it indicates that you should discard anything received from the indicated domain).

### 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.
If you also use 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 the relay-domains file 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 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. Enabling this feature will keep you from sending mails to all addresses that have an error message or REJECT as value part in the access map. Taking the example from above:

	spammer@aol.com		REJECT
	cyberspammer.com	REJECT

Mail can't be sent to spammer@aol.com or anyone at cyberspammer.com.

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 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.

Original README Copyright Eric Allman <eric@sendmail.org>
this version for SWAT from SuSE (1999)
Contact (for SWAT, not sendmail): mha@suse.de

OK	Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable.
RELAY	Accept mail addressed to the indicated domain or received from the indicated domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks.
REJECT	Reject the sender or recipient with a general purpose message.
DISCARD	Discard the message completely using the $#discard mailer. This only works for sender addresses (i.e., it indicates that you should discard anything received from the indicated domain).
### any text	where ### is an RFC 821 compliant error code and "any text" is a message to return for the command.