none
[MS-OXCMAIL] Mapping Internet Email Addresses to Properties RRS feed

  • Question

  • Hi,

    I'm implementing part of the MS-OXCMAIL spec (v20101026), relating to Addresses (Section 2.2.1). The process seems fairly simple, but the it doesn't appear to produce results that are consistent with the example in Section 3.

    Section 3 shows an RFC2822 style message that has a line that looks like:

    To: <user2@example.com>; <user3@example.com>
    

    Then it shows that mapped to a set of properties that looks like:

    PidTagDisplayName  PtypString  Test user 2
    PidTagAddressType  PtypString  EX
    PidTagEmailAddress  PtypString  /O=Example1/OU= Administrative Group/CN=recipients/CN=user2
    PidTagSmtpAddress  PtypString  user2@example.com
    PidTagRecipientType PtypInteger32  1
    PidTagObjectType   PtypInteger32  6
    

    (and similar for the second addressee).

    Since the address is not IMCEA encapsulated, I don't think the process in section 2.2.1 requires lookup of the SMTP address to produce other values. That is, the result of the process in Section 2.2.1.1 is that PidTagDisplayName and PidTagEmailAddress should be "user2@example.com", and the PidTagAddressType should be "SMTP". I also don't see anything in Section 2.2.1 that suggests setting the PidTagSmtpAddress (it is covered in generating an SMTP address in section 2.1, but that doesn't look directly applicable here).

    It looks like the handling of the From is slightly different again, where the PidTagSentRepresentingName appears to be looked up, but the PidTagSentRepresentingEmailAddress and PidTagSentRepresentingAddressType are not looked up.

    Question 1. Have I missed something in the process (per MS-OXCMAIL section 2.2.1) conversion of an RFC2822 format message address to a property set?

    Question 2. If not, is the behaviour in Section 2.2.1 correct, or is Section 3 correct (or are they both wrong)?

    Question 3. If Section 2.2.1 is not correct, can I get a description of how to convert each element of an RFC2822 format message into an Exchange property set?

    Question 4. If Section 3 is not correct, can I get a complete example of an RFC2822 format message and the Exchange property equivalents?

    [I already have an MS-OXCMAIL query open, I'm happy with combining these if it makes it easier.]

    Saturday, December 4, 2010 7:13 AM

Answers

  • Brad, the example in Section 3 is making an assumption that is not documented. Specifically, that there are user objects in the GAL with an SMTP proxy address of "user2@example.com" and "user3@example.com". External users can be added to the GAL as contacts.

     

    Per Section 2.2.1.1:

    *EntryID: If there is an Internet e-mail address part, after the de-encapsulation step, perform a lookup against the address book for an entry any of whose proxy addresses matches this address. If an entry is found, construct an address book entry ID from that entry's DN, as specified in [MS-OXCDATA]. If no entry is found, construct a one-off entry IDEntryID from the display name, address type, and Internet e-mail address property values, according to the one-off entry ID specification in [MS-OXCDATA].

     

    In the example at the start of Section 3, an entry was not found for user1@example.com (and therefore that Internet address is copied to PidTagSentRepresentingEmailAddress). But entries were found for user2@example.com and user3@example.com (and therefore the DN is copied to PidTagEmailAddress, and EX is written to PidTagAddressType).

     

    I have filed a request to have a few changes made to the document to make this clearer.

     

    1.       In section 2.2.1.1, if the SMTP proxy address lookup succeeds, write the DN to *EmailAddress and write “EX” to *AddressType.

    2.       The *Entryid fields need to be added to the first example in Section 3.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Tuesday, December 14, 2010 5:36 PM
    Moderator

All replies

  • Hi Brad,

     

    Thanks again for your questions.

    I'll create a case and one of my coworkers will follow up with you about this post.

    Thanks and regards,

     


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team
    Saturday, December 4, 2010 7:29 AM
  • Brad, I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, December 6, 2010 5:43 PM
    Moderator
  • Brad, the example in Section 3 is making an assumption that is not documented. Specifically, that there are user objects in the GAL with an SMTP proxy address of "user2@example.com" and "user3@example.com". External users can be added to the GAL as contacts.

     

    Per Section 2.2.1.1:

    *EntryID: If there is an Internet e-mail address part, after the de-encapsulation step, perform a lookup against the address book for an entry any of whose proxy addresses matches this address. If an entry is found, construct an address book entry ID from that entry's DN, as specified in [MS-OXCDATA]. If no entry is found, construct a one-off entry IDEntryID from the display name, address type, and Internet e-mail address property values, according to the one-off entry ID specification in [MS-OXCDATA].

     

    In the example at the start of Section 3, an entry was not found for user1@example.com (and therefore that Internet address is copied to PidTagSentRepresentingEmailAddress). But entries were found for user2@example.com and user3@example.com (and therefore the DN is copied to PidTagEmailAddress, and EX is written to PidTagAddressType).

     

    I have filed a request to have a few changes made to the document to make this clearer.

     

    1.       In section 2.2.1.1, if the SMTP proxy address lookup succeeds, write the DN to *EmailAddress and write “EX” to *AddressType.

    2.       The *Entryid fields need to be added to the first example in Section 3.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Tuesday, December 14, 2010 5:36 PM
    Moderator
  • Josh,

    OK, that makes more sense. I had missed the part in Section 2.2.1.1 because it appeared (from "after the de-encapsulation") to only apply if the address was IMCEA encapsulated. Perhaps "after decoding" or just leave those words out?

    Thanks again.

    Brad

     

    Tuesday, December 14, 2010 8:14 PM