3

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.

snowdude
  • 3,764
  • 1
  • 16
  • 26
namezero
  • 1,951
  • 3
  • 19
  • 35

3 Answers3

4

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 <mail@address.com>";
jtmnt
  • 716
  • 7
  • 12
  • Thank you for your answer. I'll try this at work tomorrow and see what happens. – namezero Oct 04 '12 at 15:57
  • Yes, this did indeed work! Although Outlook messes up with only LastName or Firstname. The workaround is to use "Firstname Lastname" and the leave the address field empty. Have you tried to see if this works with other MAPI clients, too? – namezero Oct 05 '12 at 18:19
  • I have tested on old XP machine with Thunderbird as default mail client and it works there. I don't really know about other mail clients. I guess since mail client must recognize whatever you type into the address field manually, they should be able to resolve the address from name. – jtmnt Oct 05 '12 at 20:01
  • Thanks for your reply. I just wanted to make sure other clients can deal with this too, but like you said, they should be able to deduce it just like Outlook. Thanks again for your help! – namezero Oct 06 '12 at 01:14
  • This also fixed our issue with outlook.com receiving our messages with questionmarks before each character (unicode problem?). Thus far the only client that had this problem. Still I'd like to know why MS implemented it this way. – Tupel Oct 07 '15 at 14:28
1

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.

Chuck Belanger
  • 9
  • 2
1

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: a@hutsfluts.nl goes wrong. While abacadabraandmore@hf.nl 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.

JanO
  • 51
  • 4
  • Interesting observation about the domain name length. I'm not aware of any limiting factor that would be at 12 odd characters, but I'm fairly certain the limit isn't arbitrary. – namezero Jun 19 '15 at 20:39