ietf-smtp
[Top] [All Lists]

Re: Possible ambiguity in SMTP RFC2821 - your opinon please

2007-11-25 15:59:03



--On Monday, 26 November, 2007 02:42 +1100 Chris Wright
<chris(_at_)ausregistry(_dot_)com(_dot_)au> wrote:

Hi John,
 My name is Chris, I am CTO of AusRegistry the registry
operator of the .au cctld. I have been doing some research on
the SMTP protocol lately and have come up with something that
I guess is a potential ambiguity in the SMTP protocol defined
in RFC2821 you authored (if I am remembering my BNF
correctly). Any clarification you can shed on the matter would
be greatly appreciated.

In section 2.3.5 of the RFC you define the domain name part of
an email address as being "one or more dot-separated
components" (I have reproduced it below to save you having to
go and find it). Further down in section 4.1.2 your grammar
describes the domain as being:

   Domain = (sub-domain 1*("." sub-domain)) / address-literal

Which (If I am hopefully remembering correctly means a
sub-domain followed by 1 or more "." sub-domain combinations.
This appears to be in contradiction to the paragraphs of 2.3.5.

I have come up against it because I am looking at the
possibilities of having email addresses under a TLD eg.
john(_at_)au or chris(_at_)com, which would presumably be legal given
that au or com is a fully qualified domain name (when you put
the dot on the end). It appears most email software doesn't
support this :(

Could you clarify firstly my interpretation and secondly the
intent of the RFC, would be greatly appreciated.

Thanks

From Section 2.3.5 of RFC2821

   A domain (or domain name) consists of one or more
dot-separated    components.  These components ("labels" in
DNS terminology [22]) are    restricted for SMTP purposes to
consist of a sequence of letters,    digits, and hyphens drawn
from the ASCII character set [1].  Domain    names are used as
names of hosts and of other entities in the domain    name
hierarchy.  For example, a domain may refer to an alias (label
   of a CNAME RR) or the label of Mail eXchanger records to be
used to    deliver mail instead of representing a host name.
See [22] and    section 5 of this specification.

   The domain name, as described in this document and in [22],
is the    entire, fully-qualified name (often referred to as
an "FQDN").  A    domain name that is not in FQDN form is no
more than a local alias.    Local aliases MUST NOT appear in
any SMTP transaction.


From Section 4.1.2

   Domain = (sub-domain 1*("." sub-domain)) / address-literal

Hi Chris,

There is a revision of 2821 in progress.  The current draft is
draft-klensin-rfc2821bis-06.txt and discussion is occurring on
the ietf-smtp list (copied on this note to expose your question
and comments on the list).

The question of whether an address of the form username(_at_)au was
actively discussed some months ago, and the ICANN ccNSO and gNSO
were polled on the question.  The (few) responses we got back
from the latter can, I think, be fairly summarized as "no one
cared very much", something you can verify with Chris Disspain
if you like.

The difficulty with TLD-only addresses is that the mail
protocols do not permit that trailing dot.  Discussion over the
last year concluded that the backwards-compatibility issues that
would be raised by changing that are far more problematic than
the change might be worth.  So, if one has a one-component name,
there is some difficulty in distinguishing it lexically from an
abbreviation (not permitted on the wire, but common in local
systems).  For that reason and regardless of what is done with
the standard, you should anticipate difficulties with some mail
user agents in handling the address.

However, while one must be cautious, there seems to be no reason
to prohibit a TLD from being used as an MX record and receiving
mail, so the revision draft has been changed to explicitly
permit that form.  In the working draft I've further modified
that uncomfortable sentence in 2.3.5 but the text (and syntax)
of -06 clearly permit what you want to do.

 regards,
     john

<Prev in Thread] Current Thread [Next in Thread>