Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can I force local parsing on IMAP Connections? #150

Open
jf-kisters opened this issue Jul 12, 2024 · 6 comments
Open

Can I force local parsing on IMAP Connections? #150

jf-kisters opened this issue Jul 12, 2024 · 6 comments
Labels
question Further information is requested

Comments

@jf-kisters
Copy link

Note: This is a "repost" of jakartaee/mail-api#733, which I created in the wrong project.

Describe the bug
We are trying to access a local-run Microsoft Exchange Server via IMAP. This leads us to retrieving attachments of incoming mails with cut-off filenames. After enabling Debug logging we can see that jakarta mail is not downloading the entire MIME structure of the e-mail but is utilizing IMAP to fetch information about attachments via the BODYSTRUCTURE call. Apparently, Exchange is too stupid to support RFC-2251 properly, which allows long fields to be split into multiple lines, and favors to return a cut-off filename instead. This was proven with the logs, the response to the BODYSTRUCTURE call contained the clipped filename (parts of the extension were missing due to them being in the next line inside the MIME structure)

Since we know that jakarta mail also supports POP3, and POP3 expects the mail to be parsed locally, is there a way to alter its behavior on IMAP connections to be the same? Our usecase mandates that we are downloading the entire mail including attachments anyways, so parsing MIME locally would both circumvent the idiocy of Exchange and not come at mentionable cost to us transmission-wise.

To Reproduce
Steps to reproduce the behavior:
Not really reproducible, this occurs on a customer system with some local Microsoft Exchange server of which operations are even outsourced to a sub-contractor...

Expected behavior
Jakarta Mail should ignore the fact that we are talking IMAP and request a download of the entire MIME structure for local parsing as it would do for POP3, instead of using IMAP commands for server-side parsing.

Screenshots
N/A

Desktop (please complete the following information):
Unknown/Irrelevant

Mail server:

Protocol being used: IMAP
Vendor/product: Microsoft Exchange
Mail service URL: company-internal

Additional context
N/A

In the other ticket, we already spoke about mail.imaps.partialfetch=false, however:

I tried it, but it seems it only determines if it downloads the entire bodypart in one go or in chunks. However, even with partialfetch = false, it is still handling the message parts individually by calling BODYSTRUCTURE and FETCH for individual parts of the message, as opposed to fetching the entire MIME in one go.
For comparison, when I manually connect to the Mailserver I do a

03 FETCH 1 BODY[]

which fetches the entire Mime structure, including headers, body and all attachments.
Jakartamail instead performs the following

C7 FETCH 1 (BODYSTRUCTURE)
* 1 FETCH (BODYSTRUCTURE (("text" "plain" ("charset" "utf-8" "format" "flowed") NIL NIL "7bit" 52 3 NIL NIL NIL NIL)("text" "plain" ("charset" "UTF-8" "name" "1.txt") NIL NIL "base64" 36 0 NIL ("attachment" ("filename" "1.txt")) NIL NIL)("text" "plain" ("charset" "UTF-8" "name" "2.txt") NIL NIL "base64" 36 0 NIL ("attachment" ("filename" "2.txt")) NIL NIL) "mixed" ("boundary" "------------379CADE6585D357FB4FBC79D") NIL ("en-US") NIL))
C7 OK Fetch completed (0.001 + 0.000 secs).
Message ID in Multipart Message is 0
C8 FETCH 1 (BODY[2])
{36}
SSBhbSB0aGUgZmlyc3QgYXR0YWNobWVudC4=)
C8 OK Fetch completed (0.001 + 0.000 secs).
C9 FETCH 1 (BODY[3])
{36}
SSBhbSB0aGUgc2Vjb25kIGF0dGFjaG1lbnQu)
C9 OK Fetch completed (0.001 + 0.000 secs).
C10 FETCH 1 (BODY[1])
{52}
Hallo,
I am an email with multiple attachments.

)
C10 OK Fetch completed (0.001 + 0.000 secs).

It is this way of essentially handing the MIME Parsing to the server (by asking for body parts via the protocol) that allows Exchange to botch the BODYSTRUCTURE response and cut of the file name because Exchange doesn't handle RFC-2251 properly

@jf-kisters
Copy link
Author

Does anybody have an idea on how I can proceed here?

@jmehrens
Copy link
Contributor

@jf-kisters The only other long shot I can think of is jakarta.mail.internet system (not session) properties.

Do you have the exact Exchange version?

Most likely we would have to patch the IMAP with a new property to do what you want.

@jf-kisters
Copy link
Author

I'm sorry I didn't see your message earlier, somehow github shows replies to me only after a couple of days??
Regardless, we don't get any reply from our customer anymore and our support ticket with them has been closed after a couple of weeks of trying to raise them -.- (I actually don't know if they just live with that issue now, it definitely wasn't resolved last I checked...) All I can say is that the BODYSTRUCTURE response of the exchange server is broken since Exchange apparently doesn't understand RFC-2251 properly.
In our special case we don't really need the distinction of mailservers anyways; if we would have the possibility to always enforce the local (POP3-Style) handling of E-Mails - regardless of mailserver - it would actually serve our usecase.

@jf-kisters
Copy link
Author

Is there any chance here to get a possibility to enable POP3-style local parsing for IMAP?

@jmehrens
Copy link
Contributor

@jf-kisters what is the exact version of Exchange? We will need this to test and verify the fix.

It will be sometime before I can look at this feature.

@jmehrens
Copy link
Contributor

Also I'll repost again what I want you to try but explained better:

https://stackoverflow.com/questions/14566422/issue-retrieving-attachment-filename-with-javamail

@jmehrens jmehrens added the question Further information is requested label Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants