MIME Authors,
This is an explanation of the difficulties some of our mail products
are having interrupting MIME encoded attachment being sent using
Eudora.
As Steve, form Qual Comm, has pointed out; a confusion has resulted in
determining and reading boundary definitions in regards to the MIME
RFC. Your last supplement does a lot to clarify the problem,
unfortunately, it doesn?t help us remedy the conflict that already
exists. There are several a
pplications that can not correctly locate Eudora?s boundaries because
their boundaries are not explicitly unique.
The problem is in the uniqueness of the boundary strings when multiple
or sub-boundaries are defined. When Eudora defines a sub-boundary
definition it merely adds one character to the end of the initial
boundary definition. Thus the first boundary string now appears in
every occurrence of the
newly defined boundary.
All the Eudora's mail will POP fine if we go into the mail server and
redefine the sub-boundary definitions. A character can be added
anywhere in the sub-boundary string so that the newly defined string
does not contain the exact contents of the original boundary
definition.
EUDORA EXAMPLE THAT WILL NOT POP:
Content-Type: multipart/mixed;
boundary="========================_123873066==_"
Content-Type: multipart/header-set;
boundary="========================_123873066==_D"
NOTE: The first boundary definition occurs as part of the second
boundary string.
MODIFIED EUDORA EXAMPLE THAT WILL POP:
Content-Type: multipart/mixed;
boundary="========================_123873066==_"
Content-Type: multipart/header-set;
boundary="========================_1238U73066==_D"
NOTE: Adding any character (or removing a character) other than at the
end of the string ('U' in this example) now makes the boundaries unique
so that the second does not contain a the exact character string of the
first. (Exact copies of the offending Email were sent to Steve)
Does the following note concerning uniqueness still apply?
RFC 1341 MIME:
?NOTE: Because encapsulation boundaries must not appear in the body
parts ....., a user agent must exercise care to choose a unique
boundary. The boundary in the example above could have been the result
of an algorithm designed to produce boundaries with a very low
probability of already exist
ing in the data to be encapsulated [Eudora assures that their boundary
will exist elsewhere by using the same string in defining the next
boundary definition] without having to prescan the data. Alternate
algorithms might result in more ?readable? boundaries for a recipient
with an old user age
nt, but would require more attention to the possibility that the
boundary might appear in the encapsulated part......?
Your RFC supplement (along with having the previous note removed) will
definitely clarify problems in the future. I thought, however, that the
easiest solution would have been for Qual Comm to modify their sub-boundary
string by simply changing one character. We (Rome Laboratory with 1300 user
s) can?t afford to get involved in a political war over who?s right and who?s
wrong. We just need products that will get the job done. Qual Comm has been
more than extremely reluctant to help us find a solution. We will more than
likely have to find alternative products and eliminate future p
urchases of offending software.
I also added this section at some point:
NOTE TO IMPLEMENTORS: Boundary string comparisons must take into
account the
full contents of the candidate line containing a possible boundary
string.
Specifically, the entire string following the CRLF and two dashes up
to either
the final two dashes or the final CRLF must be compared with the
boundary
parameter. An exact match is required; a substring match is not
sufficient.
I don't think this is in the current draft that is out there now -- I
added it
in response to feebasck at the last IETF meeting. I'm working on a new
draft
and hope to have something out by the end of the week.
If you have any more light to shed on the subject, I would be glad to
hear from you.
Thanks,
Captain Doug Sanborn, USAF
Comunications and Coumputer Division, Rome Lab
315-330-7258