Niklas submitted this message as part of MIME4J-52
==========================
Content-Type: multipart/mixed; boundary="outer-boundary"
Outer preamble
--outer-boundary
Content-Type: text/plain
Foo
--outer-boundary
Content-Type: multipart/alternative; boundary="inner-boundary"
AAA
--outer-boundary--
Outer epilouge
============================
What is the expected result for this?
Should the parser understand that the inner multipart never starts and
that it instead find another outer boundary?
ATM mime4j locks in a loop.
Adding the fix I proposed in a comment to that issue the result is that
mime4j consider:
=============================
AAA
--outer-boundary--
Outer epilouge
=============================
the preamble of the inner multipart ignoring the "--outer-boundary--" of
the external multipart.
What is the correct/best way to handle bad multiparts like this?
Stefano
PS1: I found this discussion related to boundaries, MUAs and malformed
mime messages:
http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200409.mbox/[EMAIL
PROTECTED]
This seems to tell us that it would be better (when in non strict mode)
to support spaces at the end of the boundaries because other MUAs do
that, too.
PS2: I remembered we had more messages we removed because of licensing
issues (https://issues.apache.org/jira/browse/MIME4J-11). I revamped
them and checked the mime4j 0.2 expected results with what we return now
and I found 3 differences (frag.msg, multi-2gifs-base64.msg,
multi-frag.msg). I hope I will soon find the time to create simple
example messages to reproduce the issue so we can decide wether the new
behaviour is the expected one or we have bugs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
