In <199502101508(_dot_)KAA01412(_at_)wilma(_dot_)cs(_dot_)utk(_dot_)edu> Keith
Moore <moore(_at_)cs(_dot_)utk(_dot_)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