Address Literals and Microsoft Exchange

by Bharat Suneja

RFC 2821 specifies how address literals can be used to reach recipients – particularly useful when DNS resolution doesn’t work for a particular domain or host. This is a literal form of the address which can be used as an alternative to the domain name. For IPv4 addresses, the address literal format is [email protected][1.2.3.4] – where 1.2.3.4 is the IP address of the host.

Exchange Server 2003 allows usage of address literals in Recipient Policy. You can create a Recipient Policy rule and insert the IP address (of your Exchange server) enclosed in square brackets e.g. @[1.2.3.4] to use the alias, or %1g.%[email protected][1.2.3.4] to use first initial and last name (depending upon your organization’s naming convention for primary email addresses).

Not all recipients need to be reachable using address literals, though it certainly doesn’t hurt if they are. (It may get a tad too complicated in anything but single server environments… ). It’s a good idea to have at least the common accounts used to report email problems – like postmaster (an RFC requirement), abuse, et al reachable.

If you create a Recipient Policy that doesn’t apply to any users, you can then add one-off email addresses to accounts like postmaster. The Recipient Policy tells Exchange it needs to receive email for a certain domain and whether it is authoritative for that domain. (Yes, the literal IPv4 addresses get treated like domains by Exchange.)

If you decide to take this route, you can’t use the Email Addresses tab in Active Directory Users & Computers console to add literal addresses – it doesn’t allow email addresses with square brackets. The workaround: use ADSIEdit to add the one off literal addresses to user accounts.

If your servers are behind a NAT router or firewall, it makes sense to add both the internal and external (NATted) IP addresses of the host to the Recipient Policy.

Update 9/20/2011: For Exchange 2010/2007, see Address Literals in Exchange 2007 and Exchange 2010.

{ 5 comments… read them below or add one }

Anonymous April 8, 2007 at 2:02 am

Hello,

Will this also work for Exchange 2007?

Our DELL DRAC’s can’t send mail anymore using a E2K7 hub transport because it considers @[1.2.3.4] to be an invalid address and rejects it.

Cheers

Reply

Bharat Suneja April 8, 2007 at 7:37 am

Exchange Server 2007 does not support address literals.

Bharat

Reply

Anonymous March 11, 2009 at 5:20 am

Hello,

we have the same problem with IBM Bladecenter AMM and Exchange 2007. Do you know any workaround to solve these problem?

Regards Thomas

Reply

Anonymous March 12, 2009 at 1:36 am

Hello,

We are also using IBM Blades and just upgraded to Exchange 2007.

Worked around it by relaying AMM alerts to a Linux mail server instead.

GMAIL seems to accept the alerts from AMM though.

regards, BEN

Reply

Matthias Klöpper April 24, 2009 at 5:50 am

Hi,
I recently stumbled across that problem (or at least a very similar one) while trying to talk our Exchange 2007 Server into accepting Mails for address literals. This seems to be impossible while the literal is written with enclosing square brackets. We do need this form of direct adressing to let Sendmail forwrd specific Mails/Domains directly to our internal Exchange.
To solve this problem I tried to add an unenclosed IP-Adress to the list of accepted Domains. This works without any complaints. You will just have to configure your other systems (Sendmail in our case) to relay Mails for @[1.2.3.4] directly to 1.2.3.4. In Sendmail you could use the Mailertable for example. Should be working with postfix’ transport file, too.

Regards, Matthias

Reply

Leave a Comment

{ 2 trackbacks }

Previous post:

Next post: