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

Immediately resolve InputStreams when building emails, don't reuse #268

Closed
DJAxion opened this issue May 19, 2020 · 4 comments
Closed

Immediately resolve InputStreams when building emails, don't reuse #268

DJAxion opened this issue May 19, 2020 · 4 comments

Comments

@DJAxion
Copy link

DJAxion commented May 19, 2020

Hi, we run into a problem where we have an email signed with a PKCS12 key store. Sending the mail goes as expected, and the mail is signed and sent.
Next, we want to store that email for archiving, but EmailConverter.emailToEML(email) seems to re-use the stream in which the key store is provided, resulting in an IOException.

@bbottema
Copy link
Owner

Are you providing the input stream yourself?

I'm not too happy how input streams are handled, because it provides the problem you describe. However reading the contents in the Email means moving some logic to the builder which also shouldn't be there. Perhaps I should remove support for manual input streams altogether...

@DJAxion
Copy link
Author

DJAxion commented Jun 15, 2020

No, we are using the EmailBuilder and indeed add the inputstream to signWithSmime (for the key). There is an option to add a file, but the first thing that happens in the EmailPopulatingBuilderImpl is creating an inputstream of that file, so that also isn't a solution/workarround for us.

@bbottema bbottema changed the title Converting signed mail to .eml re-uses PKCS12 key store stream Immediately resolve InputStreams when building emails, don't reuse Jul 19, 2020
@bbottema bbottema added this to the 6.4.0 milestone Jul 19, 2020
@bbottema
Copy link
Owner

Fix released in 6.4.0.

The api remains largely the same (expanded with byte[] versions), but any input stream passed into the api is resolved immediately now so it won't cause issues lateron.

It would be of great help if you could confirm whether 6.4.0 works for your use case.

@DJAxion
Copy link
Author

DJAxion commented Sep 17, 2020

Sorry for the late response, but I can confirm it's working now! Thanks for your support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants