X.400 Addresses and Exchange 2010 (Part 1)

If you would like to read the next part in this article series please go to X.400 Addresses and Exchange 2010 (Part 2).

Introduction

In the beginning of e-mail days, every e-mail system had its own way of representing content such as address formats or rich text of a message, which made it extremely difficult to interconnect different systems.

This was the case until ITU-T [International Telecommunication Union – Telecommunication Standardization Sector] published in 1984 (and revised in 1988) the X.400 standard for exchanging and addressing electronic messages. While X.400 was expected to become the norm for e-mail, it was taken over by the Internet-based standard Simple Mail Transfer Protocol [SMTP] a decade after. This was mainly due to the:

• Fast spread of the Internet;
• Simplicity of using SMTP addresses rather than X.400 (as we will see);
• Cost – service providers would charge for e-mail transmission using X.400 while with Internet e-mail it was free.

Despite this, X.400 was once a core part of Microsoft Exchange Server and variants of it are still part of some systems used by the Military, Financial and Intelligence Services, Government and Aviation where high reliability and security is required. These still use X.400 due to some advantages that it has over SMTP. Just to briefly name a few:

• Notifications – X.400 can notify the sender if the message has been successfully delivered while SMTP only notifies when a message fails to be delivered. Additionally, X.400 can automatically include receipt notifications to say that the message was read. Only some clients such as Outlook provide a similar service but by using proprietary protocols;
• Security – it is not possible to spoof X.400 addresses because the sender information is always certified and fully traceable ensuring the path the message travels is valid. Peer authentication is used by default in X.400 networks and is seen as a core feature;
• Delivery Time Control which allows senders to specify the earliest time at which a message may be delivered (Deferred Delivery) as well as the latest time at which a message may be delivered (Latest Delivery Time). Again, equivalent functions are implemented by certain clients, but not by SMTP itself;
• Performance – X.400 transmits messages in binary format and allows the prevention of content conversion. SMTP transmits messages in text and uses UUEncode or Base64 to transmit attachments, causing the overall message size to be larger;
• Priority – X.400 has usually three levels of message priority, processing messages according to their priority. This is important in many high reliability systems as it ensures high priority of certain critical messages;
• Alternate Recipient – when there is a problem delivering a message to the intended recipient, X.400 can deliver the message to an alternate recipient specified by the sender or by the recipient’s domain. This feature is often used in high reliability systems to ensure a message is handled rather than sending a failure to the sender;
• Capability Verification – X.400 always does a directory lookup before sending the message (when sending internal messages), ensuring the message is sent to a correct destination and preventing the inefficiency of failure delivery report. It also verifies some capabilities of the recipient such as checking the message is not too large for the recipient (now implemented in Exchange 2010 with MailTips); checking the client can handle the specific data formats or checking the recipient’s security clearance against the security label of the message.

X.400 Address Format

X.400 addresses are usually referred to as an Originator/Recipient [OR] address that have two purposes:

1. Identify the mailbox of the originator or the recipient;
2. Globally identify the domain where a mailbox is located.

These addresses use a hierarchical naming system and consist of a series of attributes. Some of these attributes specify the organization and other attributes specify the recipient. The sum of all these attributes form the X.400 address.

Let’s compare the same e-mail address in SMTP and X.400 format (please see figure 1.1 below):

• SMTP – [email protected]
• X.400 – C=US;A= ;P=LetsExchange;O=First Organization;S=Mota;G=Nuno;

X.400 can contain more elements, the most common ones being:

• C – Country name;
• A or ADMD – Administration Management Domain, usually a public mail service provider;
• P or PRMD – Private Management Domain (your Exchange Organization);
• O – Organization name (which corresponds to the Exchange Administrative Group);
• OU – Organizational Unit Names;
• G – Given name;
• I – Initials;
• S – Surname.

Many other elements exist that can be used in a X.400 address such as PD-OF [Physical Delivery Office Name], PD-S [Street Address], PD-B [Post Office Box Address] or PD-PC [Postal Code] just to name a few.

Because the standards originally did not specify how to write these addresses, RFC1685 (based on a 1993 draft of ITU-T Recommendation F.401) was written in 1994 to specify one encoding with the following recommendations:

