Subject: Re: [ietf-smtp] Dotless domains and email

From: Randall Gellens <[email-masked]>
Date: Thu, 4 Jul 2013 15:28:34 -0700

My own personal servers have anti-spam rules that reject hosts whose 
EHLO strings don't contain a dot.  Too much spam comes in from 
"localhost", "vivek-PC", "20110815-1552", "Dell-PC", "user", 
"OfficeRtr", "????-???????", "BPIGL2", etc.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Jul 2013 13:03:57 -0400

On 06/28/2013 10:03 AM, Alessandro Vesely wrote:
> On Thu 27/Jun/2013 06:56:51 +0200 Keith Moore wrote:
>> 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 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.
Please, no.   mDNS was, and is, a complete botch.  Let's not pollute the 
mail system with it.

All I'm saying is that there's a lot of existing and useful practice 
which expects to be able to distinguish an alias (presumably without a 
dot) from a FQDN.  People shouldn't expect email to a domain name that 
consists entirely of a TLD (any TLD) to work reliably.   This is one of 
a long list of reasons why vanity TLDs were a Really Bad Idea.

Keith

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Jul 2013 20:19:04 +0200

On Fri 05/Jul/2013 19:03:57 +0200 Keith Moore wrote:
> Please, no.   mDNS was, and is, a complete botch.

Fully agreed :-)

> Let's not pollute the mail system with it.

Yet, there seem to be quite some users who happen to download and
install MTA software on their laptops, unwittingly.  It is not at all
obvious how to provide an even barely working default configuration for
that kind of thing, which leads to frustration.  OTOH, it might
sometimes be handy to be able to exchange email messages across an
ad-hoc LAN, possibly disconnected from the rest of the Internet.

> a long list of reasons why vanity TLDs were a Really Bad Idea.

I'm neutral on this.  I see no technical reason to ban dotless domains,
and no traction to make them work.  Any chance we can catch some wind by
rocking the boat with mDNS?

---

From: "John Levine" <[email-masked]>
Date: 5 Jul 2013 20:56:30 -0000

>dot) from a FQDN. ...

Well, yes.  Take a look at SAC 053 and see if there's anything they
missed:

http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Jul 2013 14:23:46 -0700

> http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf

IMO, the report is wrong on an essential detail.  It attributes the 
handling barrier to SMTP, which has no such barrier.

Here's my summary of the situation:

      1.  SMTP does not prohibit dotless domains.  So, as far as the 
protocol is concerned foo@example is as legal as [email-masked].

      2.  A wide range of independently-developed mail-receiving 
software treats a dotless hostname as /not/ a legal domain name and 
thereby filters it out as potentially hostile.  A common example that 
justifies this is 'localhost'.

      So there is indeed a widespread, very solid email barrier to usage 
of dotless hostnames, although it is from long-standing receiving 
software practice, rather than from the protocol specification.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Jul 2013 17:46:48 -0400

--On Friday, July 05, 2013 14:23 -0700 Dave Crocker
<[email-masked]> wrote:

>>> All I'm saying is that there's a lot of existing and useful
>>> practice which expects to be able to distinguish an alias
>>> (presumably without a dot) from a FQDN. ...
>> 
>> Well, yes.  Take a look at SAC 053 and see if there's
>> anything they missed:
>> 
> IMO, the report is wrong on an essential detail.  It
> attributes the handling barrier to SMTP, which has no such
> barrier.
> 
>       1.  SMTP does not prohibit dotless domains.  So, as far
> as the protocol is concerned foo@example is as legal as
> [email-masked].
> 
>       2.  A wide range of independently-developed
> mail-receiving software treats a dotless hostname as /not/ a
> legal domain name and thereby filters it out as potentially
> hostile.  A common example that justifies this is 'localhost'.
> 
>       So there is indeed a widespread, very solid email
> barrier to usage of dotless hostnames, although it is from
> long-standing receiving software practice, rather than from
> the protocol specification.

This has been noted by others but, for purposes of completeness
in the above summary (and following Dave's outline as closely as
possible), 

     3. A wide range of independently-developed mail-composing
and sending software will treat a dotless hostname as an alias
or partial name and apply completion or other local rules to it.
Depending on the client and configurations or other
circumstances, those rules may either be part of a DNS searching
process or more locally determined (e.g., looked up in an
outbound alias table).

I think the correct statement would be that, independent of what
different versions of the SMTP spec say, or appear to say,
common and perfectly reasonable local practices at both the
sending and receiving ends make the interpretation of dotless
domain-parts sufficiently unpredictable that depending on them
to work is unwise and might easily cause security and/or
stability problems.

  best,
     --john

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2013 02:10:38 -0000

>handling barrier to SMTP, which has no such barrier.

