Some disgusting sendmail
Recently something changed for one of our clients. We had a Scalix deployment on-site; Scalix is startlingly like Exchange, except that it run on "Linux". I say "Linux" because technically only Redhat is supported. And it quite unfortunately uses sendmail.

But not in any normal configuration. 127.0.0.1:25 is basically an unaltered sendmail installation that handles local processing. 192.168.1.10:25 is a Scalix-specific version of an SMTP daemon, I assume based on sendmail, that functions as a relaying SMTP server for the groupware functionality. It uses sendmail, the binary, to send outgoing mail.

Previously, we were sending email directly from the groupware server, host to host. Then somehow, almost all of Verizon's DSL ranges in Harrisonburg got super-mega-blacklisted. About 6 months ago, I switched it over to using a smarthost. At the time, Verizon let DSL-range IPs relay without authentication. That's not a problem; the smarthost (all-mail forwarder, basically) works fine in basically any configuration...and takes some of the headache off of us.

Then, a few months ago, they went to using SMTP-AUTH, which is a scheme that requires login information to be sent before the server can send email. That's also..fine, although it's not a typical setup to require AUTH from valid IP ranges. Apparently, Verizon is unable to control spam effectively even from their own users. That's fine; SMTP-Auth is not hard to set up, even in archaic Sendmail, so I turned it on. Problem solved.

Sometime last week, though, something weird happened. I'm not sure if a configuration changed or if there's corruption on Verizon's end, but now suddenly this single client has to authenticate *every* email address, and the SMTP-Auth information has to match the FROM: header in the email.

This is stupid for various reasons. I can only assume it's a misconfiguration on their part, but I was unable to reach anybody above the "Trained Droid" status on the business help line.

Coincidently, Verizon "Business" service is worthless. I mean, in basically every aspect. If you're going to sell service to a business, as a business DSL account, at an increased price, you would think they would at least fleetingly claim to support more common configurations like, say...Exchange. Or more than one email address sending from the same IP. But the official Verizon business support Line that was fed to me: "we only support webmail access. If you can send and receive from the webmail, our responsibility is done. My systems group won't even touch it if you can send through the web site."

So fine. One-finger salute to the phone and I hang up. The problem is that sendmail has no mechanism to support multiple outbound authentication username/password combinations to the same server.

AuthInfo:outgoing.verizon.net "I:address1@verizon.net" "U:address1@verizon.net" "P:password"

Great! Using a groupware server, you will have multiple email addresses sending out through it. Inside the office, they use address1@verizon.net, address2, address3, address4, so on. If I set the AuthInfo to use address1, then address1 can send through the groupware server. Verizon's mail server, however, will reject any mail appearing to original from a FROM: address that doesn't *exactly* match the login hash. Even accounts with a master/child relationship, the child has to authenticate; it is *not* okay for the master account to authenticate for every child account.

This is patently stupid.

So I wrote an SMTP proxy that handles authentication. Or, more precisely, I modified one I found on the Internets...heavily.

It pulls from /etc/mail/user (a whitespace delimited username/password pair file; I plan to modify it later to parse fetchmailrc files) at load time and spawns a series of mail-handling daemons. It then forwards all SMTP traffic to the "real" mail server. It emulates enough SMTP server-side to get a MAIL FROM:, then looks up the from header address in the user file, base64s the info for AUTH LOGIN, and forwards it. Assuming it gets an OK, it fowards the FROM and immediately starts passing through all the text.

So the proxy works great. The last problem is that sendmail won't accept a port for the smarthost (DS) entry...which sucks. All of this is running on the same machine and the proxy is listing on 31337. So then as a final act of defiance, I had to add an ip alias to 192.168.1.99, set the proxy to listen on *that* address, :25. So it goes

LAN --> 192.168.1.10:25 (Scalix) --> 127.0.0.1:25 (Pure Sendmail) --> 192.168.1.99:25 (SMTP Proxy) --> Outgoing.verizon.net:25 (Retarded Mail Server)

I'll probably figure out in about 2 days how to do multi-AUTH in sendmail. I'm sure something else (Postfix or qmail) could have done it, but I'm not about to figure out the entire Scalix processing stack so I can swap sendmail for another mta. Bad mojo.

Bad day...bad day.

Ian turned in his notice yesterday. We went to BW3's to celebrate; he won't mind me saying he got roughly a 60% salary increase, because I'm super proud of him. Now *I* have to get out of there. Billable hours are killing me softly...with their song.

And maybe a 60% salary increase for me! That's not as drastic as it seems when you realize I get paid in GOOD JOB! Stickers and check plusses. Got a call today from Mclean for a datacenter position, and I have an interview Friday in the burg.

I can't help but wish I'd left more of an impression on the internet. If you google for me, you get

1) This page (which is unfortunate)
2) A series of postings I made to the ICRADIUS back in 98.
3) A presentation I did on NeXTSTeP in college
4) The first three chapters of Lintuition
5) Me badmouthing Wi-Fi for the local newspaper
6) Me on the Horde mailing list (IMP, not WoW) asking a legitimate question and getting shot down by the maintainer.


PS: If anybody reads this after finding SCALIX and Verizon tagged, email me for the script and directions. It's not good enough to post for general availabilty, but I'll be glad to send it to other people screwed by Verizon.