Browse All Articles > Practical Modern Sendmail Configuration
This Article is a re-write of the PAQ I wrote before EE had Articles. The original is at
http://www.experts-exchange.com/Software/Server_Software/Email_Servers/SendMail/Q_21322113.html
Unless otherwise noted, the book/chapter/page references are to Sendmail 3rd Edition by Bryan Costales, ISBN 1-56592-839-3, available at your fave local bookstore or online. At over 1,200 pages, it can be an intimidating reference, but once you learn your way around, its a good resource for the sendmail admin.
In this Article are several types of resources:
A few assumptions have been made for these materials:
If your system varies from these, then:
And finally, don't forget to create a backup of your original sendmail.mc and/or sendmail.cf (and any support files or databases) before making radical changes.
This sendmail.mc file is generally applicable to an E-Mail relay host, where the host receives E-mail for one or more Domains, and relays it to hosts inside the network (ones that are probably not directly reachable from the Internet), based on the virtualusertable and/or mailertable databases. The relay-domains and local-host-names files are quite specifically not used. relay-domains ( aka Class {R}) effectively bypasses the RBLs, and since there is no local delivery, the relay has no "local" names.
This host also would accept E-Mail relays from those internal hosts and send the E-Mail out to the Internet ( i.e. functions as a "smart" host); possibly re-writing headers while doing so (based on the genericstable database). This host has no local user accounts and does not deliver mail locally.
Features of this sendmail.mc file include 6 RBLs (you should verify that all are usable for you, and drop any that aren't), a number of other helpful anti-SPAM settings and configurations, sendmail database support, and message-size and queue-processing limits. Other features that could be added might include Load Average checking ( RefuseLA and QueueLA), MILTERs and SMTP-TLS/SMTP-AUTH support; these are left as an exercise to the reader.
If settings like the maximum number of children, messages processed per queue run, maximum message size, or whatever seem too low (or high) for your environment, feel free to increase (or decrease) them - these are just some suggested numbers for those parameters, nothing is carved in stone.
This access database file is generally applicable to an E-Mail relay host, where the host receives E-mail for one or more Domains, and relays it to hosts inside the network. The main functions of this sample database are:
Your specific environment may not require all of these things. At a minimum, if you use the RBL features in sendmail, you should use entries with the Connect: keyword to permit your internal hosts to bypass RBL checks. Otherwise you're going to be constantly making DNS requests to the various RBL servers, for your own hosts, which is kinda pointless.
Also, if you use the RBL features, I highly recommend that you have an E-Mail address that even RBLed senders can reach - this E-Mail address should not appear on any web-pages or anywhere else it might be easily harvested; and should probably be an alias on an interior machine. Spammers won't be checking the RBL error messages, so they won't see the address. Legit senders will get the info if their E-Mail system isn't brain-dead and strips it.
Finally, don't forget to allow relay for the Domains you host. Checking based on the To: header is appropriate because if an E-Mail is From: one of those Domains, the sending server will have been permitted to RELAY with the earlier Connect: entries. This helps prevent spammers from relaying by pretending to be sending from a Domain you host.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
This alias database file is generally applicable to an E-Mail relay host, where there are no local accounts and no need for local mail delivery. This makes for a very short file.
Changes to this database are not effective until the database is re-built using makemap - this is typically accomplished using the newaliases command, which is a link to sendmail. sendmail will determine that is was invoked using newaliases and will invoke makemap as needed. You could also run makemap separately. After re-building, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
This is domaintable, generally used when moving from one Domain Name to another. As a rule, most places do not need a domaintable, altho there is no harm in creating a blank (but documented) one.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
This genericstable database file is generally applicable to an E-Mail relay host. The purpose is to instruct sendmail to re-write the SMTP headers for outgoing E-Mail. There are several possible reasons you might wish to do this; for example, if your internal usernames are limited to 8 characters, but users want a firstname.lastname format for their E-Mail addresses, it's easy enough to do that for incoming E-Mail using virtualusertable or an aliases database, but outgoing E-Mail is not affected by those things. Or if a mail recipient is planning to move from one Domain you host to another, this can make the change seem to have taken place before it actually does.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
This sample mailertable database is generally applicable to a relay host, and may even be required to make mail route properly. Basically, a mailertable instructs sendmail on how to route an E-mail based on the destination Domain. The mailertable is consulted when sendmail has determined that an E-mail is destined for a Domain for which it relays, and after the virtualusertable has been consulted (so if userA@DomainOne.tld maps to UserZ@domainX.tld, that will happen first).
The syntax is similar to other databases - a left-hand, or key side that is used to match, and then a right-hand, or result side that determines what it to be done. In the case of mailertable, the left-hand keys are hostnames or Domain names. The first one that matches is the one that is used, so you will probably want to list them starting with more-specific hostnames and then put the less-specific Domain names after those, if that is appropriate for your environment.
The right-hand result consist of two parts, a mailer specification and a hostname, separated by a colon (however, no whitespace should be in either side, only between the key and result). By enclosing the hostname of the right-hand result in square brackets, you instruct sendmail to not perform an MX record lookup for the host, but instead use the A record. This helps prevent mail loops. For example, if mail1.somedomain.tld was the Mail eXchanger for somedomain.tld and individual hosts in somedomain.tld did not have MX records, then when an E-Mail arrived at mail1.somedomain.tld and mailertable indicated that the final destination was userbox.somedomain.tld, the normal address resolution that sendmail would use would result in the mail being sent to mail1.somedomain.tld - a loop. By turning off that MX lookup, the loop is avoided. The result can also be an IP address.
The mailer types can be anything that sendmail supports; in this example, smtp is used for all instances.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
This sample virtual user table ( virtusertable) database is generally applicable to a relay host, and can greatly reduce the administrative overhead of a multi-Domain environment. The virtusertable instructs sendmail on how to map INbound E-mail from one address to another. It's consulted after the aliases file, but before mailertable. So virtusertable tells sendmail where an E-Mail needs to go, but not how to get it there.
The syntax is similar to other databases - a left-hand, or key side that is used to match, and then a right-hand, or result side that determines with what the original value will be replaced. The left-hand keys can either be full E-Mail addresses, or Domain names (when preceeded with an "@"). Again, the first key to match is used, so the more-specific entries should perhaps be first. If a match is not found on the first pass, sendmail will attempt to pare down the hostname it is trying to match (so bob@mail.anotherdomain.tld
The right-hand result consists of the new E-Mail address for delivery, but it is important to note that the headers are not re-written. So the receiving host must not be too picky about the To: E-Mail address in the message headers. Also, some substitutions are possible, more than are shown here. In the sample file, an E-mail for joe@hosteddomain.tld would be directed to joe@userbox.somedomain.tld
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
Based on the sendmail.mc above, the following files should exist in /etc/mail. In some cases, as noted in sendmail.mc, the existence is optional - sendmail will still check for optional files, but will silently fail if they are not found (as opposed to generating an error message and complaining). Unlike the database files in Resources #2-7, these files are simple text files, and their "records" are one domain or username per line in the file. Comments are not supported in these files. They are read when sendmail starts up, and changes are not effective until sendmail is restarted. The files are:
genericdomains
trusted-users
virtuser.domains
local-host-names
relay-domains
This topic is discussed in greater depth, and with newer updates, in my paper entitled Practical Modern sendmail Configuration (which was originally based off the original PAQ that sources this Article). Visit my EE Profile to find a link to my website and the paper.
Unless otherwise noted, the book/chapter/page references are to Sendmail 3rd Edition by Bryan Costales, ISBN 1-56592-839-3, available at your fave local bookstore or online. At over 1,200 pages, it can be an intimidating reference, but once you learn your way around, its a good resource for the sendmail admin.
In this Article are several types of resources:
annotated
sendmail.mc files
sample
sendmail database files
helpful maintenance scripts
A few assumptions have been made for these materials:
0)
sendmail is already appropriately-compiled for your system, is properly installed, and runs without choking
1) a modern version of
sendmail is being used (v8.12.10 or later; latest as of this writing is v8.14.4); if you're running an older version, it's outdated, probably vulnerable, and shouldn't be connected to the Internet
2)
sendmail is being run on a UNIX, Linux or UNIX-like (
e.g. AIX) system
3)
sendmail has been compiled with Berkeley DB (
http://www.sleepycat.com) support
4) the production mail system configuration files and databases are stored in
/etc/mail
5) the admin has access to the m4 macros appropriate to their sendmail version (as an example, the typical Sun supplied-with-Solaris version of sendmail lacks the m4 macros needed to use the information below)
If your system varies from these, then:
0) Building and installing
sendmail can vary significantly by platform, and so is out of the scope of this Article
1) If you're not running a modern version, then
STOP - go install a modern version, then return here
2) If you're running
sendmail on Windoze or similar brain-dead OSes, you may be able to interpolate a lot of this info to your system, but I'm not responsible for anything that breaks....get a real OS
3) Berkeley DB support is not an absolute must-have; you can use
hash in place of
dbm in the appropriate lines in the configuration files and scripts below and it should work with
most environments
4) Locations other than
/etc/mail are, of course, just dandy; don't forget to tweak the files/scripts as appropriate
5) If your vendor-supplied version of
sendmail is old/outdated or doesn't include all the parts, complain to your vendor, and then go get the sources and build it so you have all the parts
And finally, don't forget to create a backup of your original sendmail.mc and/or sendmail.cf (and any support files or databases) before making radical changes.
Resource #1: sendmail.mc for mail relay (multiple domains, light-to-moderate traffic)
This sendmail.mc file is generally applicable to an E-Mail relay host, where the host receives E-mail for one or more Domains, and relays it to hosts inside the network (ones that are probably not directly reachable from the Internet), based on the virtualusertable and/or mailertable databases. The relay-domains and local-host-names files are quite specifically not used. relay-domains ( aka Class {R}) effectively bypasses the RBLs, and since there is no local delivery, the relay has no "local" names.
This host also would accept E-Mail relays from those internal hosts and send the E-Mail out to the Internet ( i.e. functions as a "smart" host); possibly re-writing headers while doing so (based on the genericstable database). This host has no local user accounts and does not deliver mail locally.
Features of this sendmail.mc file include 6 RBLs (you should verify that all are usable for you, and drop any that aren't), a number of other helpful anti-SPAM settings and configurations, sendmail database support, and message-size and queue-processing limits. Other features that could be added might include Load Average checking ( RefuseLA and QueueLA), MILTERs and SMTP-TLS/SMTP-AUTH support; these are left as an exercise to the reader.
If settings like the maximum number of children, messages processed per queue run, maximum message size, or whatever seem too low (or high) for your environment, feel free to increase (or decrease) them - these are just some suggested numbers for those parameters, nothing is carved in stone.
divert(-1)dnl
dnl # * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
dnl # Author: A-NAME-HERE
dnl # File: /some/path/sendmail.mc
dnl # Change Log:
dnl # Who When What
dnl # ---- ----------- --------------------------------------------
dnl #
dnl #
dnl #
dnl #
dnl # NOTES: Sendmail book (Chap 4.2.3, page 155) states recommended
dnl # order of entries in .mc file; see Chap 4.1.2 (Page 147)
dnl # concerning "dnl"
dnl #
dnl # * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
divert(0)dnl
dnl # Sendmail, Chap 4.2.3.1, Page 155
VERSIONID(`$Id: sendmail.mc, v8.1X.Y 2005/MM/DD HH:MM:SS NAME Exp $')dnl
dnl # Sendmail, Chap 4.2.2.1, Page 152
OSTYPE(YOUR-OS-HERE)dnl
dnl # Sendmail, Chap 4.2.2.3, Page 152
DOMAIN(generic)dnl
######################
## Optional Definitions Section ##
######################
dnl # Sendmail, Chap 24.9.8, Page 951
dnl # As an anti-SPAM measure, instruct daemon that after a sending host
dnl # gives more than one RCPT TO: for a non-existent/invalid destination,
dnl # throttle the connection by delaying the "550 user unknown" reply
define(`confBAD_RCPT_THROTTLE',`1')dnl
dnl # Sendmail, Chap 24.9.91, Page 1043
dnl # Tune DNS options to work around broken AAAA records (IPv6)
dnl # Not needed if you build sendmail without IPv6 support
define(`confBIND_OPTS',`WorkAroundBrokenAAAA')dnl
dnl # Sendmail, Chap 24.9.13, Page 955
dnl # Force daemon to re-write queue control file after successful delivery
dnl # to 5 recipients; this will minimize duplicates if the daemon is
dnl # interrupted during a delivery
define(`confCHECKPOINTINTERVAL',`5')dnl
dnl # Sendmail, Chap 24.9.21, Page 960
dnl # Instruct daemon to throttle acceptance of new connections if more
dnl # than 5 new connections arrive in 1 second
define(`confCONNECTION_RATE_THROTTLE',`5')dnl
dnl # Sendmail, Chap 24.9.26, Page 967
dnl # Send E-Mail that double-bounces, and is directed to no local
dnl # recipient, to /dev/null
define(`confDEAD_LETTER_DROP',`/dev/null')dnl
dnl # Sendmail, Chap 24.9.32, Page 973
dnl # Set Delivery Mode to "background" ("interactive" used for debugging)
define(`confDELIVERY_MODE',`background')dnl
dnl # Sendmail, Chap 24.9.25, Page 967
dnl # Specify the maximum size, in bytes, of buffered df* files (default is
dnl # 4096 bytes; 0 turns this off and is not recommended)
define(`confDF_BUFFER_SIZE',`16384')dnl
dnl # Sendmail, Chap 24.9.41, Page 993
dnl # Return error messages that bounce (a double-bounce) to User ID
dnl # "nobody" (will eventually be routed to /dev/null)
define(`confDOUBLE_BOUNCE_ADDRESS',`nobody')dnl
dnl # Sendmail, Chap 24.9.60, Page 1011
dnl # Instruct daemon to stop spawning new children when 25 children already
dnl # exist (note that this can enable a DoS attack)
define(`confMAX_DAEMON_CHILDREN',`25')dnl
dnl # Sendmail, Chap 24.9.63, Page 1013
dnl # Limit maximum size, in bytes, of any given E-Mail to 10 MB
dnl # (10485760 bytes) - checked if sender reports and again at end of DATA
define(`confMAX_MESSAGE_SIZE',`10485760')dnl
dnl # Sendmail, Chap 24.9.66, Page 1016
dnl # Set the upper limit on the number of messages that may be processed
dnl # during any single queue run to 100
define(`confMAX_QUEUE_RUN_SIZE',`100')dnl
Sendmail, Chap 24.9.67, Page 1016
dnl # As an anti-SPAM measure, limit the number of recipients per mail
dnl # envelope to 100 (over the limit tells sending host to defer - 5XX - to later
dnl # for just those addresses over the limit)
define(`confMAX_RCPTS_PER_MESSAGE',`100')dnl
dnl # Sendmail, Chap 24.9.19, Page 959
dnl # Turn on connection caching and limit maximum number of simultaneous
dnl # outbound connections kept open to 1; default is 2; this option also
dnl # depends on MCI_CACHE_TIMEOUT (below)
define(`confMCI_CACHE_SIZE',`1')dnl
dnl # Sendmail, Chap 24.9.19, Page 959
dnl # Set time limit on how long a cached outbound connection may be
dnl # kept open to 120 seconds (2 minutes) - see MCI_CACHE_SIZE above
define(`confMCI_CACHE_TIMEOUT',`120s')dnl
dnl # Sendmail, Chap 24.9.72, Page 1022
dnl # Force messages that are not delivered on the first try to wait a
dnl # minimum of 15 minutes before being processed for another delivery
dnl # attempt (keeps the same failed messages from clogging system)
define(`confMIN_QUEUE_AGE',`15m')dnl
dnl # Sendmail, Chap 24.9.75, Page 1024
dnl # Instruct daemon that if an envelope does not have at least one
dnl # "Recipient:" header, then add a "To: undisclosed-recipients;" header
dnl # to the E-Mail (this can legitmately happen if all recipients are BCCd)
define(`confNO_RCPT_ACTION',`add-to-undisclosed')dnl
dnl # Sendmail, Chap 24.9.78, Page 1027
dnl # Define the name and path of the daemon's PID file
define(`confPID_FILE',`/some/path/sendmail-mta.pid')dnl
dnl # Sendmail, Chap 24.9.80, Page 1029
dnl # Privacy/Security settings
dnl # needmailhelo - require sending host to issue HELO/EHLO before conversing
dnl # noexpn - disable name expansion command
dnl # novrfy - disable SMTP Verify command
dnl # noverb - disable SMTP Verbose mode
dnl # authwarnings - enable "X-Authentication-Warning:" headers
dnl # noetrn - disable client ability to force queue run
dnl # restrictmailq - restrict who can view mail queue
dnl # restrictqrun - restrict who can force a queue run
define(`confPRIVACY_FLAGS', `needmailhelo,noexpn,novrfy,noverb,authwarnings,noetrn,restrictmailq,restrictqrun')dnl
dnl # Sendmail, Chap 24.9.93, Page 1045
dnl # Instruct daemon to convert "Return-Receipt-To:" header to a DSN (RFC 3461 and RFC 3464)
dnl # NOTIFY=SUCCESS request (omitted boolean parameter defaults to "true")
define(`confRRT_IMPLIES_DSN')dnl
dnl # Sendmail, Chapter 24.9.107, Page 1057
dnl # Force MTA to queue each message, even for local delivery, and to sync
dnl # to disk before forking (do not use "interactive" with
dnl # "background" delivery mode)
define(`confSAFE_QUEUE',`true')dnl
dnl # Sendmail, Chap 24.9.109.13, Page 1065
dnl # Disable IDENT (RFC 1413) calls/turn off sending user-host verification
define(`confTO_IDENT',`0')dnl
dnl # Sendmail, Chap 24.9.109.18, Page 1066
dnl # Set a timeout of 3 days before a message that has not been
dnl # successfully delivered is returned to the sender as undeliverable
dnl # (default is 5 days)
define(`confTO_QUEUERETURN',`3d')dnl
dnl # Sendmail, Chap 24.9.109.19, Page 1067
dnl # Set a timeout of 6 hours (24 attempts) before a message that has not
dnl # been delivered generates a warning to the sender that it hasn't been
dnl # delivered yet (default is 4 hours)
define(`confTO_QUEUEWARN',`6h')dnl
dnl # Sendmail, Chap 24.9.120, Page 1077
dnl # Specify the maximum size, in bytes, of buffered xf* files (default is
dnl # 4096 bytes; 0 turns this off and is not recommended)
define(`confXF_BUFFER_SIZE',`16384')dnl
################
## Features Section ##
################
dnl # Disable the following features
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dnl
undefine(`DECNET_RELAY')dnl
undefine(`FAX_RELAY')dnl
dnl # Sendmail, Chap 7.5, Page 311
dnl # Turn on Access DB to accept/reject mail from selected sites, and
dnl # specify database type, path and name; "-o" makes it optional and
dnl # "-T<TMPF>" parameter instructs daemon to return SMTP 4xy codes
dnl # for temporary errors
FEATURE(`access_db',`dbm -o -T<TMPF> /etc/mail/access')dnl
dnl # Sendmail, Chap 7.5.5, Page 317
dnl # Allow blacklisting to be done on a per-recipient basis
FEATURE(blacklist_recipients)dnl
dnl # Sendmail, Chap 7.5.6, Page 318
dnl # Change order of relay checks (requires "access_db" feature above)
dnl # to check SMTP RCPT TO: first, then SMTP MAIL FROM:, and finally
dnl # the host (via access_db and RBLs) - "friend" keyword allows
dnl # entries in access_db to override RBLs and "n" turns off
dnl # backwards-compatibility with earlier versions of sendmail
dnl # This allows creation of specific entries in the access database
dnl # that bypass the RBLs (for example, an "abuse" alias, or the
dnl # address in the custom reject messages below)
FEATURE(`delay_checks',`friend',`n')dnl
dnl # Sendmail, Chap 7.2.1, Page 296
dnl # RBL lookup failures will be treated as not blacklisted (i.e. setting
dnl # is to "fail friendly")
dnl # Activate default DNS blacklist (mail-abuse.org)
FEATURE(dnsbl)dnl
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add SpamHaus BL with custom reject message
FEATURE(`enhdnsbl',`sbl.spamhaus.org',`"ACCESS DENIED. Mail from " $&{client_addr} " refused based on information from http://www.spamhaus.org/SBL"')dnl
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add ORDB BL with custom reject message
FEATURE(`enhdnsbl',`relays.ordb.org',`"ACCESS DENIED. Mail from " $&{client_addr} " refused based on information from http://www.ordb.org"')dnl
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Added NJABL BL with custom reject message
FEATURE(`enhdnsbl',`dnsbl.njabl.org',`"ACCESS DENIED. Mail from " $&{client_addr} " refused based on information from http://njabl.org"')dnl
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add AbuseAt BL with custom reject message
FEATURE(`enhdnsbl',`cbl.abuseat.org',`"ACCESS DENIED. Mail from " $&{client_addr} " refused based on information from http://cbl.abuseat.org"')dnl
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add SpamCop BL with custom reject message
FEATURE(`enhdnsbl',`bl.spamcop.net',`"ACCESS DENIED. Mail from " $&{client_addr} " refused based on information from http://spamcop.net/bl.shtml?"$&{client_addr}')dnl
dnl # Sendmail, Chap 4.8.16, Page 181
dnl # Turn on Generics mapping and specify database type, path and
dnl # name; "-o" makes it optional (used for re-writing FROM of outgoing
dnl # mail)
FEATURE(`genericstable',`dbm -o /etc/mail/genericstable')dnl
dnl # Sendmail, Chap 4.8.24, Page 188
dnl # Turn on per-Domain message delivery agent selection and specify
dnl # database type, path and name; "-o" makes it optional
FEATURE(`mailertable',`dbm -o /etc/mail/mailertable')dnl
dnl # Sendmail, Chap 4.8.28, Page 192
dnl # Turn off E-Mail canonization (should be done by MSA, and this
dnl # is a mail relay with no local users)
FEATURE(`nocanonify')dnl
dnl # Sendmail, Chap 4.8.30, Page 194
dnl # Instruct daemon not to listen on port 587 for local MSA (this
dnl # is a mail relay with no local users submitting mail)
FEATURE(`no_default_msa')dnl
dnl # Sendmail, Chap 4.8.32, Page 194
dnl # Turn off all UUCP support and give reject message
FEATURE(`nouucp', reject)dnl
dnl # Sendmail, Chap 4.8.47, Page 199
dnl # Enable use of Trusted User's file
dnl # Default location is /etc/mail/trusted-users
dnl # File is required by default; see Page 199
FEATURE(`use_ct_file')dnl
dnl # Sendmail, Chap 4.8.51, Page 201
dnl # Turn on Virtual User mapping and specify database type, path and
dnl # name; "-o" makes it optional
FEATURE(`virtusertable',`dbm -o /etc/mail/virtusertable')dnl
################
## Macro Definitions ##
################
dnl # Sendmail, Chap 21.9.100, Page 834
dnl # Set the config file version in format <server>-<serial #>
define(`confCF_VERSION',`host-123')dnl
dnl # Sendmail, Chap 7.5.4, Page 317
dnl # Set a custom message for connection rejections based on access DB
define(`confREJECT_MSG',`550 Your mail has been rejected. Report problems to bugger.off@somedomain.tld')dnl
dnl # Sendmail, Chap 7.4.2, Page 304
dnl # Set a custom message for relay attempts by unauthorized hosts
define(`confRELAY_MSG',`550 Relay DENIED: report problems to bugger.off@somedomain.tld')dnl
dnl # Sendmail, Chap 4.8.16.2, Page 183
dnl # Define the name and path of the Generic Domains file; "-o" makes
dnl # its existence optional; used in conjunction with genericstable feature
GENERICS_DOMAIN_FILE(`-o /etc/mail/generic-domains')dnl
##########
## Mailers ##
##########
dnl # Per Sendmail book (Chapter 4.2.2.2, page 152) do not change order
dnl # "local" removed since this is a relay host with no local accounts
dnl # NOTE: Removing the "MAILER(local)" entry isn't strictly kosher, so
dnl # depending on your comfort level, you may wish to keep it; if
dnl # you do keep it, make it the LAST entry in the list of MAILER entries
MAILER(smtp)dnl
##################
## Local Config Section ##
##################
dnl # Any local configuration statements, such as local
dnl # macro definitions, should go here.
dnl # Define a file for the Domains that are Virtually Hosted - but
dnl # do NOT use the built-in VIRTUSER_DOMAIN_FILE macro, as that also
dnl # adds the Domains to RELAY_DOMAINS ("Class {R}"), resulting in bypass
dnl # of the RBLs and the virtusertable lookups
dnl # Credit to Jan Pieter Cornet for this idea
LOCAL_CONFIG
F{VirtHost}/etc/mail/virtuser.domains
##################
## Local Rules Section ##
##################
dnl # Per Sendmail book (Chapter 4.2.2.2, page 153) the LOCAL_RULES
dnl # need to go AFTER the Mailers
dnl # See Sendmail book pages 158, 159 and Chapters 19 and 25
dnl # Define special rules for this host to use when processing mail
dnl # IMPORTANT NOTES: Ruleset names should begin with capital
dnl # letter to avoid collision with sendmail internal
dnl # rulesets; TAB is the delimiter between key entries,
dnl # spaces will NOT work
##################
## End of sendmail.mc ##
##################
Resource #2: Sample access database for a relay
This access database file is generally applicable to an E-Mail relay host, where the host receives E-mail for one or more Domains, and relays it to hosts inside the network. The main functions of this sample database are:
1) allow internal hosts for which this host relays to bypass RBL checks
2) create a specific E-Mail address that RBLed senders can reach to request whitelisting
3) Discard or reject mail from/to specific addresses as the admin desires
4) Reject as SPAM E-Mail sent to long-departed users
5) Permit relaying for the specific Domains that are hosted
Your specific environment may not require all of these things. At a minimum, if you use the RBL features in sendmail, you should use entries with the Connect: keyword to permit your internal hosts to bypass RBL checks. Otherwise you're going to be constantly making DNS requests to the various RBL servers, for your own hosts, which is kinda pointless.
Also, if you use the RBL features, I highly recommend that you have an E-Mail address that even RBLed senders can reach - this E-Mail address should not appear on any web-pages or anywhere else it might be easily harvested; and should probably be an alias on an interior machine. Spammers won't be checking the RBL error messages, so they won't see the address. Legit senders will get the info if their E-Mail system isn't brain-dead and strips it.
Finally, don't forget to allow relay for the Domains you host. Checking based on the To: header is appropriate because if an E-Mail is From: one of those Domains, the sending server will have been permitted to RELAY with the earlier Connect: entries. This helps prevent spammers from relaying by pretending to be sending from a Domain you host.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/access
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
# NOTE: delay_checks MUST be enabled in sendmail.mc
# so that checks are performed in correct order
# See Sendmail book, Chap 7.5.6, Page 318
# An RBLed sender can ONLY bypass the RBL if
# the action-word FRIEND can be associated with
# their mail; therefore, the RELAY directives
# for the hosted Domains do not bypass the RBLs
#
# DSN codes for ERROR values are on page 708.
#
# Syntax:
# (Optional) Header or keyword, and value, to match [whitespace] Action keyword
# Permit relay (bypass RBL) for internal hosts that relay thru this one
# No sense in doing RBL lookups for our own hosts
Connect:10.1.2.3 RELAY
Connect:10.4.5.6 RELAY
Connect:10.7.8.9 RELAY
# Permit E-Mail TO access.denied to get thru, even if sendmail thinks
# that the sender is a spammer; this allows legit senders who've been
# RBLed to request white-listing (altho they also need to get themselves
# off of whichever RBL they are on)
Spam:bugger.off@somedomain.tld FRIEND
# Reject/Discard annoying specific addresses
# Note 1: This syntax discards it in EITHER direction
# Note 2: While the syntax shown is still technically valid, a leadin
# "To:" or "From:" tag is expected by newer sendmail versions
# (as shown in the example several lines down)
really.annoying@really.annoying.domain DISCARD
# To discard based on From: or To:, prepend the appropriate string, like so
To:easily.annoyed@somedomain.tld DISCARD
From:annoying.person@aol.com DISCARD
# To reject with a failure message instead of silently dropping,
# change DISCARD to REJECT; sendmail will use default reject
# message or custom one defined in sendmail.mc (as above)
From:luser@msn.com REJECT
# Reject for users no longer here but they keep getting SPAM
To:retired.threeyearsago@somedomain.tld ERROR:5.1.7:550 SPAM rejected
# Relay for hosted Domains
To:somedomain.tld RELAY
To:otherdomain.tld RELAY
To:hosteddomain.tld RELAY
####################
## End of /etc/mail/access ##
####################
Resource #3: Sample aliases file for a relay
This alias database file is generally applicable to an E-Mail relay host, where there are no local accounts and no need for local mail delivery. This makes for a very short file.
Changes to this database are not effective until the database is re-built using makemap - this is typically accomplished using the newaliases command, which is a link to sendmail. sendmail will determine that is was invoked using newaliases and will invoke makemap as needed. You could also run makemap separately. After re-building, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/aliases
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
# Syntax:
# keyword to match: value to substitute
# Following alias is required by the mail protocol, RFC 822
# Set it to the address of a HUMAN who deals with this system's mail problems.
Postmaster: root@someinteriorhost.somedomain.tld
# Alias for mailer daemon; returned messages from our MAILER-DAEMON
# should be routed to our local Postmaster
MAILER-DAEMON: postmaster
# And finally, an alias to direct dead E-Mail to the bit-bucket
nobody: /dev/null
####################
## End of /etc/mail/aliases ##
####################
Resource #4: Sample domaintable file for a relay
This is domaintable, generally used when moving from one Domain Name to another. As a rule, most places do not need a domaintable, altho there is no harm in creating a blank (but documented) one.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/domaintable
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
# Syntax:
# keyword to match: value to substitute
#
#
# Provides mapping of Domain Names - from old to new
# See Sendmail, Chap 4.8.13, Page 180
# Generally should not be needed - virtusertable
# is preferred. Only use when actually migrating a Domain
########################
## End of /etc/mail/domaintable ##
########################
Resource #5: Sample genericstable file for a relay
This genericstable database file is generally applicable to an E-Mail relay host. The purpose is to instruct sendmail to re-write the SMTP headers for outgoing E-Mail. There are several possible reasons you might wish to do this; for example, if your internal usernames are limited to 8 characters, but users want a firstname.lastname format for their E-Mail addresses, it's easy enough to do that for incoming E-Mail using virtualusertable or an aliases database, but outgoing E-Mail is not affected by those things. Or if a mail recipient is planning to move from one Domain you host to another, this can make the change seem to have taken place before it actually does.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/genericstable
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
# Syntax:
# keyword to match [whitespace] value to substitute
#
# Sendmail generic name rewrite file - See Sendmail, Chap 4.8.16, Page 181
#####################
## Outgoing FROM: rewrites ##
#####################
# Re-write "luser@somedomain.tld" as "mr.smith@somedomain.tld"
luser@somedomain.tld mr.smith@somedomain.tld
# Re-write "bob@somedomain.tld1" as "george@hosteddomain.tld2"
bob@somedomain.tld1 george@hosteddomain.tld2
########################
## End of /etc/mail/genericstable ##
########################
Resource #6: Sample mailertable file for a relay
This sample mailertable database is generally applicable to a relay host, and may even be required to make mail route properly. Basically, a mailertable instructs sendmail on how to route an E-mail based on the destination Domain. The mailertable is consulted when sendmail has determined that an E-mail is destined for a Domain for which it relays, and after the virtualusertable has been consulted (so if userA@DomainOne.tld maps to UserZ@domainX.tld, that will happen first).
The syntax is similar to other databases - a left-hand, or key side that is used to match, and then a right-hand, or result side that determines what it to be done. In the case of mailertable, the left-hand keys are hostnames or Domain names. The first one that matches is the one that is used, so you will probably want to list them starting with more-specific hostnames and then put the less-specific Domain names after those, if that is appropriate for your environment.
The right-hand result consist of two parts, a mailer specification and a hostname, separated by a colon (however, no whitespace should be in either side, only between the key and result). By enclosing the hostname of the right-hand result in square brackets, you instruct sendmail to not perform an MX record lookup for the host, but instead use the A record. This helps prevent mail loops. For example, if mail1.somedomain.tld was the Mail eXchanger for somedomain.tld and individual hosts in somedomain.tld did not have MX records, then when an E-Mail arrived at mail1.somedomain.tld and mailertable indicated that the final destination was userbox.somedomain.tld, the normal address resolution that sendmail would use would result in the mail being sent to mail1.somedomain.tld - a loop. By turning off that MX lookup, the loop is avoided. The result can also be an IP address.
The mailer types can be anything that sendmail supports; in this example, smtp is used for all instances.
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/mailertable
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
#
# Syntax:
# keyword to match [whitespace] mailer:host to use
#
# Maps Domain Names to delivery agents and host for routing
# See Sendmail, Chap 4.8.24, Page 188
# Direct incoming mail to appropriate internal hosts (and don't use MX lookups)
hostX.somedomain.tld smtp:[hostx.somedomain.tld]
somedomain.tld smtp:[userbox.somedomain.tld]
hosteddomain.tld smtp:[hostserver.somedomain.tld]
# Route incoming E-Mail to a host we don't have in DNS at all yet
brandnewdomain.tld smtp:[10.2.3.4]
# If anything arrives for this Domain we no longer host, send
# it to its new location (and look up that location)
nothostedanymoredomain.tld smtp:serverx.otherplace.tld
#####################
# End of /etc/mail/mailertable #
#####################
Resource #7: Sample virtusertable file for a relay
This sample virtual user table ( virtusertable) database is generally applicable to a relay host, and can greatly reduce the administrative overhead of a multi-Domain environment. The virtusertable instructs sendmail on how to map INbound E-mail from one address to another. It's consulted after the aliases file, but before mailertable. So virtusertable tells sendmail where an E-Mail needs to go, but not how to get it there.
The syntax is similar to other databases - a left-hand, or key side that is used to match, and then a right-hand, or result side that determines with what the original value will be replaced. The left-hand keys can either be full E-Mail addresses, or Domain names (when preceeded with an "@"). Again, the first key to match is used, so the more-specific entries should perhaps be first. If a match is not found on the first pass, sendmail will attempt to pare down the hostname it is trying to match (so bob@mail.anotherdomain.tld
The right-hand result consists of the new E-Mail address for delivery, but it is important to note that the headers are not re-written. So the receiving host must not be too picky about the To: E-Mail address in the message headers. Also, some substitutions are possible, more than are shown here. In the sample file, an E-mail for joe@hosteddomain.tld would be directed to joe@userbox.somedomain.tld
Changes to this database are not effective until the database is re-built using makemap; however, after makemap, the changes are immediately effective and do not require that sendmail be restarted. "whitespace" in this file can be TABs or spaces; blank lines and lines that begin with # will be ignored as comments by the makemap program.
##################################
# Author: A-NAME-HERE
# File: /etc/mail/virtusertable
# Change Log:
# Who When What
# ---- ----------- --------------------------------------------
#
#
#
#
#
# Syntax:
# Address or Domain name to match [whitespace] New address specification
#
# Virtual user mapping database for INbound E-Mail
# See Sendmail, Chap 4.8.51, Page 201
#
# Allows on-the-fly re-routing of mail, but does NOT
# change headers.
#
# This is consulted AFTER aliases and BEFORE mailertable
# Send E-mail to specific host/address
bob@anotherdomain.tld bobz@hostbob.otherdomain.tld
# Send E-mail to a different hosted Domain (mailertable will route)
phil@otherdomain.tld phil@somedomain.tld
# Direct E-Mail to a "fake" address to a "real" person
bugger.off@somdomain.tld postmaster@itstaffserver.somedomain.tld
# Send all E-mail for a Domain to the same address at a specific host
@hosteddomain.tld %1@userbox.somedomain.tld
# Reject all E-Mail to a Domain that's no longer hosted
@nothereanymore.tld error:nouser 550 No such user here
########################
## End of /etc/mail/virtusertable ##
########################
Notes on Resources #1-7
Based on the sendmail.mc above, the following files should exist in /etc/mail. In some cases, as noted in sendmail.mc, the existence is optional - sendmail will still check for optional files, but will silently fail if they are not found (as opposed to generating an error message and complaining). Unlike the database files in Resources #2-7, these files are simple text files, and their "records" are one domain or username per line in the file. Comments are not supported in these files. They are read when sendmail starts up, and changes are not effective until sendmail is restarted. The files are:
genericdomains
A hosted Domain must be listed in this file before rewriting rules in the
genericstable (Resource #5 above) are effective. Domains, not hosts, should be listed.
trusted-users
This file contains a list of usernames, one per line, that
sendmail should "trust". Generally, this is only
root, although virus-scanners or other software may require that you add their associated username
virtuser.domains
This is a special file, only applicable in the
sendmail.mc presented in Resource #1. Its contents are a list of Domains, one per line in the file, that are hosted by the relay server. A Domain must be listed in this file for its
virtusertable (Resource #7 above) entries to be effective.
local-host-names
relay-domains
While these default filenames are not needed and should not be used in the relay configuration presented above, a 0-length file with mode 000 can be created for each to avoid anyone accidentally creating one with inappropriate content
Updates
This topic is discussed in greater depth, and with newer updates, in my paper entitled Practical Modern sendmail Configuration (which was originally based off the original PAQ that sources this Article). Visit my EE Profile to find a link to my website and the paper.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)