bbottema/simple-java-mail

[bug] Addresses passed as string are not always interpreted correctly

Closed this issue · 5 comments

piu130 commented

When parsing msg with valid Disposition-Notification-To or Return-Receipt-To the Recipient is not filled correctly. I assume the same applies to Return-Path.

Sample header: Disposition-Notification-To: Fname Lname <fname.lname@domain.ch>
Expected: Recipient{name='Fname Lname', address='fname.lname@domain.ch', type=null}
Actual: Recipient{name='null', address='Fname Lname <fname.lname@domain.ch>', type=null}

The problem happens in OutlookEmailConverter.parseHeader(String headerName, String headerValue, EmailPopulatingBuilder builder) where the header value is passed to EmailPopulatingBuilder.withDispositionNotificationTo(String address).

bbottema commented

Do you have a message for me to work with?

piu130 commented

Yes, sorry. The original mail was confidential. I was able to reproduce it with outlook by selecting 'Request a <Delivery|Read> Receipt'.
sample.zip

When calling EmailConverter.outlookMsgToEmail you can see the incorrect recipients in the output. Return-Receipt-To still contains the < and > in the address and Disposition-Notification-To has the name and email in the address.

piu130 commented

Some context to the problem we are facing: we have this problem with msg #40. As a workaround, we convert msg -> Email -> eml -> Email. This way we have access to the attachments which were not available in the original msg -> Email.

When we have a signed email which has one of the headers above, the first step msg -> Email stores the wrong recipient addresses. Later in eml -> Email, it fails with AddressException: Missing '<' in string ``<"Dude" <dude@domain.ch>>'', because the address was parsed incorrectly in the first step and thus converted wrongly to eml in Email -> eml.

Stacktrace:

org.simplejavamail.converter.internal.mimemessage.MimeMessageParseException: Error parsing [Disposition-Notification-To] address [<"Dude" <dude@domain.ch>>]
    at org.simplejavamail.converter.internal.mimemessage.MimeMessageParser.createAddress(MimeMessageParser.java:379)
    at org.simplejavamail.converter.internal.mimemessage.MimeMessageParser.parseHeader(MimeMessageParser.java:223)
    at org.simplejavamail.converter.internal.mimemessage.MimeMessageParser.parseMimePartTree(MimeMessageParser.java:160)
    at org.simplejavamail.converter.internal.mimemessage.MimeMessageParser.parseMimeMessage(MimeMessageParser.java:153)
    at org.simplejavamail.converter.EmailConverter.mimeMessageToEmailBuilder(EmailConverter.java:138)
    at org.simplejavamail.converter.EmailConverter.mimeMessageToEmailBuilder(EmailConverter.java:125)
    at org.simplejavamail.converter.EmailConverter.emlToEmailBuilder(EmailConverter.java:398)
    at org.simplejavamail.converter.EmailConverter.emlToEmail(EmailConverter.java:327)
    at org.simplejavamail.converter.EmailConverter.emlToEmail(EmailConverter.java:319)
bbottema commented

I found the problem to be more widespread, where the builder api for setting email addresses from strings doesn't call the appropriate parser method, which should separate the (optional) name part from the address part. It was a quick fix as all the logic was in place, but it wasn't called from all the appropriate places.

Thank you for your analyses as well as the example email, it helped me verify the fix real quick.

bbottema commented

Fix released in 8.5.0.

  • 👍2