mfc - MAPISendMail con Outlook a veces da como resultado winmail.dat

Question

Estoy usando MAPISendMail () en una aplicación MFC, y estoy teniendo un problema con los clientes de webmail que a veces reciben un archivo adjunto winmail.dat, en lugar de los archivos adjuntos "reales".

He investigado mucho y he descubierto que otros también están experimentando este problema, pero no han encontrado una solución.

Creo que el problema puede estar en mi estructura MapiFileDesc , en la que dejo al miembro lpFileType apuntando a NULL, para que el programa de correo (en mi caso, Outlook 2010) determine el tipo de archivo automáticamente. lpFiletype es una estructura MapiFileTagExt , y la documentación dice esto: Un valor de NULL indica un tipo de archivo desconocido o un tipo de archivo determinado por el sistema operativo.

Así que creo que esto debería funcionar para tipos comunes, como JPEG o GIF, etc.

Leí que winmail.dat es causado por Outlook que envía el correo codificado con la codificación ms-tnef , que es propiedad de Microsoft. Sin embargo, al enviar el correo electrónico, Outlook muestra "HTML" como resaltado, no como RTF.

¿Alguien ha encontrado este problema y lo ha resuelto correctamente?

Enviar a través de SMTP y tal no es una opción, porque el usuario debe tener una copia del mensaje en su carpeta Elementos enviados. Usar el modelo de objetos de Outlook no es una opción, porque eso requeriría que el usuario tenga Outlook instalado y no un cliente compatible con MAPI.

Answer 1

Estaba teniendo un problema similar.

Encontré un artículo de KB que tiene información interesante en la sección "Dirección única", que dice que cuando la dirección se proporciona en el formato [SMTP: dirección SMTP], el correo electrónico siempre se envía en formato de texto enriquecido.

Para mí, la solución no era establecer la propiedad "Dirección" del objeto MapiRecipDesc ​​en absoluto. En cambio, pongo la dirección en la propiedad Nombre. ¡El diálogo de apertura no resuelve la dirección al principio, pero la resuelve justo antes de enviarla y luego no se envía en RTF!

Incluso lo tengo trabajando con el nombre del destinatario junto con la dirección:

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

Answer 2

Yo también recibía todos los archivos adjuntos como archivos WinMail.Dat para la rutina jclMapi.JclEmail, InternalSendOrSave, que es invocada por jclEmail.Send.

Lo que hice fue esencialmente seguir la respuesta de jtmnt y cambiar:

 RealAddresses[I] := FAddress; //do not add the Recipients.AddressesType +     AddressTypeDelimiter

y yo cambié:

lpszName := PAnsiChar(''"'' + AnsiString(RealNames[I])+''" <'' +
            AnsiString(RealAddresses[I]) + ''>'');
lpszAddress := '''';

Esto funcionó para que ya no enviara archivos WinMail.dat como archivos adjuntos, sino que se enviaban los PDF y MP3 previstos.

Lo que realmente deseo informar es que estaba usando una rutina OLE que funcionaba bien en Windows 7 y dejé de trabajar en Windows 8. Así que comencé a buscar en las soluciones MAPI pero encontré este problema con archivos Winmail.dat adjuntos. No pude encontrar ninguna mención de este problema con OLE (con Outlook) que no funciona correctamente en Windows 8.

(Ambos:

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

ya no funcionaba en Windows 8, pero continuó funcionando bien en Windows 7.)

Gracias por la solución. Pensé que podría querer saber cómo aplicarlo al código jclMapi y este problema con OLE en Win8.

Answer 3

¡Curioso en el comportamiento de Outlook es que importa la longitud que tenga el nombre de dominio del destinatario! Si el dominio de la dirección de correo electrónico tiene 12 caracteres o más (no sé exactamente cuál es el límite), entonces enfrentamos la problemática codificación TNEF.
Entonces: [email protected] sale mal. Mientras que [email protected] dará como resultado la codificación de texto sin formato. Supongo que esto no es por diseño ...

La solución mencionada anteriormente: coloque la dirección de correo electrónico del destinatario en lpszName de MapiRecipDesc ​​y deje que lpszAddress señale una cadena vacía (¡NO nulo!) Resuelve el problema. No me preguntes por qué, porque no tengo idea de por qué esto influiría en la codificación.