Content and links to other pages:
Even though this article is from 1985, it describes the rewriting process of sendmail pretty well.
If you want to configure a
Sun
for e-mail you should read
How to Fix a Cranky Sun Mail System.
This is written for SunOS 4 and for SunOS 5.x
(aka Solaris 2.x) with x < 5.
Beginning with SunOS 5.5, Sun ships sendmail 8 (.6),
so you can use only part of the hints for that version.
E.g., there is no
sendmail.mx
anymore.
Sun
released a patch which upgrades sendmail to version 8.8.
However, your best choice is to upgrade to sendmail 8.9. The actual version (1998-07-02) is sendmail 8.9.1 ( PGP signature). Other FTP servers are available too.
Two important documents about the upgrade are: Converting Standard Sun Config Files to Sendmail Version 8 and Sendmail Issues when Migrating from SMI-8.6 to Berkeley 8.8.
Other questions should be answered in the
FAQ of sendmail V8
(long maintained by
Brad Knowles;
the original version is from the inventor of sendmail himself:
Eric Allman,
now it's back
at sendmail.org
).
The
Sendmail Installation and Operation Guide (HTML)
is part of the documentation from the
sendmail package.
It provides an in-depth explanation of sendmail.
The
cf/README
file from the
sendmail distribution
explains how to
build a configuration file for your specific needs
from a simple
m4 description file.
A
sendmail.cf
file for clients
(sends every mail to a designated mailhost)
may be used on every host which shouldn't deal with e-mail itself.
Such a file can also be generated using
FEATURE(nullclient)
in a
.mc
file.
* I'm getting "Local configuration error" messages, such as:
553 MX list for domain.net points back to relay.domain.net 554 <user@domain.net>... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to your configuration file. IMPORTANT: When making changes to your configuration file, be sure you kill and restart the sendmail daemon (for ANY change in the configuration, not just this one): kill `head -1 /etc/sendmail.pid` sh -c "`tail -1 /etc/sendmail.pid`" NOTA BENE: kill -1 does not work with versions prior to 8.7.y!
How can I solve this problem? There are two possibilities:
dom.ain
) to be
forwarded to a specific host (in this case, relay.dom.ain
)
by using an MX record, but the relay machine doesn't
recognize itself as dom.ain
.
Add dom.ain
to
/etc/sendmail.cw
(if you are using FEATURE(use_cw_file)
) or
add
Cwdom.ainto your configuration file.
relay.dom.ain
should send this
to another host mail.dom.ain
which really handles the mail for dom.ain
.
If this host is reachable by SMTP you should create
an MX record with the best (lowest) priority pointing to mail.dom.ain
.
Make sure that relay.dom.ain
really knows it is
relay.dom.ain
!
If you setup the MX records, you must use the correct name
for relay.dom.ain
.
mail.dom.ain
is reachable by some other mail transport protocol
(UUCP) or it is not directly reachable from the outside,
you may have
a look at the feature mailertable.
E.g., use in your .mc configuration file something like
FEATURE(mailertable,`dbm -o /etc/mailertable')(or another database type, see
makemap(8)
)
and add a line like the following to the mailertable:
dom.ain smtp:[mail.dom.ain]The square brackets (
[ ]
) tell sendmail to ignore MX records
for mail.dom.ain.
Two more hints:
An MX record shouldn't point to a CNAME, it will most probably cause
you a lot of trouble.
(And currently it violates
RFC 974
).
And from
src/READ_ME
:
WILDCARD MX RECORDS ARE A BAD IDEA! The only situation in which they
work reliably is if you have two versions of DNS, one in the real world
which has a wildcard pointing to your firewall, and a completely
different version of the database internally that does not include
wildcard MX records that match your domain. ANYTHING ELSE WILL GIVE
YOU HEADACHES!
IMPORTANT: Be sure you kill and restart the sendmail daemon after you change the configuration file (for ANY change in the configuration, not just this one):
kill `head -1 /etc/sendmail.pid` sh -c "`tail -1 /etc/sendmail.pid`"
NOTA BENE: kill -1 does not work!
See also next paragraph for a related question!
If it still doesn't work, take a look at some more explanations.
sendmail 8.8 offers direct support for virtual users/domains .
* How do I make all my addresses appear to be from a single host?
Using the V8 configuration macros, use:
MASQUERADE_AS(my.dom.ain)
This will cause all addresses to be sent out as being from
the indicated domain.
If you're using version 8.7 sendmail, and you want to hide this
information in the envelope as well as the headers, use:
FEATURE(masquerade_envelope)
If you also want to masquerade the recipients, use
FEATURE(allmasquerade)But be careful and read cf/README about possible problems!
Another section in cf/README explains how to masquerade for other hosts too. Usually, masquerading works only for all elements of class w. This class contains all names local to that host. But you can also add more hosts to class M which will be masqueraded too.
sendmail 8.8 offers even more flexibility with respect to masquerading .
You may also have a look at the genericstable FEATURE.
If you still use Sun's sendmail prior to version 8.6, look for a rule (should be in ruleset 22) like
R$+<@$+>$* $@$1<@$2.$m>$3 tack on our domainand change it to
R$+<@$+>$* $@$1<@$m>$3 tack on our domainif you have correctly defined $m. If you have SunOS 5.x (with x < 5; aka Solaris 2.x) you also have to change the following rule:
R$+ $@$1<@$w.$m> tack on our full nameinto:
R$+ $@$1<@$m> tack on our domain
sendmail 8.8 has some new rulesets to check who can use your machine as a mail gateway. Using check_* in sendmail 8.8 gives an overview how to use these rulesets, 8.9 has standard FEATUREs to this effect.
If you have sendmail 8.x (with x < 8), you can do the following to refuse mails from unwanted domains/hosts: Put into ruleset 98 something like: (this is LOCAL_RULE_0 in your .mc file)
R$* < @$*$=K . > $* $#error $@ 5.7.1 $: "This domain is banned." R$* < @$*$=K > $* $#error $@ 5.7.1 $: "This domain is banned."And define a class K by:
FK/etc/banned.domainsIn this file, you should put the names of the banned domains, e.g.,
cyberpromo.com quantcom.com savetrees.comIf you want to specify the user(s) too, you have to replace the first $* with the name or a match for a class.
Another possibility is to use tcp_wrappers. There is a patch available for sendmail 8.7.x, which incorporates the functionality directly into sendmail. Using this approach, you can define the access to your sendmail daemon based on the rules available for tcp_wrappers .
sendmail 8.8 supports this without a patch, just use
-DTCPWRAPPERS=1
for compilation and add the appropriate library
-lwrap
.
There is a patch for a problem with
sendmail 8.8.8
which passes incorrect data to the library routines.
A patch can be found in
ftp://ftp.win.tue.nl/pub/security/.
Thanks to
Lou Rinaldi
for pointing this out.
A third possibility is to use the
checkcompat()
routine.
Kyle Jones
proposed the following
patch.
It is intended to disallow all non-local e-mail traffic through your host.
Use at your own risk.
unsafe map file /etc/mail/aliases(or another map). There may be several reasons for this, the most common is that the permissions of the directories leading to the alias file are incorrect. It must be:
drwxr-xr-x 12 root staff 3072 Nov 20 10:47 /etc/ drwxr-xr-x 4 root staff 1024 Dec 21 16:40 /etc/mail/i.e., the directory must be owned by root and not writable by the group or the rest of the world. The alias file itself must have similar permissions. Moreover, if you have a db map, you may try to touch the resulting map (file.db) and call makemap or newaliases thereafter.
See the release notes for further details. /usr/lib/sendmail -bi -d44.4 gives some debug output for the alias map.