Question

我在MFC应用程序中使用 MAPISendMail（），并且遇到一个问题，即webmail客户端有时会收到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兼容的客户端。

Answer 1

我遇到了类似的问题。

我发现KB article在“一次性寻址”部分中有一些有趣的信息，说当地址以[SMTP：SMTP地址]格式提供时 - 电子邮件始终以富文本格式发送格式。

对我来说，修复不是设置MapiRecipDesc对象的“Address”属性。相反，我把地址放在Name属性中。然后打开对话框首先不解析地址，但它在发送之前解析它，然后它不会在RTF中发送！

我甚至使用收件人的姓名和地址：

MapiRecipDesc.Name = "Firstname Lastname <mail@address.com>";

Answer 2

我也是将所有附件作为jclMapi.JclEmail的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。

我真正想要报告的是我使用的是在Windows 7中运行良好的OLE例程，并且在Windows 8中停止工作。因此，我开始查看MAPI解决方案，但发现Winmail.dat文件存在此问题连接。我找不到任何提及此问题的OLE（使用Outlook）在Windows 8中无法正常工作。

（这两种：

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

不再在Windows 8中工作，但在Windows 7中继续正常工作。）

感谢您的解决方案。以为您可能想知道如何将它应用于jclMapi代码以及Win8中OLE的这个问题。

Answer 3

对Outlook的行为感到好奇，收件人的域名到底有多长！如果电子邮件地址域是12个字符或更多（我不知道限制是什么），那么我们将面临有问题的TNEF编码。
所以：a@hutsfluts.nl出错了。而abacadabraandmore@hf.nl将导致纯文本编码。我想这不是设计......

上述解决方案：将接收的电子邮件地址放在MapiRecipDesc的lpszName中，让lpszAddress指向一个空字符串（NOT null！）解决问题。不要问我为什么，因为我不知道为什么这会影响编码。

使用Outlook的MAPISendMail有时会导致winmail.dat

3 个答案: