Exchangepedia Blog is read by visitors from all 50 US States and 150 countries world-wide
RFC 2821 allows the use of a literal form of a recipient's address, which uses the destination system's IP address enclosed by square brackets in the domain part, as an alternative to a domain name. Commonly known as address literals, this form of addressing helps in delivery of mail to a recipient when the recipient's domain is facing DNS issues - such as when DNS servers are not available, or domain registration records point to invalid or old DNS server (as may happen temporarily when moving to different DNS servers and old information lives on in DNS caches... ).
In addition to the technical glitches with DNS, there will always be that odd case of human error, when someone responsible in your organization for domain registrations/renewals, and paying the bills, forgets to pay up for renewal. If it can happen to Microsoft (Hotmail lost the domain name hotmail.co.uk, which expired due to non-renewal), it can happen to any of us.
Exchange Server 2003 supports address literals [read previous post "Address Literals and Microsoft Exchange"]. A Recipient Policy rule can be created to generate literal addresses. This allows mail delivery to a recipient, without relying on or using DNS.
The usage scenario: A monitoring system/service like Zenprise, which monitors service availability for email, DNS, etc. detects unavailability of your external DNS servers/zones, or some inconsistency with DNS zones or records. This affects mail delivery to your domain(s) using your normal email address(es) - e.g. [email protected]. In such cases, the monitoring system or service can send mail using the address literal - foo@[1.2.3.4] or notify postmaster@[1.2.3.4].
Exchange Server 2007 does not support address literals - you cannot create an AcceptedDomain and EmailAddressPolicy (together these are equivalent of Recipient Policies in Exchange Server 2003/2000) to generate literal addresses, nor does it support manually adding such addresses to a recipient. Microsoft has no plans of reintroducing it.
However, much as one would like to see these supported, Exchange Server 2007 cannot be accused of not being standards-compliant - address literals are neither a requirement, nor a recommendation according to RFC 2821. It allows the use of such addresses.
In addition to the technical glitches with DNS, there will always be that odd case of human error, when someone responsible in your organization for domain registrations/renewals, and paying the bills, forgets to pay up for renewal. If it can happen to Microsoft (Hotmail lost the domain name hotmail.co.uk, which expired due to non-renewal), it can happen to any of us.
Exchange Server 2003 supports address literals [read previous post "Address Literals and Microsoft Exchange"]. A Recipient Policy rule can be created to generate literal addresses. This allows mail delivery to a recipient, without relying on or using DNS.
The usage scenario: A monitoring system/service like Zenprise, which monitors service availability for email, DNS, etc. detects unavailability of your external DNS servers/zones, or some inconsistency with DNS zones or records. This affects mail delivery to your domain(s) using your normal email address(es) - e.g. [email protected]. In such cases, the monitoring system or service can send mail using the address literal - foo@[1.2.3.4] or notify postmaster@[1.2.3.4].
Exchange Server 2007 does not support address literals - you cannot create an AcceptedDomain and EmailAddressPolicy (together these are equivalent of Recipient Policies in Exchange Server 2003/2000) to generate literal addresses, nor does it support manually adding such addresses to a recipient. Microsoft has no plans of reintroducing it.
However, much as one would like to see these supported, Exchange Server 2007 cannot be accused of not being standards-compliant - address literals are neither a requirement, nor a recommendation according to RFC 2821. It allows the use of such addresses.
Labels: Administration, Exchange Server 2007, Microsoft, SMTP
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home