How to prevent winmail.dat from being sent with message?

  • Thread starter Thread starter Mark Beiley
  • Start date Start date
M

Mark Beiley

I'm using MAPI to send an email with my Outlook add-in. Sometimes the
emails are sent with a winmail.dat attachment when sending through an
Exchange server. I'm trying to figure out how to prevent this from within
my add-in? I've read this:

http://support.microsoft.com/kb/138053

but in my case I'm adding the recipients dynamically, and they aren't in any
address book. I also don't have control over how they've configured their
Internet Mail Connector (IMC).

I'm wondering if any of these will help me?:

PR_SEND_INTERNET_ENCODING
PR_SEND_RICH_INFO

Any tips would be greatly appreciated.

Thanks,
Mark
http://www.email-announcer.com
 
Most likely cause is a user property added to the message.
Add the following named property (known as UseTnef) and set it to false:

{00062008-0000-0000-C000-000000000046}, 0x8582, PT_BOOLEAN

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
 
Hi Sue,

I believe I'm already using the "One-Off Addressing" format they suggested.

I'm setting the recipient properties like this:

PR_EMAIL_ADDRESS : (e-mail address removed)
PR_DISPLAY_NAME : (e-mail address removed)
PR_RECIPIENT_TYPE : MAPI_TO
PR_ADDRTYPE : SMTP

Does that seem right to you, for the "SMTP address" format? I believe that
the other format of "[SMTP:SMTP address]" would be something like this:

PR_EMAIL_ADDRESS : [SMTP:[email protected]]

Thanks,
Mark
http://www.email-announcer.com


Did you try the different address format suggested?
 
I'm using MAPI to send an email with my Outlook add-in. Sometimes the
emails are sent with a winmail.dat attachment when sending through an
Exchange server. I'm trying to figure out how to prevent this from within
my add-in? I've read this:

http://support.microsoft.com/kb/138053

but in my case I'm adding the recipients dynamically, and they aren't in any
address book. I also don't have control over how they've configured their
Internet Mail Connector (IMC).

I'm wondering if any of these will help me?:

PR_SEND_INTERNET_ENCODING
PR_SEND_RICH_INFO
Click to expand...
set PR_SEND_RICH_INFO = FALSE while adding recipients.
Even if you created OneOff entryid for recipient with RICH_INFO flag
PR_SEND_RICH_INFO property will override this setting.

Regards
Henry
 
And UseTnef ({00062008-0000-0000-C000-000000000046}, 0x8582, PT_BOOLEAN)
will override them both.


Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
 
Thanks Henry/Dmitry. I tried setting UseTnef to false, but it didn't fix
the problem (winmail.dat was still sent). I didn't set UseTnef as a "named
property", but instead used the property tag (PT_BOOLEAN and 0x80DD), as
found through OutlookSpy. Afterwards, I did verify that the property was
set okay, so I think I accomplished getting the right propert set. Is this
okay? Here is my code:

int nFields;
SPropValue *pNewProps = NULL;
LPSPropValue pProp = NULL;

nFields = 1;
MAPIAllocateBuffer((nFields * sizeof(SPropValue)), (LPVOID*)&pNewProps));
ZeroMemory(pNewProps, nFields * sizeof(SPropValue));

pProp = &pNewProps[0];
pProp->ulPropTag = PROP_TAG( PT_BOOLEAN, 0x80DD ); // UseTNEF
pProp->Value.b = 0;

((LPMAPIPROP)(IUnknown*)pMAPIMessage)->SetProps(nFields, pNewProps, NULL);

My actual code had error checking, but I took it out for easier reading
here. The code did execute without errors.

Next I'll try setting both UseTNEF to false, and also on the recipient
setting PR_SEND_RICH_INFO = FALSE to see if that helps. I'll post the
results here...

Thanks,
Mark
http://www.email-announcer.com
 
You should never hardcode the values of the named prop tags - use
GetIDsFromNames.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

Mark Beiley said:
Thanks Henry/Dmitry. I tried setting UseTnef to false, but it didn't fix
the problem (winmail.dat was still sent). I didn't set UseTnef as a
"named property", but instead used the property tag (PT_BOOLEAN and
0x80DD), as found through OutlookSpy. Afterwards, I did verify that the
property was set okay, so I think I accomplished getting the right propert
set. Is this okay? Here is my code:

int nFields;
SPropValue *pNewProps = NULL;
LPSPropValue pProp = NULL;

nFields = 1;
MAPIAllocateBuffer((nFields * sizeof(SPropValue)), (LPVOID*)&pNewProps));
ZeroMemory(pNewProps, nFields * sizeof(SPropValue));

pProp = &pNewProps[0];
pProp->ulPropTag = PROP_TAG( PT_BOOLEAN, 0x80DD ); // UseTNEF
pProp->Value.b = 0;

((LPMAPIPROP)(IUnknown*)pMAPIMessage)->SetProps(nFields, pNewProps, NULL);

My actual code had error checking, but I took it out for easier reading
here. The code did execute without errors.

Next I'll try setting both UseTNEF to false, and also on the recipient
setting PR_SEND_RICH_INFO = FALSE to see if that helps. I'll post the
results here...

Thanks,
Mark
http://www.email-announcer.com



Dmitry Streblechenko said:
And UseTnef ({00062008-0000-0000-C000-000000000046}, 0x8582, PT_BOOLEAN)
will override them both.


Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
Click to expand...
Click to expand...
 