Surprisingly, the report is sort of right.  The ABNF in RFC 2821
prohibits dotless domains, although the ABNF in 821 and 5321 allows
them.  This was arguably a mistake in 2821 (it doesn't match the text)
but it says what it says.

>justifies this is 'localhost'.

No argument there.  And a wide range of mail sending software treats a
dotless domain as a special case, appending search paths and otherwise
modifying it, so sending mail to an address at a dotless domain is an
exercise in flakiness.

There are 19 ccTLDs that have MX records at the top level.  I wonder
if anyone has checked how well mail to them works.  I am particularly
intruigued that Guatemala's and Trinidad's is outsourced to Google.

answer: ai 14391 MX 10 mail.offshore.ai
answer: ax 86392 MX 5 mail.aland.net
answer: cd 86400 MX 5 mail.nic.cd
answer: cf 10800 MX 0 mail.intnet.cf
answer: dm 86400 MX 10 mail.nic.dm
answer: gp 86400 MX 10 ns1.worldsatelliteservices.com
answer: gp 86400 MX 5 ns1.nic.gp
answer: gt 86400 MX 20 alt1.aspmx.l.google.com
answer: gt 86400 MX 20 alt2.aspmx.l.google.com
answer: gt 86400 MX 30 aspmx2.googlemail.com
answer: gt 86400 MX 30 aspmx3.googlemail.com
answer: gt 86400 MX 30 aspmx4.googlemail.com
answer: gt 86400 MX 30 aspmx5.googlemail.com
answer: gt 86400 MX 10 aspmx.l.google.com
answer: hr 14400 MX 5 alpha.carnet.hr
answer: io 604800 MX 10 mailer2.io
answer: kh 10800 MX 10 ns1.dns.net.kh
answer: km 3600 MX 100 mail1.comorestelecom.km
answer: lk 86400 MX 10 malithi-slt.nic.lk
answer: lk 86400 MX 20 malithi-lc.nic.lk
answer: mh 86400 MX 10 imap.pwke.twtelecom.net
answer: mq 86400 MX 10 mx1-mq.mediaserv.net
answer: pa 21600 MX 5 ns.pa
answer: tt 86400 MX 1 aspmx.l.google.com
answer: tt 86400 MX 10 alt1.aspmx.l.google.com
answer: ua 72072 MX 10 mr.kolo.net
answer: va 3600 MX 100 raphaelmx3.posta.va
answer: va 3600 MX 10 raphaelmx1.posta.va
answer: va 3600 MX 10 raphaelmx2.posta.va
answer: ws 21600 MX 10 mail.worldsite.ws

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Jul 2013 12:28:29 +1000

> answer: ws 21600 MX 10 mail.worldsite.ws

Which just shows 19 tld administrators that don't have clue.   One
can add MX records at any node in the DNS inluding at the root.
That doesn't mean that it is sensible to add them or that they will
work reliably.

e.g.
     . MX 0 some.domain.example.com.
     _http._tcp.example.org. MX 0 some.domain.example.com.

As for SMTP supporting dotless domains of course it does, it was
designed when there was a single flat namespace.  We got rid of
that flat namespace for good reasons which have not gone away.

Mark

> R's,
> John
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2013 02:40:10 -0000

>That doesn't mean that it is sensible to add them or that they will

I thought my point was totally obvious but perhaps not.  Should anyone
want concrete data about the flakiness of dotless domain mail rather
than just assertions, we have 19 domains who presumably have some
experience with it.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Jul 2013 20:11:12 -0700

On 7/5/2013 7:28 PM, Mark Andrews wrote:
> designed when there was a single flat namespace.

Actually, SMTP and RFC 822 and the DNS specs were all issued is 
close-sequence, in 1982.  Those email specs had domain names built in.

Perhaps you are thinking of the FTP MAIL and MLFL commands and RFC 733, 
used during the 1970s, when the hostname space was indeed flat.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Jul 2013 20:15:50 -0700

> Here's my summary of the situation:

The purpose of a summary is to summarize.  Folks seem to think that a 
summary is supposed to be fully-detailed about history.

My conflating smtp with rfc822/5322 and ignoring rfc2822 was 
intentional.  On the average, the world's pseudo-technical reference to 
email is "smtp"; hence my usage of it in the summary.

Again, as a statement about current email standards, the report is 
wrong.  In terms of current utility of dotless domains, some significant 
number email software implementations will not handle it properly.  None 
of the descriptions of that software attributed the issue to the 
specifications, instead citing protection against errors or other 
misbehavior.

d/

---

From: Russ Allbery <[email-masked]>
Date: Sat, 06 Jul 2013 20:46:19 -0700

Mark Andrews <[email-masked]> writes:

> Which just shows 19 tld administrators that don't have clue.  One can
> add MX records at any node in the DNS inluding at the root.  That
> doesn't mean that it is sensible to add them or that they will work
> reliably.

That they've added an MX rcord doesn't mean that they don't understand the
problems, or that they even expect to receive mail there.  It's the kind
of thing that, were I in the position to do, I probably would do just for
the hell of it, and because it's a sort of SMTP party trick.

It doesn't hurt anything to have the MX record.  Given how mail is
processed, it will mostly just be ignored.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 07 Jul 2013 23:17:56 +0100

> ad-hoc LAN, possibly disconnected from the rest of the Internet.

Yes, exactly.  I do think it has potential uses, even for a client that is otherwise unconfigured to send email across the public Internet.  Of course, the parallel question of how to send mail across the public Internet without configuration is also interesting, but I imagine some anti-anti-abusers would not like that thought much :-) .

> rocking the boat with mDNS?

I don't really understand the indifference.  Well, actually, I don't really understand the entire discussion, to be honest.  (But also, I'm late to it, sorry. :-) )  My Sendmail site set up in 2005 handles dotless domains by design; all the domain search resolver magic is turned off.  Why would anybody be set against that?  RFC 2821 language said I was supposed to expect dotless domains (the text, anyway) so I did.  It's also consistent with the use of full email addresses.  While I agree that advising people to depend on it would be a bad idea, it's something that can be easily solved in code.  I also don't see why a name is any less significant for being a global one rather than a local one, although I suppose that giving all that glory to the root isn't always desirable either.  Still, people should, as per spec, not be surprised when unpredictable things happen if you use unqualified domain names, in either case.

As for mDNS, what's the trouble there?  It should work just fine.  Won't be very secure, of course, but anyone in the local namespace should be able to set up MX and address records to send mail wherever they'd like, at whatever priority.  It can be, at least in theory, the apex or any name underneath, and if you have a resolver that knows to match "local" to mDNS, i.e. in practice all of them, you just replace managing zone files with responding to the right multicast messages, basically.  For convenience, you put "local" in the domain search list, and so it goes.  (On OS X, this is actually implemented rather better than glibc with the nss module, since the same process is responsible for both DNS and mDNS, so searching actually works.)

Cheers,
Sabahattin

---

From: [email-masked]
Date: Sun, 07 Jul 2013 20:56:26 -0400

On Sun, 07 Jul 2013 23:17:56 +0100, Sabahattin Gucukoglu said:

> RFC 2821 language said I was supposed to expect dotless domains (the text,
> anyway) so I did.  It's also consistent with the use of full email addresses.
> While I agree that advising people to depend on it would be a bad idea, it's
> something that can be easily solved in code.

It's hardly as "easy" as you might think.  Sure, fixing the next release of
MTAs to support dotless domains is maybe 15 minutes work per MTA.

The pain is:

1) Sites that haven't upgraded their MTAs yet.  I have a fairly high-volume
Listserv box still running RHEL 4.0 running Sendmail 8.13.1 - and it will
keep running that until I finally get a chance to upgrade it sometime in
the next few months.  And that's me.  How long will it take for the sites
that *can't* spell Sendmail or Postfix to upgrade?

