Access Database - Used for Access Control
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 bulk e-mailers. To enable such a database, use
FEATURE(`access_db')
The access database is applied to the envelope addresses and the connection information, not to header information.
The FEATURE macro can accept as a second parameter the key file definition for the database:
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access_map')
If a second argument is specified it must contain the option `-T<TMPF>' as shown above. The optional third and fourth parameters may be `skip' or `lookupdotdomain'. The former enables SKIP as value part (see below), the latter is another way to enable the feature of the same name.
Remember, since /etc/mail/access is a database, after creating the text file as described below, you must use makemap to create the database map.
makemap hash /etc/mail/access < /etc/mail/access.input_file
Like most things in Sendmail, the access database works on the theory of left hand side and the right hand side. The left hand side, also called keys, is used for matching and the right hand side, also called values, is used for the new value.
The table itself uses e-mail addresses, domain names, and network numbers as keys. Note that IPv6 addresses must be prefaced with "IPv6:". For example,
From:spammer@aol.com REJECT From:cyberspammer.com REJECT Connect:cyberspammer.com REJECT Connect:TLD REJECT Connect:192.168.212 REJECT Connect:IPv6:2002:c0a8:02c7 RELAY Connect:IPv6:2002:c0a8:51d2::23f4 REJECT
would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), any host in the entire top level domain TLD, 192.168.212.* network, and the IPv6 address 2002:c0a8:51d2::23f4. It would allow relay for the IPv6 network 2002:c0a8:02c7::/48.
Entries in the access map should be tagged according to their type. Three tags are available:
Connect: connection information (${client_addr}, ${client_name})
From: envelope sender
To: envelope recipient
If the required item is looked up in a map, it will be tried first with the corresponding tag in front, then (as fallback to enable backward compatibility) without any tag, unless the specific feature requires a tag. For example,
From:spammer@some.dom REJECT To:friend.domain RELAY Connect:friend.domain OK Connect:from.domain RELAY From:good@another.dom OK From:another.dom REJECT
This would deny mails from spammer@some.dom but you could still send mail to that address even if FEATURE(`blacklist_recipients') is enabled. Your system will allow relaying to friend.domain, but not from it (unless enabled by other means). Connections from that domain will be allowed even if it ends up in one of the DNS based rejection lists. Relaying is enabled from from.domain but not to it (since relaying is based on the connection information for outgoing relaying, the tag Connect: must be used; for incoming relaying, which is based on the recipient address, To: must be used). The last two entries allow mails from good@another.dom but reject mail from all other addresses with another.dom as domain part.
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. "Accept" does not mean "relay", but at most acceptance for local recipients. That is, OK allows less than RELAY.
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. If it is used in check_compat, it affects only the designated recipient, not the whole message as it does in all other cases. This should only be used if really necessary.
SKIP - This can only be used for host/domain names and IP addresses/nets. It will abort the current search for this entry without accepting or rejecting it but causing the default action.
### any text - where ### is an RFC 821 compliant error code and "any text" is a message to return for the command. The string should be quoted to avoid surprises, e.g., sendmail may remove spaces otherwise. This type is deprecated, use one of the two ERROR: entries below instead.
ERROR:### any text - as above, but useful to mark error messages as such.
ERROR:D.S.N:### any text - where D.S.N is an RFC 1893 compliant error code and the rest as above.
QUARANTINE:any text - Quarantine the message using the given text as the quarantining reason.
For example:
From:cyberspammer.com ERROR:"550 We don't accept mail from spammers" From:okay.cyberspammer.com OK Connect:sendmail.org RELAY To:sendmail.org RELAY Connect:128.32 RELAY Connect:128.32.2 SKIP Connect:IPv6:1:2:3:4:5:6:7 RELAY Connect:suspicious.example.com QUARANTINE:Mail from suspicious host Connect:[127.0.0.3] OK Connect:[IPv6:1:2:3:4:5:6:7:8] OK
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 relaying mail from and to any hosts in the sendmail.org domain, and allow relaying from the IPv6 1:2:3:4:5:6:7:* network and from the 128.32.*.* network except for the 128.32.2.* network, which shows how SKIP is useful to exempt subnets/subdomains. The last two entries are for checks against ${client_name} if the IP address doesn't resolve to a hostname (or is considered as "may be forged"). That is, using square brackets means these are host names, not network numbers.
Warning: if you change the RFC 821 compliant error code from the default value of 550, then you should probably also change the RFC 1893 compliant error code to match it. For example, if you use
To:user@example.com ERROR:450 mailbox full
the error returned would be "450 5.0.0 mailbox full" which is wrong. Use "ERROR:4.2.2:450 mailbox full" instead.
Note, UUCP users may need to add hostname.UUCP to the access database or class {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} 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:
From:FREE.STEALTH.MAILER@ ERROR: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:
To:badlocaluser@ ERROR:550 Mailbox disabled for badlocaluser To:host.my.TLD ERROR:550 That host does not accept mail To:user@my.other.TLD ERROR:550 Mailbox disabled for this recipient
This would prevent a recipient of badlocaluser in any of the local domains (class {w}), any user at host.my.TLD, and the single address user@my.other.TLD from receiving mail. Please note: a local username must be now tagged with an @ (this is consistent with the check of the sender address, and hence it is possible to distinguish between hostnames and usernames). 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. That's why tagged entries should be used.
queuegroup
The following is a simple example of how to select a queue group based on the full e-mail address or the domain of the recipient. Selection is done via entries in the access map using the tag QGRP:, for example:
QGRP:example.com main QGRP:friend@some.org others QGRP:my.domain local
where "main", "others", and "local" are names of queue groups. If an argument is specified, it is used as default queue group.
greet_pause
Adds the greet_pause ruleset which enables open proxy and SMTP slamming protection. The feature can take an argument specifying the milliseconds to wait:
FEATURE(`greet_pause', `5000') dnl 5 seconds
If FEATURE(`access_db') is enabled, an access database lookup with the GreetPause tag is done using client hostname, domain, IP address, or subnet to determine the pause time:
GreetPause:my.domain 0 GreetPause:example.com 5000 GreetPause:10.1.2 2000 GreetPause:127.0.0.1 0
When using FEATURE(`access_db'), the optional FEATURE(`greet_pause') argument becomes the default if nothing is found in the access database. A ruleset called Local_greet_pause can be used for local modifications, e.g.,
LOCAL_RULESETS
SLocal_greet_pause
R$* $: $&{daemon_flags}
R$* a $* $# 0
The Alias Database - Used to rewrite recipient addresses and for mailing lists
The alias database serves a couple of useful purposes. It allows you to associate another name for a user on your system. This is how you do things like map alan.pae@emailaddress.com to the Unix user account, alan. Any message sent to firstname.lastname will actually end up in the mailbox for alan since you can't create firstname.lastname accounts on a Unix system.
This can also be thought of as inbound message routing. When someone sends an e-mail message to a domain name, Sendmail looks up the mail exchange records for that domain and sends the message to the host listed. The host that accepts that message can then deliver it to the user account as mentioned above, or simply send it on to another username, hostname, or both.
Let's say that any message destined for the domain name, somedomain.com, will be sent to the host named, somehost.somedomain.com. Somehost.somedomain.com has an alias file that directs that any e-mail message destined for alan.pae@somedomain.com should in fact be sent to alan@emailaddress.com. Any messages that are addressed to alan.pae@somedomain.com are now redirected to alan@emailaddress.com instead. Depending on emailaddress.com's policy, the message could either go through the process all over again, or could be bounced as undeliverable.
If you're going to implement inbound message routing, any host that could potentially accept mail on behalf of the domain needs to have the same alias information, otherwise problems will occur. It is common to use a naming service such as NIS or LDAP to provide an alias file to all the hosts in your domain or subdomain. Doing this ensures that all hosts have the same information.
If your network is not running a name service then the /etc/mail/aliases file of each system should contain entries for all of the mail clients. You can either edit the file on each system or edit the file on one system and copy it to each of the other systems. The aliases in the /etc/mail/aliases file are stored in text form. When you edit the /etc/mail/aliases file, you need to run the newaliases program to recompile the database and make the aliases available in binary form to the Sendmail program.
You can use the mailing list feature in the Solaris Management Console to perform these tasks on the aliases database.
In order for Sendmail to actually deliver a message it actually needs three things:
The mailer
The host
The address
After recipient addresses are read from the SMTP connection or from the command line they are parsed by ruleset 0, which must resolve to a (mailer, host, address) triple. If the flags selected by the mailer include the A (aliasable) flag, the address part of the triple is looked up as the key (the left hand side) in the alias database. If there is a match, the address is deleted from the send queue and all addresses on the right hand side of the alias are added in place of the alias that was found. This is a recursive operation, so aliases found in the right hand side of the alias are similarly expanded. This process continues until no more matches are made.
The alias database exists in two forms. One is a text form, maintained in the file /etc/mail/aliases. The aliases are of the form:
name: name1, name2, ...
In theory, only local names (those on the left hand side) may be aliased.
Aliases may be continued by starting any continuation lines with a space or a tab or by putting a backslash directly before the newline. Blank lines and lines beginning with a sharp sign are comments.
The second form is the result of the alias file being processed by the ndbm or the Berkeley DB library. This form results in the file /etc/mail/aliases.db (if using NEWDB) or /etc/mail/aliases.dir and /etc/mail/aliases.pag (if using NDBM) being created. This is the form that Sendmail actually uses to resolve aliases. This technique is used to improve performance.
The control of the search order is actually set by the service switch file. On Solaris this file is /etc/nsswitch.conf.
If the service switch file contains
aliases: nis files nisplus
then aliases will first be searched in the NIS database, then in /etc/mail/aliases, then in the NIS+ database.
To use NIS based aliases see the second line shown below:
O AliasFile=/etc/mail/aliases
O AliasFile=nis:mail.aliases@my.nis.domain
will first search the /etc/mail/aliases file and then the map named "mail.aliases" in "my.nis.domain".
Warning: if you build your own NIS-based alias files, be sure to provide the -l (lowercase el) flag to makedbm to map upper case letters in the keys to lower case; otherwise, aliases with upper case letters in their names won't match incoming addresses.
The hash or dbm version of the database may be rebuilt explicitly by executing the command
newaliases
This is equivalent to giving Sendmail the -bi command line switch:
/usr/sbin/sendmail -bi
If you have multiple aliases databases specified, the -bi flag rebuilds all the database types it understands (it can rebuild NDBM databases but not NIS databases).
To verify aliases and to confirm that mail can or cannot be delivered to a specified recipient, follow these instructions:
% /usr/lib/sendmail -v -bv recipient
Substitute recipient with any local user.
This displays the aliases and identifies that the final address is deliverable or not deliverable.
Any alias that is established in the /etc/mail/aliases file can be used by any user who knows the name of the alias.
All alias databases must include an entry for postmaster. Entries should also exist for MAILER-DAEMON and abuse. Postmaster is analogous to a normal post offices postmaster.
This is the person responsible for everything that happens to the mail server. Postmaster must resolve to a real user account. MAILER-DAEMON is used to send out error messages. Abuse is used for things such as unsolicited commercial e-mail. If someone wants to report an abuse of your mail server, this is the address those messages should be sent to.
Normally, only the root user can edit /etc/mail/aliases. However, when you use the Administration Tool, all users in group 14, which is the sysadmin group, can change the local file.
The other thing the alias database can be use for is mailing lists. Mailing lists use the following format:
aliasname: recipient, recipient, recipient
aliasname is the name that the user uses when sending mail to this alias, and recipient is a valid e-mail address. You could also use:
aliasname: :include:/path/aliasfile
aliasname is the name that the user uses when sending mail, and /path/aliasfile is the full path to the file that contains the alias list. The alias file should include e-mail entries, one entry on each line, and no other notations.
user1@host1
user2@somedomain.com
You can have Sendmail write the message to a file instead of sending them to a user account. To do this, use:
aliasname: /home/backup/filename
You can also route the mail to another program. The following example shows you how to send the message to a program:
aliasname: |/path/to/program
Any lhs address in the alias database can deliver mail to a user account, file, or program using the techniques described above.
When setting up mailing lists it is beneficial to setup owners for each list that you define. In the alias file this would look like:
mailing_list_name: :include:/mail/list/sports/football owner-mailing_list_name: /path/to/bounce/file mailing_list_name-request: user
If any of the messages bounce, instead of sending the bounce messages back to the sender, Sendmail will send it to the owner of the list if one is listed.
In this situation, the owner of the list is listed as a file. You could write a script that extracts the name of the recipient from this file and then remove him/her from the mailing lists list of users. If you don't care about bounced messages, simply send them to /dev/null.
The entry for mailing_list_name-request defines the user who is in charge of administering that mailing list.
Normally, aliasing requires that the lhs has to be a local user account. You can change this behavior to include remote addresses by using:
MODIFY_MAILER(`smtp',`+A')
or you could use the virtuser table instead.
And finally, mailing lists can contain the name of other mailing lists.
Generics Table - Used to rewrite the sender's address
This feature will cause unqualified addresses (i.e., without a domain) and addresses with a domain listed in class {G} to be looked up in a map and turned into another ("generic") form, which can change both the domain name and the user name. Notice: if you use an MSP (as it is default starting with 8.12), the MTA will only receive qualified addresses from the MSP (as required by the RFCs). Hence you need to add your domain to class {G}. The same types of addresses used 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 class {G}; entries can be added to this class by the macros GENERICS_DOMAIN or GENERICS_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE).
The argument of FEATURE(`genericstable') may be the map definition; the default map definition is:
hash /etc/mail/genericstable
The key for this table is either the full address, the domain (with a leading @; the localpart is passed as first argument) or the unqualified username (tried in the order mentioned); 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 $j or the masquerade name. Note that the address being looked up must be fully qualified. For local mail, it is necessary to use FEATURE(`always_add_domain') for the addresses to be qualified. The "+detail" of an address is passed as %1, so entries like
old+*@foo.org new+%1@example.com gen+*@foo.org %1@example.com
and other forms are possible.
FEATURE(`generics_entire_domain')
If the genericstable is enabled and GENERICS_DOMAIN or GENERICS_DOMAIN_FILE is used, this feature will cause addresses to be searched in the map if their domain parts are subdomains of elements in class {G}.
Mailer Table - Use a different mailer
Include a "mailer table" which can be used to override routing for particular domains (which are not in class {w}, i.e. local host names). The argument of the FEATURE may be the key definition such as
FEATURE(`mailertable', `hash /etc/mail/mailertable')
Keys in this database are fully qualified domain names or partial domains preceded by a dot -- for example, "mail.emailaddress.com" or ".emailaddress.com". As a special case of the latter, "." matches any domain not covered by other keys. Values must be of the form:
mailer:domain
where "mailer" is the internal mailer name, and "domain" is used to define where to send the message. These maps are not reflected into the message header.
local:user
will forward the message 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
error:D.S.N:code message
will give an error message with the indicated SMTP reply code and message, where D.S.N is an RFC 1893 compliant error code.
To use FEATURE(`mailertable'), you will have to create an external database containing the routing information for various domains. For example, a mailertable file in text format might be:
.my.domain xnet:%1.my.domain .bitnet smtp:relay.bitnet
The semantics are simple. Any LHS entry that does not begin with a dot matches the full qualified host name indicated. LHS entries beginning with a dot match anything ending with that domain name (including the leading dot). Matching is done in order of most-to-least qualified. Sendmail will try to match the most explicit entry in the database.
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.
Note: e-mail to "user@my.domain" does not match any entry in the above table. You need to have something like:
my.domain esmtp:host.my.domain
This should normally be stored in /etc/mail/mailertable. The actual database version of the mailertable is built using:
makemap hash /etc/mail/mailertable < /etc/mail/mailertable.input_file
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.
Userdb - Used to rewrite the recipient's addresses - Similar to the aliases database
According to the Sendmail Installation and Operations Guide the User Database has been deprecated. You should use the virtual user table or the generics table to handle the functions that were once handled by this database.
Virtual User Table - Used for virtual hosting or handling multiple domains
A domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine. For example, if the virtuser table contains:
info@foo.com foo-info info@bar.com bar-info joe@bar.com error:nouser 550 No such user here jax@bar.com error:5.7.0:550 Address invalid @baz.org jane@example.net
then mail addressed to info@foo.com will be delivered to 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@example.net, mail to joe@bar.com will be rejected with the specified error message, and mail to jax@bar.com will also have a RFC 1893 compliant error code 5.7.0.
The username from the original address is passed as %1 allowing:
@foo.org %1@example.com
meaning someone@foo.org will be sent to someone@example.com. Additionally, if the local part consists of "user+detail" then "detail" is passed as %2 and "+detail" is passed as %3 when a match against user+* is attempted, so entries like
old+*@foo.org new+%2@example.com gen+*@foo.org %2@example.com +*@foo.org %1%3@example.com X++@foo.org Z%3@example.com @bar.org %1%3
and other forms are possible. Note: to preserve "+detail" for a default case (@domain) %1%3 must be used as RHS. There are two wildcards after "+": "+" matches only a non-empty detail, "*" matches also empty details, e.g., user+@foo.org matches +*@foo.org but not ++@foo.org. This can be used to ensure that the parameters %2 and %3 are not empty.
All the host names on the left hand side (foo.com, bar.com, and baz.org) must be in class {w} or class {VirtHost}. The latter can be defined by the macros VIRTUSER_DOMAIN or VIRTUSER_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE). If VIRTUSER_DOMAIN or VIRTUSER_DOMAIN_FILE is used, then the entries of class {VirtHost} are added to class {R}, i.e., relaying is allowed to (and from) those domains. The default map definition is:
hash /etc/mail/virtusertable
A new definition can be specified as the second argument of the FEATURE macro, such as
FEATURE(`virtusertable', `dbm /etc/mail/virtusers')
FEATURE(`virtuser_entire_domain')
If the virtusertable is enabled and VIRTUSER_DOMAIN or VIRTUSER_DOMAIN_FILE is used, this feature will cause addresses to be searched in the map if their domain parts are subdomains of elements in class {VirtHost}.
To setup a catch all address for your domain create the virtuser table and then create an entry to /workfiles/virtusertable such as:
@yourdomain.tld some_local_user_account
Then build the virtusertable map:
makemap hash /etc/mail/virtusertable < /workfiles/virtusertable