james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning (JIRA)" <server-...@james.apache.org>
Subject [jira] Resolved: (MIME4J-47) Nested multipart messages with non-empty epilogue cause indefinite loop
Date Thu, 10 Jul 2008 19:38:33 GMT

     [ https://issues.apache.org/jira/browse/MIME4J-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niklas Therning resolved MIME4J-47.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.4

Thanks Oleg, your patch has been applied.

> Nested multipart messages with non-empty epilogue cause indefinite loop
> -----------------------------------------------------------------------
>
>                 Key: MIME4J-47
>                 URL: https://issues.apache.org/jira/browse/MIME4J-47
>             Project: Mime4j
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Niklas Therning
>            Assignee: Niklas Therning
>             Fix For: 0.4
>
>         Attachments: 36368753.msg, mime4j.patch
>
>
> I'm attaching a very simple message which causes the current version of Mime4j to loop
indefinitely when the following app is run:
>   public static void main(String[] args) throws IOException {
>       String msg = "36368753.msg";
>       MimeTokenStream stream = new MimeTokenStream();
>       stream.parse(new FileInputStream(msg));
>             
>       while (stream.getState() != EntityStates.T_END_OF_STREAM) {
>           stream.next();
>       }
>   }
> If the line 'foo' is removed completely the message will parse as expected. I've tried
to figure out why this happens. It seems like the MimeBoundaryInputStream becomes out of sync
for the outer multipart at the end. The skipBoundary() method is called when read() is invoked
even though we're not at the boundary yet which means that the end boundary won't be detected
properly. One observation I did is that reset() doesn't set eof to false. If I do that in
reset() the mail parses as expected:
>     public void reset() {
>         atBoundary = false;
>         limit = -1;
>         eof = false;
>     }
> I could check in this fix myself but I do not know enough about the recent changes in
Mime4j to be able to determine if this is the correct way to fix this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message