Users cannot see [External] tag in OWA and Outlook Conversation View

Microsoft

There are multiple ways to add [External] tag to emails received from outside the organization.

 

  • O365 users can use the Native [External] tag in Office 365.
  • You can apply [External] tag using transport rule in Exchange and Office 365.
  • You can also set up [External] tag using rules in your third-party gateway.

 

Exchange Team has already covered the first two options in their blog Native external sender callouts on email in Outlook. 

 

In this post I just wanted to talk about an intermittent issue where [External] tags behave differently for different emails.

 

For example,

 

  1. You have 2 emails with [External] tag in the subject. When you reply to the first email you see the tag replaced with RE: and when you reply to the second email the tag is appended with RE: [EXTERNAL].

  2. When you enable conversation view in Outlook or OWA you don’t see the [External] tag in the message preview for some emails, while it still shows for some other emails. But when you double click on either of the two emails the tag can be seen in the Subject line.

 

The underlying cause for the issue lies in the MAPI properties of the email and the mechanism used to add the tag.

 

There is one major difference between the Conversation View and Normal View.

In normal view, the message preview displays the value in the MAPI property PR_SUBJECT. However, when we see the email in conversation view the message preview displays another MAPI property “PR_CONVERSATION_TOPIC” and that’s why in most cases you will not see the external tag. You can check these properties using MFC MAPI.

 

In OWA, Conversation View is set by default, and you won’t see External tag in the message preview. You can click on Settings and change the view.

 

surajbudhani_2-1657033837749.png

 

 

surajbudhani_3-1657033837752.png

 

 

A message store provider has the option of assuring that “PR_CONVERSATION_TOPIC” property is always set on incoming or outgoing messages. If these properties are already set, they should not be altered. If not, they can be set to PR_NORMALIZED_SUBJECT. So “PR_CONVERSATION_TOPIC” gets the value from “PR_NORMALIZED_SUBJECT”

 

Now let’s find why is the value in “PR_NORMALIZED_SUBJECT” and PR_SUBJECT different? 

 

First Scenario:

 

If the PR_SUBJECT_PREFIX is present and is an initial substring of PR_SUBJECT. In that case PR_NORMALIZED_SUBJECT and associated properties are set to the contents of PR_SUBJECT with the prefix removed.

 

For First Scenario it is straight forward, as the PR_SUBJECT_PREFIX property was set explicitly, the string can be of any length and use any alphanumeric characters, but it must match a substring at the beginning of the PR_SUBJECT property. Here “External” will be removed from Subject when setting the value for “PR_NORMALIZED_SUBJECT”

 

PR_SUBJECT_PREFIX is                            External:

PR_SUBJECT is                                          External: This is an Important Email

PR_NORMALIZED_SUBJECT is              This is an Important Email

PR_CONVERSATION_TOPIC is              This is an Important Email

 

If this is the case with an email, it will not display External tag in message preview and when you reply to this email it will change the tag from External: to Re:

 

 

Second Scenario:

 

If the PR_SUBJECT_PREFIX is present, but it is not an initial substring of PR_SUBJECT, PR_SUBJECT_PREFIX is deleted and recalculated from PR_SUBJECT.

 

 

Third Scenario:


If PR_SUBJECT_PREFIX is not present, it is calculated from PR_SUBJECT

 

In Second and Third Scenario, the property PR_SUBJECT_PREFIX is not set or needs to be recalculated. The rule for computing the prefix is that PR_SUBJECT must begin with one, two, or three letters (alphabetic only) followed by a colon and a space. If such a substring is found at the beginning of PR_SUBJECT, it is then added to PR_SUBJECT_PREFIX. Otherwise, PR_SUBJECT_PREFIX property remains unset.

 

By design if store must calculate or recalculate the value of PR_SUBJECT_PREFIX then it will fail to calculate [External] as it is more than 3 alphabets long. This means PR_SUBJECT_PREFIX property will remain unset

 

PR_SUBJECT_PREFIX is                           

PR_SUBJECT is                                          External: This is an Important Email

PR_NORMALIZED_SUBJECT is              External: This is an Important Email

PR_CONVERSATION_TOPIC is              External: This is an Important Email

 

If this is the case with an email, it will display External tag in message preview because it is now the subject itself and when you reply to this email it will change the tag from External: to RE: [EXTERNAL].

 

Now that you understand when and why will you experience this problem you can circle back to tagging rule to fix this. You can check the protocol logs to find why the two emails were processed differently. This can happen either due to conflicting rule or if the tagging rule modifies Thread-Topic and Subject headers differently.

0 Replies