I'd be grateful if anyone on the list could either shed some light on the
following problem, or direct me towards a more suitable list for this
question (I realise this is not an SMTP related question, but I could
not see a more suitable list).
Strictly speaking the ietf-822 list is where this should be discussed.
The problem is with MIME messages structured like the following:
==========================
From: sender(_at_)example(_dot_)org
To: recip(_at_)example(_dot_)org
Subject: legal message?
Date: Thu, 27 Sep 2001 14:47:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; boundary="---- mime boundary ----"
<CRLF only line>
------ mime boundary ----
some text
------ mime boundary ------
==========================
The problem I see is that the CRLF line separating the header from the
body is trying to do double duty. RFC(2)822 claims this line as the
separator between the headers and body.
Actually, RFC 1521 said that two CRLFs were needed if no preamble was present.
This was discussed at length and very explicitly changed in RFC 2046 so that
only a single CRLF was required. Some examples were also changed to make it
clear that this usage is legal.
By my reading, RFC2046 (top of page 20) claims this line as part of the
MIME boundary - i.e. part of the body: "The boundary delimiter MUST occur
at the beginning of a line, i.e., following a CRLF, and the initial CRLF
is considered to be attached to the boundary delimiter line rather than
part of the preceding part."
Um, so what? This is talking about the case where a boundary is preceeded by a
part. It isn't talking about the case where there's a preceeding header.
I suppose a wording change where the last sentence is more clearly qualified
is in order, but regardless, your intepretation stretches the words that
are there well past the breaking point.
Additionally, the ABNF matches the single-CRLF interpretation. If no preamble
is present the a multipart-body begins with the boundary, right after the CRLF
that terminates the header.
So - it seems that messages formatted like the above (which include the
example in RFC2046) are not compliant with RFC2046 since the body lacks
the leading CRLF for the boundary.
Nope. That't not what the prose says, nor is it what the ABNF says, nor is it
what the examples show,h nor is it what MIME interpretations support or create
in practice.
Have I made an error or should this corner-case be addressed in any future
revision of RFC2046? If so, where should I register this point?
I'll change the prose to make the intention more clear in the next revision.
Ned