I recently upgraded my server from Exchange 2003 to Exchange 2007. After the upgrade, my father found one of the e-mails in his distribution list is now rejected by Exchange. The e-mail address contains a domain part that's fully qualified, including the trailing period. I believe this is a valid e-mail address, but Exchange responds with the following: omitted@msn.com. #550 5.1.3 STOREDRV.Submit; invalid recipient address #SMTP# Obviously the quick fix is to remove the trailing period from the e-mail address to make it conform to the normal format.My question is, was this an unintentional regression from 2003? Searching through the RFCs, I don't see anything that suggests other than accepting any valid domain name for the domain part of the address.If this was an unintentional regression, please consider fixing it for a future service pack.Regards,Jason

Hi, Please understand that E-mail addresses are formally defined in RFC 5322 (mostly section 3.4.1) and to a lesser degree RFC 5321. An e-mail address is a string of a subset of ASCII characters separated into 2 parts by an "@" (at sign), a "local-part" and a domain, that is, local part@domain. Domain are made of non-empty labels separated by dots (.),so you cannot attach dots at the end of the domain, it will assume a empty label follow by dot(.)It is define in RFC 1034, updated by RFC 1123). So when you have dot at the end of domain, it will be considered as a invaild e-mail address. Regards, Xiu

Xiu, Thanks for the response. RFC 1034 states the following: When a user needs to type a domain name, the length of each label isomitted and the labels are separated by dots ("."). Since a completedomain name ends with the root label, this leads to a printed form whichends in a dot. We use this property to distinguish between:- a character string which represents a complete domain name(often called "absolute"). For example, "poneria.ISI.EDU."- a character string that represents the starting labels of adomain name which is incomplete, and should be completed bylocal software using knowledge of the local domain (oftencalled "relative"). For example, "poneria" used in theISI.EDU domain. RFC 1123 doesn't appear to alter that statement. Furthermore, RFC 822 defines the e-mail address format as: addr-spec = local-part "@" domain ; global addresslocal-part = word *("." word) ; uninterpreted; case-preserveddomain = sub-domain *("." sub-domain)sub-domain = domain-ref / domain-literaldomain-ref = atom ; symbolic reference Where domain-ref is defined as: A domain-ref must be THE official name of a registry, network,or host. It is a symbolic reference, within a name sub-domain. At times, it is necessary to bypass standard mechan-isms for resolving such references, using more primitiveinformation, such as a network host address rather than itsassociated host name.Therefore, although the grammar allows for dot-separated sub-domains without a trailing period, the domain-ref itself may be a "host" and in the context of Windows and nearly every other system, the trailing period is used to distinguish a relative host from an absolute host. For example, > wwwServer: dns.wdc1.speakeasy.netAddress: 66.92.159.2Non-authoritative answer:Name: aspsrv.jaraco.comAddress: 205.201.137.9Aliases: www.jaraco.com ftp.jaraco.com> www.microsoft.com.Server: dns.wdc1.speakeasy.netAddress: 66.92.159.2Non-authoritative answer:Name: lb1.www.ms.akadns.netAddresses: 65.55.12.249 207.46.192.254 207.46.193.254Aliases: www.microsoft.com toggle.www.ms.akadns.net g.www.ms.akadns.net So in the context of e-mail addresses, Microsoft does use the interpretation where the characters to the right of the '@' are the domain-ref or the hostname. Furthermore, the Exchange 2003 supported trailing-dot e-mail addresses, and many other e-mail systems accept the trailing dot, including Outlook. I have confirmed, however, that both live.com and gmail.com reject addresses with a trailing period, so perhaps this is the way the industry is moving. The problem, then, lies with the user experience. Here's the scenario. Janet sends out an e-mail to a list of people using a mail system that supports trailing periods; one address on the list contains a trailing period. Brad, one of the recipients, is using Outlook 2007 on Exchange 2007. He invokes Reply All, and sends a message to the entire list. The message is sent to all of the recipients except for the one with the trailing period. Brad must now re-send that message with the corrected e-mail address and either send a duplicate mesasge to the others on the list, or send a message without the same headers, so the new recipient doesn't have access to Reply All. So, if Exchange insists that trailing periods are not valid in an e-mail address, Outlook should likewise reject client-side any SMTP address that ends in a period, so that a faulty e-mail address doesn't break on transmission. I hope this thread can be read by the appropriate team to at least provide feedback on this new behavior. Regards, Jason