[
https://issues.apache.org/jira/browse/MIME4J-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052002#comment-13052002
]
Stefano Bagnara commented on MIME4J-199:
----------------------------------------
the message you "propose" is not a valid mime message.
here is the spec violated:
---
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
semantics of a part differ from the semantics
of a message, as described in the text.>
---
The "specified delimited" (boundary) cannot occour in the content of a
multipart message, *even* as a substring. The boundary sequence
"NextPart__5980.1307607747" appears multiple times as a substring in the
content of that message.
So, given an invalid message we have to decide how to deal. In this case we
probably chose to use the fastest algorythm and to consider the first occource
as a malformed boundary. I reread the RFC and I think our current behaviour is
correct.
The fix you propose is invalid (IMO) because "indexOf" is a generic function
and changing its behaviour to "indexOfLineEndingWith" is not an option.
The RFC also says:
---
The encapsulation boundary MUST NOT appear inside any of the encapsulated parts
---
boundary is defined as
---
boundary := 0*69<bchars> bcharsnospace
---
so the CRLF before and after the boundary are not *part* of the boundary.
Can you say what MUA produces this badly formatted email?
> does not find the pattern boundary.
> -----------------------------------
>
> Key: MIME4J-199
> URL: https://issues.apache.org/jira/browse/MIME4J-199
> Project: JAMES Mime4j
> Issue Type: Bug
> Components: parser (core)
> Affects Versions: 0.6
> Reporter: Yong-Seong Kim
> Attachments: screenshot-1.jpg
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The name of sub-boundary to the upper boundary in the name + @ If you can not
> retrieve the attachment area.
> modify : BufferedLineReaderInputStream.indexOf(final byte[] pattern, int off,
> int len)
> see image.
> boundary="NextPart__5980.1307607747"
> boundary="NextPart__5980.13076077471"
> 'NextPart__5980.1307607747' is also searched as a search
> NextPart__5980.13076077471.
> [ex
> eml]--------------------------------------------------------------------------------------------------------------------------------
> Content-Type: multipart/mixed;
> boundary="NextPart__5980.1307607747"
> This is a multi-part message in MIME format.
> --NextPart__5980.1307607747
> Content-Type: multipart/alternative;
> boundary="NextPart__5980.13076077471"
> --NextPart__5980.13076077471
> Content-Type: text/plain;
> charset="ks_c_5601-1987"
> Content-Transfer-Encoding: base64
> --NextPart__5980.13076077471
> Content-Type: text/html;
> charset="ks_c_5601-1987"
> Content-Transfer-Encoding: base64
> ...
> --NextPart__5980.13076077471--
> --NextPart__5980.1307607747
> Content-Type: application/octet-stream;
> name="1"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="1"
> ...
> --------------------------------------------------------------------------------------------------------------------------------
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
