MAPISendMail with Outlook sometimes results in winmail.dat

Question

I am using MAPISendMail() in an MFC application, and am having a problem that webmail clients sometimes receive a winmail.dat attachment, instead of the "real" attachments.

I have researched a lot, and have found that others are experiencing this problem too, but have not found a solution.

I believe that the problem may be in my MapiFileDesc structure, in which I leave the lpFileType member pointing to NULL, in order to have the mail program (In my case Outlook 2010) determine the file type automatically. lpFiletype is a MapiFileTagExt structure, and the documentation says this: A value of NULL indicates an unknown file type or a file type determined by the operating system.

So I believe this should work for common types, such as JPEG or GIF and such.

I read that the winmail.dat is caused by Outlook sending the mail encoded with the ms-tnef encoding, which is proprietary to Microsoft. However, when sending the email, Outlook shows "HTML" as highlighted, not RTF.

Has anyone encountered this problem and properly solved it?

Sending via SMTP and such is not an option, because the user should have a copy of the message in their Sent Items folder. Using the Outlook object model is not an option, because that would require the user has Outlook installed, and not any MAPI compatible client.

Answer 1

I was having similar issue.

I found a KB article that has interesting information in "One-Off Addressing" section, saying that when address is provided in the format [SMTP:SMTP Address] - then e-mail is always sent in rich text format.

For me the fix was not to set "Address" property of MapiRecipDesc object at all. Instead I put the address in Name property. The opening dialog then does not resolve the address at first, but it resolves it right before sending and then it is not sent in RTF!

I even got it working with recipient's name together with address:

MapiRecipDesc.Name = "Firstname Lastname <[email protected]>";

Answer 2

Curious in Outlooks behavior is it does matter what length the domain name of the recipient has! If the e-mail address domain is 12 characters or more (I don’t know what the limit exactly is), then we face the problematic TNEF coding.
So: [email protected] goes wrong. While [email protected] will result in plain text encoding. I guess this is not by design….

The solution mentioned above: Put the recepient e-mail address in MapiRecipDesc’s lpszName and let the lpszAddress point to an empty string (NOT null!) solves the problem. Don’t ask me why, for I have no clue why this would influence the encoding.

Answer 3

I, too, was getting all attachments as WinMail.Dat files for the jclMapi.JclEmail, InternalSendOrSave routine, which is called by jclEmail.Send.

What I did was essentially follow jtmnt's answer and changed:

 RealAddresses[I] := FAddress; //do not add the Recipients.AddressesType +     AddressTypeDelimiter

and I changed:

lpszName := PAnsiChar('"' + AnsiString(RealNames[I])+'" <' +
            AnsiString(RealAddresses[I]) + '>');
lpszAddress := '';

This worked so that I no longer was sending WinMail.dat files as attachments, instead the intended PDFs and MP3s were being sent.

What I really want to report is that I was using an OLE routine that was working fine in Windows 7 and stopped working in Windows 8. Thus, I started looking at the MAPI solutions but found this problem with Winmail.dat files being attached. I could not find any mention of this issue with OLE (with Outlook) not working properly in Windows 8.

(Both:

OutlookApp := GetActiveOleObject('Outlook.Application') and  
OutlookApp := CreateOleObject('Outlook.Application') 

were no longer working in Windows 8, but continued to work fine in Windows 7.)

Thanks for the solution. Thought you might want to know how to apply it to the jclMapi code and this issue with OLE in Win8.