[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIME boundary question recap
In <> Keith Moore <firstname.lastname@example.org> 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
> (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.
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(?)