Re: SETUP whole new system (Part 1, the firewall SMTP relay)

Administrateur de systemes wrote:
Hi all sendmail gurus !

I'm new on sendmail in a new position as sysadmin in a branch of the
university . I need to set up such a network within few days.

Internet
----->| Central server|------>| My new server (DMZ) |--->|final server |
(A) (B) (C)
university.ca dept.university.ca |
| |
| nfs mount
| workstation
|-------workstations (linux sendmail)----------------|

My what a simple question (:-). Lets split it up into a few parts:
Mail routing and relaying
Message delivery on the final host
Masquerading
Linux (Unix) client setup
A bunch of other stuff
Verifying your configurations

I will answer your questions as a series of posts, one for each part.


Mail routing and relaying:
The first issue is mail routing. Mail routing has an inbound and
outbound component.

The first step is to route inbound mail to the firewall (DMZ)
SMTP relay. This is done with DNS MX records. You can point the
lowest preference MX record to the mailbox server (final server)
itself or to the firewall SMTP relay.

In the first case the MX records would look like this:
dept.university.ca MX 10 mailboxserver.dept.university.ca.
MX 20 smtprelay.dept.university.ca.
MX 30 centralsmtprelay.university.ca.

The lowest preference MX record is used by hosts within your
department's network and by the firewall SMTP relay to forward the
mail to the mailbox server. Hosts outside of your network would not
be able to use this record because your firewall router will block
incoming SMTP connections to all hosts except the the firewall SMTP
relay. Hosts outside of your network would then roll over and use the
medium preference MX record which points to the firewall SMTP relay.
That relay would then be able to use the low preference MX record
to forward it to the mailbox server. The final highest preference
MX record which points to the university's central SMTP relay is
there for backup. If your firewall SMTP relay, firewall router, or
DMZ network should go down, then mail will spool up on the central
SMTP relay. This MX record is optional. You should check with the
owners of the central SMTP relay to make sure if it is OK with them
and that they will allow relaying to your sub-domain. If you do not
use this high preference MX record, then if your firewall SMTP relay
becomes unavailable, incoming mail will spool on the individual SMTP
hosts trying to send it to you.

In the second case of routing only to the firewall SMTP relay
the MX records would look like this:
dept.university.ca MX 10 smtprelay.dept.university.ca.
MX 20 centralsmtprelay.university.ca.

In this case the lowest preference MX record points to the firewall
SMTP relay and is intended to be used by hosts outside of your
network, i.e. other hosts at the university and other hosts on the
Internet. External mail would be forwarded to your firewall SMTP relay.
An important point to remember is that MX records only forward mail
to a host, they do not cause that host accept the message for local
delivery and they do not cause the host to allow relaying of the
message. You can configure the firewall SMTP relay to forward mail
for the sub-domain either with a sendmail rule or the "mailertable"
M4 feature.

Using a sendmail rule to forward mail to the mailbox server is
good and accepted use of a custom sendmail address rewriting rule.
What you are wanting to do is to select how sendmail will route
the message. Mail routing decisions are made in the "parse" (S0)
ruleset. This ruleset only deals with envelope addresses, not header
addresses, so any change to the address will only affect how the
message is delivered but will not be visible in the message itself.
Sendmail's routing decision is a mailer, host, user triple:
mailer What mailer to call to deliver the message.
host What host to forward the message to.
user What envelope recipient address to pass to that host.

In sendmail's rule syntax the triple is called on the Right Hand Side
(RHS) of the rule with:
$# mailer $@ host $: user
On the Left Hand Side (LHS) or pattern matching side of the rule
what you want to match is addresses ending with the local domain.
In this case dept.university.ca. This domain is stored in both the
sendmail macro "$m" as well as the sendmail class "$=m". Using the
class is more flexible since it allows you to add additional domain
names to forward.

To add this rule to a sendmail.cf file using M4 you would use the
M4 tag "LOCAL_NET_CONFIG" in your sendmail.mc file.

Something I teach in my "Managing Internet Mail" to aid in
understanding rules is to "document the rule". This includes a
sample Left Hand Side (LHS), Right Hand Side (LHS) verbiage comment
field above the rule and the numbering of the LHS meta-symbols
below the rule. I find that documenting a rule aids in decoupling
understanding the rule syntax, which is "user hostile" to put mildly,
from understanding what the rule does.

