| Infodoc ID |
|
Synopsis |
|
Date |
| 12815 |
|
Sun Sendmail Support Document/FAQ |
|
22 Feb 2000 |
Product Support Document (PSD) for Sun Sendmail
Revision 2.3
April 30, 1998
1.0: About Sun's Sendmail
1.1: Sendmail Clients And Servers
1.2: Sendmail Mailers
1.3: Sendmail Version
1.4: A Few Words on Sendmail Rules
2.0: Debugging Sendmail
2.1: Port 25 Connections
2.2: /usr/ucb/mail -v
2.3: Sendmail Debug Functions
3.0: Common How Tos
3.1: How To Set Up a Sun As An Internet Mailhost
3.2: How To Set Up a Sun As A Mail Client
3.3: How to Force Sendmail to Rewrite Sender Addresses for Internal Email
3.4: How to Force Sendmail to Rewrite Sender Addresses for External Email
3.5: How To Route Mail Through a Firewall
3.6: How To setup reverse aliasing
3.7: How do you stop mail from bouncing between two machines
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: Sendmail Bounce Messages
5.0: Patches
5.1: SunOS Patches
5.2: Solaris Patches
6.0: Known Bugs & RFEs
6.1: RFEs
7.0: References
7.1: Important Man Pages
7.2: SunSolve Documents
7.3: Sun Educational Services
7.4: Solaris Documentation
7.5: Third Party Documentation
8.0: Supportibility
9.0: Additional Support
1.0 About Sun Sendmail
1.0: About Sun's Sendmail
=========================
This PSD documents a wide variety of information concerning Sendmail,
as implemented in the SunOS and Solaris operating systems. It is
intended as both an introduction to Sendmail, and as a guide to the
most common problems. There are many more complete references to
Sendmail, a few of which are noted in section 7.0.
Due to the different versions of Sendmail available this document is most
applicable to versions 8.6 and older that you may be running on your
SunOS 4.1.x through Solaris 2.6 machines (however your specific version
of sendmail may be different due to the patch level you are running. Please
see section 1.3 below for more information on sendmail versions and how
to tell what version you are running.) If you have questions regarding
the 8.8 and newer versions of Sendmail you should call SunService and find
out if there is a PSD or document available for that version of Sendmail.
However, you will find that many of the debugging tips will apply to
many versions of sendmail.
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 sendmail.
The only differences will be different paths for the sendmail.cf and
new functionality defined within the sendmail.cf for Solaris.
1.1: Sendmail Clients And Servers
---------------------------------
Sun provides a basic client/server framework for Sendmail. 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 mailhosts and provides
all the Sendmail rules needed to route mail onto the Internet.
The SUBSIDIARY.CF file is for machines that will only route mail
directly to interal hosts and that will send outbound mail to the
designated mailhost. The subsidiary.cf file is the default sendmail.cf
file when the system is installed.
Sun provides V8.6.10+sun binaries for SunOS 4.1.4, Solaris 2.3, 2.4, 2.5
For Solaris 2.5.1 & 2.6 Sun's current patches uprev sendmail to V8.8.8+sun
Sendmail V8.9.1 will be bundled into Solaris 2.7
All other versions of SunOS use V5 sendmail. In both SunOS sendmail versions
(V5 & V8.6.10), two binaries are provided /usr/lib/sendmail &
/usr/lib/sendmail.mx. So if you want to have sendmail look for DNS MX records,
copy /usr/lib/sendmail to /usr/lib/sendmail.nomx and copy /usr/lib/sendmail to
/usr/lib/sendmail.
In Solaris 2.3, 2.4, & 2.5 with the latest Solaris sendmail V8 patch
installed, there is only one version of sendmail, which
combines the functionality of the former sendmail and sendmail.mx
programs. These newest binaries "turn on" the MX mode when *two*
conditions are met. First, the "OI" (option I) is set in the
/etc/mail/sendmail.cf (which is there by default), and second, by adding
"dns" in any position in the "hosts: " line in the /etc/nsswitch.conf file.
In Solaris 2.5.1, 2.6 with the latest Solaris sendmail V8.8.8+sun patch
installed in the Solaris 2.7 bundled V8.9.1+sun sendmail, there is only one
binary and MX mode is turned on only by the existance of "dns" in any position
in the "hosts: " line in the /etc/nsswitch.conf file.
1.2: Sendmail Mailers
---------------------
In sendmail, a "mailer" is selected based on the destination address (this
is done in ruleset 0). The mailer is a specification that describes certain
characteristics that a message must have and provides the ability to pass both
the sender & receipient addresses through rulesets unique to this mailer.
Some mailers are standard: for example, the "local" mailer always delivers
to local users, while the "prog" mailer always delivers to local programs.
In the sendmail V8.8.8 and above, sun uses standard berkely sendmail config
source files so the best reference for this info is at the URL:
http://www.sendmail.org
In the V8.6.10+sun and below, Sun includes other mailers in the configuration
files:
ether: This mailer is very similar to ddn, but it intended only for
"internal" networks of Suns within a single domain name. 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 mailhost knows how to route mail within the
local domain.
uucp: this mailer is, as the name implies, intended for use with uucp
connected hosts.
ddn: short for Data Defense Network, an old version of the Internet.
This mailer (together with ruleset 22) is only included in the
/etc/mail/main.cf (SunOS /usr/lib/sendmail.main.cf) and is a good choice
for mail destined for other domains or non-Sun machines.
smartuucp: This mailer is only necessary if the local network is
connected to external networks via UUCP. The smartuucp mailer is included
in only the main.cf file and is meant to deliver mail via uucp networks
while still using domain style addresses.
1.3: Sendmail Version
---------------------
All versions of SunOS, and Solaris earlier than 2.3 support sendmail
version 5.
Solaris 2.5, and versions of Solaris 2.3 and 2.4 which have the
sendmail V8 sendmail patch installed, support sendmail version 8.6.10+sun,
as modified by Sun. Without the sendmail patches, Solaris 2.3 and 2.4
will only be running sendmail V5.
Solaris 2.5.1 & 2.6 with the latest patch upgrade sendmail to V8.8.8+sun.
Solaris 2.7 has bundled sendmail V8.9.1+sun.
Sendmail version 8.7 or greater can be acquired from the public
domain, but it is not supported by SunService.
Generally, you will find the version that most sendmail hosts are
using, by connecting directly to the SMTP port 25 with either the
"mconnect" command on Sun's or by telneting to port 25. Below you
will see examples of each of the sendmail binaries responding
(V5, V8.6.10+sun, V8.8.8+sun):
$ mconnect host_V5
connecting to host host_V5 (129.151.26.1), port 25
connection open
220 host_V5.omnilab.com Sendmail 5.0/SMI-SVR4 ready at Wed, 19 Feb 1997
$ telnet host_V8.6 25
connecting to host host_V8.6 (129.151.26.2), port 25
connection open
220 host_V8.6.omnilab.com Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997
$ mconnect host_V8.8.8 25
connecting to host host_V8.8.8 (129.151.26.3), port 25
connection open
220 host_V8.8.8.East.Sun.COM ESMTP Sendmail 8.8.8+Sun/8.8.8; Thu, 24 Sep 1998
10:18:58 -0400 (EDT)
Reminder: Type in "quit" to get out of SMTP port 25.
1.4: A Few Words on Sendmail 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
defintions 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
ie: $=m matches anything the "the class of m"
(In Sun's sendmail, "m" is domain and the "class of m" can be seen by
running: "/usr/lib/sendmail -bt -d37.12" and look through the output for
lines like: "setclass(m, East.Sun.COM)"
(A token is one "part" of the sendmail address, seperated 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 (ie $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 relevent:
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' (ie 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 if you don't know
where to look.
It's been noted previously that the rulesets are applied to From
addresses AND to 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 (ie nfs-host)
$w machine name (ie 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.1.1 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.2: /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 mailhsot.
/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.3: Sendmail Debug Functions
-----------------------------
When debugging, consider the information provided by running sendmail
in verbose mode, and in debug mode
2.3.1 sendmail verbose mode 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.3.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.3.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.3.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
2.3.5 Sendmail debug switches and what they mean?
27.1 aliases & NIS aliases & .forward
5.5 setevent timer, clear, tick
5.6 timer tivk parsing
30.1 header info
30.3 apparently to
30.2 eat from
15.15 network debugging
15.1 get requests
15.2 forking, returning
16.1 calling, remote
16.14 network debugging
10.1 deliver
10.1 sendto
38.1 before the wait() on pid, fork with pid
11.1 open mailer
13.1 send all
13.3 checking queue
13.4 errors to
8.2 MX options
8.1 MX search result
8.3 MX answer, type
8.1 MX get common host info
8.1 MX answers
50.1 drop envelope
45.1 set sender (From:), from domain
31.6 drop envelope
32.1 collected header
31.1 capitalised, message id
33.1 initial to: address
14.2 commasize
35.24 expand
35.9 define
0.4 canonical name, aka
0.15 configuration table
1.1 print from
2.1 finis
52.1 disconnect
52.5 don't
20.1 parseaddr
22.45 prescan
22.101 state
22.101 newstate
22.36 token is
21.2 rewrite rule
21.12 trying rule
21.35 op
21.10 rule fails
21.12 rule matches
21.15 ?
21.3 call subr
21.4 rewritten as
21.2 returns
12.1 remote name
40.1 queueing
41.2 orderq cannot open
40.1 qsort, dowork
40.4 control file
7.20 queuename
7.1 queuename is
51.4 queuename unlink
37.1 setoption
37.1 ignored
37.1 unsafe
25.1 sendto list
27.1 found self reference
27.1 found self alias
26.1 recipient
26.1 in sendq
6.1 savemail error mode, return to sender
6.5 print state
36.5 stats symbol table
36.9 print function
18.1 smtp init
18.1 reply
18.100 parse
18.1 message is ...
0.44 argv =
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 #2. If not, you
wind up with the mx version of sendmail, which will work.
STEP #2 (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 #3
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 #4
Edit sendmail.cf
4a. 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!!
4.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 #5
stop and restart sendmail! Usually it runs as:
/usr/lib/sendmail -bd -q1h
STEP #6
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 Through a 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.
3.6: How To setup reverse aliasing
----------------------------------------
Let's say I want to have my unix account "bozo" become
"bozo_the_clown@comedy.com" when mail from me leaves my NIS domain (or at
lclowns
passes through my NIS domain "mailhost"). By the way this is what the
standard reverse aliasing is supposed to do. Mail within the domain doesn't
get aliased.
First you need to setup the alias file that the NIS map is created from with
the personal aliases in this manner:
bozo_the_clown: bozo@harpo
bozo: bozo_the_clown
bclown: bozo_the_clown
bozoc: bozo_the_clown
Note: the "official" alias is the only one that expands to
unix_account@mailbox_server and all other aliases expand to the "official"
alias. This is important because when the the reverse map (mail.byaddr) is
built there will be one and only one key that looks like "bozo@harpo" and the
data for that key is "bozo_the_clown". The next thing you have to do is check
/var/yp/Makefile on the NIS master to insure this line is correct:
MKALIAS=$(YPDIR)/mkalias
Change to:
MKALIAS=$(YPDIR)/mkalias -s -n
The "-s" turns on "simple" mode. Otherwise, the default is that when mkalias
encounters the alias "bozo_the_clown bozo@harpo", it will use the part
before the "@" ("bozo", in this case) as a key, fetch the translation
("bozo_the_clown"), compare it to the LHS ("bozo_the_clown") of the record
it is processing, and since they are equal, decide to produce the "bozo@harpo
bozo" entry in mail.byaddr which will defeat your efforts. With "-s", mkalias
skips that extra lookup step.
The "-n" option has no relevance for the current problem, but it makes
mkalias attempt to capitalize full names, which usually looks nicer than all
lower case.
Now let's say the NIS domain is "clowns.comedy.com and "mailhost" is an
alias for "groucho" in the NIS hosts map. "groucho" is using the main.cf file.
"harpo" is sharing /var/mail and it is using a standard unmodified
subsidiary.cf file. Now I'm logged into another host "zepo" that is mounting
/var/mail from "harpo" (actually I can be logged into any machine that is
mounting /var/mail from harpo including harpo itself) and it is also using an
unmodified subsidiary.cf file.
So now I send mail to root@foo.com . "zepo", because it is mounting /var/mail
from "harpo" sends the message to "harpo" because of the "remote mode"
operation and it does this passing the sender's addr through ruleset 11. Here
the user "bozo" is going to be changed to "bozo@harpo" because of the last
rule in that set ($k is a special macro that is set to the hostname of the
/var/mail server as reported by /etc/mnttab).
S11
R$*<@$+>$* $@$1<@$2>$3 already ok
R$=D $@$1<@$w> tack on my hostname
R$+ $@$1<@$k> tack on my mbox
hostname
So now harpo gets this message destined for "root@foo.com" from "bozo@harpo"
and harpo simply passes the message up the ladder to "mailhost".
Now "groucho" gets this message and because it is using the main.cf file and
the destination "root@foo.com" is not local, it will process the sender addr
through ruleset 22. It is ruleset 22 that finally does the reverse aliasing.
DZmail.byaddr
#DZREVERSE.mail_aliases.org_dir
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 second rule in the set matches a_single_token@a_single_token
and nothing else. So "bozo@harpo" will work but
"bozo.bozo@harpo" or "bozo@harpo.clowns" will not. So once we get past the LHS
"$-<@$->", the RHS "$:$>3${Z$1@$2$}" looks up "$1@$2" which is "bozo@harpo" in
the NIS map "Z" (mail.byaddr) and the whole mess gets replaced with
"bozo_the_clown" which then gets passed through ruleset 3 again and when that
is
done we go on to the next rule in the set but now because there is no "@" part
in the addr it will fail until it finds the last rule in the set and here it
will add the full name (more than not, we remove the "$w." from the RHS of
this rule and the one above it to hide hostnames).
There are lots of ways to modify this (and break it).
Oh and btw - in non NIS/NIS+ environments that reverse aliasing rule in
ruleset 22 is susicidal because it will return a NULL! This can set the stage
for the mail that gets returned with @@domain ... best thing to do is comment
it out in those environments.
3.7 How do you stop mail from bouncing between two machines?
One thing you should be able to do is run the sendmail daemon in queue-only
mode. This way it will accept the bad mail that is bouncing between the
machines
but rather than deliver it immediately it will stay in the queue waiting for
the next queue run. You should then monitor the messages in the queue with
the 'mailq' command and delete the d (data), q (queue control), t (temp)
and x (transcript) files related to the problem message.
Stop sendmail:
/etc/init.d/sendmail stop
and then start it this way:
/usr/lib/sendmail -bd -odq -q1h
It will queue all mail for the next hour and then at the hour mark it will
attempt to deliver all the mail in the queue. Make sure you remove all of
the bouncing messages from the queue before the hour is up.
After you have removed the offending messages from the queue make sure that
you restart sendmail with whatever options you had running before. You should
also analyze the bounced message and find out why the two machines were
passing it back and forth so that it doesn't happen again. You may have an
alias loop of some sort (start by checking things like: /etc/mail/aliases,
naming services aliases maps, .forward files .mailrc files on both machines
involved.)
4.0 Some Frequently Asked Questions
4.1: Miscellaneous Questions
----------------------------
Q1: 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.
Q4: Why doesn't Sun provide the latest sendmail version 8?
A4: 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.
Q5: 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?
A5: 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
----------------------------------------------
Q: After making modifications to my sendmail.cf file, the
modifications do not seem to take effect. Why?
A: 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
Q: Why does sendmail accept mail for every machine in my domain? How
do I prevent this?
A: 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.
Q: How do I prevent Solaris 2.5 from making use of MX records?
A: 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
-------------------------------------
Q: Why does mail _always_ fail with an "unknown host" error?
A1: 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.
A2: 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.
Q: Why does mail _sometimes_ fail with an "unknown host" error?
A1: 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.
A2: 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).
Q: Why does my Solaris machine generate the error "sendmail:
gethostbyaddr failed" whenever I send mail?
A1: 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.
A2: 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
ANOTHER ANSWER:
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.
Q: Why does mail bounce with the following error messages:
"mail: Can't open '/tmp/mailAAAa00757' type: r+"
A: 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.
Q: Why does mail bounce with a "unknown mailer" error
A1: Could be the sendmail.cf definition of "DM" (major relay mailer)
is misspelled.
A2: 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
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 sunsolve.sun.com.
5.1: SunOS Patches
------------------
100377 SunOS 4.1.3: sendmail jumbo patch
100224 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
101140 SunOS 4.1.3: /usr/ucb/Mail does not pass comma separated address
as per RFC822
101436 SunOS 4.1.3_U1: patch for mail executable
101665 SunOS 4.1.3_U1: sendmail jumbo patch
101453 SunOS 4.1.3_U1:/usr/ucb/Mail does not pass comma separated
address as per RFC822
102414 SunOS 4.1.4: mail jumbo patch
102423 SunOS 4.1.4: Sendmail jumbo patch
NOTE: SunSoft is not providing sendmail v8 for SunOS 4.1.X
5.2: Solaris Patches
--------------------
101574 SunOS 5.3: /usr/bin/mail jumbo patch
101642 SunOS 5.3: Jumbo mailx patch
101712 SunOS 5.3: uucleanup isn't careful enough when sending mail
101739 SunOS 5.3: sendmail jumbo patch - security
101359 SunOS 5.3: DNS spoofing is possible per Cern ca-96.02
102042 SunOS 5.4: 5.x /bin/mail should be backward-compatible with 4.x
102066 SunOS 5.4: sendmail jumbo patch - security
102479 SunOS 5.4: DNS spoofing is possible per Cern ca-96.02
102165 SunOS 5.4: nss_dns.so.1 fixes
102043 SunOS 5.4_x86: 5.x /bin/mail should be backward-compatible
with 4.x
102064 SunOS 5.4_x86: sendmail jumbo patch - security
102480 SunOS 5.4_x86: DNS spoofing is possible per Cern ca-96.02
102166 SunOS 5.4_x86: nss_dns.so.1 fixes
103276 SunOS 5.5: /bin/mail generates IOERR return code for quota exceeded
102980 SunOS 5.5: sendmail fixes
103667 SunOS 5.5: DNS spoofing is possible per Cern ca-96.02
102981 SunOS 5.5_x86: sendmail fixes
103668 SunOS 5.5_x86: DNS spoofing is possible per Cern ca-96.02
103594 SunOS 5.5.1: /usr/lib/sendmail fixes
103663 SunOS 5.5.1: DNS spoofing is possible per Cern ca-96.02
103680 SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3
103595 SunOS 5.5.1_x86: /usr/lib/sendmail fixes
103664 SunOS 5.5.1_x86: DNS spoofing is possible per Cern ca-96.02
103681 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.
6.1: RFEs
---------
Sendmail V8.6 doesn't have any control hooks for preventing Spam and relaying.
Sun is currently working on sendmail V8.8.8+sun. This will be
available
as a patch for Solaris releases 2.5 through 2.6 and will be part of
Solaris 2.7. It is expected to be available sometime in Feb 98. Work
will begin shortly on back-porting this into a patch of some sort for
older releases.
7.0 References
7.1: Important Man Pages
------------------------
aliases
mail
mailx
newaliases
sendmail
uucp
7.2: SunSolve Documents
-----------------------
7.2.1: FAQs
-----------
faqs 1802 Listing of the mail services programs and files
faqs 1803 How to show macro definition/expansion used by sendmail
7.2.2: SRDBs
------------
srdb 3582 Sendmail error "250 Deferred: bad file number"
srdb 4951 /etc/aliases: line 14: cannot alias non-local names
srdb 11072 What are the known bugs with the Berkeley sendmail 8.6.
srdb 11074 sendmail error: unknown mailer error 5
srdb 11513 sendmail does not prefix ">" to extra "From "'s of incl
7.3: Sun Educational Services
-----------------------------
Solaris 2.X Network Administration (1-800-422-8020)
7.4: Solaris Documentation
--------------------------
Solaris documentation can be purchased in hard copy or through the
System Administrator AnswerBook.
_Users Accounts, Printers, and Mail Administration_
_Name Services Administration Guide_
_Name Services Configuration Guide_
_TCP/IP Network Administration Guide_
7.5: Third Party Documentation
------------------------------
_Sendmail_, Bryan Costales with Eric Allman & Neil Rickert O'Reilly &
Associates, Inc.
_DNS and Bind_, Paul Albitz & Cricket Liu O'Reilly & Associates, Inc.
_Managing UUCP and Usenet_, Tim O'Reiley and Grace Todino O'Reilly &
Associates, Inc.
8.0: Supportibility
===================
The setup and administration of Sendmail is to be performed by the
Network administrator. SunService is not responsible for the
customization of the sendmail configuration file. The writing or
modification of sendmail rules are the responsibility of the System
Administrator.
9.0: Additional Support
=======================
For Customization or network setup, please contact your local
SunService office for possible consulting offerings. Sun's Customer
Relations organization can put you in touch with your local
SunIntergration or Sales office. You can reach Customer Relations at
800-821-4643.
Top
Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team
