No sooner had I set up crimson to work as the mail server, than I thought: I don't want to keep ssh'ing into crimson to pick up my mail. I'll get it redirected to my linux machine, gold. That'll be much more convenient. That's when the real fun started...
Fresh with my success of getting sendmail working on FreeBSD, I turned to Linux. The model I wanted originally was to be able to send mail internally from UNIX box to UNIX box, but let crimson act as the central mail server for dispatching email to the outside world. I figured this would be a very common setup.
First, I tried the nullclient, specifying crimson as the server. The configuration setup was a little different to FreeBSD - there was no handy make file to build the sendmail.cf file, you have to invoke m4 by hand (not a big issue, I suppose). My first test at sending mail out failed, because my ISP complained the gold.hydrus.org.uk was not a valid address. Hmm, true enough. I used the MASQUERADE_AS to set gold mail as coming from hydrus.org.uk. That worked. But... if I did that, and sent mail to crimson, how would crimson know which machine had sent the mail? You might say, well that's an academic question, you only have the one client, right? Well, I guess it just niggled me.
There was another problem with the nullclient approach. Sending a mail to gold from crimson caused it to return instantly - all mails are shipped directly to the nullclient server, irrespective of where they originate. To test this, I had to disable SMART_HOST, otherwise all mail addressed to gold.hydrus.org.uk was sent to my ISP SMTP server, and promptly bounced. Then it took me a while to figure out why crimson could not connect to sendmail on gold. The default config for Redhat 7.3 sets sendmail listening to 127.0.0.1 only - the local host. This is defined by:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
Commenting our that option opens sendmail up to the network. Nullclient wasn't going to help me, unless I started to use a POP client like fetchmail to get mail destined for gold. I didn't like that idea, as it meant leaving crimson passwords lying about on gold.
OK, so nullclient is out. My next thought was to set up SMART_HOST on gold, defining it as my ISP SMTP server. Well, that worked fine for email to the outside world, but my test message to crimson ended up being sent to my ISP, and was bounced as an unresolvable address. There must be some way of telling sendmail to deliver email to a different machine if the mail had a local recipient. After thumbing through the bat book again, I found exactly what I needed, the LOCAL_NET_CONFIG, which figured out if the mail was destined for a local machine (i.e. one with the same domain name) and smtp'd it to that machine. Hurrah, that should do it. Nope - was still sending mail to the SMART_HOST.
I tried the same LOCAL_NET_CONFIG on crimson - same problem when sending mail to gold. Then I figured out that sendmail needed DNS working in order to resolve the addresses. First I thought all I had to do was alter the /etc/service.switch file to:
hosts dns file
Sadly, that changed nothing. Now I really needed to find out why DNS on my setup was not working with sendmail.
My initial assumption about sendmail and the /etc/resolv.conf file, was that it behaved in the same manner as nslookup; only the first nameserver was tried. It turned out this was false; sendmail tries them all in turn until it gets a reply it likes (or runs out of nameservers to try). The Alcatel Speedtouch DNS server is very restrictive in what DNS queries it accepts: A (i.e. address) or ANY only. MX (mailer record) requests are answered with NOTIMP (not implemented).
With this in mind, I re-entered my ISP's nameservers in /etc/resolv.conf. On gold, this had the desired effect. Mail addressed to a local machine (crimson) used the crimson SMTP server. Outside mail was sent to the ISP's SMTP server. On crimson, the story was different. Mail addressed to gold was still being sent to my ISP. What was going on?
Back the bat book. I found a diagnostic option (-d8.8) which would
tell me what sendmail was sending and getting back from DNS. I also
discovered the -bt option which made testing sendmail with mail addresses
much easier than actually sending mail and observing the
/var/log/maillog file. If you invoke sendmail with the -bt option, it
will prompt you for diagnostic commands, of which the most useful to
me was /parse email@domain. The /parse command will get
sendmail to tell you how the address is being resolved and the final
decision on which mailer will be invoked and with what final email
address.
I found out that gold was sending a DNS query of ANY, while crimson was sending a query of AAAA. This difference was because the sendmail on gold is 8.11.6. As its name implies, ANY returns any DNS record types (A, MX). AAAA was a query for IPv6 addresses. Guess what: the Alcatel DNS returned NOTIMP for this query. Of course, sendmail went on to the other DNS servers, found no resolution for gold.hydrus.org.uk and decided it was outside the local net.
The bat book told me the AAAA records were sent when sendmail was
compiled with IPv6. Sure enough, the default settings on FreeBSD
included IPv6. OK, I had to recompile without IPv6. This was easy,
as the make file for sendmail had a commented out define in it to turn
off IPv6 compilation. I uncommented the line, performed a make
deinstall and then rebuilt sendmail. Once installed, I invoked
sendmail with -bt abd -d8.8, and gave it a /parse
mark@gold command. Success! Sendmail issued a DNS A type
query, the Speedtouch responded with an address, and sendmail decided
to direct the address to the gold sendmail instance.