2) The ever-dreaded "local alias" problem.  Until you've gone thorugh *every*
corporate and organization network and fixed every single user's address
book so it doesn't say 'fred@locus' but upgrade it to [email-masked]',
and then fix their MUA to prevent the user from savin a local alias again,
you won't be able to really reliably use '@locus' as a dotless destination.

And the speed things get upgraded can be glacial.  Non-SMTP examples follow:

1) IPv6 is now available at something like 60% of colos and a good chunk of
the 800 pound gorillas in the Alexa 1000.  And yet, IPv6 traffic is still only
running 1-2% of total, simply because in a very high percentage of cases,
it won't work until the user finally replaces their CPE wireless router.

2) How many boxes out there are *still* on XP?

3) I recently did some monitoring of an IP address we used to have an NTP
server on.  Over the course of an hour or so, I collected well over 300
unique IP addresses that still thought there was an NTP server at that
address.  The interesting thing is that the hardware was shut down in 2002
(and the NTP server itself quite possibly in 2001, I'd have to check).  So
literally a dozen years later, there were *still* hundreds of boxes in service
that had 12 year old configs.

So I'm pretty convinced it's not at all "just a small matter of code". At
best, it's "a small matter of code now to make it perhaps workable in 2025
or so".

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Jul 2013 12:53:54 +1000

> processed, it will mostly just be ignored.

But it does hurt as it gives people that don't know any better a
expectation that it will work.  A lot of this debate is a direct
result of tld administrators playing silly games by adding MX
records.
 
Mark

---

From: Russ Allbery <[email-masked]>
Date: Sun, 07 Jul 2013 19:59:19 -0700

Mark Andrews <[email-masked]> writes:
> Russ Allbery writes:

>> That they've added an MX rcord doesn't mean that they don't understand
>> the problems, or that they even expect to receive mail there.  It's the
>> kind of thing that, were I in the position to do, I probably would do
>> just for the hell of it, and because it's a sort of SMTP party trick.

> expectation that it will work.

Does anyone who doesn't know better even know that these MX records exist?
The only reason why I knew about them were from similar threads in mailing
lists like this among people who do indeed know how mail works.  I've
never seen them advertised to users broadly, or used in published email
addresses.

> A lot of this debate is a direct result of tld administrators playing
> silly games by adding MX records.

I think the debate is just because it's a weird corner case, and this
group isn't particularly active with important business these days but is
still full of people who like talking about the details of mail
implementation, particularly weird corner cases.  In other words, it's
more general entertainment than anything that has much practical impact on
the day-to-day functioning of Internet mail.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Jul 2013 14:54:05 +1000

> best, it's "a small matter of code now to make it perhaps workable in 2025
 
And even after you fix the MTAs and the MUAs you also have to stop
"ssh/telnet/<choose your app> <label>" working or suddenly "mail
user@label" and "ssh label" end up at different machines.  This
is about providing constistent naming across everything.

Mark

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jul 2013 23:54:33 -0700 (PDT)

> is about providing constistent naming across everything.

And this assumes that there's sufficient incentive to actually bother
"fixing" anything. Seems to me this is another case of something that's
quite common in the email world: An asymmetry between who bears the costs
and who accrues the benefits.

The cost of abandoning shortform names in a large deployment is likely to be
considerable, especially if they are what users are used to. And while the
benefits to the people operating the TLDs may be real, the benefits to the
large deployment are ... what exactly? The ability to send to a handful of
addresses nobody is likely to care about?

Heck, even in the unlikely event there's sufficient cause to send mail to one
of these TLDs, it's almost certainly going to be easier to add special routing
for it and ignore the general problem. 

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 8 Jul 2013 09:40:17 +0200

Then call customer service at... wherever really and tell them your new email address. "I'm sorry, our database won't accept that address, do you have another?"

Arnt

---

From: Paul Smith <[email-masked]>
Date: Mon, 08 Jul 2013 08:46:57 +0100

On 08/07/2013 03:53, Mark Andrews wrote:
> expectation that it will work. A lot of this debate is a direct result 
> of tld administrators playing silly games by adding MX records. Mark
How do 'people that don't know any better' have an expectation that it 
will work?

If the ccTLD registries were publishing a 'support@cctld' type email 
address on their website, then it would, but I haven't heard anyone say 
that that has happened. For instance there's an MX record for 'cd', but 
their website uses [email-masked]', which will work fine, not 
support@cd, which may or may not work.

It's only uber-geeks that will even know that the MX record for 'cd' 
exists, and most of those will know that that's a bit weird, and may try 
sending mail to postmaster@cd 'just to see what happens', but they won't 
complain if it doesn't work, because that email address isn't published 
anywhere.

I'm with Russ on this that it seems like a discussion "about nothing".

Is anyone 'in the real world' complaining that support@cd doesn't always 
work? If so, why are they trying to send mail to that address?

I have no problem with the discussion, but it's not exactly 
earth-shattering...

My 'vote' would be to put a note somewhere just to say that email to 
dotless domains may or may not work, so it's not recommended to use 
them. I doubt anyone really cares more than that. A ccTLD registry isn't 
exactly going to complain that they have to register 'nic.cctld' since 
they are just registering it with themselves, and I'm sure if they 
thought it was an issue, it would have come up before now.

The other use case would be within a company, using '@local' or 
'@mycompany' - and that has neatly excluded interoperability, since it's 
just within a single company, so that's a matter between that company 
and their mail server provider.

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Jul 2013 10:15:46 +0200

On Mon 08/Jul/2013 00:17:56 +0200 Sabahattin Gucukoglu wrote:
> 
> As for mDNS, what's the trouble there?  It should work just fine.
> Won't be very secure, of course, but anyone in the local namespace
> should be able to set up MX and address records to send mail wherever
> they'd like, at whatever priority.  It can be, at least in theory,
> the apex or any name underneath, and if you have a resolver that
> knows to match "local" to mDNS, i.e. in practice all of them, you
> just replace managing zone files with responding to the right
> multicast messages, basically.  For convenience, you put "local" in
> the domain search list, and so it goes.  (On OS X, this is actually
> implemented rather better than glibc with the nss module, since the
> same process is responsible for both DNS and mDNS, so searching
> actually works.)

I don't think everything can be solved by just tinkering with resolvers.

Let me try an example:  Suppose I send to Sabahattin@local --presumably
because I can see you, or equivalent local evidence.  Every local box
having an MTA should reply to my query for a local MX.  An MTA with a
hight priority MX will rply "550 user not local" to my RCPT.  In that
case, a unicast relay must give up, while a multicast MTA had better
behave differently, and possibly keep on querying as it tries each MX in
turn, because that's what the nature of mDNS looks like.

Yes, that would require lots of little changes.  The question is if it
can entice people to upgrade their mail software at the same pace that
they upgrade their browsers and web servers.

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Jul 2013 09:21:20 +0100

Sabahattin Gucukoglu <[email-masked]> wrote:
>
> As for mDNS, what's the trouble there?

How do you know who is going to receive mail when you send to
[email-masked]?

Your MUA is likely to send the mail to your submission server which is
likely to be halfway round the world and have no idea that there is a
Fred with a MacBook that you can see in your network browser.

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: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 08 Jul 2013 09:51:59 +0100

> turn, because that's what the nature of mDNS looks like.

I think that would be against the whole mDNS ethos of having every node take complete responsibility for its own little chunk of the namespace.  You'd really want to write to [email-masked], which of course defeats the useful purpose of decoupling the mailbox from the host.  Because, otherwise one of my machines will have to assume responsibility for the whole subnet, in which case … and so on, and so on, and so forth. :-)  Of course, with this strategy all the burden of implementation is moved to the receiver, which is nice.  I could register a response for sabahattin.local with an MX for all my computers, and now I just have to make sure that the computers organise amongst themselves which is going to go bing when I receive the mail (or just turn the others off).

> they upgrade their browsers and web servers.

Probably not, at least not now.  The only reason to suggest it is in realising some gleaming future in which every node is autonomous.  Clearly, user expectations aren't there yet.

But then again, writing to sales@amazon or support@apple probably isn't in the public conscience at the moment either.  ICANN wants to know what the implications are for the TLDs; the answer is "The IETF disclaims all responsibility for wrongdoing as usual, but wishes to point out that it won't work anyway". :-)

Cheers,
Sabahattin

---

From: "John Levine" <[email-masked]>
Date: 8 Jul 2013 15:57:55 -0000

>lists like this among people who do indeed know how mail works.

I knew about n@ai (still likely to be the shortest e-mail address of
all time) from chatter about the Financial Cryptography conference.
The others I know about because I was supposed to be doing something
on deadline so instead I wrote a tiny shell script that looked up MX
records for all of the TLDs.

I don't know anyone who actually uses a TLD mail address.  Mr. n@ai is
Ian Goldberg who has a normal cs.uwaterloo.ca address.

My point about MX records at TLDs is not that they're useful, but that
since they exist, we could get some actual data about how badly they
work rather than doing what we've been doing so far, making assertions
based on plausible but unsupported hunches.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Jul 2013 14:31:30 -0400

--On Sunday, July 07, 2013 19:59 -0700 Russ Allbery
<[email-masked]> wrote:

>...
> I think the debate is just because it's a weird corner case,
> and this group isn't particularly active with important
> business these days but is still full of people who like
> talking about the details of mail implementation, particularly
> weird corner cases.  In other words, it's more general
> entertainment than anything that has much practical impact on

Russ,

I think this is at least partially true.  The other part is that
a fairly large number of entities are spending a very large
amount of money trying to obtain new gTLDs.  Many of those
entities have ideas and consequent expectations about how usable
those TLD are going to be and for what.  If the reality doesn't
match those expectations,  I think it is reasonable to assume
that there is likely to be a good deal of recrimination and
finger-pointing.  That might be followed up by litigation and
other sorts of unpleasantness.  

That unpleasantness might be directed elsewhere, or at least
easier to take, it we are all on the same page about what the
issues are and why.  It might be largely avoided if ICANN (or
others) can successfully get people to understand what to expect
before significant resources are committed to ideas that won't
work well.  It might be too late for that already, but it is
still possible to try.

best,
   john

---

From: Russ Allbery <[email-masked]>
Date: Mon, 08 Jul 2013 11:36:37 -0700

John C Klensin <[email-masked]> writes:

> I think this is at least partially true.  The other part is that a
> fairly large number of entities are spending a very large amount of
> money trying to obtain new gTLDs.  Many of those entities have ideas and
> consequent expectations about how usable those TLD are going to be and
> for what.  If the reality doesn't match those expectations, I think it
> is reasonable to assume that there is likely to be a good deal of
> recrimination and finger-pointing.  That might be followed up by
> litigation and other sorts of unpleasantness.

Good point.

I try to avoid thinking about the new gTLDs as much as possible, since
they just make me disgusted and nauseated.  So I missed that this means a
bunch of new top-level domains run by people who may not realize what
works and what doesn't work with such domains.

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Mon, 08 Jul 2013 12:00:54 -0700

> works and what doesn't work with such domains.

Actually, the question that started this whole thread was around ICANN's 
"SSAC Report on Dotless Domains"  that stated dotless domains are not 
allowed in SMTP. Dave Crocker was just wondering if anyone knew what was 
the standards basis for ICANN's statement (since RFC 5321 allows them).

In other words, it appears ICANN is saying what we'd want them to say.

<csg>

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Mon, 8 Jul 2013 15:31:06 -0400

At 20:56 -0400 on 07/07/2013, [email-masked] wrote about Re: 

>you won't be able to really reliably use '@locus' as a dotless destination.

I see two separate but related issues here.

Will the MUA append domain to any address which is Dotless (ie: 
User@Host) and/or one that is User Only (ie:@-Less)? So long as it 
does there is no need to force FQDN addresses since the FQDN address 
will be created by the MUA before it hands the message off to the MSA 
Server.

The second issue is that we are talking about the address supplied to 
the MUA needing to be compliant with the RFC821/2821/5821 rules when 
this address is not necessarily what will be submitted to the MSA due 
to the domain appending code referenced above. IOW: If I create a 
message addressed to fred@locus is the address that is supplied to 
the MSA (and in the TO Header) fred@locus or [email-masked]?

---

From: "John Levine" <[email-masked]>
Date: 8 Jul 2013 20:05:32 -0000

>those TLD are going to be and for what. ...

The applicant guidebook for new gTLDs says quite clearly that the only
things you can put in your TLD zone file are SOA, NS, DS, in-bailiwick
glue, and associated DNSSEC records.  If you want to put anything else
in your zone file, you need to ask ICANN's permission in advance.
(See pages 2-25 and 2-26 of the applicant guidebook.)

The reason this has come up now is that Google applied for .SEARCH as
a single registrant domain, and upon learning that there would be
major political headwinds, modified it to one where other search
providers could register and there would be something at
http://search/ or https://search/ that redirects you to your favorite
search provider, presumably remembered in a cookie.

You can read about it here, the (v2) link, section 23.10:

https://gtldresult.icann.org/application-result/applicationstatus/applicationchangehistory/1319

You don't have to tell me all the policy reasons that it might not be
a great idea to give Google a preview of everyone else's search
traffic, but there's nothing in the guidebook about that.  The
guidebook does say no A or AAAA records for the TLD, so Google is
asking for an exception.

ICANN being ICANN, and clearly aware that Google has an unlimited
supply of lawyers, has been going around asking people are you *SURE*
that it's a bad idea to put A and AAAA records at the TLD?  An
entirely reasonable response is, yes, nothing has changed, we're still
sure it's a bad idea.

But, of course, actual data would be nice, too.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Jul 2013 13:34:43 -0700 (PDT)

> will be created by the MUA before it hands the message off to the MSA

Very unlikely. Most MUAs just blort out whatever the user entered and/or
whatever they scarfed off a header line with little if any syntax checking. In
fact I recently ran into an MUA that was sending things like:

     RCPT TO:<list: ;>

And getting upset when it didn't work. (And then retrying over and over,
presumably on the theory that if you ask the question often enough maybe you'll
get a different answer.)

