See, now this is interesting. I almost called this "broken" but
fortunately caught myself in time.
Is this is a transcription error:
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="----------------------------"
------------------------------
Content-Type: text/plain
DIGEST_INTRO_AND_TOC
------------------------------
I would have expected the "Content-Type: text/plain" to be right next to
its prior boundary marker, i.e., no intervening blank line like this:
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="----------------------------"
------------------------------
Content-Type: text/plain
DIGEST_INTRO_AND_TOC
------------------------------
However, it turns out it's legal regardless and, in fact, the form in
which you transcribed it is arguably preferred.
With the blank line, as you transcribed it, the content is actually a
message/rfc822 for which the content is a text/plain. This is because
the default content-type in a multipart/digest is a message/rfc822 and a
blank line separates MIME headers from its content. Of course, 2046
also says that a message/rfc822 should have at least a From:, Date:, and
Subject: header, but that's a different issue.
If the actual implementation does not have the blank line, then this is
the situation which is legal according to the specification but is
explicitly discouraged in favor of having only messages in a
multipart/digest.
It occurs to me that a good example of what a digest could look like
(which is probably what LISTSERV does) is the following:
Content-Type: multipart/digest; boundary="line"
--line
From: the Moderator
Date: MESSAGE_DATE (perhaps duplicate of outermost date?)
Subject: Table of Contents
(* list of subject lines *)
--line
first digest message headers
first digest message body
--line
second digest message headers
second digest message body
--line--
Thoughts?
Jim
