« I guess the foot's on the other hand now, Kramer! | Main | Flight 209, now arriving at gate 8... gate 9... gate 10... »

I'm doing all that I can. And stop calling me Shirley.

Minor mistake in my last entry... I said that ISEC fell under the SEC. Not so. ISEC is a sibling organization to SEC. That is, it goes like this:



Perk e-mailed me today asking if I had any recollection of an journal entry that I wrote long ago about "CR-114" from Dr. Strangelove.

I knew at once what he meant -- the "CRM-114" is the encryption device used on the Air Force planes in Dr. Strangelove. However, I only had a really dim recollection about a journal entry that I may have written about it.

So I dug through my journal archives and didn't find any references to it. Hmm.

So I dug through my mail archives.

After searching through 233MB of old mail, I found the mail in question: it was in a mail that I sent to Jeremy, Kevin, Brian, Pete, Arun, and Perk on Sunday, October 3, 1999. Check this out:

Subject: Dr. Strangelove / Back to the Future

So I was watching Back to the Future today (it was on USA). Remember at the very beginning when Michael J. Fox is hooking up his guitar to the massive speaker? You see him flipping all kinds of switches and turning several knobs, etc.

I just happened to notice that one of the switches that he flips to the "on" position is labeled "CRM-114".

The astute reader will recognize "CRM-114" as the name of the encryption device used on the Air Force planes in Dr. Strangelove (I just saw Dr. Strangelove again a few weeks ago, and they mention the name "CRM-114" at least a dozen times). Strangely enough, the CRM-114 in Back to the Future, just like the CRM-114 in Dr. Strangelove, gets fried and blows up.

So do you think that "Back to the Future" is actually an apoloectic (sp?) realization of the doom prophesied in "Dr. Strangelove"?


Howzat for the random-reference-of-the-month?

Latency out of Ft. Huachuca is really sucky tonight.


Here's another weird [tech] story...

We got a report yesterday from some random sysadmin that he has some user that subscribes to the LAM mailing list in MIME digest form. It appears that GNU Mailman is appending a string to the end of its MIME digests, "\nEnd of xxxx digest\n".

This is all fine and good, except that it comes after the last MIME boundary separator. Hence, it's technically not part of any body part in the message.

Apparently, this crashes their mail server!

That's right, not the user's mail client -- it crashes their mail server!
I don't know what kind of sorry excuse they have for a mail server that a single "malformed" message causes it to crash, but apparently this is a repeatable occurrence. Doh!

The sysadmin asked if we could fix out errant listserver.

Being a good netizen, I investigated and found the place in MailMan (it's all in python) and found right where the "End of xxxx digest" string is being added to the end of digest mails. I changed the logic slightly so that this string is only added when the digest is being sent out in non-MIME form. No biggie.

I tested it (since I was doing this on a live system -- don't try this at home, kids!) and forced a digest message to be sent out to a test list. I received the message in pine and it all looked good --
no "End of xxxx digest" message. Rock on.

As a sanity check, I edited Mailman to put the "End of..." message back and forced another digest message to be sent. Looking at this second message in pine, I still didn't see the "End of xxxx digest". Hmm. So I looked at my raw mail file on the mail server, and I did see that string at the end of the message.


A nagging thought occurred to me... a throwback from long, long ago when I was working on a web mail client from a prominent web hosting provider.

I did a quick Google search and found RFC 2822 ("The" RFC that governs e-mail -- a second generation to the original RFC 822, actually). This cross-referenced me to the MIME RFCs -- 2045, 2046, 2047, and 2048.

I found that my dim recollection was right: message authors are allowed to put extra junk before the first MIME delimiter and after the last MIME delimiter if they want to. A conformant MIME implementation will ignore this junk.

From section 5.1.1 of RFC 2046, "Common Syntax":

There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one.

NOTE: These "preamble" and "epilogue" areas are generally not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways. However, rather than leaving the preamble area blank, many MIME implementations have found this to be a convenient place to insert an explanatory note for recipients who read the message with pre-MIME software, since such notes will be ignored by MIME-compliant software.

Hence, since Mailman is putting this "End of xxxx digest" string after the last MIME delimiter, pine is [rightfully] ignoring it and not displaying it to me.

In other words -- Mailman is perfectly conformant to put that string at the end after the last MIME delimiter.

You gotta love it when you can quote RFC's to someone. :-)

So I didn't file a bug report with Mailman, and just because I'm such a nice guy, I left the "End of xxxx digest" message out of lam-mpi.org's mailman server, but I did recommend that they upgrade their mail server. :-)

Random note: I'm starting to see more and more software packages starting to use Autoconf 2.52.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on December 6, 2001 10:33 AM.

The previous post in this blog was I guess the foot's on the other hand now, Kramer!.

The next post in this blog is Flight 209, now arriving at gate 8... gate 9... gate 10....

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34