4

我在 MFC 应用程序中使用MAPISendMail()，并且遇到一个问题，即 webmail 客户端有时会收到 winmail.dat 附件，而不是“真实”附件。

我研究了很多，发现其他人也遇到了这个问题，但没有找到解决方案。

我相信问题可能出在我的MapiFileDesc结构中，我让 lpFileType 成员指向 NULL，以便让邮件程序（在我的情况下为 Outlook 2010）自动确定文件类型。 lpFiletype是MapiFileTagExt结构，文档中这样说： NULL 值表示未知文件类型或由操作系统确定的文件类型。

所以我相信这应该适用于常见的类型，比如 JPEG 或 GIF 等。

我读到 winmail.dat 是由 Outlook 发送用微软专有的ms-tnef编码编码的邮件引起的。但是，在发送电子邮件时，Outlook 将“HTML”显示为突出显示，而不是 RTF。

有没有人遇到过这个问题并妥善解决？

通过 SMTP 发送等不是一种选择，因为用户应该在他们的已发送邮件文件夹中拥有邮件的副本。使用 Outlook 对象模型不是一种选择，因为这需要用户安装 Outlook，而不是任何 MAPI 兼容的客户端。

4

3 回答 3

5

我有类似的问题。

我在“一次性寻址”部分找到了一篇 KB 文章，其中包含有趣的信息，说当地址以 [SMTP:SMTP 地址] 格式提供时，电子邮件总是以富文本格式发送。

对我来说，解决方法是根本不设置 MapiRecipDesc 对象的“地址”属性。相反，我将地址放在 Name 属性中。然后打开的对话框首先不解析地址，但它在发送之前解析它，然后它不在 RTF 中发送！

我什至将它与收件人的姓名和地址一起使用：

MapiRecipDesc.Name = "Firstname Lastname <mail@address.com>";
于 2012-10-04T13:49:40.880 回答
1

我也将所有附件作为 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 例程在 Windows 7 中运行良好，但在 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 的这个问题。

于 2014-05-27T10:26:08.460 回答
1

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

上面提到的解决方法：将收件人的e-mail地址放在MapiRecipDesc的lpszName中，让lpszAddress指向一个空字符串（NOT null！）解决问题。不要问我为什么，因为我不知道为什么这会影响编码。

于 2015-06-19T12:58:18.137 回答