If the message database encoding format (MDBEF) content type is used, only one address can be included for a message originator or recipient. Although the address can be the distinguished name address or the O/R address, it is usually the distinguished name address. For this reason, distinguished name access for the originator and all recipients is required during conversion. That way, the O/R addresses required by P2 can be obtained. The decision to convert from MDBEF to P2 can be delayed only until the final replicated Microsoft Exchange Server site (where the MTA can always obtain access to the objects) is referenced by distinguished names in the message. The decision to convert must be made as soon as possible, to ensure that all information required for the conversion is available.
If only a few recipients for a given destination allow MDBEF messages, the message copy for a particular destination is split into two copies. However, this is an atypical situation because conversion on the sending MTA is usually determined on the basis of message and destination MTA or connector properties rather on recipient properties.
The main conversion decision process is based on the type of message content and the destination (either the local MTA or the recipient or remote MTA or connector). However, even if the content of a message is in MDBEF and the chosen connector allows MDBEF content, an individual recipient might not support MDBEF content.
Per-recipient checking is completed during routing to verify whether a particular recipient can support MDBEF. If a recipient is a Microsoft Exchange Server recipient, it is assumed to support MDBEF. A recipient is assumed to be a Microsoft Exchange Server recipient if it supports MDBEF and if:
If a recipient is not known to support MDBEF, the message is converted by the conversion decision routine during fan-out. However, the following exceptions override the per-recipient MDBEF determined during routing: