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.
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.
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.
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.
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).
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.
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.
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.