> the MSA (and in the TO Header) fred@locus or [email-masked]?

Actually we're talking about real world behavior. It would be nice
if there was a perceived need to be compliant, but I for one am not seeing it.

				Ned

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Mon, 08 Jul 2013 14:29:26 -0700

FWIW

The "compose" dialogs on Microsoft Outlook 2010, Yahoo! Mail, Live.com, 
and Gmail do not allow dotless domains. Yahoo and Live.com reject the 
address as malformed; Outlook tries to look it up in the local address 
book; Gmail gives an error on send.

Thunderbird 2.0 to my employer's Exchange server (over SMTP) worked fine 
-- and then the message got rejected by the corporate firewall as 
"invalid domain."

<csg>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 9 Jul 2013 00:06:14 +0200

One out nine isn't bad;)

Arnt

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Jul 2013 18:12:59 -0400

--On Monday, July 08, 2013 11:36 -0700 Russ Allbery
<[email-masked]> wrote:

>> I think this is at least partially true.  The other part is
>> that a fairly large number of entities are spending a very
>> large amount of money trying to obtain new gTLDs.  Many of
>> those entities have ideas and consequent expectations about
>> how usable those TLD are going to be and for what.  If the
>> reality doesn't match those expectations, I think it is
>> reasonable to assume that there is likely to be a good deal of
>> recrimination and finger-pointing.  That might be followed up
>> by litigation and other sorts of unpleasantness.
> 
> Good point.
> 
> I try to avoid thinking about the new gTLDs as much as
> possible, since they just make me disgusted and nauseated.  So
> I missed that this means a bunch of new top-level domains run
> by people who may not realize what works and what doesn't work
> with such domains.

