x-header insertion issue

[Microsoft]

Hi Ken,

I tried to implement the following code in the ThisAddIn_Startup method on
application startup. The code seems to be working fine and no exception is
thrown on the run time. However, when I go back into the inbox and right
click on option, I couldn't find the 'x-testheader' in the header section. I
have tried out all the possible solutions that I can think of but still no
luck to make it work. Can you please give me some direction on what may went
wrong with the following code? thanks in advance.

foreach (Outlook.MAPIFolder folder in this.Application.Session.Folders)

{

Outlook.MAPIFolder inbox = folder.Folders["Inbox"];

foreach (object o in inbox.Items)

{

Outlook.MailItem mailItem = o as Outlook.MailItem;

if (mailItem != null)

{

// Adding x-header

string xHeaderTag =
"http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/x-testheader";

mailItem.PropertyAccessor.SetProperty(xHeaderTag,
mailItem.EntryID.ToString()); // set entry id value

mailItem.Save();



}

}

}



Cheers,

Kyle

 

[Ken Slovak - [MVP - Outlook]]

An x-header is created from that MAPI named property only when the item is
sent out. The x-header creation is done after the item leaves Outlook and
goes through the message transport.

So you will never see that x-header in a saved item or even your copy of the
sent item in Sent Items. It will be there only in the received email, and
only then if the email was sent to a recipient outside of an Exchange
organization.

If an email is sent internally within an Exchange organization no x-header
is created because the PR_TRANSPORT_MESSAGE_HEADERS property is never
created. It's also never created on saved items or your copy of a sent item.

 

[Mark B]

Thanks Ken.

Kyle and I want to store a bit of information in the original email so that
when someone replies to it we can programmatically read the information from
the original email now stored in the reply email and take a certain action.

We had thought that X-Headers be able to be used to carry over this
information but as you described below that isn't appropriate.

The next thought I had was to append a bit of text to the body of the
original email so that's carried over to the reply email's body but the
danger there is that the user may inadvertently delete it when composing the
reply.

The next thought was to follow the idea on Sue Mosher's posting thread at
http://www.outlookcode.com/threads.aspx?forumid=5&messageid=24242, in
particular:

"28-Sep-2007 06:31
Very cool indeed! Interesting idea using <input type="hidden">. Have you
seen any problem getting Outlook 2007 to include that tag in the reply,
given that it's one of the ignored elements per
http://msdn2.microsoft.com/en-us/library/aa338201.aspx ? "

But instead of <input type="hidden"> use an HTML property such as Class to
store the bit of information since we are using OL2007 and according to the
post <input type="hidden"> is ignored.

However the questions now remain:

a) What if the incoming email is simply a plain-text email? Can we add a
"Class" HTML attribute for our purposes only, even though it is not an HTML
or rich-text email?

b) What if the reply email being composed is set to plain text or Rich-Text?
Will there be any way of intercepting Outlook's conversion of a normal HTML
email or a) to plain text so we can get our little piece of information?

Basically all of this is to try and make a fast way of identifying the
original email replied to. I know there has been some posts on using the
conversation index attribute and using advanced search to find the original
using that but I seem to recall that wasn't bullet-proof. I think there were
some situations (such as moving emails to different folders?, Exchange
scenarios?) where it wouldn't work. If I am wrong on that please let me
know.

TIA

 

[Ken Slovak - [MVP - Outlook]]

The HTML idea would only work under controlled conditions. For example, if
someone were to have the setting for read all emails in plain text enabled
that would be one failure point.

I don't really see the problem, unless I'm missing something.

If you add the named MAPI property that becomes an x-header when the email
is sent over the Internet you can check for that. If the email stays within
an Exchange organization and there is no PR_TRANSPORT_MESSAGE_HEADER
property on the item just look for the named MAPI property. One or the other
should be there, so just fork your logic based on checking for both.

 

[Mark B]

So when a user hits the reply button is the MAPI property of the original
email carried over into the new email so that when the user finally hits the
Send button on the new email we can interpret which email they are replying
to?

We only need to ascertain all this within the Outlook client itself on the
desktop -- we don't need it to be included after it leaves via the Send
event.

In summary -- an email comes in, we want to add a property with a specific
identifier and that gets stored within the email. Then later when the user
replies to that stored email, the new email has a new property to store the
original email's property value. Then when they eventually click Send we
perform our action if certain criteria based on the property are met.

 

[Ken Slovak - [MVP - Outlook]]

No, the MAPI named property isn't carried over. But neither would the
Internet headers be carried over, so the design is flawed if it counts on
either property being there in a reply.

In an addin you can handle the Reply() event on a selected item or items,
and by handling the Reply() event on an opened item you are notified about
by the NewInspector() event.

Then you can add whatever MAPI properties you want to those newly opened
Reply items.

ConversationIndex and ConversationTopic are used to link an original item
with a reply or replies. Each item in the conversation has the same
ConversationTopic. ConversationIndex has a new date/time structure appended
to it for each new item in the conversation. So you can look for items with
that ConversationTopic to find the conversation, and evaluate the
ConversationIndex property to see which has a value there that's one entry
shorter than the current item.