With the above in mind, here is the rule:
LOCAL_NET_CONFIG
# added with `LOCAL_NET_CONFIG'

# user @ 1ofmydoms -> deliver via the "relay" mailer
# to host "mailhub.dept.university.ca"
# for user "user @ 1ofmydoms"
R $+ <@ $=m . >
$# relay $@ mailhub.dept.university.ca $: $1 <@ $2 . >
# $1 $2

The rule or "R" line itself can be a single line with the LHS and RHS
separated by one or more tabs. It also can be two lines with the LHS
on the first line and the RHS on the second line. But in this case
the second line must start with one or more tabs. If you forget the
tabs, you will get the error:
line ###: invalid rewrite line "R ..." (tab expected)

The above rule will route mail to the domain itself,
user@xxxxxxxxxxxxxxxxxx, but not for hosts within the domain,
user@xxxxxxxxxxxxxxxxxxxxxxxx A second rule can be added for this
case.
It is very similar to the first rule except the pattern to match is
user@xxxxxxxxxxxxxxxxxxxxxxx:

# user @ something . 1ofmydoms
# -> deliver via the "relay" mailer
# to host "mailhub.dept.university.ca"
# for user "user @ something .
1ofmydoms"
R $+ <@ $+ . $=m . >
$# relay $@ mailhub.dept.university.ca $: $1 <@ $2 . >
# $1 $2

