Subject: [ietf-smtp] Dotless domains and email

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 07:46:10 -0700

Folks,

G'day.

 From ICANN SSAC SAC 053
(www.icann.org/en/groups/ssac/documents/sac-053-en.pdf):

> "3.4	Electronic Mail One serious and prevalent concern is that
> dotless domains would not work with protocols that specify additional
> rules of what constitutes a legal domain. The most prominent example
> is the Simple Mail Transfer Protocol (SMTP) to deliver electronic
> mail. It requires at least two labels in the FQDN of a mail address.
> Thus standard-compliant mail servers would reject emails to addresses
> such as user@brand."
>

I'm not seeing this requirement/limitation in RFC 5321.  It merely 
requires an FQDN.

Does anyone have an explanation for the assessment in the ICANN report 
that at least two levels are required?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 07:46:31 -0700

Folks,

G'day.

 From ICANN SSAC SAC 053

d/

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2013 17:54:39 -0000

>that at least two levels are required?

a) they goofed

2) MTAs running on Unix-ish systems typically use POSIX
gethostbyname() or res_query() to resolve host names.  Most
implementations of those routines when presented with an unqualified
name will first try the name with a locally configured default domain,
and only if that fails will try the bare name.  There is a parameter
in the resolver config file to change that, but I don't know anyone
who changes it.

So it's not in the RFC, but it's sure in the code, and the way it's
implemented, a local host name will mask a dotless TLD, leading to
highly unpredictable results.

The counter-counter argument is that a fair number of ccTLDs have MX
records for the TLD and the world hasn't come to an end, such as the
world's shortest e-mail address n@ai.  For a good time, do an MX
lookup on gt.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Jun 2013 18:56:07 +0100

> >that at least two levels are required?

They might have been looking at RFC 2821

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Alex Bobotek <[email-masked]>
Date: Fri, 21 Jun 2013 10:58:24 -0700

In practice, reliable delivery It requires at least two labels in the FQDN of a mail address.

Quite a few of the mail systems I've tested break when a dotless domain is used.  So there's an operational issue with this use.
Although I've looked, I've never been able to find a current RFC that requires a dot on the RHS of SMTP addresses.

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
Sent: Friday, June 21, 2013 10:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-smtp] Dotless domains and email

a) they goofed

2) MTAs running on Unix-ish systems typically use POSIX
gethostbyname() or res_query() to resolve host names.  Most implementations of those routines when presented with an unqualified name will first try the name with a locally configured default domain, and only if that fails will try the bare name.  There is a parameter in the resolver config file to change that, but I don't know anyone who changes it.

So it's not in the RFC, but it's sure in the code, and the way it's implemented, a local host name will mask a dotless TLD, leading to highly unpredictable results.

The counter-counter argument is that a fair number of ccTLDs have MX records for the TLD and the world hasn't come to an end, such as the world's shortest e-mail address n@ai.  For a good time, do an MX lookup on gt.

R's,
John
_______________________________________________
ietf-smtp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 10:59:33 -0700

>>> that at least two levels are required?
...
> They might have been looking at RFC 2821

Well, that would be odd, certainly.

On the other hand, I'm not finding text in RFC 2821 (searching only for 
FQDN) that asserts the limitation.  Pointer please?

d/

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Fri, 21 Jun 2013 11:04:12 -0700

> that at least two levels are required? 

I don't see any standards requirement either, but it certainly would be 
problematic in the Real World. The number of existing software 
implementations that require externally facing names to contain at least 
one dot are legion, especially administrative UI's and submission 
elements. I still run into software that won't accept TLDs that are more 
than 4 letters long, too. And of course there's the ambiguity that 
results from suffixes being added -- a problem we already went through 
with .cs.

<csg>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Jun 2013 15:14:39 -0400

> FQDN) that asserts the limitation.  Pointer please?

Assembled from the bits of grammar in 2821:

   "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" /
          Forward-Path) [SP Rcpt-parameters] CRLF

   Forward-path = Path

   Path = "<" [ A-d-l ":" ] Mailbox ">"

   Mailbox = Local-part "@" Domain

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

