Opinionated behavior limits usability

[matlik]

After searching online, this library as the simplest and best implementation of S/MIME support in Java I could find. Thank you for your work!

I've integrated it into our application, but have run into an issue related to the hard coded default DES_EDE3_CBC algorithm in SmimeUtil.prepareEncryptor(). Our use case requires us to use AES_256_CBC instead. I was able to work around this by creating SmimeUtil.encrypt(Session session, MimeMessage mimeMessage, X509Certificate certificate, ASN1ObjectIdentifier cmsAlgorithm)

Additionally, it may be worth adding some comments in the readme about how SmimeUtil.sign(...) will canonicalize EOL characters as a side-effect. This has the potential of corrupting attachments, as was the case for us. The work-around is to force a Base64 (or something else that will never have a newline) encoding of the attachment instead of allowing the default (7bit text in our case)

If you'd be interested in a pull request, I can try submitting one. It would be a first for me.

Thanks again for this library!

[l-O-O-l]

@matlik Thanks very much for your post. i was using this library and having some strange behavior and though it was just my own problem.

Is it possible to publish your work and I could sync it.

Very much appreciate.

[matlik]

If you are referring to the ability to specify the encryption algorithm, I do have a fork that I will be pushing my changes to soon. You can see it at https://github.com/vnomics/java-utils-mail-smime under the variable-encryption-algorithms branch once I've pushed it.

As for the problem I was having with the text attachment, this is an example snippet of how to make the canonicalization safe for the inbound email message:

    BodyPart attachmentBody = new MimeBodyPart();
    attachmentBody.setDataHandler(new DataHandler(new ByteArrayDataSource(attachment, MediaType.TEXT_PLAIN_VALUE)));
    attachmentBody.setHeader( "Content-Transfer-Encoding", "base64" );
    attachmentBody.setFileName(attachmentName);
    multipart.addBodyPart(attachmentBody);

Setting the Content-Transfer-Encoding after setting the DataHandler resulted in the rendered email body containing Base64 output wrapped every 76 characters and delimited with "\r\n".

[l-O-O-l]

@matlik you are the life saver. I have the encryption part working as expected now. But looks like still have issue with sign. i have a simple sign function that to send out email but looks like not work as expected:

		String from ="x@y.com", to="x@y.com", subject = "sbj", body="body";		
		javax.mail.Session mailSession = javax.mail.Session.getInstance(new Properties(), null);
		MimeMessage message = new MimeMessage(mailSession);
		message.setFrom(new InternetAddress(from));
		message.setRecipient(RecipientType.TO, new InternetAddress(to));
		message.setSubject(subject);
//		message.setContent(body, "text/plain; charset=utf-8"); // neither works.
		message.setText(body);
		System.out.println(SmimeUtil.getStatus(message));
		SmimeKey privateKey = getSmimeKey();
		message = SmimeUtil.sign(mailSession, message, privateKey);
		System.out.println(SmimeUtil.getStatus(message));
		System.out.println("-----------------");

And result

NEITHER
NEITHER
-----------------

I added JCE to JDK, and used the certificate that is generated from COMODO. Because the Encryption works, I think the SmimeKey should be generated right. But just did not figure out why the sign fails.

[matlik]

Try calling message.saveChanges() after signing.

[l-O-O-l]

Another observation:

I need to do following to get signed message sent out

	msg = SmimeUtil.sign(mailSession, msg, getSmimeKey());
	msg.setContent((Multipart) msg.getContent());
	msg.saveChanges();

Otherwise, I will get

	java.io.IOException: "text/plain" DataContentHandler requires String object, was given object of type class javax.mail.internet.MimeMultipart
	at javax.mail.Transport.send0(Transport.java:218)
	at javax.mail.Transport.send(Transport.java:80)

The https://github.com/vnomics/java-utils-mail-smime version handled it way much better. Hope those change would be push to maven.