MAPISendMail с Outlook иногда приводит к winmail.dat

Question

Я использую MAPISendMail() в приложении MFC, и у меня возникает проблема, связанная с тем, что клиенты веб-почты иногда получают вложение 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

У меня была похожая проблема.

В разделе "Одноразовая адресация" я нашел интересную информацию, в которой говорится, что если адрес указан в формате [SMTP:SMTP Address], то электронная почта всегда отправляется в формате расширенного текста.

Для меня исправление не состояло в том, чтобы вообще установить свойство "Адрес" объекта MapiRecipDesc. Вместо этого я поставил адрес в свойстве Name. Диалоговое окно открытия сначала не разрешает адрес, но разрешает его непосредственно перед отправкой, а затем не отправляет в RTF!

Я даже получил это работает с именем получателя вместе с адресом:

MapiRecipDesc.Name = "Firstname Lastname <[e-mail]>";

Answer 2

Я тоже получал все вложения в виде файлов WinMail.Dat для подпрограммы jclMapi.JclEmail, InternalSendOrSave, которая вызывается 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 и решить эту проблему с OLE в Win8.

Answer 3

Любопытно в поведении Outlooks, имеет ли значение длина доменного имени получателя! Если домен адреса электронной почты составляет 12 символов или более (я не знаю, какой именно предел), то мы сталкиваемся с проблемным кодированием TNEF.
Итак: [e-mail] идет не так. В то время как [e-mail] приведет к кодированию простого текста. Я думаю, что это не по замыслу...

Решение, упомянутое выше: поместите адрес получателя электронной почты в lpszName MapiRecipDesc, и пусть lpszAddress указывает на пустую строку (НЕ null!), Чтобы решить проблему. Не спрашивайте меня почему, потому что я понятия не имею, почему это повлияет на кодировку.