We use a MultipartFormDataReader to process our "multipart/form-data" (multiple files uploaded via POST). We use inputPart.getBody(InputStream.class, null) to get the binary content of the uploaded files.

Everything worked well until someone tried to upload an EML/rfc822 file.
Turns out the EML gets parsed as part of the request and turned into objects. All other files/mimetypes stay in binary form. EML files turn up as Message objects where the getBody doesn't work with InputStream.
This only happens when the Content-Type of the "formpart" is set to "message/rfc822". So it really does not depend on the content of the file transmitted!

Turns out MultipartFormDataReader uses MultipartInputImpl::BinaryMessage. There a mime4j MimeStreamParser is created, which in turn uses MimeTokenStream. That stream supports MIME as well as rfc822 parsing which results in EML files being parsed. Even attachments in the attached email get parsed.

We obviously don't want the files to be touched and have no control over how the client sends this information. So I looked into how to change this:
MimeTokenStream has a way to control the recursion mode: setRecursionMode
If I set RecursionMode.M_NO_RECURSE there, it won't start parsing any mimeparts in the post request.

Unfortunately this can't be set easily in mime4j 0.6 because the MimeTokenStream is not exposed. I could only solve by patching mime4j. I added a setNoRecurse() to MimeStreamParser and call this in BinaryMessage after creating the parser. Then everything works as expected.
mime4j 0.7 has a new constructor MimeStreamParser(MimeTokenStream tokenStream) which allows to set the streams no_recurse flag.
To make it even easier, I submitted a push request to mime4j to support the settting via a method: https://github.com/apache/james-mime4j/pull/4

I would like to see that fixed in a new version of Resteasy though. How can I help?