Send mail PSD/FAQ ( Sun send mail )
1.0: About Sun's Send mail
1.1: Send mail Clients And Servers
1.2: Send mail Mailers
1.3: Send mail Version
1.4: A Few Words on Send mail Rule
1.4.1: The Parts of a Sendmail Rule
1.4.2: Examples of Sendmail Rules
1.4.3: Which Rulesets are Used
1.4.4: Important Defines
2.0: Debugging Send mail
2.1: Debugging using SMTP port 25
2.2 How to use SMTP commands to send mail directly to port 25
2.3: /usr/ucb/mail -v, mailx -v or /usr/lib/sendmail -v
2.4: Sendmail Debug Functions
2.4.1 sendmail verbose mode
2.4.2 sendmail debug mode to get basic sendmail info
2.4.3 sendmail debug to test address rulesets
2.4.4 The MOST COMMON input to address ruleset debug mode
3.0: Common How To's
3.1: How To Set Up a Sun As An Internet Mail host
3.2: How To Set Up a Sun As A Mail Client
3.3: How to Force Send mail to Rewrite Sender Addresses for Internal Email
3.4: How to Force Send mail to Rewrite Sender Addresses for External Email
3.5: How To Route Mail Through a Firewall
4.0: Some Frequently Asked Questions
4.1: Miscellaneous Questions
4.2: Configuration File & Mail Setup Questions
4.3: Mail Command Line Error Messages
4.4: Send mail Bounce Messages
5.0:Patches
5.1:SunOSPatches
5.2: Solaris Patches
6.0: Known Bugs & RFEs
6.1: RFEs
1.0: About Sun's Send mail
This PSD documents a wide variety of information concerning Send mail,
as implemented in the SunOS and Solaris operating systems. It is
intended as both an introduction to Send mail, and as a guide to the
most common problems. There are many more complete references to Send mail, a few of which are noted in section 7.0.
Because all network configurations are different, the setup that sun
provides will suit 80 - 90 percent of a System Administrators needs.
The other 10 - 20 percent will require some modification or
customization to the administrator's sendmail.cf.
This Tip sheet basically applies to both Solaris and SunOS send mail.
The only differences will be different paths for the sendmail.cf and
new functionality defined within the sendmail.cf for Solaris.
1.1: Send mail Clients And Servers
Sun provides a basic client/server framework for Send mail. There are
two sendmail.cf files found in /etc/mail called main.cf and
subsidiary.cf.
The MAIN.CF file is for machines designated as mail hosts and provides
all the Send mail rules needed to route mail onto the Internet.
The SUBSIDIARY.CF file is for machines that will only route mail
directly to internal hosts and that will send outbound mail to the
designated mail host. The subsidiary.cf file is the default sendmail.cf
file when the system is installed.
Sun also provides two versions of Send mail for all versions of SunOS
and Solaris earlier than 2.5 that do not have the latest Solaris send mail V8 patch installed. send mail and sendmail.mx executables can
be found in /usr/lib: SEND MAIL should be used on clients and other machines that have no
need to access MX records.
SENDMAIL.MX should be used when trying to route mail to addresses that
are DNS MX records. Typically, sendmail.mx will be installed on all
mail servers.
Under Solaris 2.5, or with the latest Solaris send mail V8 patch
installed, there is only one version of send mail, which
combines the functionality of the former send mail and sendmail.mx
programs. 1.2: Send mail Mailers In send mail, a "mailer" defines the manner in which send mail tries to deliver mail. Some mailers are standard: for example, the
"local" mailer always delivers to local users, while the "prog"
mailer
always delivers to local programs. However, Sun send mail also defines
a special mailer which is used for all non-local mail. This is done
with the 'DM' line in the sendmail.cf. For example, the following line
defines a mailer for delivery within the local domain, to be "ether":
DMether
The following three mailers are the ones most typically used for
non-local mail:
ddn: short for Data Defense Network, an old version of the Internet.
This mailer should be used in any sendmail.cf which is expected to
talk directly to the Internet, rather than acting as a client to a mail host. It negotiates connections via SMTP, and also fully
qualifies domain names, so that they will be correct out on the Internet.
Typically, ddn will be used on a main.cf machine, which means
directly attached to the Internet.
ether: This mailer is very similar to ddn, but it intended only for
"internal" networks within a single domain name.
It connects via SMTP directly to hosts within the local domain.
It delivers "external" mail by forwarding it on to a
"mail host",
which general serves as a mail relay to other domains and/or the
Internet. Thus, the ether mailer lets the mail host deal with
any complexities. Typically, ether will be used on all subsidiary
hosts, but of course the ether mailer is also found in the main.cf,
so that a mail host knows how to route mail within the local domain.
smartuucp: This mailer is only necessary if the local network is
connected to external networks via UUCP. Typically, smartuucp will be
used on a main.cf machine, provided it has a UUCP connection. A
variant of smartuucp exists, called just UUCP. It will not fully
domainize names, and should not be used unless you must be compatible
with (very) old UUCP standards.
1.3: Send mail Version
All versions of SunOS, and Solaris earlier than 2.3 support send mail version 5.
Solaris 2.5, and versions of Solaris 2.3 and 2.4 which have the send mail V8 send mail patch installed, support send mail version 8.6.10,
as modified by Sun. Without the send mail patches, Solaris 2.3 and 2.4
will only run at send mail V5. Send mail version 8.7 or greater can be acquired from the public
domain, but it is not supported by Sun Service.
Generally, you will find the version that most send mail hosts are
using, by connecting directly to the SMTP port 25 with either
the "mconnect" command on Sun's or telnet to port 25. Here are
two examples on mconnect to a 2.3 unpatched host, and telnet to
port 25 on a 2.5.1 host:
$ mconnect omni
connecting to host omni (129.151.26.1), port 25
connection open
220 omni.omnilab.com Send mail 5.0/SMI-SVR4 ready at Wed, 19 Feb 1997
mercedes[hackley]:telnet cascades 25
Trying 129.151.26.160...
Connected to cascades.
Operating in single character mode
Remote character echo
Escape character is '^]'.
Connected to cascades.
Escape character is '^]'.
220 cascades.omnilab.com Send mail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997
Reminder: Type in "quit" to get out of SMTP port 25.
1.4: A Few Words on Send mail Rules
The heart of sendmail is the rulesets defined in the sendmail.cf.
These are what determine how from addresses are rewritten, how to
addresses are rewritten, and what mailers should be used. Most
administrators will not have to work with these, except in the very
minimal ways described in Section 3.0. If you don't think you'll need
to get into the rulesets, skip ahead to Section 2.0.
For those administrators with special needs, the way rules work is
described a little bit here. For more information, you should consult
the references listed in Section 7.0. This information is provided to
you, in the hope that you can learn how to write rule sets on your
own if it is not sufficient, SunService can not help you further, but
you can get help from Sun Consulting, as is described in Sections 8.0
and 9.0.
1.4.1: The Parts of a Sendmail Rule
A typical sendmail rule has four parts:
Rlhs rhs comments
The letter R defines the line as a rule (there are also macros, mailer definitions and lots of other stuff in the sendmail.cf).
The lhs (left hand side) is a conditional test. If the From/To address
matches the lhs, then the rhs is applied.
The rhs (right hand side) is a rule that describes what action should
be taken.
The comments describe what the rule line is doing.
There are a lot of weird variables in the sendmail rulesets. The most
important ones follow.
lhs:
$* matches zero or more tokens
$- matches exactly one token
$+ matches one or more tokens
$=letter matches any token which is equal to $letter i.e.: $=m matches your domain name
(A token is one "part" of the sendmail address, separated by a
"." or
a "@". For example, in the example "joe@machine.test.com", joe,
@,
machine, ., test, . and com are tokens.)
rhs:
$@ action for the RHS is rewrite-and-return
$>num action for the RHS is rewrite using the num ruleset
$# action for the RHS is final delivery, via the listed Mailer
$letter equal to the Defined variable (i.e. $m matches what Dm is set to)
$number equal to the $numberth $*, $- or $+ on the lhs
Sendmail rules are grouped into rulesets. A Marker as following starts
off each ruleset:
S#
For example, ruleset 11 would be started with the following line:
S11
1.4.2: Examples of Sendmail Rules
Below are two quick examples of rules, each taken from main.cf.
First, the 'tack on our domain' rule:
R$+<@$+>$* $@$1<@$2.$m>$3 tack
on our domain
The following Define is also relevant:
Dmtest.com
The above rule will match anything in the form
"something<@something>maybe".
The format is a little funny with <s and >s because the address has
already been rewritten a few times. For example, assume we have the
following address:
joe@machine
By the time we get to this rule, the address will have been rewritten
as follows:
joe<@machine>
The above lines successfully matches the lhs of our rule, and the
following numerical variables are set:
$1 = "joe"
$2 = "machine"
$3 = ""
In addition, we already have the following set:
$m = "test.com"
Since the lhs starts off with $@, sendmail knows to do a db
replacement, and:
$1<@$2.$m>$3
becomes:
joe<@machine.test.com>
As you can see, this rule tacks on a domain name, when the address is
already of the form user@machine (for example, when mail comes to a
mailhost, from a mail client).
Our second example, is the 'tack on our full name' rule:
R$+ $@$1<@$w.$m> tack on our
full name
This will match anything except "". However, because of the way
earlier rulesets are set up, anything that is not of just the form
'joe' or 'joe.smith' (i.e. no @) will have already been
rewritten-and-returned. Assume that $w is set to mailhub and $m is set
to test.com. In this case, if we get the following address as input:
joe
It will be output as:
joe<@mailhub.test.com>
1.4.3: Which Rulesets are Used
There are lots of rulesets in the sendmail.cf, and it come be somewhat
overwhelming to try and find the correct one if you don't know
where to look.
It's been noted previously that the rulesets are applied to From
addresses AND to addresses. The To address is typically used to
figure out where to send the mail to, while the From address is
sometimes rewritten in some manner (for example, the From address
'joe' might be changed to 'joe@machine' for internal mail and to
'joe@domain' for external mail). The From and To addresses are sent to
different rulesets, so that these different rules may be applied.
The From (or Sender) address goes through the following rulesets:
3,1,S,4.
The To (or Recipient) address goes through the following rulesets:
3,2,R,4.
R and S are special rulesets that depend upon which Mailer you are
using. For example, smartuucp and ddn process addresses in different
ways. To figure out what R and S are set to, first look for the line
that starts off 'DM'. This defines your external mailer:
DMddn
Then, look for a line that reads "Mmailer-name". For example, Mddn:
Mddn, P=[TCP], F=msDFMuCX, S=22, R=22, A=TCP $h, E=\r
As you can see, this line sets S and R each to ruleset 22.
Almost every single rule that a typical administrator cares about is
defined in the S and R rulesets. If you want to make a change to the
way that one specific mailer deals with addresses, you should put it
in S or R. Likewise, if you want to figure out how addresses get
rewritten, you should usually look in S and R.
Another example follows:
Mlocal, P=/bin/mail, F=flsSDFMmnP, S=10, R=20, A=mail -d $u
You'll recall that earlier it was stated that 'local' is used to do
local mail delivery. Here, you can see that one final rule rewrite
gets done before that local mail delivery. The Sender address goes
through rule 10, while the Recipient address goes through rule 20.
1.4.4: Important Defines
In the above examples, several defined variables ($w, $m, etc) were
mentioned. The most important ones are:
$k mailbox machine name (i.e. nfs-host)
$w machine name (i.e. mailhub) $m domain name (ie test.com)
$M default mailer (ie ddn)
2.0 Debugging Sendmail
2.1: Debugging using SMTP port 25
If you are having troubles with sendmail on a particular machine, you
can connect to it on port 25 to examine how it is functioning.
The following determines that sendmail is up and running:
$ telnet localhost 25
Trying 127.0.0.1 ...
Connected to localhost.
Escape character is '^]'.
220 rainbow.Corp.Sun.COM Sendmail SMI-8.6/SMI-SVR4 ready at Tue, 12 Mar 1996
10:19:57 -0800
This also tells you what sendmail has its name set to (rainbow.corp.sun.com)
and what version of sendmail you are running (SMI-8.6/SMI-SVR4).
Once you have connected to the sendmail port, you may use the 'expn'
SMTP command to examine the expansion of addresses, such as you might
want to see when debugging mail alias problems.
$ telnet localhost 25
...
expn postmaster
250 < root >
expn appel
250 Shannon Appel < appel@rainbow.Corp.Sun.COM >
Note: on suns, the command 'mconnect <machine>' does the same thing as
'telnet <machine> 25' and may be used as a sort of shorthand. Be aware
that this command is not standard though.
There are several SMTP commands available. Use the HELP command to
find out what commands the sendmail host supports. Note that most
mail locations directly attached to the Internet have disabled
the EXPN (EXPaNd alias) and VRFY (VeRiFY user).
2.2 How to use SMTP commands to send mail directly to port 25
Folks, we use this all the time to debug mail problems with
our customers. The command sequence to use is:
helo sending-hostname
mail from: yourname@yourdomain.com (yourname@yourdomain.com is the
sender)
rcpt to: user@destination (user@destination is where you want the mail to
go)
data
(put in Subject: and body of email message here)
. (this is a period on a line by itself)
quit
For example:
$ telnet test 25
Trying 192.151.24.1...
Connected to test.
Escape character is '^]'.
220 test.East.Sun.COM Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997
18:01:20 -0500
helo mercedes
250 sunesc.East.Sun.COM Hello mercedes [192.151.24.64], pleased to meet you
mail from: hackley@east.sun.com
250 hackley@east.sun.com... Sender ok
rcpt to: user@testhack.com
250 user@testhack.com... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: Testing from Sun Service Network Support, please ignore
testing...
.
250 SAA13622 Message accepted for delivery
quit
221 sunesc.East.Sun.COM closing connection
Connection closed by foreign host.
For those of you have used mailx -v or /usr/lib/sendmail -v to
debug sendmail, you will recognize the stand SMTP command sequence.
2.3: /usr/ucb/mail -v, mailx -v or /usr/lib/sendmail -v
The older /usr/ucb version of mail has a verbose flag, which may be
used to determine exactly what mail is doing. It is useful if you are
getting bounces, or mail is not getting through, and you'd like a
slightly more expansive analysis.
The Solaris mailx command also has a -v switch, as does /usr/lib/sendmail
It is particular helpful because, for outgoing mail, it will show you
where mail is going, and how it is communicating:
rainbow% mailx -v test@test.com
Subject: test
this is a test of outgoing mail.
^D
EOT
rainbow% test@test.com... Connecting to mailhost (ether)...
220 Corp.Sun.COM Sendmail 5.x/SMI-5.3 ready at Tue, 12 Mar 1996 10:26:26
-0800
>>> HELO rainbow.Corp.Sun.COM
250 Corp.Sun.COM Hello rainbow.Corp.Sun.COM (rainbow-bb.Corp.Sun.COM),
pleased
to meet you
>>> MAIL From:<appel@rainbow>
250 <appel@rainbow>... Sender ok
>>> RCPT To:<test@test.com>
250 <test@test.com>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Ok
>>> QUIT
221 Corp.Sun.COM closing connection
test@test.com... Sent (Ok)
In the above example, we see that the "ether" mailer is being used,
and that our local machine is connect to mailhost. /usr/ucb/mail, mailx, or sendmail in the verbose mode will often give
you hints for easy sendmail problems, particularly "bounce" messages
If it is insufficient, sendmail itself provides
some much more robust verbose functionality.
2.4: Sendmail Debug Functions
When debugging, consider the information provided by running sendmail
in verbose mode, and in debug mode
2.4.1 sendmail verbose mode
This is an example of running sendmail interactive on a "subsidiary"
machine. Below in "{}" are comments of useful information.
$ /usr/lib/sendmail -v jane@foo.com this is a test
. (or CTRL/D)
jane@foo.com... Connecting to mailhost via ether...
{The machine we are sending mail to^^^^^^^ ^^^^^the mailer
used}
Trying 129.151.21.1... connected.
{The connection to machine "mailhost" completed}
220 sunesc.East.Sun.COM Sendmail 4.1/SMI-4.1 ready at Wed, 30
Aug 95 09:33:49 EDT >>> HELO
doghouse.East.Sun.COM
{I identify myself: defined by the macro Dj$w.$m}
250 sunesc.East.Sun.COM Hello doghouse.East.Sun.COM, pleased to
meet you>>> MAIL From:<valante@doghouse>
{Here is the address that will show in the mail's "from" line or
"to" line when someone replies to it}
250 <valante@doghouse>... Sender ok >>> RCPT
To:<jane@foo.com>
250 <jane@foo.com>... Recipient ok
{The person receiving the mail is a valid address. NOTE: This is
valid for the machine connected to, but may not be a valid final
address. Running sendmail -v from the machine you are connecting
to may give an error and will identify the real problem.}
>>> DATA 354 Enter mail, end with "." on a line by
itself >>>
. 250 Mail accepted >>> QUIT 221 sunesc.East.Sun.COM
delivering mail jane@foo.com... Sent
{The mail has been sent to sunesc and is now the responsibility of the
sunesc to deliver or relay the mail to the destination} 2.4.2
sendmail debug mode to get basic sendmail info
To find out what some basic macros, user debug level 0.1:
$ /usr/lib/sendmail -bt -d0.1 < /dev/null
Version SMI-8.6
SYSTEM IDENTITY (after readcf):
(short domain name) $w = mercedes
(canonical domain name) $j = $w.$m
(subdomain name) $m = East.Sun.COM
(node name) $k = mercedes
This is very helpful in debugging "mail loops back to myself" problems,
which are caused by improper definition of $j.
2.4.3 sendmail debug to test address rulesets
To find where in a rule is matching, and how mail is being
routed, use debug level 21.12. In this case, we are looking to
check on how the "From" address is being rewritten:
doghouse -> /usr/lib/sendmail -bt -d21.12
Version 5.x
ADDRESS TEST MODE
Enter <ruleset> <address>
> 3,11 glen
rewrite: ruleset 3 input: "glen"
-----trying rule: $* "<" ">" $*
----- rule fails
... It runs thru the rules ...
rewrite: ruleset 11 input: "glen"
-----trying rule: $* "<" "@" $+ ">" $*
----- rule fails
-----trying rule: $=D
----- rule fails
-----trying rule: $+
-----rule matches: $@ $1 "<" "@" "doghouse"
">"
rewritten as: "glen" "<" "@"
"doghouse" ">"
rewrite: ruleset 11 returns: "glen" "<" "@"
"doghouse" ">"
This tells me that in ruleset 11 it matches:
R$+ $@$1<@$k> tack on my mbox
hostname
And Here is were the address ^^^^^^ is getting rewritten.
2.4.4 The MOST COMMON input to address ruleset debug mode
Folks, when we troubleshoot sendmail problems, we find the
most helpful ruleset rewriting modes are:
1. TO DEBUG WHERE MAIL IS GOING TO NEXT, WITH WHICH MAILER:
3,0,4 user@wherever.you.want
2. To DEBUG YOUR "From" ADDRESS WITH THE "ddn" MAILER:
3,22,4 user@sending.address
3. TO DEBUG YOUR "From" ADDRESS WITH THE "ether" MAILER:
3,11,4 user@sending.address
3.0 Common How Tos
3.1: How To Set Up a Sun As An Internet Mailhost
When setting up a Sendmail mailhost on the Internet, you should follow
the listed steps to ensure that the most basic configuration needs are
met. Other modification may be necessary to customize to your specific
environment.
1) Install the correct sendmail and sendmail.cf for a mailhost:
mv /usr/lib/sendmail /usr/lib/sendmail.nonmx
cp /usr/lib/sendmail.mx /usr/lib/sendmail
cp /etc/mail/main.cf /etc/mail/sendmail.cf
Note: Under Solaris 2.5 and higher, the first two steps, involving
/usr/lib, are not necessary. Same holds try for sendmail v8 patches
on 2.3. and 2.4.
2) In the /etc/mail/sendmail.cf file, change the following:
a. Comment out the line:
Dj$m
b. Uncomment the line:
Dj$w.$m
c. Change the DM macro from "smartuucp" to ddn:
DMddn
d. Define the Dm macro. Look for an example about "podunk.edu" and
a blank line). Put this anywhere that blank line:
Dm"Your domain name"
example:
Dmfoo.bar.com
NOTE: Dm NO SPACE AFTER THE "m" AND YOUR DOMAIN.
e. Comment out this line:
R$*<@$*.$+>$* $#$M $@$R $:$1<@$2.$3>$4
user@any.domain
f. Uncomment this line:
#R$*<@$*.$+>$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4
user@any.domain
Hint: in vi, search for ddn
g. If your host receives mail for multiple domains, add a "Cm" entry
after the "Dm" in Step "d.". NOTE THERE IS A SPACE AFTER
the "Cm"!
e.g.
Cm mydomain.com testdomain.com
h. If your host is receiving mail under different names for "local"
delivery, often you need to define those hosts in a "Cw" line:
e.g.
Cw www another-name and-another
3) Verify that DNS is working properly. Running the command "nslookup
sun.com" should return
Name: sun.com
Address: 192.9.9.1
In Solaris, dns must be defined in /etc/nsswitch.conf. In SunOS, NIS
must be running to use DNS.
4) Verify that the hosts file has been changed so that the machine is
identified as "mailhost".
The hosts file should look like:
xxx.xxx.xxx.xxx doghouse mailhost loghost
5) Remember to stop and restart the sendmail daemon if any changes
have been made to the sendmail.cf file.
To stop sendmail:
/etc/init.d/sendmail stop
To start sendmail:
/etc/init.d/sendmail start
When all of this is complete, the mailhost should be able to correctly
deliver its own mail to the internet, and in addition it should be
able to accept mail from mailer clients, and pass that on to the
internet.
3.2: How To Set Up a Sun As A Mail Client
Once you have set up a mailhost on your network, creating any number
of mail clients is relatively simple. By default, everything should be
setup correctly. The non-mx sendmail is default on Solaris previous to
2.5, as is the subsidiary.cf, and these are the items that you want to
use.
STEP #1 (SunOS 4.x or Solaris 2.3/2.4 without the V8 patch ONLY)
1a: cd /usr/lib
1b: ls -l sendmail*
1c: if "sendmail" is smaller than the "sendmail.mx" file
you have the non-mx version of sendmail, go to
STEP #2.
1d: is there a "sendmail.nomx" in the directory? If so,
copy it to "sendmail" and go to STEP #3. If not, you
wind up with the mx version of sendmail, which will work.
STEP #3 (All version of sendmail)
Gather the following information:
- your domain name that will be used with email (try the
command, "domainname").
- are you using NIS (YP) or NIS+ (nisplus)?
- The name of your mailhost (it might be "mailhost").
STEP #4
copy the /etc/mail/subsidiary.cf to /etc/mail/sendmail.cf (Solaris)
copy the /usr/lib/sendmail.subsidiary.cf to /etc/sendmail.cf (SunOS)
STEP #5 Edit sendmail.cf
5.a. If your mailhost has a name OTHER THAN "mailhost", change the
lines:
DRmailhost
CRmailhost
to reflect the name of the mailhost. Note NO SPACE between
DR and the name of the mailhost!!
5.b If you are not using NIS nor NIS+, *OR* if your
mail domain is different than the output from "domainname",
insert the line anyplace after the commented entry about
"podunk.edu":
Dmmaildomain.com
where "maildomain.com" is the name of your mail domain. Note
NO SPACE between Dm and the name of your mail domain!!!!
You don't need a "Cm" line, but if you feel better about that,
go ahead and put it in. Unlike "Dm", you put a space after
"Cm" e.g.
Cm maildomain.com
STEP #6 stop and restart sendmail! Usually it runs as:
/usr/lib/sendmail -bd -q1h
STEP #7 Test using mailx -v or /usr/lib/sendmail -v as discussed in
an earlier section of this Tips sheet.
Additional note about the mailhost or mail server:
Often times, customers just go in to their naming
service (/etc/hosts, NIS, NIS+ or DNS) and make sure that themail
server has the alternative name 'mailhost'. See if you
can ping it from your client:
rainbow% ping mailhost
corpmail2 is alive
...thats it!!
3.3: How to Force Sendmail to Rewrite Sender Addresses for Internal Email
By default, mail sent from mail clients (running subsidiary.cf) to
other machines in the same DOMAIN appears with the following Sender
Address:
user@machine
e.g.
user@rainbow
This procedure can be used to change the "From" address of the
mail to user@domain e.g. user@yourdomain.com .
Looking at your sendmail.cf, you will typically see that it is
running the ether mailer:
$ grep ^DM sendmail.cf
DMether
And the Mether line reveals that the following S and R rules are used
(see Section 1.4 and 2.3 for more info on sendmail rulesets if you like):
$ grep ^Mether sendmail.cf
Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h
Since we want to change the way that the Sender address is rewritten,
we must consult rule 11, which reads:
S11
R$*<@$+>$* $@$1<@$2>$3 already
ok
R$=D $@$1<@$w> tack on my
hostname
R$+ $@$1<@$k> tack on my mbox
host
It is common for sysadmins to want to replace user@machine ($1<@$w> or
$1<@$k>) with user@domain ($1<@$m>). In ether, the last two
lines
would be changed to the following:
R$=D $@$1<@$m> tack on my
hostname
R$+ $@$1<@$m> tack on my mbox
host
CAREFUL: There are tabs seperating some of these fields!!!
When these changes have been made, all mail sent with the "ether"
mailer will appear inthe format:
user@domain
e.g.
user@yourdomain.com
TIP:
Some admins might instead want to use $1<@$w.$m>, which would make
mail appear as:
user@machine.domain
Note that these changes only affect mail sent from an internal user to
another internal user.
If you're confused about the $w and $k, remember that:
/usr/lib/sendmail -bt -d0.1 < /dev/null
Will list out their values. It so happens that:
$w is the machine name,
$m is the domainname,
$k is the mailbox hostname where you have mounted /var/mail from
(as is noted in Section 1.4.4)
To test this out, either send some mail, or you can use address test mode
to see if it works or not:
/usr/lib/sendmail -bt -d21.12
> 3,11,4 user
...stuff spits out
rewrite: ruleset 4 returns: user @ mydomain . com
3.4: How to Force Sendmail to Rewrite Sender Addresses for External Email
This procedure is used for "site hiding" where you want the address
for all mail coming thru your mail gateway to read:
user@domain
e.g.
user@mydomain.com
Typically, a mailhost uses the ddn mailer. Consulting the Mddn line,
you will see that it uses rule 22 for the Sender address. This reads:
S22
R$*<@LOCAL>$* $:$1
R$-<@$-> $:$>3${Z$1@$2$} invert
aliases
R$*<@$+.$*>$* $@$1<@$2.$3>$4 already
ok
R$+<@$+>$* $@$1<@$2.$m>$3 tack on
our domain
R$+ $@$1<@$w.$m> tack on our
full name
The last two are relevent. The 'tack on our domain' line matches mail
of the format 'user@machine' and converts it to 'user@machine.domain'
(this rule is used when mail arrives on the mailhost from a client).
The 'tack on our full name' line matches mail of the format 'user' and
converts it to 'usr@machine.domain' This particular rule is used when mail
originates on the mailhost).
Note: Technically, it's an over simplification to say that $+<@$+>
matches user@machine, since it could match user@anything, but since
the line BEFORE it ($*<@$+.$*>) matches user@machine.domain, and then
applies $@, which causes a rewrite and then an EXIT from the ruleset,
nothing but user@machine ever gets down to the $+<@$+> rule. Similar
logic applies to why $+ only matches user.
Many administrators wish to make outgoing mail just read user@domain.
You can accomplish this by changing the last two lines as follows:
R$+<@$+>$* $@$1<@$m>$3 tack on
our domain
R$+ $@$1<@$m> tack on our full
name
Note this is only affects mail that is sent to external domains.
That's it! Test by sending out email.
Address test mode to use (note: mail relayed from another sun machine
comes in user@host, so you might also want to test that):
/usr/lib/sendmail -bt -d21.12
> 3,22,4 user
...stuff spits out
rewrite: ruleset 4 returns: user @ East . Sun . COM
(CTRL/D to exit)
/usr/lib/sendmail -bt -d21.12
> 3,22,4 user@host
...stuff spits out
rewrite: ruleset 4 returns: user @ East . Sun . COM
(CTRL/D to exit)
3.5: How To Route Mail Througha Firewall
There are many ways to implement sending mail thru a firewall based on
how the firewall is implemented. This may be a task that would be best
handled by a consultant (see Section 9.0 for how to get Consulting
help from Sun). This section 3.5 is provided "As is". DO NOT
EXPECT SUN SERVICE 800 # SUPPORT TO PROVIDE CONSULTING FOR FREE
ON THIS TOPIC BEYOND A "BEST EFFORT".
The most important consideration is that the firewall must be
configured to allow packets of type SMTP to pass both in and out of
the gateway.
Once your firewall is correctly configured, you'll need to decide upon
an internal mail configuration.
Most typically, you will set up a host to receive mail for each domain
directly from the Firewall. In this model you actually
would just use the "subsidiary.cf" file, and define the
relay name to be the firewall hostname:
DRfirewall-host
CRfirewall-host
Another possible method is to set up a mailhost on the internal side of
the network (see Section 3.1). After this is set up, set the macros DR
and CR on the mailhost to some machine that is able to talk directly
to the internet (this is probably your firewall machine):
DRfirewall
CRfirewall
You will also need to undo steps 2e and 2f of your initial mailhost
setup (ie, change the comment symbols back).
On the firewall itself, you would use the "main.cf" and
the procedure 3.1 (To set up an Internet mailhost).
Often, customers comment out Ruleset 6 so that the Firewall
relay the mail "inwards" to the subdomain mailhosts.
Just comment out the line after "S6".
Depending on the firewall, you may also need to be concerned about how
the mail is addressed going out and how it is going to return. A
single rule may need to be configured on the relay host to take all
mail coming in from the Internet and route it to the "inside domain"
mailhost. Section 1.4 explains a little bit about how rules work, and
will hopefully get you started.
4.0 Some Frequently Asked Questions
4.1: Miscellaneous Questions
QUESTION 1: How do i verify that sendmail is working?
A1: Using sendmail in verbose mode is a good method for verifying
sendmail is working and how the mail is sent. To do this, run the
following command:
> /usr/lib/sendmail -v "some user address"
this is a test of sendmail....
.
Sendmail will then give a verbose output. See section 2.0 on
"Debugging Sendmail" for further info.
Q2: Why is my "From" address being "blanked out" when sending
mail outside my domain via the mailhost?
A2: This should only be seen if the mailhost is not
running NIS or NIS+. Comment out the line in Ruleset 22 of
sendmail.cf that has a comment "invert aliases".
Q3: How do I limit the size of an outgoing sendmail message?
A3: How do I limit the size of an outgoing sendmail message?
In the sendmail.cf file, there are severeal "mailers"
defined. Of primary interest are "uucp", "ddn" and
"ether".
They are used for uucp mail, mail outside your domain,
and mail inside your domain.
You can define the maximum outbound message size on a
per-mailer basis, in the mailers definition.
Just add M=xxxxx to the mailer definition,
where xxxxxx is the maximum outbound message size.
For example, to limit the maximum uucp message size to 100,000 bytes:
Muucp, P=/usr/bin/uux, F=msDFMhuU, S=13, R=23,
to:
Muucp, P=/usr/bin/uux, F=msDFMhuU, S=13, R=23, M=100000,
^^^^^^^^
For the ddn mailer, to limit to 250,000 bytes:
Mddn, P=[TCP], F=msDFMuCX, S=22, R=22, A=TCP $h, E=\r\n, M=250000
^^^^^^^^
NOTE: this will not work for QUEUED messages on 2.3/2.4
without the sendmail version 8 patch(es).
Reference: "sendmail", pub by O'Reilly and Assoc, P. 388.
QUESTION 4: Why doesn't Sun provide the latest sendmail version 8?
ANSWER 4: Sun modified the sendmail code many years ago, and provides functionality
that is not in the sendmail v8 code. We also fixed some bugs and need
a stable code base to work from. In the future, we will be migrating
towards a more standardized mail environment. Right now we are stuck
with our "Sun-isms". Please note that Sun will not help you
debug problems with non-Sun sendmail, nor with configuration problems
with non-Sun supplied sendmail.cf files.
QUESTION 5: I am an ISP. I host mail for multiple domains. How can I get the
mail for each user to have a "From" address for the user's own
domain
instead of the domain of the mailhost?
ANSWER 5: You are looking for "reverse aliasing". Sun does not have a good
solution for this, and our sendmail v8 has known bugs with it,
about the only thing you can do is create a database or class
of usernames, work in S22 to match the username against the class,
and substitute the appropriate domain. Ugly, unsupported, but
a consultant can help you.
4.2: Configuration File & Mail Setup Questions
QUESTION: After making modifications to my sendmail.cf file, the
modifications do not seem to take effect. Why?
ANSWER: Sendmail allows one to create a "Frozen" Config file. The file
will reside with the sendmail.cf and be called sendmail.fc. Using a
frozen config file is not recommended until all testing is completed
and a stable mail environment is achieved. In order to make sure that
the new configuration file is being used, you can either remove the
frozen configuration file:
# rm sendmail.fc
Or, alternatively, create a new one:
# /usr/lib/sendmail -bz
QUESTION: Why does sendmail accept mail for every machine in my domain? How
do I prevent this?
ANSWER: The default sendmail.cf file tell sendmail to acccept mail for
every machine in your domain. This is almost always correct, because
if mail is sent to a machine, you usually want it to accept it.
However, there are some infrequent cases where you need to explicitly
tell sendmail to only accept mail for itself (for example, if you set
up a machine as a secondary MX, and you want it to only queue mail,
not actually process it). In this case, you must modify ruleset 6 in
the sendmail.cf.
By default, ruleset 6 reads as follows:
# special local conversions
S6
R$*<@$*$=m>$* $1<@$2LOCAL>$4
convert local domain
The LHS matches anything@anything.domain. The RHS tells sendmail to
treat such addresses as local. Changing ruleset 6 to read as follows
says to only treat items matching anything@machine-name as local:
R$*<@$=j>$* $1<@$2LOCAL>$3
convert local domain
Your $j variable must be set to $w.$m for this to have the desired
effect.
QUESTION: How do I prevent Solaris 2.5 from making use of MX records?
ANSWER: In Solaris prior to 2.5, you could use the non-MX version of
sendmail on internal machines, and not have those machines expand MX
records. Unfortunately, with Solaris 2.5, this functionality is no
longer availble. To convince sendmail not to expand MX records in 2.5
and higher, you just edit the sendmail.cf file and comment out
the line with the "OI" in it. Note MX lookups only occur if
you have "dns" specified anywhere on the /etc/nsswitch.conf hosts
entry.
4.3: Mail Command Line Error Messages
QUESTION: Why does mail _always_ fail with an "unknown host" error?
ANSWER 1: You have set up a mail client, with a subsidiary.cf, but you have
neglected to define a mailhost. You can verify this with the following
command:
% ping mailhost
corpmail2 is alive
If the ping instead give you 'host unknown', you must define a
mailhost before you can expect mail to work.
ANSWER 2: You have set up a mail server, with a main.cf, but without
following the precise instructions given in Section 3.1. As a result,
your server is expecting to find a relay machine called 'ddn-gateway',
and when it does not, mail fails. If you should have a mail relay
(such as in the firewall situation described in Section 3.5), then
define the DR and CR lines appropriately in your sendmail.cf. If you
should not, then follow the instructions in Section 3.1 to make sure
that all references to relays are removed from the sendmail
configuration file.
QUESTION: Why does mail _sometimes_ fail with an "unknown host" error?
ANSWER 1: This can occur on mailhosts prior to 2.5 if you neglected to
install the sendmail.mx binary. Compare the size of the sendmail and
sendmail.mx binaries:
% ls -l sendmail sendmail.mx
-r-sr-x--x 1 root 205846 Mar 20 1995 sendmail
-r-sr-x--x 1 root 234708 Mar 21 1995 sendmail.mx
If they are not the same size, you are not using sendmail.mx, and thus
sendmail will generate "host unknown" errors on any attempts to mail
to an MX record. Follow the instructions detailed in Section 2.1 to
replace the sendmail binary with sendmail.mx.
ANSWER 2: You do not have the "OI" entry in the /etc/mail/sendmail.cf
file because you just copied over one from an another
machine (typically seen with upgrades to 2.5 and 2.5.1).
QUESTION: Why does my Solaris machine generate the error "sendmail:
gethostbyaddr failed" whenever I send mail?
ANSWER 1: One of more of the IP addresses configured on your system
does not have a matching entry in /etc/hosts. sendmail
does a "reverse" lookup (input IP address, output hostname)
when it starts up, generating the error. You can either
fix /etc/host and your Nameservice, or ignore the message.
ANSWER 2: When Solaris 2.4 sendmail runs, it looks at all the ifconfiged
interfaces on a machine, and runs gethostbyaddr() on their addresses.
The above error is usually generated because there is an interface
with the address "0.0.0.0" on the machine. This can happen for two
reasons:
It might be that you have been testing out an interface, but it isn't
in full use, and happens to not have an IP address assigned. If this
is the case, get rid of the /etc/hostname.interface file, or do
whatever else is necessary to turn off this test interface. When you
reboot the machine, the error will disappear.
It might be that you are using an interface where it is legal to have
an address of 0.0.0.0 (ie, TR). If this is the case, you can work
around the error by using ifconfig to set an IP address on the
interface which appears in your /etc/hosts file. This is not
particularly recommended though, and it is probably better to just
ignore the error message.
4.4: Sendmail Bounce Messages
QUESTION: Why does mail bounce with one of the following error messages:
"I refuse to talk to myself"
"553 Host name configuration error"
"Local configuration error"
ANSWER: This occurs when sendmail tries to deliver a piece of mail,
THINKS that it should do a remote delivery, via SMTP, connects to the remote
machine, and finds out that the remote machine is itself.
This is most often because the Dj variable has been defined
incorrectly, or because the host is known to receive mail locally
by a name different than told in the sendmail.cf file.
SOLUTION 1:
You put a space after the "Dm" in sendmail.cf, or mis-spelled
your domain.
Remember: NO SPACE AFTER Dm when defining your local domain: Dmmydomain.com
SOLUTION 2 (Also frequent):
Dj set incorrectly because you read the comments in the
sendmail.cf file which are confusing and misleading:
$j should generally be the "long" or "canonical" hostname of
your
machine, which would be the entry:
Dj$w.$m
$j might be set to different things, depending on how your sendmail is
configured:
rainbow% grep ^Dj /etc/mail/main.cf
Dj$m
rainbow% grep ^Dj /etc/mail/subsidiary.cf
Dj$w.$m
(In the first case, $j is set to domain, while in the second, it is
set to machine.domain.)
You can examine $j by looking at the sendmail.cf,
or with the command:
/usr/lib/sendmail -bt -d0.1 < /dev/null, or by connecting to port 25:
rainbow% telnet localhost 25
Trying 127.0.0.1 ...
Connected to localhost.
Escape character is '^]'.
220 rainbow.Corp.Sun.COM Sendmail SMI-8.6/SMI-SVR4 ready at Mon, 11 Mar 1996
17:03:06 -0800
The word after '220' and before 'Sendmail' is the $j variable,
'rainbow.corp.sun.com' ($w.$m) in this example.
IF YOU SET Dj$m AND DO NOT WANT TO CHANGE IT, just use the
Cw to define the Class w (names I receive mail for) to reflect that $m,
e.g.
Cw mydomain.com
ANSWER 2:
A machine does not know that it should accept mail for a foreign
domain. By default, sendmail.cf will tell sendmail to accept mail for
anything in its own domain. For example, if your mail machine is
mailer.test.com, it will accept mail for any machine in the test.com
domain (test7.test.com, foobar.test.com, etc). If you want to accept
mail for additional domains, you must modify the Cm variable. The
following would tell sendmail to accept mail for both the test.com
domain, and the other.com domain:
Cm test.com other.com
Without these lines, your mailhost would receive mail for
something.other.com, have no rules for local delivery, and send it out
to the net, where it would try to connect with itself.
ANSWER 3:
You are using a global MX record for your entire domain. Global MX
records are really not recommended, because they can cause no end of
problems. In this particular case, your problem is that foreign mail
(ie to sun.com) get expanded by DNS per the normal search path (ie to
sun.com.test.com) and then bounced back to your own machine.
You can work around this by changing the following line in a main.cf:
R$*<@$*.$+>$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4
user@any.domain
To:
R$*<@$*.$+>$* $#ddn $@ $2.$3. $:$1<@$2.$3>$4
user@any.domain
But, be aware that this is just a kludge, and may cause other oddness.
Global MX records cause problems and should not be used.
ANSWER 4: Two machines have the same $j name. This occurs most frequently
when you have two machines in the same domain which each identify
themself as $m. This will occur if you have two main.cfs in the same
domain that talk to each other. Look carefully at your bounce message,
and see if it occurred when trying to deliver to a machine OTHER than
your own. If so, see if they have the same $j definition. If they do,
you will need to differentiate them in some way.
QUESTION: Why does mail bounce with the following error messages:
"mail: Can't open '/tmp/mailAAAa00757' type: r+"
ANSWER: Despite the nonintuitive error message, this is actually the result
of bad permissions in /var/mail. By default, /var/mail should have
permissions of 3777. If your machine has different permissions, you
should change them to 3777 to prevent mail from bouncing.
QUESTION: Why does mail bounce with a "unknown mailer" error
ANSWER 1: Could be the sendmail.cf definition of "DM" (major relay mailer)
is misspelled.
ANSWER 2: Sometimes this is caused by program mailer errors in
a mail alias. This error is usually happening when an alias
is writing to a file, or running a program, and encounters
an error. Debug the alias in question on the host that
was "receiving" the message.
5.0 Patches
The following patches are particular to using mail. These can be
acquired via the SunSolve site online or the SunSolve CD. If you are
having problems with sendmail, you should apply the appropriate
patches before investigating further.
In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve1.sun.com.
5.1: SunOS Patches
100377-22 SunOS 4.1.3: sendmail jumbo patch
100224-13 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
101140-02 SunOS 4.1.3: /usr/ucb/Mail does not pass comma separated address
as per RFC822
101436-08 SunOS 4.1.3_U1: patch for mail executable
101665-07 SunOS 4.1.3_U1: sendmail jumbo patch
101453-01 SunOS 4.1.3_U1:/usr/ucb/Mail does not pass comma separated
address as per RFC822
102414-01 SunOS 4.1.4: mail jumbo patch
102423-04 SunOS 4.1.4: Sendmail jumbo patch
NOTE: SunSoft is not providing sendmail v8 for SunOS 4.1.X.
5.2: Solaris Patches
101574-06 SunOS 5.3: /usr/bin/mail jumbo patch
101642-01 SunOS 5.3: Jumbo mailx patch
101712-01 SunOS 5.3: uucleanup isn't careful enough when sending mail
101739-13 SunOS 5.3: sendmail jumbo patch - security
101359-04 SunOS 5.3: DNS spoofing is possible per Cern ca-96.02
102042-05 SunOS 5.4: 5.x /bin/mail should be backward-compatible with 4.x
102066-15 SunOS 5.4: sendmail jumbo patch - security
102479-04 SunOS 5.4: DNS spoofing is possible per Cern ca-96.02
102165-03 SunOS 5.4: nss_dns.so.1 fixes
102043-01 SunOS 5.4_x86: 5.x /bin/mail should be backward-compatible with 4.x
102064-12 SunOS 5.4_x86: sendmail jumbo patch - security
102480-04 SunOS 5.4_x86: DNS spoofing is possible per Cern ca-96.02
102166-03 SunOS 5.4_x86: nss_dns.so.1 fixes
103276-01 SunOS 5.5: /bin/mail generates IOERR return code for quota exceeded
102980-10 SunOS 5.5: sendmail fixes
103667-03 SunOS 5.5: DNS spoofing is possible per Cern ca-96.02
102981-09 SunOS 5.5_x86: sendmail fixes
103668-03 SunOS 5.5_x86: DNS spoofing is possible per Cern ca-96.02
103594-06 SunOS 5.5.1: /usr/lib/sendmail fixes
103663-05 SunOS 5.5.1: DNS spoofing is possible per Cern ca-96.02
103680-01 SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3
103595-05 SunOS 5.5.1_x86: /usr/lib/sendmail fixes
103664-05 SunOS 5.5.1_x86: DNS spoofing is possible per Cern ca-96.02
103681-01 SunOS 5.5.1_x86: nscd/nscd_nischeck rebuild for BIND 4.9.3
Note: Patches 101739, 102066 and 102064 are necessary to upgrade
sendmail version from 5.6.5 to 8.6.10+.
6.0 Known Bugs And RFEs
6.1: RFEs
1237869 solaris sendmail8 does not support keyed databases
The current version of sendmail on Solaris does not support the keyed
database functionality present in other versions of 8.6. This RFE requests
that the keyed database functionality be added.
|