Practical Modern Sendmail Configuration (Info Question)
This is an informational Question that I'll have the Mods PAQ so it'll be in the solutions DB. (Note to Mods: I'll be adding material for several days, probably, so please wait)
Other Experts should feel free to reference this Question if doing so helps them answer another Question. So that credit may be given where credit is due, please provide Askers with pointers to this Question as opposed to copy-n-paste. Askers who desire to create a "Points for PsiCop" question should still award points to the other Expert who directed them here.
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 Question 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.13.3); if you're running an older version, its 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 very significantly by platform, and so is out of the scope of this informational Question
1) If you're not running a modern version, then STOP - go get and 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.
So, let's go to it.
Other Experts should feel free to reference this Question if doing so helps them answer another Question. So that credit may be given where credit is due, please provide Askers with pointers to this Question as opposed to copy-n-paste. Askers who desire to create a "Points for PsiCop" question should still award points to the other Expert who directed them here.
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 Question 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.13.3); if you're running an older version, its 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 very significantly by platform, and so is out of the scope of this informational Question
1) If you're not running a modern version, then STOP - go get and 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.
So, let's go to it.
ASKER
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.
--- Cut here ----
##########################
# 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
# Reject/Discard annoying specific addresses
# Note that this syntax discards it in EITHER direction
really.annoying@really.ann
# To discard based on From: or To:, prepend the appropriate string, like so
To:easily.annoyed@somedoma
From:annoying.person@aol.c
# 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@s
# Relay for hosted Domains
To:somedomain.com RELAY
To:otherdomain.org RELAY
To:hosteddomain.net RELAY
####################
## End of /etc/mail/access ##
####################
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.
--- Cut here ----
##########################
# 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
# Reject/Discard annoying specific addresses
# Note that this syntax discards it in EITHER direction
really.annoying@really.ann
# To discard based on From: or To:, prepend the appropriate string, like so
To:easily.annoyed@somedoma
From:annoying.person@aol.c
# 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@s
# Relay for hosted Domains
To:somedomain.com RELAY
To:otherdomain.org RELAY
To:hosteddomain.net RELAY
####################
## End of /etc/mail/access ##
####################
ASKER
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.
---- Cut here ----
##########################
# 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.some
# 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 ##
####################
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.
---- Cut here ----
##########################
# 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.some
# 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 ##
####################
ASKER
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.
---- Cut here ----
##########################
# 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 ##
########################
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.
---- Cut here ----
##########################
# 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 ##
########################
ASKER
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 folx want a firstname.lastname format for their E-Mail addresses, its 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.
---- Cut here ----
##########################
# 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.com" as "mr.smith@somedomain.com"
luser@somedomain.com mr.smith@somedomain.com
# Re-write "bob@somedomain.com" as "george@hosteddomain.net"
bob@somedomain.com george@hosteddomain.net
########################
## End of /etc/mail/genericstable ##
########################
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 folx want a firstname.lastname format for their E-Mail addresses, its 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.
---- Cut here ----
##########################
# 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.com" as "mr.smith@somedomain.com"
luser@somedomain.com mr.smith@somedomain.com
# Re-write "bob@somedomain.com" as "george@hosteddomain.net"
bob@somedomain.com george@hosteddomain.net
########################
## End of /etc/mail/genericstable ##
########################
ASKER
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.com maps to UserZ@domainX.org, 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 results 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.com was the Mail eXchanger for somedomain.com and individual hosts in somedomain.com did not have MX records, then when an E-Mail arrived at mail1.somedomain.com and mailertable indicated that the final destination was userbox.somedomain.com, the normal address resolution that sendmail would use would result in the mail being sent to mail1.somedomain.com - 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.
---- Cut here ----
##########################
# 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.com smtp:[hostx.somedomain.com
somedomain.com smtp:[userbox.somedomain.c
hosteddomain.org smtp:[hostserver.somedomai
# Route incoming E-Mail to a host we don't have in DNS at all yet
brandnewdomain.net 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.com
#####################
# End of /etc/mail/mailertable #
#####################
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.com maps to UserZ@domainX.org, 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 results 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.com was the Mail eXchanger for somedomain.com and individual hosts in somedomain.com did not have MX records, then when an E-Mail arrived at mail1.somedomain.com and mailertable indicated that the final destination was userbox.somedomain.com, the normal address resolution that sendmail would use would result in the mail being sent to mail1.somedomain.com - 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.
---- Cut here ----
##########################
# 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.com smtp:[hostx.somedomain.com
somedomain.com smtp:[userbox.somedomain.c
hosteddomain.org smtp:[hostserver.somedomai
# Route incoming E-Mail to a host we don't have in DNS at all yet
brandnewdomain.net 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.com
#####################
# End of /etc/mail/mailertable #
#####################
ASKER
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. Its 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.org
The right-hand results consist 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.net would be directed to joe@userbox.somedomain.com
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.
---- Cut here ----
##########################
# 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.org bobz@hostbob.otherdomain.o
# Send E-mail to a different hosted Domain (mailertable will route)
phil@otherdomain.org phil@somedomain.com
# Direct E-Mail to a "fake" address to a "real" person
bugger.off@somdomain.com postmaster@itstaffserver.s
# Send all E-mail for a Domain to the same address at a specific host
@hosteddomain.net %1@userbox.somedomain.com
# Reject all E-Mail to a Domain that's no longer hosted
@nothereanymore.com error:nouser 550 No such user here
########################
## End of /etc/mail/virtusertable ##
########################
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. Its 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.org
The right-hand results consist 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.net would be directed to joe@userbox.somedomain.com
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.
---- Cut here ----
##########################
# 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.org bobz@hostbob.otherdomain.o
# Send E-mail to a different hosted Domain (mailertable will route)
phil@otherdomain.org phil@somedomain.com
# Direct E-Mail to a "fake" address to a "real" person
bugger.off@somdomain.com postmaster@itstaffserver.s
# Send all E-mail for a Domain to the same address at a specific host
@hosteddomain.net %1@userbox.somedomain.com
# Reject all E-Mail to a Domain that's no longer hosted
@nothereanymore.com error:nouser 550 No such user here
########################
## End of /etc/mail/virtusertable ##
########################
ASKER
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", altho 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
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", altho 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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
See my Profile for a link to an updated version of the information in this PAQ.
ASKER
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, 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.
---- Cut Here ----
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_THROT
dnl # Sendmail, Chap 24.9.91, Page 1043
dnl # Tune DNS/BIND options to work around broken AAAA records (IPv6)
dnl # Not needed if you build sendmail without IPv6 support
define(`confBIND_OPTS',`Wo
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(`confCHECKPOINTINTE
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_RAT
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_DR
dnl # Sendmail, Chap 24.9.32, Page 973
dnl # Set Delivery Mode to "background" ("interactive" used for debugging)
define(`confDELIVERY_MODE'
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
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_
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_CHI
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_SI
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 one queue run to 100
define(`confMAX_QUEUE_RUN_
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 to later
dnl # for just those addresses over the limit)
define(`confMAX_RCPTS_PER_
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
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_TIME
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'
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
dnl # Sendmail, Chap 24.9.78, Page 1027
dnl # Define the name and path of the daemon's PID file
define(`confPID_FILE',`/so
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:
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'
dnl # Sendmail, Chap 24.9.93, Page 1045
dnl # Instruct daemon to convert "Return-Receipt-To:" header to a DSN
dnl # NOTIFY=SUCCESS request (omitted boolean parameter defaults to "true")
define(`confRRT_IMPLIES_DS
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',`t
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 # 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
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',
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
################
## Features Section ##
################
dnl # Disable the following features
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dn
undefine(`DECNET_RELAY')dn
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_recipien
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',`fr
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.sp
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add ORDB BL with custom reject message
FEATURE(`enhdnsbl',`relays
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Added NJABL BL with custom reject message
FEATURE(`enhdnsbl',`dnsbl.
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add AbuseAt BL with custom reject message
FEATURE(`enhdnsbl',`cbl.ab
dnl # Sendmail, Chap 7.2.2, Page 297
dnl # Add SpamCop BL with custom reject message
FEATURE(`enhdnsbl',`bl.spa
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',`d
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
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')d
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',`d
################
## Macro Definitions ##
################
dnl # Sendmail, Chap 21.9.100, Page 834
dnl # Set the config file version in format <server>-<serial #>
define(`confCF_VERSION',`h
dnl # Sendmail, Chap 7.5.4, Page 317
dnl # Set a custom message for connection rejections based on access DB
define(`confREJECT_MSG',`5
dnl # Sendmail, Chap 7.4.2, Page 304
dnl # Set a custom message for relay attempts by unauthorized hosts
define(`confRELAY_MSG',`55
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'
##########
## 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
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/virtu
##################
## 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 ##
##################