A simple M4 host.mc template file for these rule would be:
VERSIONID(`firewall.ruleroute.mc Robert Harker 20060720')
OSTYPE(`linux')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
LOCAL_NET_CONFIG
# added with `LOCAL_NET_CONFIG'

# user @ 1ofmydoms -> deliver via the "relay" mailer
# to host "mailhub.dept.university.ca"
# for user "user @ 1ofmydoms"
R $+ <@ $=m . >
$# relay $@ mailhub.dept.university.ca $: $1 <@ $2 . >
# $1 $2

# user @ something . 1ofmydoms
# -> deliver via the "relay" mailer
# to host "mailhub.dept.university.ca"
# for user "user @ something .
1ofmydoms"
R $+ <@ $+ . $=m . >
$# relay $@ mailhub.dept.university.ca $: $1 <@ $2 . >
# $1 $2


Start aside 1, using M4 to generate a custom sendmail.cf file:

"m4" is a utility for generating customized source code based on
the setting of M4 macros. It was originally developed for Fortran,
but Eric Allman, the author of both m4 and sendmail, decided to
use it to generate custom sendmail.cf files as well. For sendmail,
the input to M4 is a host.mc template file (mc -> m4 configuration).
A bare bones host.mc template file has 4 lines:

VERSIONID(`host.mc Robert Harker 20060720')
OSTYPE(`linux')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

The VERSIONID line puts a comment at the top of the generated
sendmail.cf file and is used to note what host.mc input file was used
to generate the sendmail.cf file.

The OSTYPE line is used to define differences between different
operating systems that affect sendmail. These include location of
files and directories, programs used for local delivery as well as
other things.

The MAILER lines include the mailers (delivery agents) that sendmail
can use to deliver a message. MAILER(`local') includes the "local"
and "prog"ram mailers. MAILER(`smtp') includes 5 different SMTP
mailers with different behaviors.

The "dnl" at the end of each line means "delete through new line" and
it deletes the extra carriage return at the end of each line. "dnl"
is optional but it makes the top of the sendmail.cf file cleaner by
removing extraneous <CR>s. "dnl" can also be used at the beginning
of an M4 statement to force M4 to ignore the statement:
dnl FEATURE(`mailertable')
Caution: pound sign, "#", comments do not work in M4, the M4 statement
would still be used.

Also note that it is important to quote M4 keywords to avoid
unexpected results. In M4 you use non-matching single quotes around
the M4 keywords. The non-matching quotes seems bizzar, but with
non-matching single quotes it is simple to nest your quotes in M4:
`start first `start second `start third ... third end'
`new third ... third end' second end' `new second
... second end' first end'

For Linux, the default m4 template file is /etc/mail/sendmail.mc.
There is a "Makefile" in the /etc/mail directory that will regenerate
the sendmail.cf file after you change the sendmail.mc file by simply
typing "make" in the /etc/mail directory.

If you are going to create multiple sendmail.cf files, I recommend
you generate them on a single host, the host you might have compiled
sendmail on or perhaps the mailbox host. For Linux, you would store
your host.mc files in the directory /usr/share/sendmail-cf/cf (requires
the sendmail-cf-8.13... package to be installed). The sendmail
"cf/cf" ("sendmail-cf/cf") directory contains a bunch of sample
template files that may be useful to look at (check out knecht.mc),
but clutter up the directory. I recommend cleaning things up a bit:
cd /usr/share/sendmail-cf
mv cf cf.orig
mkdir cf
cp cf.orig/Makefile cf
cp cf.orig/submit.mc cf
I also recommend cleaning up the domain and hack directories:
mv domain domain.orig
mv hack hack.orig
mkdir domain hack

There are three ways you can generate your sendmail.cf file in the
"cf/cf" directory.

You can use M4 directly:
cd /usr/share/sendmail-cf/cf
m4 ../m4/cf.m4 host.mc > host.cf

You can tell "make" what to build:
cd /usr/share/sendmail-cf/cf
make host.cf

You can add the target file (host.cf) to the "Makefile" and let
"make" build it for you:
cd /usr/share/sendmail-cf/cf
Look for the ALL=" line in the "Makefile".
Add the target file (host.cf) to this line:
ALL= submit.cf host.cf
("$(GENERIC)" and "$(OTHER)" are not needed)
Type "make" to update any target in "$(ALL)" who's ".mc" file
is newer than the ".cf" file.

Once you have generated the new host.cf file you would then use "scp"
to copy it to "/etc/mail/sendmail.cf" on the correct host:
scp host.cf root@host:/etc/mail/sendmail.cf
You also need to restart the sendmail daemon on the remote host in
order for that host to use the new configuration.

End aside 1.


The other way you could route mail for sub-domain is with the
"mailertable" M4 feature. This feature allows you to use a hash/key
database to control how you route your mail. The benefit of
using the "mailertable" database is that it adds flexibility to
your configuration. You can change how sendmail routes mail by simply
editing the text file and regenerating the database. The other benefit
is that the changes are used as soon as the database is regenerated.
You do not need to kill and restart the sendmail daemon.

You would include the "mailertable" feature in your host.mc file with:
FEATURE(`mailertable')dnl

A simple M4 host.mc template file would be:
VERSIONID(`firewall.mailertable.mc Robert Harker
20060720')
OSTYPE(`linux')dnl
FEATURE(`mailertable')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

Once this feature is enabled, sendmail will check the envelope
recipient address's hostname and domain name in the database
/etc/mail/mailertable.db. This hash/key database is generated with
the "makemap" command from the /etc/mail/mailertable ASCII source file:

cd /etc/mail
makemap -v hash /etc/mail/mailertable < /etc/mail/mailertable

Because "makemap" will add the ".db" extension to the database file,
you can use the same file name for both the source and destination
file. For Linux, there are typically rules in the "Makefile" in
/etc/mail directory to run "makemap" for you.

Format of the mailertable database:
The lookup key (LHS) in the mailertable file can be:
host.some.dom A specific FQDN used for user@xxxxxxxxxxxxxx
some.dom A domain name used for user@xxxxxxxx addresses.
..some.dom Every host or sub-domain below a domain name.

There is also the special lookup key dot, ".", which is used as a
default match. More on this later.

The returned value of the database is a "mailer:host" pair to use
for routing of the message:
esmtp:mailboxserver.dept.university.ca

So to route mail for user@xxxxxxxxxxxxxxxxxx to the mail box server
you would use:
dept.university.ca esmtp:mailboxserver.dept.university.ca
And to route mail for hosts within your domain you would use:
.dept.university.ca esmtp:mailboxserver.dept.university.ca


Outbound SMTP routing on the firewall SMTP relay:

The final routing issue on the firewall is how to route outbound SMTP
mail.
Assuming that your firewall SMTP relay can send mail directly to hosts
and
domains on the Internet as well as hosts and
sub-domains in the University's network then outbound routing is
simple.
If the message is not addressed to your sub-domain, sendmail will
simply
pass the message to the SMTP mailer for delivery. The SMTP mailer will
then
lookup the DNS MX records for the envelope recipient's host or domain.
These MX records tell sendmail what host or hosts to attempt to connect
to
in order to deliver the message.


Enabling SMTP relaying on the firewall SMTP relay:

In both of the above configurations a final issue that remains is to
selectively re-enable SMTP relaying for both inbound and outbound mail.

SMTP relaying is when an SMTP client connects to an SMTP server and
tries to forward a message not addressed to the server itself. In the
case of sendmail, a host or domain name in class $=w. Instead the
message is addressed to another remote SMTP server that this SMTP
server must forward the message to.

By default sendmail does not allow any SMTP relaying. It will
only accept mail specifically addressed to the host itself,
user@xxxxxxxxxxxxxxxxxxxxxxxxxxxx in this case. It will also forward
mail that is generated locally on the host itself to other SMTP hosts.

Enabling SMTP relaying with class $=R:

The simplest way to selectively re-enable SMTP relaying is by using
the sendmail class "$=R". Class "$=R" is a list of domains and IP
addresses that are allowed to relay through this host. This class
can use the following formats:
dept.university.ca
host.dept.university.ca
1.2.3.4
1.2.3

The first two cases are typically used for the envelope
recipient addresses and allow inbound relaying. They allow
relaying for the host or domain itself, user@xxxxxxxxxxxxxxxxxx or
user@xxxxxxxxxxxxxxxxxxxxxxxx They also allow relaying for hostnames
that end with the domain name, user@xxxxxxxxxxxxxxxxxxxxxxxxxxxx or
user@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Note that in this example
user@xxxxxxxxxxxxxxxxxxxxxxx would be allowed by the first case,
dept.university.ca.

The final two cases are used to enable outbound relaying based on
the IP address of the SMTP client trying to relay mail through the
relay host. A specific IP address only allows a single SMTP client
to relay mail through the relay host. The IP network number, without
the trailing zeros, allows any SMTP client with an IP address starting
with the IP network number 1.2.3 to relay mail through the relay host.

Note1: the second case of an IP network
number must be sub-divided on even octets. Sendmail can not use
variable length subnet masks. So 4 super-netted class C addresses
would need 4 entries. I.e. for 1.2.3/22 you need:
1.2.3
1.2.4
1.2.5
1.2.6
And the 1.2.3.64/26 sub-netted class C addresses would need two
entries:
1.2.3.65
1.2.3.66
(The network address, 1.2.3.64, and the broadcast address, 1.2.3.67,
are not needed)

Note2: the first to cases, dept.university.ca and
host.dept.university.ca, also allow outbound relaying, but it is
based on the DNS pointer (PTR) record for the IP address of the SMTP
client trying to relay mail through the relay host. This works but
is not recommended.

You can add entries to class "$=R" using the M4 tag "RELAY_DOMAIN".
So assuming that your department's internal network uses the two class
"C" sub-nets 1.2.3 and 1.2.4, you would enable inbound relaying with
"dept.university.ca" and you would enable outbound relaying with
"1.2.3" and "1.2.4". In your host.mc file add:
RELAY_DOMAIN(`dept.university.ca 1.2.3 1.2.4')dnl

You can also tell sendmail to read a separate file to define the
class by using a "file class" definition. This would be an "F"
line in the configuration file rather than the traditional "C" class
definition line. You can define this file class with the M4 tag
"RELAY_DOMAIN_FILE". In your host.mc file add:
RELAY_DOMAIN_FILE(`/etc/mail/relay-domains')dnl

In fact this file class is predefined in the sendmail M4 templates,
so you can simply create the file /etc/mail/relay-domains with:
dept.university.ca
1.2.3
1.2.4

Remember that class definitions in sendmail are static in memory.
So if you change a class definition either by changing the sendmail.cf
file or by editing the file class file, you need to kill and restart
the sendmail daemon in order to pick up the changes.

Enabling SMTP relaying with the access database:

The other way you can enable SMTP relaying is with the "access"
database using the "access_db" M4 feature. This feature allows you
to use a hash/key database to control SMTP relaying through the host.
The "access" can be used for other things as well such as rejecting
spam mail during the initial SMTP conversation with the SMTP client
thus avoiding the need for the server to generate a bounce message.
The benefit of using the "access" database is that it adds flexibility
to your configuration. You can change what sendmail will relay by
simply editing the text file and regenerating the database. The other
benefit is that the changes are used as soon as the database is
regenerated. You do not need to kill and restart the sendmail daemon.

You would include the "access" database feature in your host.mc
file with:
FEATURE(`access_db')dnl

Although the feature is called "access_db", the database name is simply
"access" and it is stored in /etc/mail by default.

The format of the "access" database is a key/value pair where the
lookup key defines what the entry applies to and the returned value
defines what the restriction is.

The lookup key can use the same formats as class $=R:
dept.university.ca
host.dept.university.ca
1.2.3.4
1.2.3

What the lookup key applies to, the scope of the lookup key, is the
same as with class $=R with the same even octet boundaries restrictions
for IP network numbers.

The lookup key can also take a prefix that limits the key to
a specific check:
CONNECT: Checks of the client's hostname and IP address
FROM: Checks of the envelope sender address
TO: Checks of the envelope recipient address

In addition there are other formats the lookup keys can take that
are used by other checks that the "access" database feature can make.

The returned value defines what sendmail will do if the lookup key is
matched. It can be:
RELAY Allow SMTP relaying
REJECT Reject the lookup key

There are other return values as well. They are mostly used for spam
control.

You would enable inbound relaying with:
dept.university.ca RELAY

Again assuming that your department's internal network uses the two
class "C" sub-nets 1.2.3 and 1.2.4, you would enable outbound relaying
with:
1.2.3 RELAY
1.2.4 RELAY

To make the lookup key match more precise you should use the prefix
"TO:" for the domain name and "CONNECT:" for the IP network numbers.

Your initial /etc/mail/access table would be:
TO:dept.university.ca RELAY
CONNECT:1.2.3 RELAY
CONNECT:1.2.4 RELAY

You would generate the hash/key database with the "makemap" command:
cd /etc/mail
makemap -v hash /etc/mail/access < /etc/mail/access


The next installment will talk about message delivery
within the sub-domain.

Hope this helps

RLH

For info about our "Managing Internet Mail, Setting Up and Trouble
Shooting sendmail and DNS" and a schedule of dates and locations,
please send email to info@xxxxxxxxxx, or visit www.harker.com

Robert Harker Harker Systems
Sendmail, DNS and TCP/IP Network Training 4182 Pleasant Hill Rd.
Sendmail, Network and Sysadmin Consulting Lincoln, CA 95648
harker@xxxxxxxxxx 530-887-9990

.

Relevant Pages

  • sendmail client side smtp authentication problem
    ... sendmail client side smtp authentication problem ... made and installed cf, restarted sendmail, ... # Resolve map (to check if a host exists in check_mail) ...
    (freebsd-questions)
  • Re: Solaris 8 - Configuring sendmail relay (NoAuth inbound -> SSL outbound)
    ... I haven't used sendmail in a scenario where there isn't a real domain ... The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. ... Any other use would conflict with widely deployed code which assumes this use. ... Relay mail from insecure clients to an SMTP server that requires SSL. ...
    (comp.mail.sendmail)
  • Re: Same sendmail.cf files in different machines, cause different RULE EFFECTS
    ... # Copyright 1998-2001 Sendmail, ... names that should be exposed as from this host, ... # use Errors-To: header? ...
    (comp.mail.sendmail)
  • MTU PPP
    ... I would like to set the MTU of my ppp0 above 1500. ... sendmail ... Smart relay host in sendmail ... # checkpoint queue runs after every N successful deliveries ...
    (RedHat)
  • UPDATE weird sendmail problem on Solaris 9 (fwd)
    ... I was asked to supply info about my sendmail config and my nsswitch.conf ... names that should be exposed as from this host, ... # list of locations of user database file ... # SMTP STARTTLS server options ...
    (SunManagers)
Loading