• Only the main abbreviations G, I, S, O, OU1, OU2, P, A and C are used and written using upper case;
• The separation character should be semicolon;
• The ADMD value “blank” is expressed by omitting the attribute. No other interpretation of a missing ADMD attribute is allowed;
• The recommended sequence is G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;

The example address mentioned above was taken from an Exchange environment and, as you can see, does not exactly comply with this RFC.

Throughout the years, many different forms of addressing were recommended for X.400 which many believe to be the main factor to contribute to the lack of success of X.400.

A few differences and similarities between the two formats:

• SMTP addresses are shorter;
• X.400 uses labels to compose the address;
• The ADMD and PRMD elements are often the same, which doesn’t happen in SMTP;
• The order of some elements are reversed (which cannot be seen in the example above);
• Both are usually hierarchical in nature;
• Both have a restricted character set for naming;
• Both can be separated into components;
• Both are intended to be globally unique addresses;
• There is no clean mapping between them.

X.400 History in the Exchange World

Before Exchange Server 2000, X.400 was the default protocol and connectivity standard used in Exchange. It was only then that SMTP became the native method for message transfer. However, due to backward compatibility, Exchange Server 2000/2003 still include a Message Transfer Agent [MTA] compliant with X.400, providing seamless integration of Exchange Server 2000/2003 with Exchange Server 5.5 and allowing administrators to use X.400 connectors to connect to external X.400 messaging systems.

If you have deployed a pure Exchange 2007 or 2010 environment, your users will not have X.400 addresses. This is because they are not used any more. Since Exchange 2007 that the MTA service is not used and the X.400 connector is gone. Therefore, there are no longer X.400 default proxy e-mail addresses in Exchange Server 2007/2010.

However, if you transitioned from Exchange Server 5.5 or migrated from an e-mail system that uses X.400, you will probably still have X.400 addresses in your users’ attributes:

Figure 1.1: Exchange 2010 mailbox with legacy X.400 address

X.400 in Exchange Server 2010

As stated before, Exchange 2010 does not provide native transport support for X.400 so you cannot route or relay e-mails directly to an X.400 MTA. So how can we connect an Exchange 2010 environment to an e-mail system that uses X.400? To achieve this you have two options (both only implemented by using the Exchange Management Shell):

1. Configure one or more X.400 Authoritative Domain namespaces by using the New-X400AuthoritativeDomain cmdlet;
2. Create a Foreign Connector to send e-mails to a local messaging server that does not use SMTP.

Although I mentioned “two” options, for you to use an Authoritative Domain, Exchange 2010 must route these e-mails through an Exchange 2003 server hosting an X.400 connector or through a Foreign Connector.

Also, because Exchange 2010 does not have an X.400 MTA, it cannot convert messages to the X.400 format. This is taken care by the X.400 connector hosted on Exchange 2003 or by the Foreign Connector. To transport X.400 messages, Exchange 2010 routes the message over SMTP as a MIME-encapsulated Transport Neutral Encapsulation Format [TNEF] message.

A third option might be available: Delivery Agents, a new feature introduced in Exchange 2010. These agents are also used to route e-mails to systems that do not use SMTP and are considered a significant improvement over Foreign connectors in handling non-SMTP messages in Exchange. They allow queue management of Foreign connectors, thus eliminating the need for storing messages on the file system in a Drop directory (as we will see in the second part of this article) and provide greater control over the message delivery to the foreign systems.

The downside of Delivery Agents is that they are typically written by third-parties – Exchange 2010 only comes with one Delivery Agent connector by default: the Text Messaging Delivery Agent connector used to send messages to mobile devices (try running Get-DeliveryAgentConnector):

Figure 1.2: Exchange 2010 Default Delivery Agent

Conclusion

In this first part of the article, we explored what X.400 addresses are and if they are used by Exchange 2010. In the second and final part of the article, we will see how to configure an Authoritative Domains, Foreign Connectors and how to remove X.400 addresses from all users’ mailboxes.

If you would like to read the next part in this article series please go to X.400 Addresses and Exchange 2010 (Part 2).