---
RFC 5321 makes "Domain" this:

   Domain         = sub-domain *("." sub-domain)

...which allows the dotless option.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 12:24:18 -0700

> ...which allows the dotless option.

wow.  never occurred to me.

thanks!

d/

---

From: Alex Bobotek <[email-masked]>
Date: Fri, 21 Jun 2013 12:27:57 -0700

Does anyone know why RFC 2821 added the dotless domain restriction?

Like 5321, 821 permits dotless domains by its construction rules:

           <forward-path> ::= <path>

            <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"

            <at-domain> ::= "@" <domain>

            <domain> ::=  <element> | <element> "." <domain>

            <element> ::= <name> | "#" <number> | "[" <dotnum> "]"

            <mailbox> ::= <local-part> "@" <domain>

            <local-part> ::= <dot-string> | <quoted-string>

            <name> ::= <a> <ldh-str> <let-dig>

            <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

            <let-dig> ::= <a> | <d>

            <let-dig-hyp> ::= <a> | <d> | "-"

            <dot-string> ::= <string> | <string> "." <dot-string>

            <string> ::= <char> | <char> <string>

            <quoted-string> ::=  """ <qtext> """

            <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>

            <char> ::= <c> | "\" <x>

            <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

            <number> ::= <d> | <d> <number>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, June 21, 2013 12:15 PM
To: Dave Crocker
Cc: Tony Finch; John Levine; [email-masked]
Subject: Re: [ietf-smtp] Dotless domains and email

   Forward-path = Path

---

Barry
[email-masked]

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Fri, 21 Jun 2013 12:36:11 -0700

> Like 5321, 821 permits dotless domains by its construction rules:

This same discussion came up on this list in January 2009. Here's a 
snippet from a discussion between John Klensin and John Levine:

> Date: Sat, 24 Jan 2009 20:27:15 -0500
> From: John C Klensin <[email-masked]>
> To: John Levine <[email-masked]>, [email-masked]
>
> > As best I understand it, the prose description of addresses in
> > 2821 allowed TLDs in addresses, but the ABNF didn't.  In 5321
> > the ABNF changed to match the prose.  Although the DNS allows
> > you to put a dot at the end of a domain name to make it clear
> > that it's an absolute address, SMTP has never allowed that.
>
> Correct on all counts.  In the 2821bis work, the possibility of
> changing the syntax to match the prose was considered too.  That
> change was actually made to the document at one point.  The
> group then decided it was a bad idea and the change was un-done.

The archaeologists might want to dig into the rest of it. My personal 
archives don't go back that far.

<csg>

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jun 2013 15:31:56 -0400

Folks,

FWIW and remembering that I didn't do the ABNF for either 2821
or 5321...

Both 5321 and 2821 contain

RFC 2821 contains:

While 5321 contains

That change, effectively removing the requirement for at least
two components in the domain-part, is consistent with the text
in Section 2.5.5 of 5321 (and the very similar text in the
section of the same number in 2821) but does not appear in any
of my notes about intentional changes between 2821 and 5321
(I've just done a quick check and might have missed something),
including being absent from the change log in the last I-D
version of 5321, so I'm not sure where it came from.    I do
remember some quite explicit discussions during both the 2821
and 5321 work about eliminating the prohibition on trailing
periods in mailbox names.  That change would have both better
aligned SMTP with 1034/1035 and make the distinction between a
TLD name and a possible abbreviation/ alias in need of
completion, but the WG (and group that commented on 5321) wanted
nothing to do with it, at least in part because that distinction
was considered a UI issue and that SMTP should adhere rigidly to
the rule that any <Domain> that appeared in an SMTP Mailbox was
required to be an FQDN.

That is all I'm likely to remember without doing a lot of
time-consuming research, but I do agree with Carl -- while one
would hope that everyone would have abandoned 2821 (and 821,
974, and the mail-specific requirements of 1123) in favor of
5321, we know that hasn't happened in practice and that some
MUAs and MTAs will refuse to resolve single-component domain
names or will, despite years or prohibitions, try to treat them
as aliases.  So there is a predictability problem at best and
might well be some other issues.

 best,
   john

---

From: "John R. Levine" <[email-masked]>
Date: 21 Jun 2013 15:36:07 -0400

> Does anyone know why RFC 2821 added the dotless domain restriction?

Dunno, perhaps the author can dredge up the distant memories.  The text in 
2821 sec 2.3.5 looks to me like it does allow dotless domains, and doesn't 
match the ABNF.

2.3.5 Domain

    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]. ...

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jun 2013 16:07:00 -0400

