SharedByteArrayInputStream instead mutipart with mail.pop3.forgettopheaders=true

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

Start by reproducing the POP3 parsing behavior with mail.pop3.forgettopheaders=true and compare the TOP and RETR responses described in the issue. Trace how getContent() handles the changed Content-Type and SharedByteArrayInputStream. Done means the RETR content is parsed as multipart/mixed while the initial headers remain available for filtering.

Written by the indexing model from the issue text.