-
Notifications
You must be signed in to change notification settings - Fork 101
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
SharedByteArrayInputStream instead mutipart with mail.pop3.forgettopheaders=true #613
Comments
Hi @demarco88 are you able to provide a reproducer or some example code so I can get better understanding?. |
Hi @jbescos. Thanks for your request for additional information.
Furthermore the debug protocol of this execution. Some data are anonymized. The complete base-64 content is cutted (MIAGCyqGS.....................CUTTED...==). It does'nt make sence to post it here completely.
In the RETR Command we first have a multipart/mixed. Including a part text/plain and message/rfc822. But the additional debug logging in the travers method said:
if this example is executed with the mail.pop3.forgettopheaders=true we will get the same output except the Type of the content object:
Now the working example: Only think that seems to work is setting the mail.pop3.disabletop to true. But that's no good option for us.
Now the message has the correct parts. mail.pop3.forgettopheaders does not help or it's a bug in there.
|
@demarco88 Just ran in the same issue. How did you solve it? |
I am debugging this. This flag has to be true, and that can only happen if You said that |
Hi. We face the problem, that we ant to use the flag mail.pop3.forgettopheaders=true in order to force new header request in RETR command, because of header changes of some providers between the TOP and the RETR Command.
At TOP Command the content-type is:
Content-Type: application/pkcs7-mime; smime-type=authenticated-enveloped-data;
name=smime.p7m
At RETR Command the content-type is:
Content-Type: multipart/mixed;
boundary="----=_Part_45_761695249.1657878900597"
Because between TOP Command and RETR Command the provider packed the mail inside a new mail envelope.
This behaviour is part of a german healthcare communication standard specification called KIM.
Now when parsing the content of the email after the RETR Command content-type of the message is application/pkcs7-mime but it should be multipart/mixed. Further the getContent() delivers a SharedByteArrayInputStream instead of a Multipart-Object. Seams to be a bug in combination with forgettopheaders.
If we switch off the forgettopheaders parsing the content is working, but we have the "wrong" (first received ) header informations. If we switch of the mail.pop3.disablecapa or activate the mail.pop3.disabletop then we force the api to use directly the RETR Coammnd. In this case the email is also parsed correctly. But it isn't a good solution for us because we need to filter out some emails in case of specific header informations.
Tested with version 1.6.4 and also 1.6.7.
regards Marco
The text was updated successfully, but these errors were encountered: