Bug in Aspose Email or Outlook format?

Hello,
I extracted a whole pst and just one message has a strange From email address:

From: “/O=FIRST ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE GROUP(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=00037FFE50E1D8FE” </O=FIRST ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE GROUP(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=00037FFE50E1D8FE>

Anyone seen such case?
Full headers:

Received: Fri, 15 Jul 2022 09:38:58 -0400
MIME-Version: 1.0
From: "/O=FIRST ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE
 GROUP(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=00037FFE50E1D8FE" </O=FIRST ORGANIZATION/OU=EXCHANGE
 ADMINISTRATIVE GROUP(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=00037FFE50E1D8FE>
To: "Richard Poate" <info@xxxxxxx.xxx>
Subject: Re: Download
Message-ID: <SN6PR1501MB21922751D5DEAA52C7F9EB6DBB899@SN6PR1501MB2192.namprd15.prod.outlook.com>
Date: Wed, 13 Jul 2022 11:20:17 -0400
X-Date-Sent: Wed, 13 Jul 2022 11:20:17 -0400
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_4DA4_6E44CB9D.F0911CB4"

@australian.dev.nerds

To ensure a timely and accurate response, please attach the following resources here for testing:

  • Your input PST or message file.
  • Please create a standalone console application (source code without compilation errors) that helps us to reproduce your problem on our end and attach it here for testing.

As soon as you get these pieces of information ready, we will start investigation into your issue and provide you more information. Thanks for your cooperation.

PS: To attach these resources, please zip and upload them.

Hello,
I’ve exported the said msg using aspose… please checkfile.zip (71.1 KB)

@australian.dev.nerds

Please share the requested detail for testing. Thanks for your cooperation.

Hi,
No need for any special sample app, just use your own to see the from field…

I also ask you to browse to your samples data folder:
\Data\Outlook\NewGroup.msg

This is your own .msg sample, check the From field:

From: “Maria Shahid” </o=Aspose/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Maria Shahid8d0>

How to fix and prevent such kind of FROM, which will render the from field invalid in some cases like signature verification?

Please check my attachment:
https://forum.aspose.com/uploads/default/67899

And your msg:
NewGroup.zip (17.1 KB)

@australian.dev.nerds

Could you please point which code example you want us to execute from GitHub examples?

Hi, please just load the msg using mapiMessage to see the from field, I’ve seen many cases that from field is rendered similar and contains invalid chars like: /Exchange…

@australian.dev.nerds

It’s a known thing.
The Exchange server uses its own addressing for sending and receiving. If the sender and recipient are in the same internal organization, SenderEmailAddress does not return an SMTP address.
That is, if you look in such msg, the value of the SenderEmailAddress property will be something like:

“/o=Aspose/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Maria Shahid8d0”

Accordingly, when converting to eml, this value goes into the From field.

Thanks.

1 Like

Hi, thanks for the great info, however, when this value goes into the From field, the from field will contain invalid characters (EmailValidator will show it) and also violates the RFC5322 and RFC2822
Any workaround to prevent having such exchange admin group / etc… data being passed-in? (not using string manipulation)

@australian.dev.nerds

We can, of course, add an option that will search for SenderSmtpAddress property in MSG and fill From address instead of SenderEmailAddress when converting to EML. But this property is not always present. Then leave the From address empty?

Thanks.

1 Like

hmmm, looking at:

“Maria Shahid” </o=Aspose/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Maria Shahid8d0>

From Name exists, From Email does not! If not found in any field (Sender Email, SentRepresentative etc):
So return an empty string for From address (not null), is wise I think, because:

  • This part is pretty useless in eml format:
    </o=Aspose/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Maria Shahid8d0>
  • Violating RFCs
  • Even if not violating, still invalid (contains invalid chars) and might cause some problem somewhere else.
  • Does not give any helpful data to take the risk to keep.

No idea if any good reason available to support keeping it in eml format, but I agree to keep the default state as is now, and add an option for it.

Sometimes I think the original ole2 structure designers were going to make the most complex format possible! While not well-designed and the compatibility keeping issue caused a 2 decades left over of those headaches :frowning:

@australian.dev.nerds

Ok, I have created EMAILNET-40870 ticket to add such option.

Thanks.

1 Like

Hello, if SenderSmtpAddress is absent, SentRepresentingEmailAddress will also be tried to get the email?

@australian.dev.nerds

I think there is one problem here, SentRepresentingEmailAddress isn’t always present. If it is present, in most cases it’s different from the real sender address. Because the property is usually set, “when a client application sends a message on behalf of another client”. Find more here. Thanks.

1 Like

Hello,
Yes, but I thought it’s better than nothing, anyway it’s kinda sender :smiley:
And if you don’t consider SenderRepresentativeName as a sender, why PST.MessageInfo only has SenderRepresentativeName and no From/Sender?
Message.From is pretty important, can’t get why not there, while OlmMessageInfo already has it.

Anyway, let me ask and report some issues if you don’t mind, please?

  • When reading OlmMessageInfo.From, should I check is “OlmMessageInfo.From” is null? empty string? or OlmMessageInfo.From.IsEmpty? or all 3 conditions can happen?
    And when OlmMessageInfo.From.IsEmpty = True, it means all From.DisplayName/From.OriginalDisplayName/From.EmailAddress/From.FaxNumber/From.AddressType will be empty?

  • Not sure if asked about olmstorage extract property?

  • OlmMessageInfo. From/Subject etc will be blank for all kind of smime messages, even for signed only ones, since those headers are not encoded! (no idea why their message class is not IPM.Note.SMIME on olm?) * Windows 7 only? Does not happen under Windows 10?! possible?

  • OlmMessageInfo.From.DisplayName vs OlmMessageInfo.From.OriginalDisplayName?

  • Please inform me, if OlmMessageInfo.GetHashCode.ToString will be unique for each message in the storage?

Best :slight_smile:

@australian.dev.nerds,

And if you don’t consider SenderRepresentativeName as a sender, why PST.MessageInfo only has SenderRepresentativeName and no From/Sender?

That’s a question isn’t for me I guess :slight_smile: The MessageInfo property values are filled with values from Contents Table records. It’ strange, the real PSTs don’t have From/Sender properties in the contents table, even as additional properties. Here’s a link with the required properties, if interested.

When reading OlmMessageInfo.From, should I check is “OlmMessageInfo.From” is null? empty string? or OlmMessageInfo.From.IsEmpty? or all 3 conditions can happen?

You should check, there is no guarantee that From field in a message is empty or missing

And when OlmMessageInfo.From.IsEmpty = True, it means all From.DisplayName/From.OriginalDisplayName/From.EmailAddress/From.FaxNumber/From.AddressType will be empty?

Yes, that’s true.

Not sure if asked about olmstorage extract property?

This is worth discussing. In fact, the OLM is completely different from the PST. And all that is implemented in PST is due to its structure.
It’s strange, but OLM is similar to MBOX in which the data is organized sequentially. It is easy to implement sequential reading there. For random access to data we have to invent all sorts of things.

OlmMessageInfo. From/Subject etc will be blank for all kind of smime messages, even for signed only ones, since those headers are not encoded! (no idea why their message class is not IPM.Note.SMIME on olm?) * Windows 7 only? Does not happen under Windows 10?! possible?

I don’t know either, unfortunately. Such cases have to be investigated further.

OlmMessageInfo.From.DisplayName vs OlmMessageInfo.From.OriginalDisplayName?

I haven’t faced a case of using OriginalDisplayName. Perhaps I should clarify what it was added for.

Please inform me, if OlmMessageInfo.GetHashCode.ToString will be unique for each message in the storage?

Not sure, because in MS Docs:

If value types do not override GetHashCode, the ValueType.GetHashCode method of the base class uses reflection to compute the hash code based on the values of the type's fields. In other words, value types whose fields have equal values have equal hash codes.

If two objects compare as equal, the GetHashCode() method for each object must return the same value. However, if two objects do not compare as equal, the GetHashCode() methods for the two objects do not have to return different values.

Thanks.

1 Like

So, OlmMessageInfo.From.IsEmpty is enough or being null also should be checked?

So leave the investigation to me, will get back with more info :slight_smile:

Sorry but Calendar.Attendees.AppointmentUnsendableRecipients means invalid emails that sending to them is not possible? or something else?

And do you have any idea about Calendar.Attendees.AppointmentRecipients vs Appointment.Attendees?

Thanks for all your help :slight_smile:

@australian.dev.nerds,

So, OlmMessageInfo.From.IsEmpty is enough or being null also should be checked?

I think the following be more correct:

If messageInfo.From Is Nothing OrElse messageInfo.From.IsEmpty Then

Sorry but Calendar.Attendees.AppointmentUnsendableRecipients means invalid emails that sending to them is not possible? or something else?
And do you have any idea about Calendar.Attendees.AppointmentRecipients vs Appointment.Attendees?

As MS says:

The PidLidAppointmentUnsendableRecipients property ([MS-OXPROPS] section 2.35) contains a list of unsendable attendees.

unsendable attendee: An attendee to whom a meeting request or meeting update is not sent.

Unfortunately, I do not know more about this property.
Thanks.