none
Office 365 Exchange breaking change (EWS API) Recipient To missing RRS feed

  • Question

  • Hi,

    Today my Office365 Exchange account got updated (I assume).

    I am running an Azure service for the 911 dispatch center in Canada which relies on the To: address of the email. The Azure service monitors one email account which has numerous alias email addresses associated to it.

    Before today (july 16, 2013) I was able to get the recipient address (alias) from the InternetAddessHeaders collection.

    Today, that collection does not provide the alias to address anymore. This is a serious issue and I need help as soon as possible please.

    Any help or direction to get the alias address again is greatly appreciated.

    Wouter

    Wednesday, July 17, 2013 8:44 PM

Answers

  • I solved the problem. I found that you can get the ExtendedProperties using the load method on the MailItem object in EWS.

    private static String GetToAddress(Item mailItem)
            {
                ExtendedPropertyDefinition PR_TRANSPORT_MESSAGE_HEADERS = 
                    new ExtendedPropertyDefinition(0x007D, MapiPropertyType.String);
    
                PropertySet psPropSet = new PropertySet(BasePropertySet.FirstClassProperties) { 
                    PR_TRANSPORT_MESSAGE_HEADERS, ItemSchema.MimeContent 
                };
    
                mailItem.Load(psPropSet);
    
                Object valHeaders;
    
                if (mailItem.TryGetProperty(PR_TRANSPORT_MESSAGE_HEADERS, out valHeaders))
                {
                    Regex regex = new Regex(@"To:.*<(.+)>");
                    Match match = regex.Match(valHeaders.ToString());
    
                    if (match.Groups.Count == 2)
                        return match.Groups[1].Value;
                    else
                        return "";
                }
                else
                    return "";
                
            }

    • Marked as answer by Wouter vanEck Thursday, July 18, 2013 9:57 AM
    Thursday, July 18, 2013 9:57 AM

All replies

  • >> This is a serious issue and I need help as soon as possible please.

    If its a really serious issue then you should log a case with Office365 support so you can get the fastest possible resolution.

    You really need to provide a code sample of what your doing and which InternetAddressHeader your using ?. Are you specifically requesting those properties. Have you tested your code against an OnPremise Exchange 2013 server.

    Another method of getting the Transport headers is to use the PidTagTransportMessageHeaders http://msdn.microsoft.com/en-us/library/office/cc815628.aspx property. That should contain all the transport headers and you can also view the contents of this property using a Mapi editor like MFCMapi or Outlook spy to confirm what it contains. This property will always be greater then 512 KB so you need to use a GetItem\Load to retrieve it fully.

    Cheers
    Glen

     

    Thursday, July 18, 2013 5:18 AM
  • Hi Glen,

    It is serious to me and although I would like to contact Microsoft directly, I am just a single owner software builder without the means for expensive support contracts or per hour support calls.

    I can't test it against a onpremise Exchange server because I don't have one.

    It is not the code that breaks it is the result of a Office365 Exchange server change which results in EWS losing some info. The "to" email address is visible when you use Outlook and look at the properties of the email.

    Below are two elements where the email address is displayed.

    Received: from mail193-db9 (localhost [127.0.0.1]) by
     mail193-db9-R.bigfish.com (Postfix) with ESMTP id 98E0E3000B3 for
     <elbow.valley@blabla.com>; Wed, 17 Jul 2013 02:28:34 +0000 (UTC)

    To: <elbow.valley@blabla.com>

    My service (code), which has been running for more than a year (same code) uses EWS to get to the recipient which is an alias email address.

    The problem is that the EWS API (v2) is returning the main account email address in the RecipientsTo collection or any other property related to the recipient.

    I was using the following code to get to the email address in the InternetMessageHeaders

      

    private static String GetToAddress(Item mailItem) { String aliasAddress = String.Empty; for (Int16 index = 0; index < mailItem.InternetMessageHeaders.Count; index++) { if (mailItem.InternetMessageHeaders[index].Name.Equals("Received")) { String from = mailItem.InternetMessageHeaders[index].Value; Regex regex = new Regex(@"for.*<(.+)>"); Match match = regex.Match(from); if (match.Groups.Count == 2) { aliasAddress = match.Groups[1].Value; break; } } } return aliasAddress; }

    The code above now is not able to find the address in the headers anymore as there is no address present. None of the message headers are showing an address anymore since the change from July 16th.

    I don't see an option to use the PidTagTransportMessageHeaders as it is not present in EWS.

    Anybody from the EWS team able to sort this out?

    Thursday, July 18, 2013 7:53 AM
  • I solved the problem. I found that you can get the ExtendedProperties using the load method on the MailItem object in EWS.

    private static String GetToAddress(Item mailItem)
            {
                ExtendedPropertyDefinition PR_TRANSPORT_MESSAGE_HEADERS = 
                    new ExtendedPropertyDefinition(0x007D, MapiPropertyType.String);
    
                PropertySet psPropSet = new PropertySet(BasePropertySet.FirstClassProperties) { 
                    PR_TRANSPORT_MESSAGE_HEADERS, ItemSchema.MimeContent 
                };
    
                mailItem.Load(psPropSet);
    
                Object valHeaders;
    
                if (mailItem.TryGetProperty(PR_TRANSPORT_MESSAGE_HEADERS, out valHeaders))
                {
                    Regex regex = new Regex(@"To:.*<(.+)>");
                    Match match = regex.Match(valHeaders.ToString());
    
                    if (match.Groups.Count == 2)
                        return match.Groups[1].Value;
                    else
                        return "";
                }
                else
                    return "";
                
            }

    • Marked as answer by Wouter vanEck Thursday, July 18, 2013 9:57 AM
    Thursday, July 18, 2013 9:57 AM