MAPISendMail與Outlook有時會導致winmail.dat

我在MFC應用程序中使用MAPISendMail（），並遇到webmail客戶端有時會收到winmail.dat附件而不是「真正的」附件的問題。MAPISendMail與Outlook有時會導致winmail.dat

我研究了很多，發現其他人也遇到這個問題，但還沒有找到解決方案。

我認爲，問題可能出在我MapiFileDesc結構，在我離開lpFileType成員指向NULL，纔能有郵件程序（在我的情況下，Outlook 2010中）自動判斷文件類型。 lpFiletype是MapiFileTagExt結構，並且該文檔這樣說： NULL值表示一個未知文件類型或由操作系統所確定的文件類型。

所以我相信這應該適用於常見的類型，如JPEG或GIF等。

我讀到winmail.dat是由Outlook發送編碼爲Microsoft專有的ms-tnef編碼的郵件引起的。但是，在發送電子郵件時，Outlook將突出顯示「HTML」，而不是RTF。

有沒有人遇到這個問題，並妥善解決它？

通過SMTP發送信息並不是一種選擇，因爲用戶應該在其「已發送郵件」文件夾中有郵件副本。使用Outlook對象模型不是一種選擇，因爲這需要用戶安裝Outlook，而不是任何MAPI兼容客戶端。

來源

2012-10-02 namezero

我有類似的問題。

我發現了一個KB article，它在「一次性尋址」部分有一些有趣的信息，說當以[SMTP：SMTP地址]格式提供地址時，電子郵件總是以富文本格式發送。

對我來說，解決的辦法並不是設置MapiRecipDesc對象的「Address」屬性。相反，我把地址放在Name屬性中。然後打開的對話框首先不解析地址，但它在發送之前就解決了，然後它不會以RTF發送！

我甚至得到了它與收件人的名稱正在與地址一起：

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

來源

2012-10-04 13:49:40 jtmnt

謝謝你的回答。我明天將在工作中嘗試這個，看看會發生什麼。 – namezero

是的，這確實有效！儘管Outlook只使用LastName或Firstname來彌補。解決方法是使用「名字姓氏」<[email protected]>並將地址字段留空。你有沒有試圖看看它是否也適用於其他MAPI客戶端？ – namezero

我已經使用Thunderbird作爲默認郵件客戶端在老XP機器上測試過，並且它在那裏工作。我真的不知道其他郵件客戶端。我想因爲郵件客戶端必須識別你手動輸入到地址域中的任何東西，他們應該能夠從名稱解析地址。 – jtmnt

我也漸漸的所有附件，WINMAIL.DAT文件的jclMapi.JclEmail，InternalSendOrSave程序，這是由jclEmail稱爲。發送。

我所做的基本上是遵循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中正常工作且在Windows 8中停止工作的OLE例程。因此，我開始查看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-27 10:26:08

好奇在Outlook的行爲是收件人的域名的長度有多重要！如果電子郵件地址域是12個字符或更多（我不知道限制的確切含義），那麼我們將面臨有問題的TNEF編碼。
因此：[email protected]出錯了。而[email protected]nl將導致純文本編碼。我想這不是由設計...。

上面提到的解決方案：將接收的電子郵件地址放在MapiRecipDesc的lpszName中，並讓lpszAddress指向一個空字符串（NOT NULL！）以解決問題。不要問我爲什麼，因爲我不知道爲什麼這會影響編碼。

來源

2015-06-19 12:58:18 JanO

關於域名長度的有趣觀察。我不知道任何限制因素可能是12個字符，但我相當肯定這個限制並不是任意的。 – namezero

MAPISendMail與Outlook有時會導致winmail.dat

回答

相關問題