We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Message delivery time changed during conversion of MailMessage to MapiMessage

I am facing problem with Date and Time issue for Draft Mail
PR_MESSAGE_DELIVERY_TIME value are changing
following are code i used
MapiMessage pMail = null;
MailMessage Obj_MailMessage = null;
string MsgPath = @"C:\Users\rohidas\Desktop\New folder (3)\Microsoft Office Outlook Test Message.msg";
MailMessageLoadOptions loadOptions = new MailMessageLoadOptions();
loadOptions.MessageFormat = MessageFormat.Msg;
Obj_MailMessage = MailMessage.Load(MsgPath, loadOptions);
pMail = MapiMessage.FromMailMessage(Obj_MailMessage, OutlookMessageFormat.Unicode);

File.Delete(@"C:\Users\rohidas\Desktop\output\pstFile.pst");
PersonalStorage pst = PersonalStorage.Create(@"C:\Users\rohidas\Desktop\output\pstFile.pst", FileFormatVersion.Unicode);
pst.RootFolder.AddSubFolder("TestFolder");
FolderInfo outfolder = pst.RootFolder.GetSubFolder("TestFolder");

outfolder.AddMessage(pMail);




I am sending some sample MSG file and exported PST, Please see the attachment

Hi Rohidas,


I have tested the scenario and have observed that message delivery time is changed. I have logged this issue under id:NETWORKNET-34332 in our issue tracking system.

This thread is linked with this ticket and you will be automatically notified once the issue is analyzed and feedback is received from the development team.

Please feel free to write us back if you have any other query in this regard.

Hello Kashif,


Thanks for quick replay, Is this known issue for your API or it will be address in upcoming release.

We also facing issue with Mail Size:
Whenever we add the message in mapi message the PR_MESSAGE_SIZE are differs from original size.Please go through the sample MSG File and let us knows about it.

Hi Rohidas,


Thank you for writing to Aspose support again.

As the earlier issue Id:NETWORKNET-34332 is logged in our issue tracking system, so please spare little time while developers analyze it and provide feedback. If it is declared as bug, it will be resolved in the future release and you will be notified automatically.

I have analyzed the sample MSG file “body n HTML.msg” using Outlook Spy and found that PR_MESSAGE_SIZE value is 201537. Later this message is loaded into MapiMessage and it is observed that Aspose.Email shows same value for the property PR_MESSAGE_SIZE.

Could you please provide more detail about the difference in the original size and PR_MESSAGE_SIZE value? If possible please send some snapshot or sample code which can be used to reproduce the scenario here. It will be helpful for us to analyze the problem and provide assistance in this regard.

Hello


i will share some screen shot along with exported PST where PR_MESSAGE_SIZE Differ
Please go through the attachment

Hi Rohidas,


Thank you for providing sample data.

I have analyzed the scenario and observed that if we manually drag the original message in some PST and then compare the PR_MESSAGE_SIZE property of original and dragged message in PST, both are different. It shows that difference in property is expected behavior and is not a bug in Aspose library.

Please feel free to write us back if you have any other query related to Aspose.Email. We will be glad to provide you assistance as much as possible.

Hi Rohidas,


I am glad to share that Aspose.Email for .NET 4.1.0 is released and available for download now.

I would also like to share that we have thoroughly investigated the issue id: NETWORKNET-34332. It is observed that conversion is used like MSG->EML->MSG. As a result of MSG->EML conversion, the DeliveryTime property is lost as the field, analogous to this property, does not exist in EML. This date could be saved in Received heading, but as the original message is UNSENT, such a heading is absent in the destined EML. It is suggested that you may avoid such conversion with loses and use MapiMessage for loading from file i.e. MapiMessage.FromFile.

Hope this clarifies the issue and please feel free to write us back if you have any other query in this regard.