Sender no longer present

[Faelean]

We're currently testing the 9.0.0 release and noticed, that the Sender is no longer present in the "chinese message.msg" file from the Outlook Message Parser test data (https://github.com/bbottema/outlook-message-parser/blob/master/src/test/resources/test-messages/chinese%20message.msg)

        String msgFileName = ".\\assets_sjm\\chinese message.msg";

        try (FileInputStream fileInputStream = new FileInputStream(msgFileName)) {

            Email email = EmailConverter.outlookMsgToEmail(fileInputStream);
            System.out.println("Sender: " + email.getFromRecipient().getAddress());
        }

With 8.12.6 this results in
Sender: x@Ctrip.com,
with 9.0.0 we're getting
Sender: donotreply@unknown-from-address.net

[bbottema]

Thanks, reproduced.

This changed between Simple Java Mail 8.12.6 and 9.0.0 through the outlook-message-parser 1.15.0 update. The value previously returned for this file is not present in a real sender field/header. In chinese message.msg, the Ctrip address is stored in Outlook MAPI property 0x3FFA / PR_LAST_MODIFIER_NAME.

That property is a history/source-file property, not sender identity. It was removed from sender detection in outlook-message-parser because of bbottema/outlook-message-parser#77: the previous behavior could incorrectly report the creator/last modifier of a .msg file as the email sender.

So the current 9.0 behavior is intentional at the parser level: no real sender is found, and Simple Java Mail then applies its missing-sender fallback address.

If you need the pre-9.0 compatibility behavior for your own data set, you can opt into it explicitly by reading the raw Outlook property and applying it yourself:

import org.simplejavamail.api.email.Email;
import org.simplejavamail.api.outlook.OutlookEmailConversionResult;
import org.simplejavamail.converter.EmailConverter;
import org.simplejavamail.outlookmessageparser.OutlookMessageParser;
import org.simplejavamail.outlookmessageparser.model.OutlookMessage;

import java.io.File;
import java.io.FileInputStream;

File msgFile = new File("chinese message.msg");

OutlookEmailConversionResult result =
        EmailConverter.outlookMsgToEmailBuilderWithOutlookData(msgFile);

OutlookMessage outlookMessage;
try (FileInputStream input = new FileInputStream(msgFile)) {
    outlookMessage = new OutlookMessageParser().parseMsg(input);
}

Object lastModifierName = outlookMessage.getPropertyValue(0x3ffa);
if (lastModifierName instanceof String
        && ((String) lastModifierName).contains("@")) {
    result.getEmailBuilder().from((String) lastModifierName);
}

Email email = result.buildEmail();

I will keep this issue open briefly while deciding whether Simple Java Mail should expose this as a deliberately named compatibility option, but I do not want to restore the old automatic behavior because that would reintroduce the bug fixed in outlook-message-parser#77.

[bbottema]

It's tempting to use PR_LAST_MODIFIER_NAME as a missing-sender fallback because it will often look right for simple exported .msg files, but it really isn't reliable: it could be the sender, but it could just as well be middleware tooling, Outlook itself, a migration process, a delegate/shared-mailbox user, or anything else responsible for creating/modifying the stored Outlook item without being the actual email sender.

[bbottema]

As a middle ground solution, the Outlook last-modifier value is now exposed as first-class source metadata:

OutlookEmailConversionResult result =
    EmailConverter.outlookMsgToEmailBuilderWithOutlookData(msgFile);

String lastModifierName = result.getOutlookMessageData().getLastModifierName();
Email email = result.buildEmail();

This intentionally does not restore the pre-9.0 sender mapping: PR_LAST_MODIFIER_NAME / 0x3FFA remains source/store metadata and is not treated as Email.from, but at least now there's a nice api to use it yourself as fallback if you choose so.

Released in Simple Java Mail 9.0.2.

[Faelean]

Thanks for the update. We weren't aware that this might not be the sender. At least for me this seems like a reasonable change, if in the future someone wants the old behaviour back I'll use the new api functions.