biztalk cluster sso

MIME/SMIME decoder: Determination of the body part of the message doesn’t work as expected if Body Part Index is set to 0 and the Body Part Content Type is blank

Published on : Oct 3, 2016

Category : BizTalk Server Support

Swarna Prabhu


The MIME/SMIME Decoder in the POP3 adapter for BizTalk Server 2013 R2 with installed CU1, CU2 and/or CU3 doesn’t work as expected.

According to the this document, in case if Body Part Index is set to 0 and the Body Part Content Type is blank, the following algorithm will be used to determine the body part of the message:

• Use the first MIME part with the Content-Description header set to “body”.
• Otherwise use the first MIME part with the Content-Type header set to “text/xml”.
• Otherwise use the first MIME part with the Content-Type header set to “text/plain”.
• Otherwise use the first MIME part with the Content-Type header set to “text/”.
• Otherwise use the first MIME part.

Unfortunately, this doesn’t work as expected.

This doesn’t work as expected.

BizTalk MIME/SMIME decoder

POP3 Adapter

BizTalk MIME/SMIME decoder

A multipart message consists of two parts. The first one is a message with the text/plain content type and the second one with text/html content type. None of the parts is marked as body part by Content-Description header.
According to the POP3 adapter documentation described above, the expected behavior would be to use the first message part with the content type text/plain as body part. Unfortunately, the POP3 adapter uses the second message part with the content type text/html as a body part.

It seems like the POP3 adapter always assumes that the last part of the multipart message is the body part, independent of Content-Type header of the particular message parts.

The behavior was observed on BizTalk Server 2013 in the production environment (standard edition) and in the development environment (developer edition). We also tested with installed CU1, CU2 and CU3 for BTS2013 R2, unfortunately, without success. We can confirm, that the MIME/SMIME decoder BizTalk pipeline component provides the same behavior if we use this pipeline component in a custom receive pipeline with the settings described above (Body Part Content Type property is empty and Body Part Index is set to 0).


It is observed that the MIME decoder component is a seperate dll itself that biztalk uses. So we wanted to test if that dll is working fine in .net Created .net code. Downloaded BTSMIMECOMPSLib.dll
using .net code with the above dll  to check if the issue is happening using .net. Did not get much help with this code as I was unable to print : _comObject

The attempt to use MIME dll in code: We get output as “System.__ComObject” when trying to print the MIME message.

Tried a work around by : Downloaded Microsoft.VisualBasic.dll, Added reference and used the following code:
In the below code, this time getting output as :  Contents of WriteText.txt = IMIMEDecoderProperties
Yet to find a way to print the MIME message as output.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;

namespace ClassLibrary1
    public class Class1
        static void Main(string[] args)
            string text = System.IO.File.ReadAllText(@"C:\Users\BizTalkAdmin\Desktop\Edin.out");
           MIMECOMPSLib.BTSMIMEDecoder Decode = new MIMECOMPSLib.BTSMIMEDecoder();
           Decode = new MIMECOMPSLib.BTSMIMEDecoder(text);
      //    string output = Decode.ToString();
    //      System.Console.WriteLine("Contents of WriteText.txt = {0}", output.ToString());
          //string output = Microsoft.VisualBasic.Information.TypeName(Decode);
           System.Console.WriteLine("Contents of WriteText.txt = {0}", Microsoft.VisualBasic.Information.TypeName(Decode));

If you specifiy Body Part Content Type = text/plain and Body Part Index = 0, it picks up the part correctly.
However, without specifying Body Part Content Type, it always picks up second part.
In my scenario the message, second part is text/html.
Tried to set it to text/plain – and simplified the message content to a simple string “abcd”.
Did not change the behaviour.

This feature seemed to have worked perfectly with BTS 2006R2. However, this issue seems to be reported at BTS 2013R2.

<This article is incomplete. To be updated based on the findings by Microsoft PG on this issue>