Yeah.  John Levine's note is relevant here too -- I didn't want
to go into that much detail and the note makes it clear that he
has been following things more closely than I have -- but email
addresses are certainly not the only issue or the only things
that work differently or are restricted in ways that those
applying for those domains may not have fully appreciated
(whether they should have been able to figure that out from the
Applicant Guidebook or not).

As to disgust and nausea, you might have ample reason to feel
that way but I couldn't possibly comment.

best,
    john

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Jul 2013 15:31:58 -0700

> entirely reasonable response is, yes, nothing has changed, we're still

Seems to work fine for http://ac/ and http://dk/ amongst others.

> But, of course, actual data would be nice, too.

Of 317 current TLDs, 19 have MX records[1].

Of those 19, only 5 accept email to postmaster@tld. (ai, ax, km, tt, ua).

The remaining 14 either aren't listening on port 25, aren't configured to
handle that domain or, in one case, "Recipient address
rejected: need fully-qualified address".

I didn't bother checking for fallback to A.

Cheers,
  Steve

[1] http://privatepaste.com/8e191ef714

---

From: Mark Andrews <[email-masked]>
Date: Tue, 9 Jul 2013 08:43:17 +1000

Just because it worked for you, it doesn't mean it will work for everyone. Working or not depends on the clients search list and hostnames that resolve using that search list. 

This is not a fixable problem.  It can NEVER be made to work reliable as people want to be able to use short names and just because you have several thousand dollars to buy a TLD it doesn't give you the right to steal the short name from others. 

Mark

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Jul 2013 15:51:43 -0700

> Just because it worked for you, it doesn't mean it will work for everyone. Working or not depends on the clients search list and hostnames that resolve using that search list. 

That it didn't work (at all) for 14 out of 19 TLDs who have explicitly published an MX record is relevant data. That it works just fine (with a non-broken SMTP client) for the other five is somewhat interesting too (.ai was the only one I knew about before I checked).

