ietf-822
[Top] [All Lists]

Re[2]: MIME boundary question recap

1995-02-10 09:50:42
 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

<Prev in Thread] Current Thread [Next in Thread>