Hello,
As title suggests, there’s a nasty bug there OLM2.zip (6.5 MB)
Could you please share the folder name that is not read by Aspose.Email? Please also share the sample application to reproduce this issue at our end. Thanks for your cooperation.
Hi,
OK attaching 2 ready to run sample projects with different problems
Run and extract the OLM, then check the “out” folder for the parsed results with the related notes
- Apology for the confusion:
ONLY signed/encrypted messages are deformed, not the whole folder.
Sample #1
“Address Book” folder:
-
Question, please advise how to detect if the item is a contact to save as VCF?
-
Problem, please check any file inside Address Book folder, “EMAIL;INTERNET” field is rendered incorrectly: info@hayedehmusic=2Ecom
=2E instead of dot (.)
At sign (2) is correct but not dot (.) ??? -
Problem, three emails exist in this path inside OLM:
INBOX
You can see a partial deformed file named “_6.eml”
That’s the one which is signed and encrypted, if you check it at the runtime, it’s just mostly null/nothing!
So this is the bug: Signed/Encrypted emails are not extracted properly!
WindowsApplicationOLM0.zip (6.2 MB)
2nd sample project:
-
Problem, check Archive folder: all files are extracted incorrectly, check file contents
-
Problem, check Contacts folder: open those files, what kind of mess is this? Pure html inside message as body?!
-
Problem, check Inbox folder: some files with no chars in name starting with _ and numbers (_195 to _230), check their contents, why?!
-
Problem, check Notes folder: two files, open them, again html?!
-
Problem, check Sent Items folder, again corrupt numbered files!
-
Problem, Tasks folder, same problem.
-
Problem, United States holidays folder, same problem.
WindowsApplicationOLM1.zip (5.9 MB)
We have logged these issues in our issue tracking system as EMAILNET-40773 and EMAILNET-40774. We will inform you once there is an update available on it. We apologize for your inconvenience.
Please check the following code snippet.
If msgInfo.MessageClass = "IPM.Contact" Then
Dim mapiItem = InputStorage.ExtractMapiMessage(msgInfo).ToMapiMessageItem()
Dim contact = CType(mapiItem, MapiContact)
contact.Save(Path.Combine(MyPath, String.Format("{0}_{1}.vcf", FileNameSafeString(msgInfo.Subject), ContactSaveFormat.VCard)))
End If
The Content-Transfer-Encoding in EML is quoted-printable. We encode the dot (.) to avoid problems with some mail filters when sending messages. Thus, encoding a dot is acceptable and is not considered an error.
This issue will be fixed in next version of Aspose.Email for .NET 22.10.
Please advise how to decode items correctly? We’re not aware what happens internally in your engine (ie which characters are encoded like that) anyway, a sample to show the correct extraction method is wise to be published
You will see the encoded characters on opening the saved message in a text editor. When opening the message in Aspose.Email, all the field values will be decoded. Or maybe I didn’t understand your question?
Thanks.
Hello,
No need to spend time on it, on my new code with new Aspose build it’s fixed, if I find more issues, I will get back to you, anyway, this was my response for reference only:
My app is not about sending any kind of emails at all, so if that’s just because of preventing send errors, seems wise to prevent such encoding at first place, but why? I’m using both Aspose and Mailbee simultaneously, and the emails will eventually load using Mailbee, consider not all users will use Aspose to load back emails.