Sam Pointer

When installing Sendmail from the repository packages it is pretty much assumed that you will only be running one instance on a given server. If, like I had to recently, you want to maintain a number of sendmail configurations and process, but want to fit into the Debian rc script scheme, it takes a bit of work.

I’ve created a patch that can be run against the stock /etc/init.d/sendmail script to produce scripts like /etc/init.d/sendmail.mail1 to manage named instances of sendmail. There are a few things you need to know:

• The patched scripts expects to find the configuration for the named instances in /etc/mail/servers/instancename
• The script expects to be called sendmail.instancename
• Along with changing the INSTANCE= variable at the top of the script, be sure to change the comments so that the update-rc.d style daemon registration works if required. A global search and replace is probably your best bet.
• /etc/default/sendmail can be copied to /etc/default/sendmail.instancename and populated, if present or required.
• PID and lock files end up in /var/run/sendmail.instancename. You will need to edit your named instances sendmail.mc/cf to have the PID files created in the correct location. Spools end up in /var/spool/mqueue.instancename

The final piece of configuration required to make this mechanism work is to copy /etc/mail/sendmail.conf to /etc/mail/servers/instancename/sendmail.conf and to modify the MISC_PARMS variable:

MISC_PARMS="-C/etc/mail/servers/INSTANCENAME/sendmail.cf"

Substituting INSTANCENAME as required. This ensures that the correct configuration file is read from.

If you are binding your sendmail instances to different interfaces you might like to also modify the DAEMON_NETIF variable to have the instance watch the correct interface for state changes, if you have DAEMON_NETMODE set to something other than the default “Static”.

Apart from that the patched script does everything that you would expect and the various logged messages reflect the instance name. Managing individual instances then becomes a matter of:

$ sudo service sendmail.mail3 stop
$ sudo service sendmail.mail2 start

Easy as that.

If you want your Sendmail instance to accept mails for a nonsense domain and then discard them completely, here is one way of doing it. Another is to use milters. This is documented to death for Linux and the *BSDs, so I thought I’d write down the steps for getting it working under Solaris 10.

This guide assumes that the main *.cf files have always been built through m4, and that the .mc files in /etc/mail/cf/cf are current.

All steps to be performed as root.

Make a backup of your mail configuration, just in case

cd /etc
cp -pr mail mail.bak

Edit the sendmail.mc file to add the virtusertable feature definition.

