From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: Mailing list admin, please read this! 8 Sep 1998 12:07:51 -0700 Message-ID: <19980907153734.B11287.cygnus.gnu-win32@cygnus.com> References: <35F00A85 DOT 502D153A DOT cygnus DOT gnu-win32 AT ina DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Alexander Kriegisch Cc: GNU-Win32 Discussion 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 "gnu-win32-request AT cygnus DOT com" 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. -- cgf AT cygnus DOT com "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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".