james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] [Commented] (MIME4J-199) does not find the pattern boundary.
Date Mon, 20 Jun 2011 15:08:53 GMT

    [ 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


View raw message