我在MFC应用程序中使用MAPISendMail()，并且遇到一个问题，即Web邮件客户端有时会收到winmail.dat附件，而不是"真实"附件。
我研究了很多，发现其他人也遇到了这个问题，但还没有找到解决方案。
我认为问题可能出现在我的MapiFileDesc结构中，在该结构中，我将lpFileType成员保留为NULL，以便让邮件程序(在我的情况下为Outlook 2010)自动确定文件类型。lpFiletype是一个MapiFileTagExt结构，文档中这样写道：NULL值表示未知的文件类型或由操作系统确定的文件类型
所以我认为这应该适用于常见的类型，比如JPEG或GIF等等。
我读到winmail.dat是由Outlook发送的邮件使用ms-tnef编码引起的，该编码是Microsoft专有的。但是，在发送电子邮件时，Outlook会显示突出显示的"HTML"，而不是RTF。
有人遇到这个问题并妥善解决了吗？
通过SMTP等发送不是一种选择，因为用户应该在其"已发送邮件"文件夹中拥有邮件的副本。使用Outlook对象模型不是一个选项，因为这需要用户安装Outlook，而不是任何MAPI兼容的客户端。
我也遇到了类似的问题。
我在"一次性寻址"部分找到了一篇KB文章，其中有一些有趣的信息，说当地址以[SMTP:SMTP地址]的格式提供时，电子邮件总是以富文本格式发送。
对我来说，修复方法根本没有设置MapiRecipDesc对象的"Address"属性。相反，我将地址放在Name属性中。打开的对话框一开始不会解析地址，但它在发送之前就解析了地址，然后就不会以RTF格式发送了！
我甚至用收件人的名字和地址：
MapiRecipDesc.Name = "Firstname Lastname <mail@address.com>";
I也在获取jclMapi.JclEmail，InternalSendOrSave例程的所有附件作为WinMail.Dat文件，该例程由JclEmail.Send.调用
我所做的基本上是遵循jtmnt的答案并改变：
RealAddresses[I] := FAddress; //do not add the Recipients.AddressesType + AddressTypeDelimiter
我改了：
lpszName := PAnsiChar('"' + AnsiString(RealNames[I])+'" <' +
AnsiString(RealAddresses[I]) + '>');
lpszAddress := '';
这样我就不再将WinMail.dat文件作为附件发送，而是发送预期的PDF和MP3。
我真正想报告的是，我使用的OLE例程在Windows7中运行良好，但在Windows8中停止了工作。因此，我开始研究MAPI解决方案，但在附加Winmail.dat文件时发现了这个问题。我找不到任何关于OLE(Outlook)在Windows8中无法正常工作的问题。
(两者：
OutlookApp := GetActiveOleObject('Outlook.Application') and
OutlookApp := CreateOleObject('Outlook.Application')
不再在Windows 8中工作，但在Windows 7中仍然可以正常工作。)
感谢您的解决方案。我想你可能想知道如何将其应用于jclMapi代码，以及Win8中OLE的这个问题。
Outlooks的奇怪行为是，收件人的域名长度有多长并不重要！如果电子邮件地址域是12个字符或更多(我不知道确切的限制是什么)，那么我们将面临TNEF编码的问题
所以：a@hutsfluts.nl出错了。虽然abacadabraandmore@hf.nl将导致纯文本编码。我想这不是故意的…。
上述解决方案：将接收的电子邮件地址放在MapiRecipDesc的lpszName中，并让lpszAddress指向一个空字符串(NOT null！)来解决问题。不要问我为什么，因为我不知道为什么这会影响编码。