I was beginning to wonder if I had lost my sanity. I tried emailing a
friend who lived in North Carolina, but whose ISP was in Seattle.
Thankfully, it failed. If the problem had had to do with the geography
of the human recipient and not his mail server, I think I would have
broken down in tears.

Having established that -- unbelievably -- the problem as reported was
true, and repeatable, I took a look at the sendmail.cf file. It looked
fairly normal. In fact, it looked familiar.

I diffed it against the sendmail.cf in my home directory. It hadn't been
altered -- it was a sendmail.cf I had written. And I was fairly certain
I hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option. At a loss, I
telnetted into the SMTP port. The server happily responded with a SunOS
sendmail banner.

Wait a minute... a SunOS sendmail banner? At the time, Sun was still
shipping Sendmail 5 with its operating system, even though Sendmail 8 was
fairly mature. Being a good system administrator, I had standardized on
Sendmail 8. And also being a good system administrator, I had written a
sendmail.cf that used the nice long self-documenting option and variable
names available in Sendmail 8 rather than the cryptic punctuation-mark
codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs
of my now-cold latte. When the consultant had "patched the server," he
had apparently upgraded the version of SunOS, and in so doing
downgraded Sendmail. The upgrade helpfully left the sendmail.cf
alone, even though it was now the wrong version.

It so happens that Sendmail 5 -- at least, the version that Sun shipped,
which had some tweaks -- could deal with the Sendmail 8 sendmail.cf, as
most of the rules had at that point remained unaltered. But the new
long configuration options -- those it saw as junk, and skipped. And
the sendmail binary had no defaults compiled in for most of these, so,
finding no suitable settings in the sendmail.cf file, they were set to
zero.

One of the settings that was set to zero was the timeout to connect to
the remote SMTP server. Some experimentation established that on this
particular machine with its typical load, a zero timeout would abort a
connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100%
switched. An outgoing packet wouldn't incur a router delay until hitting
the POP and reaching a router on the far side. So time to connect to a
lightly-loaded remote host on a nearby network would actually largely be
governed by the speed of light distance to the destination rather than by
incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979

"500 miles, or a little bit more."

Trey Harris

I'm looking for work. If you need a SAGE Level IV with 10 years Perl,
tool development, training, and architecture experience, please email
me at trey@sage.org. I'm willing to relocate for the right opportunity.