Re[2]: MIME boundary question recap

[RCB@xxxxxx (Chris Bartram)]

 In <> Keith Moore <moore@cs.utk.edu> writes:

> For robustness, I suggest:
>
> (a) MIME composers MUST avoid emitting boundaries such that
>     one boundary is a substring of another.  (However, MIME readers
>     MUST NOT refuse to process a message because it has such
>     boundaries.)
>
> (b) MIME readers MUST ignore trailing whitespace in lines that
>     are less than 1000 characters long, when examining a line
>     to see if it is a boundary marker.   (However, since a
>     boundary marker can contain no more than 74 characters before any
>     padding whitespace, including leading and trailing '-'
>     characters, any line with non-white-space characters after
>     the 74th position cannot be a boundary marker.)

Not entirely on subject, but I note that we recently shortened the length
of our generated boundary strings to 'accomodate' broken [IBM] Listserv
implementations, that when distributing our [MIME] messages, chose to
"pretty up" the output, aligning all the content-type parameters on lines
below the original header, indenting each about 30 characters, and wrapping
the resulting boundary across lines - breaking it WITHIN its quotes. I.E.

Content-Type; Multipart/mixed;
              Boundary="--boundary-appears-here-in-this-ridicul
              ous-example"

Try parsing THAT correctly!

Again, customers complained, and we decided it was simpler for us to
accomodate the 'quirk' - I don't know if the listserv program(s) in question
have since been fixed or not(?)

                               -Chris Bartram
                                3k Associates