Advertisement
Guest User

Untitled

a guest
Jun 26th, 2017
611
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.31 KB | None | 0 0
  1. From trey@sage.org Fri Nov 29 18:00:49 2002
  2. Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
  3. From: Trey Harris <trey@sage.org>
  4. To: sage-members@sage.org
  5. Subject: The case of the 500-mile email (was RE: [SAGE] Favorite impossible
  6. task?)
  7.  
  8. Here's a problem that *sounded* impossible... I almost regret posting the
  9. story to a wide audience, because it makes a great tale over drinks at a
  10. conference. :-) The story is slightly altered in order to protect the
  11. guilty, elide over irrelevant and boring details, and generally make the
  12. whole thing more entertaining.
  13.  
  14. I was working in a job running the campus email system some years ago when
  15. I got a call from the chairman of the statistics department.
  16.  
  17. "We're having a problem sending email out of the department."
  18.  
  19. "What's the problem?" I asked.
  20.  
  21. "We can't send mail more than 500 miles," the chairman explained.
  22.  
  23. I choked on my latte. "Come again?"
  24.  
  25. "We can't send mail farther than 500 miles from here," he repeated. "A
  26. little bit more, actually. Call it 520 miles. But no farther."
  27.  
  28. "Um... Email really doesn't work that way, generally," I said, trying to
  29. keep panic out of my voice. One doesn't display panic when speaking to a
  30. department chairman, even of a relatively impoverished department like
  31. statistics. "What makes you think you can't send mail more than 500
  32. miles?"
  33.  
  34. "It's not what I *think*," the chairman replied testily. "You see, when
  35. we first noticed this happening, a few days ago--"
  36.  
  37. "You waited a few DAYS?" I interrupted, a tremor tinging my voice. "And
  38. you couldn't send email this whole time?"
  39.  
  40. "We could send email. Just not more than--"
  41.  
  42. "--500 miles, yes," I finished for him, "I got that. But why didn't you
  43. call earlier?"
  44.  
  45. "Well, we hadn't collected enough data to be sure of what was going on
  46. until just now." Right. This is the chairman of *statistics*. "Anyway, I
  47. asked one of the geostatisticians to look into it--"
  48.  
  49. "Geostatisticians..."
  50.  
  51. "--yes, and she's produced a map showing the radius within which we can
  52. send email to be slightly more than 500 miles. There are a number of
  53. destinations within that radius that we can't reach, either, or reach
  54. sporadically, but we can never email farther than this radius."
  55.  
  56. "I see," I said, and put my head in my hands. "When did this start? A
  57. few days ago, you said, but did anything change in your systems at that
  58. time?"
  59.  
  60. "Well, the consultant came in and patched our server and rebooted it.
  61. But I called him, and he said he didn't touch the mail system."
  62.  
  63. "Okay, let me take a look, and I'll call you back," I said, scarcely
  64. believing that I was playing along. It wasn't April Fool's Day. I tried
  65. to remember if someone owed me a practical joke.
  66.  
  67. I logged into their department's server, and sent a few test mails. This
  68. was in the Research Triangle of North Carolina, and a test mail to my own
  69. account was delivered without a hitch. Ditto for one sent to Richmond,
  70. and Atlanta, and Washington. Another to Princeton (400 miles) worked.
  71.  
  72. But then I tried to send an email to Memphis (600 miles). It failed.
  73. Boston, failed. Detroit, failed. I got out my address book and started
  74. trying to narrow this down. New York (420 miles) worked, but Providence
  75. (580 miles) failed.
  76.  
  77. I was beginning to wonder if I had lost my sanity. I tried emailing a
  78. friend who lived in North Carolina, but whose ISP was in Seattle.
  79. Thankfully, it failed. If the problem had had to do with the geography of
  80. the human recipient and not his mail server, I think I would have broken
  81. down in tears.
  82.  
  83. Having established that--unbelievably--the problem as reported was true,
  84. and repeatable, I took a look at the sendmail.cf file. It looked fairly
  85. normal. In fact, it looked familiar.
  86.  
  87. I diffed it against the sendmail.cf in my home directory. It hadn't been
  88. altered--it was a sendmail.cf I had written. And I was fairly certain I
  89. hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option. At a loss, I
  90. telnetted into the SMTP port. The server happily responded with a SunOS
  91. sendmail banner.
  92.  
  93. Wait a minute... a SunOS sendmail banner? At the time, Sun was still
  94. shipping Sendmail 5 with its operating system, even though Sendmail 8 was
  95. fairly mature. Being a good system administrator, I had standardized on
  96. Sendmail 8. And also being a good system administrator, I had written a
  97. sendmail.cf that used the nice long self-documenting option and variable
  98. names available in Sendmail 8 rather than the cryptic punctuation-mark
  99. codes that had been used in Sendmail 5.
  100.  
  101. The pieces fell into place, all at once, and I again choked on the dregs
  102. of my now-cold latte. When the consultant had "patched the server," he
  103. had apparently upgraded the version of SunOS, and in so doing
  104. *downgraded* Sendmail. The upgrade helpfully left the sendmail.cf
  105. alone, even though it was now the wrong version.
  106.  
  107. It so happens that Sendmail 5--at least, the version that Sun shipped,
  108. which had some tweaks--could deal with the Sendmail 8 sendmail.cf, as most
  109. of the rules had at that point remained unaltered. But the new long
  110. configuration options--those it saw as junk, and skipped. And the
  111. sendmail binary had no defaults compiled in for most of these, so, finding
  112. no suitable settings in the sendmail.cf file, they were set to zero.
  113.  
  114. One of the settings that was set to zero was the timeout to connect to the
  115. remote SMTP server. Some experimentation established that on this
  116. particular machine with its typical load, a zero timeout would abort a
  117. connect call in slightly over three milliseconds.
  118.  
  119. An odd feature of our campus network at the time was that it was 100%
  120. switched. An outgoing packet wouldn't incur a router delay until hitting
  121. the POP and reaching a router on the far side. So time to connect to a
  122. lightly-loaded remote host on a nearby network would actually largely be
  123. governed by the speed of light distance to the destination rather than by
  124. incidental router delays.
  125.  
  126. Feeling slightly giddy, I typed into my shell:
  127.  
  128. $ units
  129. 1311 units, 63 prefixes
  130.  
  131. You have: 3 millilightseconds
  132. You want: miles
  133. * 558.84719
  134. / 0.0017893979
  135.  
  136. "500 miles, or a little bit more."
  137.  
  138. Trey Harris
  139. --
  140. I'm looking for work. If you need a SAGE Level IV with 10 years Perl,
  141. tool development, training, and architecture experience, please email me
  142. at trey@sage.org. I'm willing to relocate for the right opportunity.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement