Exported message has MSG format violation?

Hi,

in a test project we’re exporting some sample messages from PersonalStorage like this:

Code:

using (var src = PersonalStorage.FromFile(@“small_pst.pst”, false))
{
var folder = src.RootFolder.GetSubFolder(“Inbox”);
foreach (var messageEntryId in folder.EnumerateMessagesEntryId())
{
var message = src.ExtractMessage(messageEntryId);
var fileName = message.Subject;
message.Save(string.Format(@“output\Aspose</span>{0}.msg”, fileName));
}
}
This works. We’re able to observe the MSG files being written to the destination location.

Then we load the exported MSG files for further processing via an 3rd party library and it complains that the MSG files violate MSG specification, specifically - Property Stream was empty.

This is odd. We’re able to open up the messages via double-clicking them and they do show up via Outlook reading window.

So we investigated a little bit further and after we exported the same messages via Outlook (Save As) and via MFCMapi - the 3rd party library accepted all those MSG files. So it seems like Aspose.Email isn’t creating some required property stream.

I’m attaching the samples I’ve retrieved from the sample PST (which I can also provide if necessary). Please ignore “rendezvoused matador batching.msg” files - those have PR_MESSAGE_CLASS set to empty string to test some other problem - I just kept it there.

PS: I reached out also to the 3rd party library to get more details about which property stream is missing, but I do believe you can figure it out form the samples I included.

Thanks and best regards,
Michal

Hi Michael,

Thank you for posting your query.

We have analyzed the sample MSG files here at our end. These are loaded fine using our own API, MS Outlook (as you mentioned) and even MFCMapi. For further investigation, we request you to please share the 3rd party API that you are using to load the extracted message files. Also, please share how to load the extracted MSGs using this 3rd party API. We shall further investigate this issue in detail and share our feedback with you.

Hi Muhammad,

unfortunately I can’t share more details about the 3rd party library. I contacted them directly as well to let me know which property stream they are missing with their load method.

Once I get the details, I’ll post them here too. It might / might not be a problem with the export and how the MSG file is constructed.

This post was just to get a feel about what might be a problem with the posted MSG files - I guess you have more experts on MSG file format specifics and the expected / required streams within each MSG file.

As you write - you can open them with Aspose, Outlook and MFCMapi - which I validated too. It’s just something that is different/unexpected in the Aspose ones, as the 3rd party complained just about them.

Thanks,
Michal

Hi Michal,

Can you please name the 3rd party API atleast for our knowledge and testing until further information is available about it? We are just inquisitive to try it at our end and observe the behavior for our consideration. In any case, your feedback will allow us to investigate the issue and assist you further.

Hi Muhammad,

I’ve got a feedback about the violation from the 3rd party library provider.

The specification violation is in NamedProperty storage. To be precise - in the string stream (__substg1.0_00040102). Each of the entries MUST conform to the following format (MSDN String Stream):


Name Length (4 bytes): The length of the following Name field in bytes.





Name (variable): A Unicode string that is the name of the property. A new entry MUST always start on a 4 byte boundary; therefore, if the size of the Name field is not an exact multiple of 4, and another Name
field entry occurs after it, null characters MUST be appended to the
stream (1) after it until the 4-byte boundary is reached. The Name Length field for the next entry will then start at the beginning of the next 4-byte boundary.

The main problem is that the strings (and the name lengths) are not aligned to 4 byte boundary. Here is a hex view from one of the sample messages generated by Aspose:

0000000000: 4A 00 00 00 78 00 2D 00 │ 6D 00 73 00 2D 00 65 00 J x - m s - e

0000000010: 78 00 63 00 68 00 61 00 │ 6E 00 67 00 65 00 2D 00 x c h a n g e -

0000000020: 6F 00 72 00 67 00 61 00 │ 6E 00 69 00 7A 00 61 00 o r g a n i z a

0000000030: 74 00 69 00 6F 00 6E 00 │ 2D 00 61 00 75 00 74 00 t i o n - a u t

0000000040: 68 00 73 00 6F 00 75 00 │ 72 00 63 00 65 00 10 00 h s o u r c e ►

0000000050: 00 00 49 00 73 00 53 00 │ 69 00 67 00 6E 00 65 00 I s S i g n e

0000000060: 64 00 36 00 00 00 43 00 │ 6F 00 6E 00 76 00 65 00 d 6 C o n v e

0000000070: 72 00 73 00 61 00 74 00 │ 69 00 6F 00 6E 00 49 00 r s a t i o n I

0000000080: 6E 00 64 00 65 00 78 00 │ 54 00 72 00 61 00 63 00 n d e x T r a c

0000000090: 6B 00 69 00 6E 00 67 00 │ 45 00 78 00 1A 00 00 00 k i n g E x →

00000000A0: 49 00 73 00 52 00 65 00 │ 61 00 64 00 52 00 65 00 I s R e a d R e

00000000B0: 63 00 65 00 69 00 70 00 │ 74 00 1A 00 00 00 53 00 c e i p t → S

00000000C0: 6F 00 75 00 72 00 63 00 │ 65 00 45 00 6E 00 74 00 o u r c e E n t

00000000D0: 72 00 79 00 49 00 44 00 │ 36 00 00 00 53 00 6F 00 r y I D 6 S o

00000000E0: 75 00 72 00 63 00 65 00 │ 4C 00 61 00 73 00 74 00 u r c e L a s t

00000000F0: 4D 00 6F 00 64 00 69 00 │ 66 00 69 00 65 00 64 00 M o d i f i e d

0000000100: 54 00 69 00 6D 00 65 00 │ 73 00 74 00 61 00 6D 00 T i m e s t a m

0000000110: 70 00 42 00 00 00 78 00 │ 2D 00 6D 00 73 00 2D 00 p B x - m s -

0000000120: 65 00 78 00 63 00 68 00 │ 61 00 6E 00 67 00 65 00 e x c h a n g e

0000000130: 2D 00 6F 00 72 00 67 00 │ 61 00 6E 00 69 00 7A 00 - o r g a n i z

0000000140: 61 00 74 00 69 00 6F 00 │ 6E 00 2D 00 61 00 75 00 a t i o n - a u

0000000150: 74 00 68 00 61 00 73 00 │ t h a s
And here is one by Outlook:
0000000000: 1A 00 00 00 53 00 6F 00 │ 75 00 72 00 63 00 65 00 → S o u r c e
0000000010: 45 00 6E 00 74 00 72 00 │ 79 00 49 00 44 00 00 00 E n t r y I D
0000000020: 36 00 00 00 53 00 6F 00 │ 75 00 72 00 63 00 65 00 6 S o u r c e
0000000030: 4C 00 61 00 73 00 74 00 │ 4D 00 6F 00 64 00 69 00 L a s t M o d i
0000000040: 66 00 69 00 65 00 64 00 │ 54 00 69 00 6D 00 65 00 f i e d T i m e
0000000050: 73 00 74 00 61 00 6D 00 │ 70 00 00 00 36 00 00 00 s t a m p 6
0000000060: 43 00 6F 00 6E 00 76 00 │ 65 00 72 00 73 00 61 00 C o n v e r s a
0000000070: 74 00 69 00 6F 00 6E 00 │ 49 00 6E 00 64 00 65 00 t i o n I n d e
0000000080: 78 00 54 00 72 00 61 00 │ 63 00 6B 00 69 00 6E 00 x T r a c k i n
0000000090: 67 00 45 00 78 00 00 00 │ 42 00 00 00 78 00 2D 00 g E x B x -
00000000A0: 6D 00 73 00 2D 00 65 00 │ 78 00 63 00 68 00 61 00 m s - e x c h a
00000000B0: 6E 00 67 00 65 00 2D 00 │ 6F 00 72 00 67 00 61 00 n g e - o r g a
00000000C0: 6E 00 69 00 7A 00 61 00 │ 74 00 69 00 6F 00 6E 00 n i z a t i o n
00000000D0: 2D 00 61 00 75 00 74 00 │ 68 00 61 00 73 00 00 00 - a u t h a s
00000000E0: 4A 00 00 00 78 00 2D 00 │ 6D 00 73 00 2D 00 65 00 J x - m s - e
00000000F0: 78 00 63 00 68 00 61 00 │ 6E 00 67 00 65 00 2D 00 x c h a n g e -
0000000100: 6F 00 72 00 67 00 61 00 │ 6E 00 69 00 7A 00 61 00 o r g a n i z a
0000000110: 74 00 69 00 6F 00 6E 00 │ 2D 00 61 00 75 00 74 00 t i o n - a u t
0000000120: 68 00 73 00 6F 00 75 00 │ 72 00 63 00 65 00 00 00 h s o u r c e
0000000130: 10 00 00 00 49 00 73 00 │ 53 00 69 00 67 00 6E 00 ► I s S i g n
0000000140: 65 00 64 00 1A 00 00 00 │ 49 00 73 00 52 00 65 00 e d → I s R e
0000000150: 61 00 64 00 52 00 65 00 │ 63 00 65 00 69 00 70 00 a d R e c e i p
0000000160: 74 00 │ t
There are multiple occurrences where NULL chars were added to be conform with the specification (e.g. 0x1E, 0x1F, 0x5A, 0x5B, etc).

Thanks and best regards,
Michal

Hi Michal,


I have reviewed the snapshot and have observed the difference in the named property storage stream. Could you please provide the sample PST (small_pst.pst) from which this message is extracted as I need to re-produce this issue here before logging it for the product team? It will help us to analyze the issue and provide assistance as soon as possible.

Hi Muhammad,

please see the sample PST file attached (within ZIP file).
The code to retrieve the messages is located in 1st post.

Thanks and best regards,
Michal

Hi Michael.

Thank you for sharing the sample PST file. While we are trying to analyze the problem at our end, could you please share how to observe the difference between the MSGs exported by Aspose and MS Outlook in either MFCMapi or any other analysis tool? This may help expedite the investigation at our end for assisting you further. We appreciate your cooperation in this regard.

PS: If possible, please share the name of the 3rd party API that raises error when used to read the Aspose exported messages.

Hi Michael,


This is to update you that we have logged this issue as EMAILNET-34810 in our bug tracking system for our Product team to investigate it further. We shall write back here once there is some information available in this respect.

The issues you have found earlier (filed as EMAILNET-34810) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by Aspose Notifier.