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

Bugfix: Decoding missing in a few placed when parsing MimeMessage or sending an Email #293

Closed
sbellan opened this issue Oct 1, 2020 · 9 comments
Milestone

Comments

@sbellan
Copy link

sbellan commented Oct 1, 2020

Using Version 6.4.3

Couple of issues,

  1. When sending an email with non-ascii characters, like this,
    String attachementName = "⏳.txt";
    System.out.println(attachementName);
    Email email = EmailBuilder.startingBlank()
        .to("foo@gmail.com")
        .from("bar@yopmail.com")
        .withReplyTo("baz@gmail.com")
        .withSubject("hey")
        .withHTMLText("<img src='cid:wink1'><b>We should meet up!</b><img src='cid:wink2'>")
        .withPlainText("Please view this email in a modern email client!")
        .withAttachment(attachementName, IOUtils.toByteArray(attachmentStream), "text/plain")
        .buildEmail();


the content generated when seen using withTransportModeLoggingOnly looks like the following,

Content-Type: text/plain; filename="�.txt"; name="�.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="�.txt"
Content-ID: <=?UTF-8?B?4o+z?=>

The filename and name are not encoded correctly. https://tools.ietf.org/html/rfc1342, https://tools.ietf.org/html/rfc1341

  1. When parsing a email generated by a Outlook client which has the headers like the following,
...
--_004_9e40f9086684426f9ce55a9caffb3ab1Point72com_
Content-Type: text/html;
	name="=?Windows-1252?B?Q29uZmlndXJlX1NTT19mb3JfQWRtaW5fQ29uc29sZV9BY2Nlc3Nfll9T?=
 =?Windows-1252?Q?ilverfort.pdf.html?="
Content-Description: =?Windows-1252?B?Q29uZmlndXJlX1NTT19mb3JfQWRtaW5fQ29uc29sZV9BY2Nlc3Nfll9T?=
 =?Windows-1252?Q?ilverfort.pdf.html?=
Content-Disposition: attachment;
	filename="=?Windows-1252?B?Q29uZmlndXJlX1NTT19mb3JfQWRtaW5fQ29uc29sZV9BY2Nlc3Nfll9T?=
 =?Windows-1252?Q?ilverfort.pdf.html?="; size=274602;
	creation-date="Tue, 29 Sep 2020 14:18:08 GMT";
	modification-date="Tue, 29 Sep 2020 16:33:58 GMT"
Content-Transfer-Encoding: base64
...

with code like this,


    InputStream emailStream = new FileInputStream("somefile.eml");
    MimeMessage mm = new MimeMessage(null, emailStream);
    Email email = EmailBuilder.copying(mm).buildEmail();

It fails with,


org.simplejavamail.mailer.MailValidationException: Suspected of injection attack, field: email.header.Content-Description with suspicious value: =?Windows-1252?B?Q29uZmlndXJlX1NTT19mb3JfQWRtaW5fQ29uc29sZV9BY2Nlc3Nfll9T?=
 =?Windows-1252?Q?ilverfort.pdf.html?=

	at org.simplejavamail.mailer.MailerHelper.scanForInjectionAttack(MailerHelper.java:139)
	at org.simplejavamail.mailer.MailerHelper.validate(MailerHelper.java:97)
	at org.simplejavamail.mailer.internal.MailerImpl.validate(MailerImpl.java:361)
	at org.simplejavamail.mailer.internal.MailerImpl.sendMail(MailerImpl.java:339)
	at org.simplejavamail.mailer.internal.MailerImpl.sendMail(MailerImpl.java:330)

@meeximum
Copy link

I'm facing similar problmes. My filename is ignored, the recipient get's an attchament with =UTF-8BRWRlbmhhdXNlcl9LQjAwMDAwMDE2OQ=== =UTF-8BNF9CcmFuZHN0w6R0dGVyIEhhbnMucGRm= as filename?

Content-Type: application/pdf; name="=UTF-8BRWRlbmhhdXNlcl9LQjAwMDAwMDE2OQ=== =UTF-8BNF9CcmFuZHN0w6R0dGVyIEhhbnMucGRm=" Content-Description: =UTF-8BRWRlbmhhdXNlcl9LQjAwMDAwMDE2OQ=== =UTF-8BNF9CcmFuZHN0w6R0dGVyIEhhbnMucGRm= Content-Disposition: attachment; filename="=UTF-8BRWRlbmhhdXNlcl9LQjAwMDAwMDE2OQ=== =UTF-8BNF9CcmFuZHN0w6R0dGVyIEhhbnMucGRm="; size=38133; creation-date="Wed, 25 Nov 2020 20:08:11 GMT";

@bbottema
Copy link
Owner

@sbellan, could you please provide me with an example email? Even if you don't face this issue anymore or moved on to another library, I would like to analyse the problem and find a solution. Would be much appreciated!

@dschrul-cf
Copy link

You can use this to fix it:
.withAttachment(MimeUtility.encodeText(filename, "UTF-8", null), FileDataSource(pdf))

@bbottema
Copy link
Owner

bbottema commented Jan 2, 2022

Note that attachment name encoding was turned off deliberately due to #271. Not sure what the best solution is right now...

@bbottema
Copy link
Owner

What's the latest status here?

@bbottema
Copy link
Owner

Still waiting for an example. Will close this as non-actionable soon.

@sbellan
Copy link
Author

sbellan commented Jan 24, 2023

Apologies for not following up. Attaching the email which is failing, (rename .txt to .eml)

vers_quoted_printable.txt

This is the code snippet,

    InputStream emailStream = getClass().getResourceAsStream("/vers_quoted_printable.eml");
    MimeMessage mm = new MimeMessage(null, emailStream);
    Email email = EmailBuilder.copying(mm).buildEmail();

    TransportStrategy.SMTP.setOpportunisticTLS(false);
    Mailer mailer = MailerBuilder
        .withSMTPServer("localhost", 25)
        .withTransportStrategy(TransportStrategy.SMTP)
        .withSessionTimeout(10 * 1000)
        .clearEmailAddressCriteria() // turns off email validation
        .withDebugLogging(true)
        .withTransportModeLoggingOnly(true)
        .buildMailer();

    mailer.sendMail(email);

bbottema added a commit that referenced this issue Feb 21, 2023
@bbottema bbottema changed the title Encoding issues with non ascii attachement names. Bugfix: Decoding missing in a few placed when parsing MimeMessage or sending an Email Feb 21, 2023
@bbottema
Copy link
Owner

bbottema commented Feb 21, 2023

Fixed in release 7.8.3, please verify. It was a bit of a pain to figure this one out, thanks again for helping me analyse this!

@bbottema bbottema added this to the 7.8.3 milestone Feb 21, 2023
@sbellan
Copy link
Author

sbellan commented Feb 21, 2023

Great!!. The fix looks quite involved. Thank you.

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

4 participants