Folder Container class mismatch

Aspose.Email Product Family
1

When Message class of the item and container class of the folder does not match , it throws error while in earlier version it was allowed.

2

Hello @ritikruhela26,

Could you please let us know which Aspose.Email version you are using and provide a small code sample that reproduces the issue?

For some scenarios, this behavior is intentional and was introduced to align with Outlook behavior. However, we’d like to verify whether your case falls into that category or if there is a regression.

3

Aspose.Email version 26.5.0

             string msgClass = msgInfo.MessageClass ?? "";
         /////////////

         Console.WriteLine(
 $"{soucrce_folder.DisplayName} | " +
 $"{soucrce_folder.ContainerClass} | " +
 $"{msgInfo.MessageClass}");

         ///////////////////////

         if (msgClass.StartsWith("IPM.Configuration",
             StringComparison.OrdinalIgnoreCase))
         {
             continue;
         }

         if (msgClass.StartsWith("IPM.Note",
             StringComparison.OrdinalIgnoreCase))
         {
             if (m_senderName_List.Contains(msg.SenderName))
             {
                 //dest_Folder.AddMapiMessageItem(msg);
                 try
                 {
                     dest_Folder.AddMapiMessageItem(msg);
                 }
                 catch (Exception ex)
                 {
                     Console.WriteLine(
                         "FAILED\n" +
                         $"Folder      : {soucrce_folder.DisplayName}\n" +
                         $"Container   : {soucrce_folder.ContainerClass}\n" +
                         $"MsgClass    : {msgClass}\n" +
                         $"Subject     : {msgInfo.Subject}\n" +
                         $"Error       : {ex.Message}\n");
                 }
             }
             continue;
         }

         /////////
         
         if (msgClass.StartsWith("IPM.MessageManager",
 StringComparison.OrdinalIgnoreCase))
         {
             continue;
         }
         
         if (msgClass.StartsWith("REPORT.IPM.Note.NDR",
 StringComparison.OrdinalIgnoreCase))
         {
             continue;
         }

         if (msgClass.StartsWith("IPM.Outlook.Recall",
StringComparison.OrdinalIgnoreCase))
         {
             continue;
         }

         /////////
         else
         {
             //dest_Folder.AddMapiMessageItem(msg);
             try
             {
                 dest_Folder.AddMapiMessageItem(msg);
             }
             catch (Exception ex)
             {
                 Console.WriteLine(
                     "FAILED\n" +
                     $"Folder      : {soucrce_folder.DisplayName}\n" +
                     $"Container   : {soucrce_folder.ContainerClass}\n" +
                     $"MsgClass    : {msgClass}\n" +
                     $"Subject     : {msgInfo.Subject}\n" +
                     $"Error       : {ex.Message}\n");
             }
         }

i had to add these conditions to avoid the mismatching Container classes , but these messges are supposed to be in the folder.
that error mostly accrued in else section

4

Thank you for the additional details and for sharing the code snippet.

We will update you as soon as we have reproduced the scenario and have more information regarding whether this is expected behavior or a potential regression.

5

Hi,
Any update ?

6

Hello @ritikruhela26 ,

We reproduced your scenario. This is intentional validation modeled on Outlook/MAPI folder typing (PR_CONTAINER_CLASS).

FolderInfo.AddMapiMessageItem validates the item’s MessageClass against the destination folder’s ContainerClass.
A folder whose container class is IPF.Note (a mail folder) only accepts mail-type message classes, so adding an item with a different class throws.
If the folder’s container class is empty, any known class is accepted; if it has a concrete container class, the item’s class must match that container.

However, you are right, the allowed-class lists are currently too narrow.
Classes such as REPORT.IPM.Note.NDR, IPM.Outlook.Recall, IPM.MessageManager, etc. legitimately live in a normal mail (IPF.Note) folder in real Outlook, yet they are rejected.
We have logged this and plan to broaden the allowed-class lists in a future release so that messages which genuinely belong in a folder are accepted.

Recommended workaround in the meantime

Instead of skipping those message classes (which silently drops items that should be copied), use FolderInfo.AddMessage(MapiMessage) instead of AddMapiMessageItem.
AddMessage does not perform the container/class check, and AddMapiMessageItem itself ends up calling AddMessage, so it is the safe underlying primitive and still produces a valid PST:

// was:  dest_Folder.AddMapiMessageItem(msg);   // enforces container/class match
dest_Folder.AddMessage(msg);      // no match check, keeps all items

This lets you remove the IPM.Configuration / REPORT.IPM.Note.NDR / IPM.Outlook.Recall / IPM.MessageManager guard conditions you had to add, and all messages will be copied.

If you specifically want Outlook-style typing enforced, you can keep AddMapiMessageItem and ensure each destination folder’s ContainerClass matches the items you place in it.

Thank you.