Re: ICANN opens up Pandora's Box of new TLDs
Stephane Bortzmeyer bortzmeyer@nic.fr wrote:
I am very curious of what tests a "security-aware programmer" can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs.
The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and '[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective. Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name. It's not too hard to see the problems with that. An analogous network scenario would be IP addresses of varying length and without a netmask.
If you test that the TLD exists... it will still work.
Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case.
If you test that the name matches (com|net|org|[a-z]{2}), then you are not what I would call a "security-aware programmer".
Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic? Not that that doesn't happen now, to a far lesser degree. But it's the extent to which this presents new opportunities for black hats that should have given ICANN pause. Odds are that RBLs will be among the first targets. Bottom line is the decision was made for it's _monetization_ value, not security, and customer service was just a pretense. Roger Marquis
If you test that the TLD exists... it will still work.
Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case.
Even under the most wildly optimistic scenarios, it's hard to imagine new TLDs being added more than once a month, and I presume that everyone here already knows how easy it is to get copies of the root zone. The reasonable way to validate TLDs is to fetch a copy of the zone every couple of weeks and cache it. By the way, to be sure we're all on roughly the same page, here's a quiz. How many names are there in the root zone right now? a) 11 b) 97 c) 153 d) 280 e) 974 Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly.
Phil Regnauld (regnauld) writes:
John Levine (johnl) writes:
d) 280
# dig @f.root-servers.net axfr . | egrep 'IN[[:space:]]NS' | awk '{ print $1 }' | sort -u |wc -l
281
Interesting extract from a transcript of tICANN board meeting in Paris. It doesn't say much about what was originally envisioned, but sheds light on the considerations that were made. http://isoc-ny.org/wiki/ICANN_-_Paris/Board_meeting [It's in the first statement from Dave Wodelet:] I just think it's important for the public record to make some comments about adding new gTLDs to the root. While conceptually I agree and see the benefit to the community with adding more TLDs to the root, there are still some concerns about how scalable in the long term this will be. How many can we truly support? Well, from the best guess we have, and I do stress the word "guess," somewhere around 5,000 or so TLDs seem to be realistic. But how high can we actually go? We really don't know. There are both technical and administrative issue limits to the scaling. And it looks like the administrative issues may be more limiting than the technical ones. Certainly, what we do now administratively will certainly need to change to support even the 5,000 or so that I mentioned earlier. So how many will we have to support? Well, if we just look at the number of place names, there seems to be somewhere between 5 and 6 million place names in the world. And if every one of these wanted a TLD, that might not be possible. And the 5 to 6 million place names doesn't include the number of commercial TLDs businesses may want, and this 5 to 6 million doesn't include the vanity names people may want as well, nor does this 5 to 6 million include what we may need in the future for names of planets, planetary colonies, which may, indeed, happen within the life of our Internet. So I am a bit concerned about spending our TLD name inheritance for future generations of Internet users. As we know, everything has limits, like IPv4. We all know that has a limit, and that's why we're looking at IPv6.
On Sun, Jun 29, 2008 at 02:45:55PM -0700, Roger Marquis <marquis@roble.com> wrote a message of 31 lines which said:
The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}'
If this is a regexp for the current root zone, it is wrong... (".museum" and the test IDNs, whose punycode encoding contains digits and hyphens.)
Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name.
Interesting requirment but one which was never written down, I'm afraid. You certainly cannot expect ICANN to comply with every requirment that someone at Nanog may imagine every day.
Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic?
Be my guest. The DNS is a tree and the existence of nic.de or nic.com was never a problem. Why should ".nic" be different?
Terribly stupid question, but one aproppos to this thread. If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address? If they simply use "smtp" as the hostname, most of the current resolver libraries will append the local domain name, so that instead of reaching my A record for smtp, they'll end up trying to reach smtp.their.domain. Will operating system manufacturers release updated resolver libraries that no longer assume that single token names should have the local domain attached? Or should I always ensure that resolvers reach my domain explicitly by including the trailing "dot" in all uses, so that my email would be given out as "myname@smtp." in the hopes that everyone would correctly remember to add the "." at the end when entering my email address into their mail clients? In the past, this wasn't really a concern, as you never had a case of a single entity owning an entire TLD, and as such you'd never see A or MX records showing up for an entire TLD. But now, with private ownership of TLDs possible, that could very well be the case in the future. Google could register .gmail, and decide that they want to have the shortest, easiest to remember addresses, so people can just be "user@gmail" (well, until MSN gets in the business, and decides that their users should have even shorter addresses, and register .msn so that their users can be "user@msn". ^_^; ) Or does the current resolver logic already handle these cases (check root, work your way down stopping at the first match found; if you run out of tokens in the string being resolved, append the local domain name to the string and start the process over)? Simply looking to solidify my understanding of how these new names would resolve. Thanks! Matt
Matthew Petach (mpetach) writes:
If they simply use "smtp" as the hostname, most of the current resolver libraries will append the local domain name, so that instead of reaching my A record for smtp, they'll end up trying to reach smtp.their.domain.
Actually, that's a good point -- although it will try first with the domains specified in the search list first. So I wouldn't worry too much about this kind of thing. But considering the amount of flag waving and "Caution: Wet Floor" signs ICANN placed when it rolled out something has harmless as the IDN tests in the root, I'm surprised that they haven't thought about all the non-FQDNs that will suddenly resolve, including all the private TLDs that people use internally. It's bad practice, and isn't recommended anyway, but I do expect it will cause many more fun (read: annoying) calls to helpdesks of the sort "where did my mail go ?". And mail won't be the only thing.
Will operating system manufacturers release updated resolver libraries that no longer assume that single token names should have the local domain attached?
I know a lot of mail clients that won't accept to send mail to user@tld, but they certainly will accept user@smtp as the outgoing mail name. Luckily, that will match the search list as well first.
Or should I always ensure that resolvers reach my domain explicitly by including the trailing "dot" in all uses, so that my email would be given out as "myname@smtp." in the hopes that everyone would correctly remember to add the "." at the end when entering my email address into their mail clients?
A fair number will barf on this (for now).
Or does the current resolver logic already handle these cases (check root, work your way down stopping at the first match found; if you run out of tokens in the string being resolved, append the local domain name to the string and start the process over)?
The other way around. And if I ping 'dk', my resolver stops after "catpipe.net" and my other private domain. It doesn't try "dk.", even though dk. has an A record associated with it. I get NXDOMAIN.
Simply looking to solidify my understanding of how these new names would resolve.
Not too many problems, I think, except for resolver libraries that fail to find the name in the domains listed in the search list, and continue to '.'. It's not standard practice though. Phil
On Jun 30, 2008, at 1:53 AM, Phil Regnauld wrote:
But considering the amount of flag waving and "Caution: Wet Floor" signs ICANN placed when it rolled out something has harmless as the IDN tests in the root, I'm surprised that they haven't thought about all the non-FQDNs that will suddenly resolve, including all the private TLDs that people use internally.
1) The new gTLD stuff hasn't gotten as far as the point where the testing of IDN stuff started. 2) ICANN (or rather, the technical side of ICANN staff) has thought about this and there is a 'technical evaluation' phase of the application evaluation 3) We've already run into the 'private TLD' thing: lots of global companies (apparently) have internal domains organized on regional/ continental boundaries. When '.asia' was put into the root, the Internet did not break.
The other way around. And if I ping 'dk', my resolver stops after "catpipe.net" and my other private domain. It doesn't try "dk.", even though dk. has an A record associated with it. I get NXDOMAIN.
Your resolver appears to be broken. Works for me: % dig +short dk 193.163.102.23 % traceroute dk. traceroute to dk (193.163.102.23), 64 hops max, 40 byte packets 1 10.0.1.1 (10.0.1.1) 4.484 ms 3.933 ms 1.163 ms 2 * * * 3 * ge-2-14-ur01.santaclara.ca.sfba.comcast.net (68.86.248.65) 13.600 ms 10.250 ms ... 20 netgroup.r2.dk-hostmaster.dk (217.116.254.58) 204.900 ms 200.835 ms 199.208 ms ^C (doesn't appear to answer to pings) Regards, -drc
David Conrad (drc) writes:
1) The new gTLD stuff hasn't gotten as far as the point where the testing of IDN stuff started.
Mhh, ok :)
2) ICANN (or rather, the technical side of ICANN staff) has thought about this and there is a 'technical evaluation' phase of the application evaluation
Fair enough.
3) We've already run into the 'private TLD' thing: lots of global companies (apparently) have internal domains organized on regional/continental boundaries. When '.asia' was put into the root, the Internet did not break.
The other way around. And if I ping 'dk', my resolver stops after "catpipe.net" and my other private domain. It doesn't try "dk.", even though dk. has an A record associated with it. I get NXDOMAIN.
Your resolver appears to be broken. Works for me:
dig doesn't use the resolver the same way other applications do. Try "ping dk" vs "ping dk.", or "telnet dk" vs. telnet "dk." Of course, depends on the OS -- but at least on a few BSDs (OS X, FreeBSD), Linuxes (Debian, Ubuntu), it behaves the same way.
On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote:
If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address?
I suspect the assumption is that no one will actually do this since it would have operational issues (as you note) and it would be challenging to recover costs in the "traditional" manner (i.e., selling names under the TLD). If someone were to try, perhaps it would demonstrate the quote "stupidity, like virtue, is its own reward"? Regards, -drc
It seems to me that there are technical reasons to try and block .local, and maybe some other potential TLDs, but that for .exe, .smtp, and other choices that confuse current browser implementations, a warning note is about all the registrant can expect. Of course, it would not surprise me if people are right now going through web logs and search logs and saying, hmm, .smtp and .exe occur so often, they would make GREAT TLDs. Regards Marshall On Jun 30, 2008, at 8:28 AM, David Conrad wrote:
On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote:
If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address?
I suspect the assumption is that no one will actually do this since it would have operational issues (as you note) and it would be challenging to recover costs in the "traditional" manner (i.e., selling names under the TLD). If someone were to try, perhaps it would demonstrate the quote "stupidity, like virtue, is its own reward"?
Regards, -drc
In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> you write:
Terribly stupid question, but one aproppos to this thread.
If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address?
In the usual way. Try typing this into your browser's address bar: http://museum/ R's, John
On 30 Jun 2008 14:47:23 -0000, John Levine <johnl@iecc.com> wrote:
In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> you write:
Terribly stupid question, but one aproppos to this thread.
If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address?
In the usual way. Try typing this into your browser's address bar:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question. In order to reach that page, in Firefox 1.5.0.12, I had to actually enter "http://museum./ and add the trailing dot to force the browser to *not* treat it as a stub token. IE was a little more normal, and simply returned a 'host unknown" error. Annoyingly enough, however, IE returned the "host unknown" for *both* "http://museum/" and "http://museum./" so it failed to follow proper resolution practice and ignored the trailing dot. Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^;
R's, John
Thanks! Matt
Matthew Petach (mpetach) writes:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question.
... and Safari took me to www.museum.com.
Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^;
This is not only about client resolvers, it's equally about the individual applications and their choice of how to handle a single-label domain name, or just domain names (FQDN or not) in particular. Most often you'll see that the regular expressions used to parse what is considered to be a valid domain -- or even the policy that decides whether a given name has a special meaning or not -- will vary wildly. Most of them are wrong, or don't do the expected thing.
In the usual way. Try typing this into your browser's address bar:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question.
Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library.
Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^;
Too bad. You might try writing the guy whose address is n@ai (yes, his name is Ian) and see what his experience has been. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly.
On Monday 30 June 2008 17:24:45 John Levine wrote:
In the usual way. Try typing this into your browser's address bar:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question.
Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library.
I think that the following hold ... but I have a headache.... Since the hostname part of the URI does not contain a dot, RFC1034 section 3.1 applies (according to RFC 2396), the name is treated as relative initially, and the interpretation "varies from implementation to implementation". In particular if a "museum" name exists in your current domain, and/or other searches that may be applied to the lookup that may be correctly returned first. The language implies that "." need not be part of the search, so the URL need not work and the implementation could still be RFC conforming. Certainly there is scope for confusion here. My machines resolver is configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm sure the folks who wrote the resolver code considered the default carefully. Clearly an area ICANN need to ponder, if they haven't already, as changing the resolver defaults globally might undermine the stability of the root name servers. And introducing new domains will encourage vendors to change their resolvers default behaviour (even for areas where it is already technically RFC conforming, if not "least surprise" conforming).
Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^;
Too bad. You might try writing the guy whose address is n@ai (yes, his name is Ian) and see what his experience has been.
Now that is an email address not a URI, so section 5 of RFC 2821 applies, and treating the domain as "relative" is "discouraged". So I'd expect his email address to work (with a few exceptions - just like addresses with apostrophes - some folks will have bad implementations). IE gets to the correct page here. Firefox on Windows did something else again - sigh (I'm sure it is can be corrected in the browser configuration somewhere). There is a squid proxy behind both of them. On the other hand if people need short domain names, my employers may have a couple to sell of the old fashioned variety the same total length as "museum" but without the added complications, and the ICANN fee is a lot less ;)
It would be helpful if someone could put together of web page of different links so that people could test the native resolvers for each OS and applications (web browsers primarily, but also DNS clients separated from the OS stack such as dig and nslookup). Perhaps some of this brokenness can be illuminated sooner rather than later. Frank -----Original Message----- From: Simon Waters [mailto:simonw@zynet.net] Sent: Monday, June 30, 2008 12:21 PM To: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs On Monday 30 June 2008 17:24:45 John Levine wrote:
In the usual way. Try typing this into your browser's address bar:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question.
Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library.
I think that the following hold ... but I have a headache.... Since the hostname part of the URI does not contain a dot, RFC1034 section 3.1 applies (according to RFC 2396), the name is treated as relative initially, and the interpretation "varies from implementation to implementation". In particular if a "museum" name exists in your current domain, and/or other searches that may be applied to the lookup that may be correctly returned first. The language implies that "." need not be part of the search, so the URL need not work and the implementation could still be RFC conforming. Certainly there is scope for confusion here. My machines resolver is configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm sure the folks who wrote the resolver code considered the default carefully. Clearly an area ICANN need to ponder, if they haven't already, as changing the resolver defaults globally might undermine the stability of the root name servers. And introducing new domains will encourage vendors to change their resolvers default behaviour (even for areas where it is already technically RFC conforming, if not "least surprise" conforming).
Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^;
Too bad. You might try writing the guy whose address is n@ai (yes, his name is Ian) and see what his experience has been.
Now that is an email address not a URI, so section 5 of RFC 2821 applies, and treating the domain as "relative" is "discouraged". So I'd expect his email address to work (with a few exceptions - just like addresses with apostrophes - some folks will have bad implementations). IE gets to the correct page here. Firefox on Windows did something else again - sigh (I'm sure it is can be corrected in the browser configuration somewhere). There is a squid proxy behind both of them. On the other hand if people need short domain names, my employers may have a couple to sell of the old fashioned variety the same total length as "museum" but without the added complications, and the ICANN fee is a lot less ;)
On Mon, Jun 30, 2008 at 01:02:29PM -0500, Frank Bulk wrote:
It would be helpful if someone could put together of web page of different links so that people could test the native resolvers for each OS and applications (web browsers primarily, but also DNS clients separated from the OS stack such as dig and nslookup).
Doing that comlpetely generally turns out to have more layers than you might expect. My first cut is here: http://bestpractices.wikia.com/wiki/Unusual_Domain_Names Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Mon, Jun 30, 2008 at 09:05:41AM -0700, Matthew Petach wrote:
In the usual way. Try typing this into your browser's address bar:
That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question.
In order to reach that page, in Firefox 1.5.0.12, I had to actually enter "http://museum./ and add the trailing dot to force the browser to *not* treat it as a stub token.
FWIW, FF3.0/Win dealt with that properly for me. It also deals properly, on the same machine, with several internal webservers, which I also hit with one-word names, but which actually resolve, of course, by the search list on the machine. So FF3, at least, will try to resolve oneword as oneword., before moving along. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Jay R. Ashworth wrote:
It also deals properly, on the same machine, with several internal webservers, which I also hit with one-word names, but which actually resolve, of course, by the search list on the machine.
So FF3, at least, will try to resolve oneword as oneword., before moving along.
Firefox has a gazillion "advanced" config settings that allow you to remove all the fluff added to try to emulate Microsoft's virus explorer. When I switched platform I went from Mozilla to Firefox and spent a fair amount of time finding out how to disable those unwanted features. Disabling the feature that send all your URL typos to Google was one of the first things I strived to do. When I type http://museum/ I get a "not found " error message. But nslookup museum works. With all the phishing shananigans, you'd think the folks outside of microsoft who would strive to avoid features that could bring you to unwanted destinations and they should just stick to feeding your host name string to the resolver and letting resolver decide how to manipulate that string to resolve it.
On Mon, Jun 30, 2008 at 8:34 PM, Jean-François Mezei <jfmezei@vaxination.ca> wrote:
With all the phishing shananigans, you'd think the folks outside of microsoft who would strive to avoid features that could bring you to unwanted destinations and they should just stick to feeding your host name string to the resolver and letting resolver decide how to manipulate that string to resolve it.
You sure would... hurrah for paxfire/barefruit/... :( enabling phishing one typo at a time. -Chris
On Mon, 30 Jun 2008, Matthew Petach wrote:
Or should I always ensure that resolvers reach my domain explicitly by including the trailing "dot" in all uses, so that my email would be given out as "myname@smtp." in the hopes that everyone would correctly remember to add the "." at the end when entering my email address into their mail clients?
Trailing dots in email addresses are a syntax error.
In the past, this wasn't really a concern, as you never had a case of a single entity owning an entire TLD, and as such you'd never see A or MX records showing up for an entire TLD.
Not true. There have been TLDs with MX and A records for a long time, though they tend to be badly set up, and many MTAs treat single-component domains specially such that email to these TLDs will often not work. http://fanf.livejournal.com/72486.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHWEST BACKING SOUTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST AND LATER. SLIGHT OR MODERATE. MAINLY FAIR. MAINLY GOOD.
On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote:
On Mon, 30 Jun 2008, Matthew Petach wrote:
Or should I always ensure that resolvers reach my domain explicitly by including the trailing "dot" in all uses, so that my email would be given out as "myname@smtp." in the hopes that everyone would correctly remember to add the "." at the end when entering my email address into their mail clients?
Trailing dots in email addresses are a syntax error.
RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14. STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a standard for domain name literals which appears to expand to a pattern which does not in fact permit a trailing dot. In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header. Tony: what authority were you depending on for your assertion, and in which context do you make it? Cheers, -- jr 'comp.mail.headers lives!' -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
On Mon, Jun 30, 2008 at 4:45 PM, Jay R. Ashworth <jra@baylink.com> wrote:
RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14.
STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a standard for domain name literals which appears to expand to a pattern which does not in fact permit a trailing dot.
In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header.
Tony: what authority were you depending on for your assertion, and in which context do you make it?
This whole set of arguements is one of the points Bill Manning was bringing up, yes? Clients and OS's and other things make oddball assumptions (museum really is www.museum.com for some versions of FF or IE or ....) Without adequate time to fix this in code (properly fix this) support calls and mis-direction are going to be an issue :( Now, lump on IDN foo!!! wee! How fast will IEX be out of normal use? FFY? who runs a largish traffic magnet and can tell when the last Windows 98 IE4 client hit them? Matt Petach, let's nominate him for that stat update :) -Chris
On Mon, 30 Jun 2008, Jay R. Ashworth wrote:
On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote:
Trailing dots in email addresses are a syntax error.
In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header.
Postfix corrects many syntax errors rather than rejecting erroneous messages.
Tony: what authority were you depending on for your assertion, and in which context do you make it?
It has been true of all internet email addresses since before dots were introduced into host names. RFC 2821 section 4.1.2 Command Argument Syntax Domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig Note that this does not permit a trailing dot. (It also doesn't permit single-component domains, but that's due to an editorial mistake.) Section 4.1.2 of RFC 821 also does not permit trailing dots. RFC 2822 section 3.4.1 Addr-spec specification domain = dot-atom / domain-literal / obs-domain dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) This also does not permit trailing dots. RFC 822 section 6 is similar. See also RFC 733, which allows no dots at all. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6 IN HUMBER, BECOMING VARIABLE 3 OR 4. SLIGHT OR MODERATE. THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
participants (14)
-
Christopher Morrow -
Christopher Morrow -
David Conrad -
Frank Bulk -
Jay R. Ashworth -
Jean-François Mezei -
John Levine -
Marshall Eubanks -
Matthew Petach -
Phil Regnauld -
Roger Marquis -
Simon Waters -
Stephane Bortzmeyer -
Tony Finch