Subject: Re: Mailing list admin, please read this!
From: [email-masked] (Christopher Faylor)

8 Sep 1998 12:07:51 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Alexander Kriegisch <[email-masked]>
Cc: GNU-Win32 Discussion <[email-masked]>

On Mon, Sep 07, 1998 at 12:02:27PM +0200, Alexander Kriegisch wrote:
>Hello Christopher!
>
>> There is obviously a blank line following the mail header.
>
>There seems to be a misunderstanding. I did not mean the top-level mail
>header (which is indeed okay), but the (missing) blank line after the
>(also missing) sub-part header (the mail has a MIME multipart type, and
>every part has a header of its own):

Look, not to beat a dead horse, but the RFC you were quoting does not
mention MIME in any way.  It was written in 1982 and refers to the
format of ARPA INTERNET TEXT MESSAGES.  It is referenced in the
appropriate MIME RFC but I'm not sure that it has any bearing on
this problem.

>    1    ----=_35eb3be341926316052e3279.MFSBCHJLHS--
>    2    -
>         For help on using this list (especially unsubscribing), send a 
> 	 message to "[email-masked]" with one line of 
>	 text: "help".
>
>Line #1 is the boundary separating the before-last sub-part from the
>last one. Line #2 ist the first line of the last sub-part. As it is not
>blank it is regarded as a header line, which is wrong.
>
>Just for comparison a valid sub-part from the same mail message:
>
>    1    ----=_35eb3be341926316052e3279.MFSBCHJLHS
>    2    Content-Type: text/plain; charset=us-ascii
>    3    Content-Transfer-Encoding: 7bit
>    4
>    5    Hi folks,
>
>         this is the first draft of the gnuwin32 mini FAQ
>         (...)
>
>Here we also have our boundary (line #1). Now there is a header (lines
>#2, #3), the required blank line (#4) ans the actual beginning of the
>sub-part body (from #5 on).
>
>I hope I could make the issue clear this time: Not the whole mail is
>wrong, but the very last sub-part. Some mail clients may tolerate this
>RFC violation, but not ours. It is just a bit more stringent in this
>respect.

I think the RFC in question here is RFC 1341.  It says:

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

That would suggest that it is ok for us to put anything we want after the
separator.

-- 
[email-masked]             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".