Stefano Bagnara ha scritto:
Oleg Kalnichevski (JIRA) ha scritto:
[
https://issues.apache.org/jira/browse/MIME4J-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613295#action_12613295
]
Oleg Kalnichevski commented on MIME4J-52:
-----------------------------------------
I'll look into fixing the infinite loop. Unfortunately I do not see an
easy way of fixing the way corrupt multipart entities are parsed. The
parser in its present form tracks only one boundary at a time. It
can't resume looking for the outer boundary until the inner one is
properly terminated. This approach has its advantages and
disadvantages: on the plus side it is more efficient both in terms
performance and the memory footprint. Also, the parser can handle
correctly inner body parts that may accidentally contain the outer
boundary. On the negative side, malformed multipart entities mess the
rest of the message up completely.
Oleg
The < to <= change already fix the infinite loop.
Whether we want to keep the current behaviour or revamp the old
behaviour is something we have to discuss in the list.
I think Niklas and other old-time mime4j users can help us with this
dilemma.
Here is the rfc text:
-------------
5.1.2. Handling Nested Messages and Multiparts
The "message/rfc822" subtype defined in a subsequent section of this
document has no terminating condition other than running out of data.
Similarly, an improperly truncated "multipart" entity may not have
any terminating boundary marker, and can turn up operationally due to
mail system malfunctions.
It is essential that such entities be handled correctly when they are
themselves imbedded inside of another "multipart" structure. MIME
implementations are therefore required to recognize outer level
boundary markers at ANY level of inner nesting. It is not sufficient
to only check for the next expected marker or other terminating
condition.
---------------
In particular the last sentence:
It is not sufficient to only check for the next expected marker or other
terminating condition.
It seems we'll have to think twice at this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