cd /etc/mail/cf/cf
vi sendmail.mc
...
DOMAIN(`solaris-generic')dnl
FEATURE(`virtusertable')dnl
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
...

Build your new sendmail.cf, setup some configuration files, restart sendmail and ensure the SMF-managed service has been been restarted and is marked “online”.

/usr/ccs/bin/make
cd /etc/mail
cp sendmail.cf sendmail.cf.bak
cp /etc/mail/cf/cf/sendmail.cf .
echo "nowhere.com" >> local-host-names
echo "@nowhere.com:    nobody" >> virtusertable
makemap hash /etc/mail/virtusertable < virtusertable
svcadm restart sendmail
svcs -a | grep -i sendmail

Test that it really works as we think it should. You should also try mailing a “real” deliverable domain if you intend this Sendmail instance to do that for normal mail. (You can paste this whole box straight onto the command line and it’ll work)

mail bob@nowhere.com
TEST
.
mail mary@nowhere.com
TEST
.

Finally, we check the logs to ensure everything is working. The important parts to look for are ‘to=/dev/null’ and ‘mailer=file’. Check your spools, too.

grep -i nowhere.com /var/log/syslog

Jun 11 14:05:59 dev sendmail[4472]: [ID 801593 mail.info] o5BD5xto004472: to=bob@nowhere.com, ctladdr=sam (60005/10), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30103, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (o5BD5xsQ004474 Message accepted for delivery)
Jun 11 14:05:59 dev sendmail[4476]: [ID 801593 mail.info] o5BD5xsQ004474: to=/dev/null, ctladdr= (1/0), delay=00:00:00, xdelay=00:00:00, mailer=*file*, pri=30551, dsn=2.0.0, stat=Sent
Jun 11 14:06:18 dev sendmail[4489]: [ID 801593 mail.info] o5BD6Iem004489: to=mary@nowhere.com, ctladdr=sam (60005/10), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30103, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (o5BD6Iru004490 Message accepted for delivery)
Jun 11 14:06:18 dev sendmail[4491]: [ID 801593 mail.info] o5BD6Iru004490: to=/dev/null, ctladdr= (1/0), delay=00:00:00, xdelay=00:00:00, mailer=*file*, pri=30553, dsn=2.0.0, stat=Sent

1983 was a pretty amazing year. Lotus 1-2-3 was released, the IBM PC XT was released, Pioneer 10 becomes the first man-made object to leave the solar system. We get a woman and a black man in space, there is nuclear panic, the first NES is released, Brinks Mat, the IRA and Maggie Thatcher. Also, DNS was invented. If you want the history, here is a link to the Wikipedia article. With it, DNS brought us the great naming conundrum.

As a Systems Administrator (or a variant thereof, whatever the title), I have strong views on DNS naming conventions in your average corporate network. I’ve seen some obtuse and downright sadistic host and DNS naming convention abuses; I want to avoid more of the same. So, below, is my take on the definitive guide to your average internal namespace. Feel free to comment.

Use full words: don’t omit vowels or use cryptic two letter abreviations

‘dc’, ‘prn01’, ‘ps1-LON’. Wrong, wrong, wrong. Just learn to type and use full words. And what is this obsession with omitting only vowels? I mean: ‘exchngsvr’. Is it really worth it? Does it roll off of the fingers that much more easily? Really? It makes things much more obvious to you and non-technical people alike if you just use full words in logical domains. What would you both as an admin and a user prefer?

    app14.svr.internal.corp.com

or

    sales.servers.internal.corp.com

A logically configured name that can be read almost as a sentence can’t be a bad thing. To the business it makes the whole thing seem less like a Heath Robinson cranky geek outfit and a modern proper infrastructure.

Properly Configure and Use the Domain Search List

Make sure your domain search list is properly ordered and contains everything sensible for your outfit. Not only does it simplify configuration to single, obvious (full!) words, it comes into it’s own if you ship Virtual Machines between locations, copy configuration information to backup sites, or otherwise sychronize configuration between differently named domains.

Let’s say you ship a VM to a DR and production location. Each is handed out DNS information via DHCP and they have their domain search lists set to dr.corp.com and production.corp.com respectively. All of your scattered, site-specific configuration goes away. Want to talk to an SMTP server? Call it ‘mailhost’ in your configuration and at the DR site the DNS search list will cause a lookup for mailhost.dr.corp.com - likewise for the production location.

Not forgetting the users, having a domain search list that enables them to refer to hosts as ‘sales’, ‘fileserver’, ‘sage’ without full qualification makes everybody’s life easier.

The Cricket Book

Read it. It is getting slightly out-of-date, but the fundamentals still apply. Not optional.

Be Careful of Split Horizon Namespaces

… or revealing a different view of the world to your internal machines. Better that www.corp.com resolves to the same address no matter where you’re coming from and you handle the traffic from one point of ingress only. When the box moves in a year, or something else changes you’ll have an outage. A subdomain of your real (or /a/ real) domain is preferable to an unqualified ‘.corpnet’ internal domain, or a dummy domain in another TLD unresolvable externally. You have a proper chain of DNS delegation making any future delegation and rearrangement of your DNS configuration exponentially more trouble-free.

Get ready for DNSSEC, Test Your Resolver

DNSSEC is coming. When is open to debate, but it pays to keep on top of things. The DNS-ORAC have kindly created a test to determine if your resolver chain can or cannot receive large responses, a problem with additional traffic required for a DNSSEC lookup. Run it and do something about any problems.

Don’t neglect it

DNS is critical to any modern network, be it the Internet as a whole, or your little part of it. A bit of thought and a bit of discipline will make for a better infrastructure for you and your clients.

When I’m on a Windows box and I want to sync two directories (remote or local), I use this little one-liner:

@echo off
xcopy %1 %2 /M /E /Y /Z

The switches are:

• M: Copy only files with the archive bit set
• E: Copy directories and subdirectories, even empty ones
• Y: Supress prompting for overwrites
• Z: Copy in network restartable mode

The %1 and %2 obviously denote parameter arguments when called from a batch file, so when saved as ‘file_sync.bat’:

C:\>file_sync.bat c:\somedirectory \\someserver\sometargetdir

Will sync the local directory with the remote share. When files are modified or added, Windows sets the NTFS archive bit. When run again the script will only copy the new or amended files.