There are five entities who are running apparently working mailservers at the TLD level; they seem likely to have more experience with, and actual data about, this issue than anyone here.

Cheers,
  Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 08 Jul 2013 16:06:23 -0700

On 7/8/2013 12:00 PM, Carl S. Gutekunst wrote:
> Dave Crocker was just wondering if anyone knew what was the standards
> basis for ICANN's statement (since RFC 5321 allows them).
>

Not really.

In terms of the conclusion, "dotless domains won't work over the open 
Internet", yes that's correct.

In terms of the technical explanation that is provided, they are wrong. 
  They attribute it to SMTP.  Whether they mean the specific protocol or 
the collection of email specifications, they are wrong.

If they meant to include "implementation issues", I think they are being 
overly broad in language, for a body of technical experts.

And SSAC really is a body of technical experts.  So I expect technical 
rigor, for whatever level of granularity the choose to assert, shy of 
"anything that has anything to do with email on the Internet."  So when 
they say SMTP, they ought to mean the specific protocol, or the 
collection of email protocol specifications.

They should not mean "whatever pragmatic operational cruft the real 
world happens to have chosen to add to the email protocols, 
/sometimes/."  That last is what's actually going on.

And while that cruft is understandable and justifiable, it is still 
outside any documented standards.

d/

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Mon, 08 Jul 2013 16:17:11 -0700

> In terms of the technical explanation that is provided, they are 
> wrong. They attribute it to SMTP. Whether they mean the specific 
> protocol or the collection of email specifications, they are wrong.

And the impression I get is that ICANN is attempting to fight a 
political battle on technical grounds? If that's the case, then making 
incorrect or indefensible technical statements is going to sink them.

<csg>

---

From: Russ Allbery <[email-masked]>
Date: Mon, 08 Jul 2013 16:32:47 -0700

Mark Andrews <[email-masked]> writes:

> This is not a fixable problem.  It can NEVER be made to work reliable as
> people want to be able to use short names and just because you have
> several thousand dollars to buy a TLD it doesn't give you the right to
> steal the short name from others.

+1

---

From: Dave Crocker <[email-masked]>
Date: Mon, 08 Jul 2013 16:36:13 -0700

> incorrect or indefensible technical statements is going to sink them.

SSAC is not a political entity.  It provides expert technical opinion. 
It is my understanding over the years that it has been careful to remain 
detached from the politics and, instead, to focus on technical issues.

In practical terms, the point I'm complaining about is a nuance.  I'm 
"irritated" rather than pissed off.  At worst, some feet might get 
moist; the boat won't sink.

d/

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2013 00:14:06 -0000

>Seems to work fine for http://ac/ and http://dk/ amongst others.

I suspect you don't have hosts on your LAN (or in whatever domain your DHCP server sets as
your resolver default) called ac and dk.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 8 Jul 2013 17:17:26 -0700

> your resolver default) called ac and dk.

Well, of course not. All *my* hosts have fully qualified hostnames. :)

Cheers,
  Steve

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2013 01:06:21 -0000

>Well, of course not. All *my* hosts have fully qualified hostnames. :)

So do mine, but since my DHCP setup installs a default domain
(.iecc.com on my server, and .lan on my home mostly-NAT LAN), I can
type http://router/ on this PC and it will find the router whose name
is router.lan.*

Failures and confusions with dotless domains are more likely to be due
to helpful completions by DNS libraries that have been around for 30
years as to warts of MUAs or MTAs.

So although Dave is right that SAC 053 screwed up the discussion of
SMTP, there are worse problems that I think it got right.

R's,
John

* - I have my own DNS cache with a highly customized configuration.
Imagine that I'm a tiny corporate LAN.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Jul 2013 11:16:53 +1000

> > incorrect or indefensible technical statements is going to sink them.

What is technically incorrect about merging two namespaces will cause
operational problems for some people?  RFC 1535 is all about unexpected
consequences of a entered name reaching the wrong destination. Merging
multiple syntactically identical namespaces will result in the sorts of
problems reported in RFC 1535 for some people.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 09 Jul 2013 03:37:22 +0100

On 8 Jul 2013, at 22:29, Carl S. Gutekunst <[email-masked]> wrote:
> FWIW
> 
> The "compose" dialogs on Microsoft Outlook 2010, Yahoo! Mail, Live.com, and Gmail do not allow dotless domains. Yahoo and Live.com reject the address as malformed; Outlook tries to look it up in the local address book; Gmail gives an error on send.
> 
> Thunderbird 2.0 to my employer's Exchange server (over SMTP) worked fine -- and then the message got rejected by the corporate firewall as "invalid domain."

Yeah.  Over in Mac land, no warning on dotless domain, but iCloud's Oracle servers then tried to qualify the domains and hence failed.  The username-only form "foo" just puts up a "This looks wrong, continue anyway?" type dialog.  Continue and the SMTP server gets it as is.

On iOS (iPhone, iPad, iPod Touch) the "This looks invalid, send anyway?" dialog comes up in both the bare user and dotless domain cases.

In Postfix, both append_dot_mydomain and append_at_myorigin are both set Yes by default.  So both cases are taken care of.

So yeah, stiff resistance from the front lines.

Cheers,
Sabahattin

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Jul 2013 22:26:16 -0700 (PDT)

> Yeah.  Over in Mac land, no warning on dotless domain, but iCloud's Oracle
> servers then tried to qualify the domains and hence failed.

FWIW, this is entirely configurable. If you want dotless domains to
be treated as bare gTLDs you can get that, if you want them qualified
with your local domain you can get that. You can also have only
valid gTLDs treated as bare gTLDs, the rest handled some other way.

I haven't paid much attention to what cutomers elect to do in this regard
so I have no clear idea of what overall preferences in the field look like.

				Ned

---

From: Paul Smith <[email-masked]>
Date: Tue, 9 Jul 2013 07:16:17 +0100

> valid gTLDs treated as bare gTLDs, the rest handled some other way.

