Message accepted for delivery

The white-on-blue xterm at right is what I've been staring at during my free moments these last couple of days. I've been trying to get my home Linux box to forward my email to our ISP but couldn't get sendmail configured properly. It's been a while since I looked at the sendmail config file and things have changed somewhat in version 8.14. Mainly there's been a lot of anti-spam stuff embedded, and rightly so. As a result, to get my Linux box to talk with the outgoing SMTP MTA I had to turn on authentication so that my sendmail could talk to the ISP's sendmail and pass on my email messages.

To get this to work, I had to turn on several things in my sendmail.mc file, including:

• define(`SMART_HOST', `smtp.your.provider')dnl: uncommenting this line to identify the outgoing SMTP host. This seems obvious but what wasn't was that it's really [smtp.your.provider] with the square brackets. Why are these needed I haven't a clue, but it seems to make all the difference.
• TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
FEATURE(`authinfo', `hash -o /etc/mail/authinfo.db')dnl: turn on authentication, and provide the user id and password in the authinfo file. Ok, this too makes sense, except for the actual syntax of the authinfo file, which requires "M:LOGIN PLAIN". I had to go through countless google searches to find a web page that had provided this nugget.
• Turn on masquerading: I'm not entirely sure whether this is necessary, however, I know that I'm sending out email from behind a router and that I think my ISP does reverse DNS lookups. Which I think means that sendmail should masquerade as the host whose IP will come back as the router's. This might sound kind of weird, but it also makes sense: the ISP needs to look up the IP of where it's getting a mail forwarding request, and so the host name in the request should match the IP address from where it's originating.
• define(`confHELO_NAME', `my.host.domain')dnl: I'm not positive that this is necessary, but as all the other stuff it also seems to make sense. This defines the domain that my sendmail uses to say "hello" with to the ISP's sendmail. So again, this should match the IP address that the ISP is going to DNS lookup. With this I also added in lines that rewrite the sender's address to also come from this domain, using the genericstable db.
• MAILER(local)dnl: this I think just allows sendmail to relay locally queued email, which, just like everything else, also makes sense.

All of the above configuration tweaks are logical in retrospect, but piecing together all of these ingredients took a bit of time and quite a bit of google searching. In addition to sendmail I also had to turn on the saslauthd service. This is something new from my perspective, but it is needed to encrypt the id/password that get sent to the ISP during authentication. All of this stuff just to circumvent spammers. Before these jerks came along, things were much simpler.

Eventually define(`confLOG_LEVEL', `20')dnl really helped me see what was going on at the SMTP protocol level: turning this on produces the verbose log that you see in the white-on-blue xterm. At one point I tried snooping on the ethernet port, but the increased debug level is really what I was after. This lets you see how the sendmail MTA (ISP side) and client (my side) communicate. After numerous "Deferred: Connection refused" messages, I finally got the "Message accepted for delivery" response I was after.

And why bother? You may well ask...this whole endeavour was prompted by the purchase of an UPS (Uninterrupted Power Supply) for the machine. The AE550 unit from Cyber Power Systems is basically a smart battery that provides power to the PC if the utility (AC power) goes down. Which for some strange reason is quite frequent around here. In the winter I can almost understand: our "ice storms" (South Carolina's variant of a snow storm I guess) weigh down the power lines causing them to snap. But in the summer? Too many A/C units running? Well, whatever the reason, power outages occur almost weekly it seems. And that's not good for computers. Sudden shutdowns leave the system in a bad state, potentially causing file loss and other nasty things. So it's best to shut down gracefully. Which is what the UPS allows. Not only does it allow those extra precious few minutes of up time during a power outage that you can use to shut down the machine manually, but the newer units also provide autonomous control. They do this by providing battery state information to the PC via serial or USB line. (This took a couple of days of configuration as well, btw, but eventually I got NUT compiled and properly configured.) This allows the machine to monitor its power draw and upon detecting that power is about to get cut off, it can now shut itself off without human intervention. Clever, no? Not only that, the above sendmail configuration also allows the machine to send me an email to let me know that it's about to shut itself off. Do I really need to know this? Nah, I guess not, but I think it's pretty cool! So now whenever I get an email from cyberpower_usb at my home domain name, I'll know that we've had yet another power outage out at the house.