This project has moved and is read-only. For the latest updates, please go here.


Sender name/email not available in message properties in MAPI when sending an email


Hi Team,

I am developing an application that will tell attachment in email using MAPI.

1) When I send an email, the sender name is coming up in some systems and there is a problem in others. I have implemented the technique that is provided in MFCMAPI ( I have used AdviseSink Notifications ).

2) Where sender name is not coming, its giving "0x8004010f <Bad Ptr>" values. When I can retrive PR_MESSAGE_DELIVERY_TIME, then there shouldn't be any problem to retrieve sender name of an email. And I can't even check for bad pointer.

3) 0x800A001E gives sender name of email when the mailbox is connected to Exchange and 0x800D001E gives sender name of email when the mailbox is connected to Internet email. Kindly name these properties. And, even these properties give bad pointer values when AdviseSink Notifications are implemented.

file attachments

Closed Jun 16, 2014 at 2:40 PM by sgriffin


sgriffin wrote Jun 13, 2014 at 2:38 PM

2 - 8004010f is MAPI_E_NOT_FOUND - whatever property you asked for wasn't there.
3 - You should look at the named prop names.

How is any of this a bug in MFCMAPI?

wrote Jun 14, 2014 at 7:19 AM

talib2608 wrote Jun 14, 2014 at 7:51 AM

This is not a bug in MFCMAPI, but it is a bug in MAPI subsystem. Where to post about the bugs of MAPI subsystem. There are many.

2) There is inconsistency here: We look for property names for most of the properties and named prop name for some. Also, while retrieving property we can't send parameter as PidLidInternetAccountName. We have to send as 0x800A001E or 0x800D001E.

talib2608 wrote Jun 14, 2014 at 9:14 AM

If MAPI_E_NOT_FOUND is returned when the property is not available would be good. "0x8004010f <Bad Ptr>" as a returned value would confuse some developers

sgriffin wrote Jun 16, 2014 at 2:40 PM

0x8004010f is the same thing as MAPI_E_NOT_FOUND. It's not a bad pointer. You're not checking the type of the returned property. It was PT_ERROR, which means you should be looking at the .err member and interpreting it as an error code.

There's no inconsistency. You need to read about named properties:

I'm closing this bug. Please don't add further to it. If you want to discuss something, post on the discussions tab.

wrote Jun 16, 2014 at 2:40 PM

wrote Jun 18, 2014 at 10:37 AM

talib2608 wrote Jun 18, 2014 at 10:37 AM

Why don't you just return the macro 'PT_ERROR' when you have defined it? In other cases it returns as 'PT_ERROR' and not "0x8004010f <Bad Ptr>". This was so simple and it is taking you so much time.


wrote Jun 18, 2014 at 10:38 AM

talib2608 wrote Jun 18, 2014 at 10:38 AM


wrote Jun 18, 2014 at 10:40 AM

talib2608 wrote Jun 18, 2014 at 10:40 AM


sgriffin wrote Jun 18, 2014 at 2:26 PM

Your attachments illustrate the difference between regular properties and named properties. In attachmant, where you wrote "no property names", those were named properties (easily identified by the IDs greater than 0x8000). So there is no PR_* macro associated with that value (can't be, since it's not constant), and the Named prop name has the name I looked up with GetNamesFromIDs.

In attachment 2, you highlighted the Named prop name column for properties under 0x8000, which are not named properties. So they wouldn't have names to look up.

You really need to go read the documentation I linked. It explains all this.

As for your comment about PT_ERROR - are you even talking about MFCMAPI? I don't understand the context of the complaint.