It may be configurable on an individual level, but if Google, Apple or whoever want to be able to publish "sales@apple" type addresses, they've got no chance. It just wouldn't work for billions of people. They'd have to say "just email us on sales@apple and if that doesn't work go reconfigure your mail server, change ISP, reconfigure your dns server, upgrade your infrastructure, change the way you access local resources, etc"

They just need to accept that it won't work, and CAN'T be made to work for everyone at a global level.
-

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Tue, 09 Jul 2013 10:07:03 -0700

> problems reported in RFC 1535 for some people.

Mark, I don't understand what you're asking. All I'm saying is that if 
ICANN is relying on technical arguments to push back against pressure 
from corporate entities to loosen their restrictions on dotless domains, 
then it weakens their position when their technical arguments are 
incorrect. (And claiming that SMTP forbids dotless domains is incorrect.)

<csg>

---

From: [email-masked]
Date: Tue, 09 Jul 2013 16:56:20 -0400

On Mon, 08 Jul 2013 15:51:43 -0700, Steve Atkins said:
> That it didn't work (at all) for 14 out of 19 TLDs who have explicitly
> published an MX record is relevant data.

The fact that 2/3 of TLDs that list an MX are publishing broken data is a
possibly relevant point as well.  That certainly speaks to ICANN's
"requirement" that only certain record types will be permitted - it certainly
looks like there's a high probability that (a) the new TLDs will publish
violating RR types and (b) won't bother checking that they're even "right".

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2013 23:13:22 -0000

>violating RR types and (b) won't bother checking that they're even "right".

a) No

b) No

All of the existing TLD MX records are in ccTLDs, over which, as I
assume you are aware, ICANN has no control at all.  The new TLDs
have a long complicated contract, and a verification process.  I
know the guy managing the verification, and I can assure you that
if there are funky MX records, they'll notice them.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2013 09:14:57 +1000

> incorrect. (And claiming that SMTP forbids dotless domains is incorrect.)

Its more about picking the right technical argument.   I agree that
SMTP doesn't preclude unqualified/simple names.

Mark

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jul 2013 13:36:01 -0700

Folks,

The IAB just issued a 'statement' on the topic:"

    IAB Statement: Dotless Domains Considered Harmful
 
http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

It only discusses DNS-related standards that make dotless domains 
problematic.

It might help the case against dotless domains to also record the 
email-related implementation problems that have been cited on this thread.

d/

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Jul 2013 17:04:46 -0400

--On Wednesday, July 10, 2013 13:36 -0700 Dave Crocker
<[email-masked]> wrote:

>  http://www.iab.org/documents/correspondence-reports-documents
> /2013-2/iab-statement-dotless-domains-considered-harmful/
> 
> It only discusses DNS-related standards that make dotless
> domains problematic.
> 
> It might help the case against dotless domains to also record
> the email-related implementation problems that have been cited
> on this thread.

Yes.  But, for whatever reason, it apparently didn't occur to
the IAB to either figure that out or to expose a draft of that
document or the fact that they were working on such a thing to
the community, presumably eliciting comments about the various
applications that are also affected by the topic.  If anyone
finds that disturbing, I believe the key phrase is "tell it to
the Nomcom".

:-(

   john

---

From: hector <[email-masked]>
Date: Wed, 10 Jul 2013 18:31:48 -0400

On 7/8/2013 5:29 PM, Carl S. Gutekunst wrote:
> FWIW
>
> The "compose" dialogs on Microsoft Outlook 2010, Yahoo! Mail, 
> Live.com, and Gmail do not allow dotless domains. Yahoo and Live.com 
> reject the address as malformed; Outlook tries to look it up in the 
> local address book; Gmail gives an error on send.
>
> Thunderbird 2.0 to my employer's Exchange server (over SMTP) worked 
> fine -- and then the message got rejected by the corporate firewall as 
> "invalid domain."
>
> <csg>

The only real place I have seen dotless domains is with dealing with 
NETBIOS computer names and the EHLO/HELO field.

Outlook will use the local computer NETBIOS name IFF a FQDN is not found 
in DNS for the EHLO/HELO field.    This all goes back to ARP and the 
mapping with WINS.   Outlook-based end users with NATs do not have 
problems because SMTP, although technically required to be a valid 
EHLO/HELO domain, historically, the EHLO/HELO can be a misconfiguration 
hence when its a DOTLESS field entry no validation is possible.

OTOH, Tbird will use a domain IP literal  and the IP can be wrong when 
the private IP is used.   This is a strong rule that can be used to 
validate the connected IP with the machine IP, but TBIRD and others 
behind a NAT local LAN need to be also configured to use the NAT IP or 
the public FQDN domain, if any.    The only place I seen a problem here 
is with the SUBMIT protocol which requires a valid EHLO field.   It 
needs to be relax.  In our port 587 connectivity implementation the EHLO 
field validation is skipped because ESMTP AUTH is required anyway for 
SUBMIT.

Part of the problem is what SOCKET API is used.  Under Windows,  if you 
use the Windows SOCKET API, you can get the NETBIOS name when a IP 
lookup is made.    We had to change and force across the board DNS 
record API lookup usage and avoid the Windows Socket API commands as 
much as possible.

Dotless Domains are only valid within a LAN or internal WAN, but not 
across the public internet.   That's really the only conclusion I can 
see here.  Perhaps whats going on is that Microsoft can turn off the 
NETBIOS protocol by default in the OS being install and this causes 
lookup problems when the machine is not fully qualify possible.

--
HLS

---

From: SM <[email-masked]>
Date: Wed, 10 Jul 2013 22:32:29 -0700

Hi Dave,
At 13:36 10-07-2013, Dave Crocker wrote:
>It only discusses DNS-related standards that make dotless domains problematic.
>

Thanks for the heads-up.  In my opinion, one of the problems with the 
"statement" is that it is, as you mentioned above, only a discussion 
about the DNS-related standards.  I don't know whether the statement 
considered the recommendations in SSAC report SAC053.  One of the 
arguments made in favor dotless domains is that it "provides 
potential innovations to the domain name industry and new gTLD 
applicants".  All this is driven by the "web" at the expense of other 
application protocols.  I guess that it is worth a try to record the 
email-related implementation problems.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jul 2013 22:46:13 -0700

On 7/10/2013 10:32 PM, SM wrote:
> considered the recommendations in SSAC report SAC053.

I got a private note that said at least one member of the IAB was aware 
of some of the email issues, but felt that focusing purely on the DNS 
lookup issue was best.

Given that these sorts of Statements are a) political, and b) single 
occurrence -- there won't be a serious of bite-sized Statements issued 
-- I'd think it makes more sense to have the document mount every 
applicable engineering, operations and standards concern it can 
document, rather than try to be surgical.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Jul 2013 09:47:53 -0400

