Note that RedHat, as of version 6.0, is using version 8.9.3 of Sendmail. The instructions here are for that version. Later versions might change slightly, but probably not significantly unless Sendmail is updated to version 8.10 or 9.0.
RedHat made what I consider a moderately important ommission from their sendmail configuration: they left out tcp_wrappers support. This is what checks your hosts.allow and hosts.deny files to see whether a particular machine is allowed to connect to various services on your machine, including the SMTP port. It also handles logging of connection attempts and information about the entity connecting to you in the various log files. Luckily, there's not much to adding this support. As root, do the following:
Here's a section from hosts.allow that I use on my system:
sendmail : ALL@localhost ALL@127.0.0.1 : \
rfc931 : \
spawn ( /usr/bin/logger -p authpriv.info -t SMTP \
access to %s granted to %c ) : \
ALLOW
sendmail : ALL@ALL : \
rfc931 : \
spawn ( /usr/bin/logger -p authpriv.alert -t SMTP \
access to %s denied to %c ) : \
DENY
This logs all accesses to your SMTP port, allows only connections from your local machine and rejects anyone else. If you have a static IP address you can add ALL@myusername.users.xmission.com to the first line. If you have an SMTP feed from XMission, you can also add similar bits naming the XMission mail machines after the @-sign. This allows you to limit who can send mail directly to your machine by connecting to your SMTP port without completely turning off sendmail, and the logs perpetuate the evidence in the event that some moron figures you're an open relay and tries bouncing his spam through you. For more information on the hosts.allow file and it's syntax, read the hosts_access(5) and hosts_options(5) man pages on your system. You can do any number of wonderful things with hosts.allow entries, and they provide a nice way of severely limiting who can access what services on your system. Simple fact: if they cannot open a connection to a service, they cannot exploit bugs or security flaws in it.
NOTE: If you use fetchmail to retrieve mail and use this entry, add an "smtphost localhost" line to your .fetchmailrc to force fetchmail to use a source address of 127.0.0.1. If you do not, it might well attempt to use the source address of your dial-up PPP interface which, while entirely legal, will be rejected by this entry.
XMission usually re-writes your address so that everyone sees just username@xmission.com in the From: header of your mail. sendmail as RedHat has it installed will use whatever your machine's hostname is after the @-sign. Luckily, there are features you can set up in sendmail.cf that will do the same re-writing that XMission does. In fact, you don't even need to edit sendmail.cf directly to do this. The only condition is that, as it stands, your username on your Linux box has to be the same as your username on XMission. I'm working on a way to get around this. I would strongly suggest that, if you do run sendmail, you install the tcp_wrappers support described above. This will prevent spammers from using you as an unwitting relay.
RedHat's sendmail package includes the directory /usr/lib/sendmail-cf/cf which contains a sampling of configuration files for sendmail. We'll start with one of the .mc files. These are the macro configuration files used to generate the much more complex and loudly-and-ingeniously-cursed sendmail.cf files. The file redhat.mc is the file used to generate RedHat's initial sendmail configuration. You can use this to generate the original /etc/sendmail.cf file if all else fails.
The first thing to do is create a new .mc file describing how we need sendmail configured. The file I start with looks like this:
divert(-1) dnl This is the macro config file used to generate the /etc/sendmail.cf dnl file. If you modify thei file you will have to regenerate the dnl /etc/sendmail.cf by running this macro config through the m4 dnl preprocessor: dnl dnl m4 /etc/sendmail.mc > /etc/sendmail.cf dnl dnl You will need to have the sendmail-cf package installed for this to dnl work. include(`../m4/cf.m4') define(`confDEF_USER_ID',``8:12'') OSTYPE(`linux') undefine(`UUCP_RELAY') undefine(`BITNET_RELAY') define(`confAUTO_REBUILD') define(`confTO_CONNECT', `1m') define(`confTRY_NULL_MX_LIST',true) define(`confDONT_PROBE_INTERFACES',true) define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail') FEATURE(`smrsh',`/usr/sbin/smrsh') FEATURE(`mailertable',`hash -o /etc/mail/mailertable') FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable') FEATURE(redirect) FEATURE(always_add_domain) FEATURE(use_cw_file) FEATURE(local_procmail) FEATURE(masquerade_envelope) FEATURE(masquerade_entire_domain) MASQUERADE_AS(xmission.com) MASQUERADE_DOMAIN(localhost) MASQUERADE_DOMAIN(localdomain) MAILER(procmail) MAILER(smtp) FEATURE(`access_db') FEATURE(`blacklist_recipients') dnl We strongly recommend to comment this one out if you want to protect dnl yourself from spam. However, the laptop and users on computers that do dnl not hav 24x7 DNS do need this. FEATURE(`accept_unresolvable_domains') dnl FEATURE(`relay_based_on_MX')
If you compare it to RedHat's original, you'll see there's only a few things added. The interesting parts are the last two features, masquerade_entire_domain and masquerade_envelope, and the MASQUERADE_* lines. These do the re-writing of your mail address to appear to have come from your XMission account rather than your machine itself. The MASQUERADE_DOMAIN lines say what e-mail addresses should be rewritten. If the hostname ( to the right of the '@' ) ends in any of the strings listed in these entries, they will be rewritten to have the string listed in the MASQUERADE_AS entry instead. If you have a static IP address, you will want to add an additional MASQUERADE_DOMAIN entry with the hostname of your machine ( for example, for my system I add MASQUERADE_DOMAIN(tknarr.users.xmission.com) ). Save this file as xmission.mc in the /usr/lib/sendmail-cf/cf directory.
To generate the .cf file from the .mc file, just type:
make xmission.cfand let the makefile do the work for you. The result will be xmission.cf, ready for the last touches. The first is a few lines early on in the file like this:
# my official domain name # ... define this only if sendmail cannot automatically determine your domain #Dj$w.Foo.COM
I generally replace the line starting with '#D' with:
Djlocalhostto insure that sendmail always figures it's official name is localhost. That insures that, if you don't give a domain name in your address, your address will be username@localhost to start with. That will then be properly rewritten to be username@xmission.com. If, however, you have a static IP address and have your hostname ( returned by hostname -f ) set to the name XMission assigned you, and you added the MASQUERADE_DOMAIN line to xmission.mc as I said to above, you can leave these lines alone and sendmail will work things out correctly. This would apply to DSL customers, and PPP customers who have bought static IP addresses.
Now we need to apply a patch. This patch will modify xmission.cf so that it will not masquerade hostnames when delivering mail on the local machine. With this patch, if you send mail from albert@localhost to tony@localhost, the address that tony would reply to would wind up being albert@xmission.com. This is redundant, and may cause misdelivery if albert exists on your local machine but isn't your XMission username. Download the patch file into the same directory as xmission.cf and apply it via:
patch <xmission-sendmail.patchThis will modify xmission.cf as needed. If patch responds with errors and they aren't immediately clear, contact me with the messages and I can take a look at it. One normal message from patch is that the changes weren't at exactly the lines originally specified but that it found matches at an offset from the original patch. These can be ignored. If it leaves .rej files around afterwards, this is a definite sign that something went seriously wrong and the results of the patch should not be used.
Now, copy /etc/sendmail.cf to sendmail.cf.original in /usr/lib/sendmail-cf/cf just to be safe, then copy xmission.cf to /etc/sendmail.cf. Now go to /etc and edit the sendmail.cw file there. It contains hostnames, 1 per line, that sendmail should consider to be "this machine". Generally this file should include:
localhostIf your machine is known by other names, they should be included here. For example, those with static IP addresses could also include:
username.users.xmission.com
Now all you have to do is cd to /etc/rc.d/init.d and issue the following commands as root:
./sendmail stop ./sendmail startto stop and restart sendmail. It should begin running with the new configuration. You might want to run a few test messages through, either to yourself or to a friend who won't be bothered by errors or strangeness, to confirm that all addresses are correct. This shouldn't be strictly needed, but it's good to get into the habit of double-checking everything that you do just to be sure it really works the way it's supposed to.
Now you have a fully-working sendmail configuration. It's capable of taking incoming mail, from programs like fetchmail, and dropping it into your local mailbox using procmail so you can read it with Pine or Elm. It's also capable of correctly handling outgoing mail, so programs that assume they can just use sendmail and have it take care of the details will work right. There's information available on how to configure fetchmail.
I'm working on this. sendmail has facilities in it to map arbitrary addresses to
other arbitrary addresses. One application is to make mail from a local user appear to be
from an arbitrary mail address. An immediate application would be for businesses with mail
hosted in a virtual domain on XMission, so that mail originating from thomas on
the local machine would appear to the rest of the world to come from
tech-support@mybusiness.com. I'll fill in this section when I actually set this up
for myself.
This section will be completed in the near future.
By default, RedHat's sendmail installation has the anti-relaying hacks included and relaying disabled. This is good because it insures that nobody is going to use your machine to relay spam/UCE, but it also means that if you have other machines on a network they can't use your machine to relay legitimate mail. It's possible to add entries to files in /etc/mail to tell sendmail that certain machines are allowed to relay mail, while still restricting anyone else from using your machine to send mail to anyone but you.
tknarr@silverglass.org