Fixing the Charset on MIME Messages When Using ADODB.Stream.ReadText

Patrick Creehan — Thu, 29 Oct 2009 20:00:00 GMT

We had an issue recently where the customer had written an application to process MIME messages that had body parts encoded with the koi8-r charset…or at least that’s what it said:

------_=_NextPart_001_01C9F067.D9742103
Content-Type: text/plain;
    charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

If you use code similar to the following, the resulting characters returned were not correct.

private string ReadBodyPart()

{

    CDO.IDataSource oIDsrc;

    ADODB.Stream objBpStream = new ADODB.Stream();

    CDO.Message objCDOMsg = new CDO.Message();

    CDO.IBodyPart oIBodyPart;

    objBpStream.Open(vtMissing, 

        ADODB.ConnectModeEnum.adModeUnknown,

        ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified, 

        string.Empty, 

        string.Empty);

    objBpStream.LoadFromFile(EML_FILE_PATH);           

    oIDsrc = (CDO.IDataSource)objCDOMsg;

    oIDsrc.OpenObject(objBpStream, "_Stream");

    objBpStream.Close();

    oIBodyPart = (CDO.IBodyPart)objCDOMsg.TextBodyPart;

    objBpStream = (ADODB.Stream)oIBodyPart.GetDecodedContentStream();

    return objBpStream.ReadText(-1);

}

The problem is that koi8-r is the body name for both “windows-1251” (codepage 1251) and “koi8-r” (codepage 20866). I took a look at what the TextBody and HtmlBody properties were doing because they can return the characters correctly. Turns out, when the message is loaded, we make an API call to GetCharsetInfo and pass in the value defined in the header. This gives us back a structure that contains the uiCodePage used by TextBody and HtmlBody later.

Fortunately, the .net framework provides methods to do this as well. I simply leverage them to correct the charset I’m given.

public static string GetCharSetName(string bodyName)

{

    Encoding encoding = Encoding.GetEncoding(bodyName);

    if (encoding != null)

    {

        int iCP = encoding.WindowsCodePage;

        return Encoding.GetEncoding(iCP).WebName;

    }

    return bodyName;

}

Then I just insert a call to that function above my call to ReadText and we’re good.

private string ReadBodyPart()

{

    CDO.IDataSource oIDsrc;

    ADODB.Stream objBpStream = new ADODB.Stream();

    CDO.Message objCDOMsg = new CDO.Message();

    CDO.IBodyPart oIBodyPart;

    objBpStream.Open(vtMissing, 

        ADODB.ConnectModeEnum.adModeUnknown,

        ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified, 

        string.Empty, 

        string.Empty);

    objBpStream.LoadFromFile(EML_FILE_PATH);           

    oIDsrc = (CDO.IDataSource)objCDOMsg;

    oIDsrc.OpenObject(objBpStream, "_Stream");

    objBpStream.Close();

    oIBodyPart = (CDO.IBodyPart)objCDOMsg.TextBodyPart;

    objBpStream = (ADODB.Stream)oIBodyPart.GetDecodedContentStream();

    objBpStream.Charset = GetCharSetName(objBpStream.Charset);

    return objBpStream.ReadText(-1);

}

Why Pickups are the Best. More Robust, More Reliable, etc.

Patrick Creehan — Fri, 08 Aug 2008 15:58:00 GMT

We get calls about this all the time. You have a CDOSYS application that…what? No, I’m not talking about automobiles, why did you…oh, the title. Well, it’s true. Read on.

The Dreaded Transport Error

The problem we see more than any other is when a customer is trying to send a lot of e-mail using an SMTP API such as CDOEX, CDOSYS, or System.Web.Mail, they will start to get CDO_E_FAILED_TO_CONNECT errors (0x80040213) (-2147220973) which is “The transport could not connect to the server.”

The Resolution

We see it over and over again. This error is because you are sending such a high volume of email over one port, typically the default port (25), that you flood the port with traffic until your app can no longer talk to the server. If your application is sending such a large volume of mail so quickly that it generates this error, it’s time to install a local SMTP service (if one is not already installed) and start sending via port.

Setting the Send and Post Method

Sending or Posting using the Pickup Directory

How To Send HTML Formatted Mail Using CDO for Windows 2000 and the Local Pickup Directory

You can employ the same strategy in the article above to your System.Web.Mail emails:

How to send e-mail messages by using CDOSYS and the local SMTP pickup directory with VB.NET

How to use the Cdosys.dll library to send an e-mail message with attachments by using Visual C# (this also shows how to send using pickup)

Benefits of using the pickup folder

Performance

It is very easy to generate a text file on the file system. When your CDOSYS configuration is set to send via pickup, all CDOSYS is doing in your application is creating an .eml file in a specific directory. You’ve just removed the entire networking stack from your application. You can whip through email generation in a fraction of the time it takes to communicate over a TCP port.

Reliability

When you let the SMTP service do the sending of your emails, you are working on a far more stable architecture than for you to handle error conditions yourself in your application. IIS’s SMTP service makes it easy when there is a problem as well by just moving your .eml file to the BadMail folder. If the service runs into a problem where transport is too busy to take new connections, it just tries again later. Email is asynchronous by nature, so this shouldn’t be a big deal.

Resiliency

The SMTP service will just continually monitor the Pickup folder for any files in it and will try to send them. If there’s a power failure for example, or your machine crashes, when it reboots, the files are still there so the service will once again work on sending them.

When You Shouldn’t Use Pickup

If it is impossible for you to install a local SMTP service for whatever reason, sending via port may be your only option. For example, if you are writing an application to run on a desktop running Windows XP/Vista, it doesn’t make sense to install an SMTP service on a desktop platform. Additionally, if your application only sends an email occasionally, it will probably be fine to send using port instead of pickup – you’ll probably never run into this error. If you application does need to know immediately whether or not the email is going to succeed in each command in the protocol (MAIL FROM, RCPTTO, etc) then you may need to send via port as well. In those cases, if you will be sending a large volume of email very quickly, you should throttle your application to allow some time between each mail so that you don’t clog the pipes and end up with the dreaded transport error. This is, of course, assuming that you can’t install SMTP services locally.

Another reason you may not code your application to use a pickup folder is that you don’t know the environment your application will be deployed on. For example, you’ve written a web application that sends email notifications when some data has changed and you’re going to sell this application for companies to deploy in their own environments. You don’t know, nor can you count on an SMTP service running locally on the box. Your first instinct may be to code your application to send via port. Certainly, they’ll have an SMTP service somewhere in the organization and it’s easy for them to just type in a setting somewhere “mail.company.com” – folks are used to it by now. My plea to you is to account for both possibilities. Provide a mechanism for sending via pickup as well – you won’t regret it.

Wiz/dumb : CDOSYS