--On Wednesday, July 10, 2013 22:46 -0700 Dave Crocker
<[email-masked]> wrote:
 
> I got a private note that said at least one member of the IAB
> was aware of some of the email issues, but felt that focusing
> purely on the DNS lookup issue was best.
> 
> Given that these sorts of Statements are a) political, and b)
> single occurrence -- there won't be a serious of bite-sized
> Statements issued -- I'd think it makes more sense to have the
> document mount every applicable engineering, operations and
> standards concern it can document, rather than try to be
> surgical.

FWIW, I strongly agree to the point of considering this serious
bad judgment on the IAB's part (and making that decision without
any opportunity for community input even worse).

   john

---

From: SM <[email-masked]>
Date: Thu, 11 Jul 2013 15:44:45 -0700

Hi Dave,
At 22:46 10-07-2013, Dave Crocker wrote:
>I got a private note that said at least one member of the IAB was 
>aware of some of the email issues, but felt that focusing purely on 
>the DNS lookup issue was best.
>
>occurrence -- there won't be a serious of bite-sized Statements 
>issued -- I'd think it makes more sense to have the document mount 
>every applicable engineering, operations and standards concern it 
>can document, rather than try to be surgical.

Yes.

I'll quote part of one of your messages [1] out of context:

>As with all security risks, the requirement is to anticipate them 
>and protect against them, rather than wait to fix things afterwards...

Yes.

People have already disputed SAC 053 on the grounds that it doesn't 
provide sufficient arguments against dotless domains.

Regards,
-sm

1. msg-id: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sat, 13 Jul 2013 08:57:40 -0400

On 07/11/2013 09:47 AM, John C Klensin wrote:
> FWIW, I strongly agree to the point of considering this serious bad 
> judgment on the IAB's part (and making that decision without any 
> opportunity for community input even worse).
It occurs to me that the fact that the IAB didn't solicit public input, 
actually provides an opportunity for the IETF to put in its own two 
cents on the issue, adding its voice to those of IAB and ICANN.

Keith

---

From: Barry Leiba <[email-masked]>
Date: Sat, 13 Jul 2013 14:39:24 -0400

> actually provides an opportunity for the IETF to put in its own two cents
> on the issue, adding its voice to those of IAB and ICANN.
>

An excellent suggestion!
Who will write the first draft?

Barry

---

From: Keith Moore <[email-masked]>
Date: Sat, 13 Jul 2013 17:36:57 -0400

On 07/13/2013 02:39 PM, Barry Leiba wrote:
>
>
>         FWIW, I strongly agree to the point of considering this
>         serious bad judgment on the IAB's part (and making that
>         decision without any opportunity for community input even worse).
>
>     It occurs to me that the fact that the IAB didn't solicit public
>     input, actually provides an opportunity for the IETF to put in its
>     own two cents on the issue, adding its voice to those of IAB and
>     ICANN.
>
>
> An excellent suggestion!
I might be willing, especially if people want to have a bar BOF about it 
in Berlin.

Keith

---

From: "John Levine" <[email-masked]>
Date: 13 Jul 2013 22:26:59 -0000

>An excellent suggestion! Who will write the first draft?

Depends whether the topic is "dotless domains suck" or the more
general but more important "local namespaces on the Internet and why
the global DNS has to stay out of them."

The problem with dotless domains and the problem with whatever.corp or
whatever.lan or whatever.local are really the same: these are
namespaces that have historically been informally managed on
innumerable private networks, often behind firewalls or NATs, and if
you try to use them as global domain names, Bad Things(tm) will
happen.

In both cases you can argue, more or less credibly, that it's sloppy
software that would never have done that if it strictly followed the
RFCs, and in both cases the reality on the ground is that it happens
and it's not going to stop.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Jul 2013 00:28:13 -0700

Hi John,
>the global DNS has to stay out of them."

The usual way is to have "dotless domains considered harmful".

Yes.

>and it's not going to stop.

It is difficult to argue on technical grounds that it should not be 
done as this is more about assumptions instead of a rule in standards 
which prohibit the software from handling dotless domains.

The question which was asked is whether dotless domains will, for 
example, work with email.  The initial comment from Dave Crocker, on 
this thread was "I'm not seeing this requirement/limitation in RFC 
5321. It merely requires an FQDN."  You mentioned on this thread that 
there are some ccTLDs which have a MX RR at the top-level.

Some of the problems that can be encountered are visible at the 
application level.  As a matter of convenience a person might type 
user@example as the recipient address and the software converts that to a FQDN.

draft-moonesamy-dotless-domains-00 [1] discusses about the case of 
dotless domains.  I listed two arguments in Section 6 of the 
draft.  Section 4.4 may be of interest to the people reading this mailing list.

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-dotless-domains-00

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Jul 2013 22:04:57 -0700 (PDT)

> It may be configurable on an individual level, but if Google, Apple or
> whoever want to be able to publish "sales@apple" type addresses, they've got no
> chance. It just wouldn't work for billions of people. They'd have to say "just
> email us on sales@apple and if that doesn't work go reconfigure your mail
> server, change ISP, reconfigure your dns server, upgrade your infrastructure,
> change the way you access local resources, etc"

I'm well aware of all this. My point, such as it was, was that this stuff *is*
highly configurable, and in practice it can and will be set in all sorts of
different ways.

> everyone at a global level.

Agreed.

				Ned