Sam Varshavchik writes:
Leonid Andreev writes:
--=====================_93394015==_
--=====================_93394015==_.ALT
The piece of code responsible for this is in
courier-0.33.0/rfc2045/rfc2045.c:
l=strlen(cb);
if (c[0] == '-' && c[1] == '-' && n >= 2+l &&
strncasecmp(cb, c+2, l) == 0)
^^^^^^^^^^^^^^^^^^^^^^
i.e., only the first L characters are compared, where L is the length
Absolutely correct. From RFC 2046, page 19:
====
NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
boundary value with the beginning of each candidate line. An exact
match of the entire candidate line is not required; it is sufficient
that the boundary appear in its entirety following the CRLF.
====
In other words, if the boundary value is "xyz", then the sequence
"<CR><LF>--xyz" is sufficient to identify a boundary, so a line with
either "--xyz" and "--xyzfoo" will match the "xyz" boundary value.
A nested multipart MIME section that uses one boundary value that is an
exact substring of an inner or an outer boundary value is invalid.
I suspected that this was invalid MIME; it is a relatively common condition
in real world though -- Eudora 5* does this all the time. Eudora aside,
if this is invalid MIME, then courier probably shouldn't accept it -- just
like you reject messages with improperly mime-d 8bit content. Accepting
the message and then sending out an even more invalid (corrupted) message
doesn't look like the best possible solution.
Out of curiosity: are there any mailers out there that actually use
boundaries strings with only the beginnings matching the declared
boundary value?
thanks,
-L.
11 messages in net.sourceforge.lists.courier-users[courier-users] Re: bug report: Couri...