--On Friday, June 21, 2013 12:36 -0700 "Carl S. Gutekunst"
<[email-masked]> wrote:

>...
> This same discussion came up on this list in January 2009.
> Here's a snippet from a discussion between John Klensin and
> John Levine:
> 
>> > As best I understand it, the prose description of addresses
>> > in 2821 allowed TLDs in addresses, but the ABNF didn't.  In
>> > 5321 the ABNF changed to match the prose.  Although the DNS
>> > allows you to put a dot at the end of a domain name to make
>> > it clear that it's an absolute address, SMTP has never
>> > allowed that.
>> 
>> Correct on all counts.  In the 2821bis work, the possibility
>> of changing the syntax to match the prose was considered too.
>> That change was actually made to the document at one point.
>> The group then decided it was a bad idea and the change was
>> un-done.

I.e., at the time I wrote that note, somewhat after the
publication of 5321, I may not have realized that the ABNF in
5321 didn't match that in 2821.   Or not... just don't recall...
see below.
 
> The archaeologists might want to dig into the rest of it. My
> personal archives don't go back that far.

Thanks.  Mine sort of do (see earlier note, which I tried
sending a while ago but screwed up the posting address and just
noticed).  My archives should go back to when I started work on
what became 2821 but it would require pulling out old DAT backup
tapes and seeing if I can still read them.  Also, the initial
versions or 2821 and 5321 were prepared in a commercial word
processor and annotated carefully with the reasons for changes
(some of which were made by a professional editor in an attempt
to clarify the text and make it easier to follow).  When that
effort, and the associated versions, were abandoned, the
information didn't quite get lost, but became a lot harder to
reconstruct.

best,
   john

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 Jun 2013 20:31:16 +0200

> archives don't go back that far.

IMC's archives do:
http://www.imc.org/ietf-smtp/mail-archive/msg05431.html

A passage from that page shows how redaction follows the same rule:

    My impression is that in the real world, mail addressed to
    postmaster@va is far more likely to be rewritten to
    postmaster@xxxxxxxxxxxxxx than delivered to the Vatican

Likewise, [email-masked] is more likely to be clickable on
MUAs that add hyperlinks.

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2013 00:56:51 -0400

I've seen a lot of code (including but not just in email software) that 
assumed that if a domain name contained a dot, it was an FQDN (and 
therefore should be taken as correct as-is), and if it didn't contain a 
dot, it was potentially an alias (and therefore subject to having a 
default domain suffix appended to it).

I'm sorry that I wasn't paying close enough attention to object to the 
change in RFC 5321.   I consider it very important for software to be 
able to distinguish an FQDN from a locally-supplied domain alias.

Keith

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 27 Jun 2013 08:07:49 +0200

Yes.

I suspect that postmaster@va may not be able to order very many things via the web, our sign up for sites which demand a valid email address.

Arnt

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 28 Jun 2013 16:03:42 +0200

> default domain suffix appended to it).

I'm not sure appending a domain is the right thing to do.  If you have
RCPT TO:<postmaster>, or something like that, you also append the "@".
RFC 5321 just says "mechanisms for inferring FQDNs from partial names or
local aliases are outside of this specification."

How about RCPT TO:<user@local>?  According to RFC 6762, "operators
SHOULD NOT attempt to configure authoritative DNS servers to act as
authoritative for any of these names."  So any address or MX should be
defined using mDNS.  It might make sense to devise an SMTP flavor that
works with such data --would it be called a multicast MTA?