FYI... This fixed my problem, thank you. I ended up setting both UseTNEF
to false, and also on the recipient setting PR_SEND_RICH_INFO to false also.
No more winmail.dat...

Thanks,
Mark
http://www.email-announcer.com



Mark Beiley said:
Thanks Henry/Dmitry. I tried setting UseTnef to false, but it didn't fix
the problem (winmail.dat was still sent). I didn't set UseTnef as a
"named property", but instead used the property tag (PT_BOOLEAN and
0x80DD), as found through OutlookSpy. Afterwards, I did verify that the
property was set okay, so I think I accomplished getting the right propert
set. Is this okay? Here is my code:

int nFields;
SPropValue *pNewProps = NULL;
LPSPropValue pProp = NULL;

nFields = 1;
MAPIAllocateBuffer((nFields * sizeof(SPropValue)), (LPVOID*)&pNewProps));
ZeroMemory(pNewProps, nFields * sizeof(SPropValue));

pProp = &pNewProps[0];
pProp->ulPropTag = PROP_TAG( PT_BOOLEAN, 0x80DD ); // UseTNEF
pProp->Value.b = 0;

((LPMAPIPROP)(IUnknown*)pMAPIMessage)->SetProps(nFields, pNewProps, NULL);

My actual code had error checking, but I took it out for easier reading
here. The code did execute without errors.

Next I'll try setting both UseTNEF to false, and also on the recipient
setting PR_SEND_RICH_INFO = FALSE to see if that helps. I'll post the
results here...

Thanks,
Mark
http://www.email-announcer.com



Dmitry Streblechenko said:
And UseTnef ({00062008-0000-0000-C000-000000000046}, 0x8582, PT_BOOLEAN)
will override them both.


Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
Click to expand...
Click to expand...
 
What solution are you talking about? You have to provide details of what you
want, what version of Outlook you're using and what you're trying to
accomplish if you want answers.
 
Here is my code:

const GUID GUIDUseTnef={0x00062008, 0x0000, 0x0000, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46 };
MAPINAMEID namedProp;
namedProp.lpguid = (LPGUID)&GUIDUseTnef;
namedProp.ulKind = MNID_ID;
namedProp.Kind.lID = 0x8582;

LPMAPINAMEID lpNameID[1]={ &namedProp };
LPSPropTagArray lppPropTags;

if (m_pMessage->GetIDsFromNames(1,lpNameID,FALSE,&lppPropTags) == S_OK)
{
int nFieldType = PT_BOOLEAN;
prop.ulPropTag=(lppPropTags->aulPropTag[0]|nFieldType);
prop.Value.b = FALSE;
m_pMessage->SetProps(1,&prop,NULL);
MAPIFreeBuffer(lppPropTags);
}

Please let me know if something wrong with what I am doing.

Thanks in advance.
 
For Microsoft Exchange 2007

Go to Microsoft Exchange console, expand organisation Configuration, click hub transport select remote domain. Go to the properties of remote domain click on format of original message sent as attachment to journal report.
Within charactor sets
MIME character Set....Select none
Non-MIME character set...select none.

Please reply if your problem solved
 
Hello

I have been having a similar problem with some customers who can get simple mapi working fine from our software, but extended mapi they get the email with the attached winmail.dat.

I am using the Delphi ExtendedMAPI library that Dmitry Streblechenko mentions on his site.

I am also using his Outlook Spy progrma (Fantastic tool btw!)to check my results. both myself and the customer are sendnig using outlook 2007 sp1 through exchange server (mine is 6.5, dont know what the customer has) to outlook express.

On mine the simple mapi has winmail.dat and extended mapi works fine?? very odd.

On the customers the simple mapi works fine, but the extended mapi they get the winmail.dat.




I am doing the following in my code:

In the delphi mapi library PR_EMS_AB_SEND_TNEF 0x8191 and PR_SEND_RICH_TEXT_INFO 0x3A40 exist.

Also PR_EMS_AB_SEND_TNEF shows in Outlook Spy as having GUID {00062008-0000-0000-C000-000000000046}

UseTNEF 0x8582 doesnt exist and when created doesnt show a GUID in Outlook Spy.

If I set PR_EMS_AB_SEND_TNEF then PR_SEND_RICH_TEXT_INFO also gets set automatically.

This does not happen if I use UseTNEF and so has to be set manually.

I saw your comment about not explicitly using the property id and wondering if that is what i am using

PropertyID is type ULONG and is passed the following constant:
PR_EMS_AB_SEND_TNEF = (ULONG($8191) shl 16) or PT_BOOLEAN;

// Initialise and set the details of the property we want to modify
FillChar(NewProperty, SizeOf(TSPropValue), 0);
NewProperty.ulPropTag := PropertyId;
NewProperty.Value.b := SmallInt(Value);

// Update said property
SetPropResult := MapiProp.SetProps(1, @NewProperty, Problems);

This is not likely to work despite showing ok in Outlook Spy as far as exchange is concerned?
 
TNEF is the Rich Text envelope used for transmitting RTF text and that
produces the winmail.dat file. Only Outlook knows how to use winmail.dat,
other software such as Outlook Express will just show the attachment. You
should never send out RTF text unless you know the recipient is using
Outlook or you end up with the winmail.dat attachment that can't be
interpreted.
 
Back
Top