There is an interesting discussion currently on the IETF list about the consequences of the approval of the new gTLD process by ICANN. One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld This may be confusing to email clients and MTAs which try to be "smart". Currently , the current standard is defined in RFC 2821 as such: 2.3.5 Domain A domain (or domain name) consists of one or more dot-separated components. [...] The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction. Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable. The new gTLD context is addressed in the draft RFC2821bis, which states: 2.3.5. Domain Names A domain name (or often just a "domain") consists of one or more components, separated by dots *if more than one appears*. (emphasis added) Unfortunately, the current implementations are based on the original RFC2821, not the revised draft. There may be a lot of software out there that would treat user@tld as a local e-mail address (ie not FQDN). I am not aware of any study by SSAC on that matter (pointers appreciated). Where I think it matters for the user community is that we actually expect our e-mails to complaints@ebay or support@apple to be delivered. I see here an opportunity for the ALAC to ask ICANN for a report on this. Patrick
Patrick, Which IETF list? Patrick Vande Walle wrote:
There is an interesting discussion currently on the IETF list about the consequences of the approval of the new gTLD process by ICANN. One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
This may be confusing to email clients and MTAs which try to be "smart". Currently , the current standard is defined in RFC 2821 as such:
2.3.5 Domain A domain (or domain name) consists of one or more dot-separated components. [...] The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable.
The new gTLD context is addressed in the draft RFC2821bis, which states:
2.3.5. Domain Names A domain name (or often just a "domain") consists of one or more components, separated by dots *if more than one appears*. (emphasis added)
Unfortunately, the current implementations are based on the original RFC2821, not the revised draft. There may be a lot of software out there that would treat user@tld as a local e-mail address (ie not FQDN).
I am not aware of any study by SSAC on that matter (pointers appreciated). Where I think it matters for the user community is that we actually expect our e-mails to complaints@ebay or support@apple to be delivered. I see here an opportunity for the ALAC to ask ICANN for a report on this.
Patrick
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
But this isn't a new issue. The address n@ai has been in use for a decade. I have to say that what particularly impressed me about the discussion on the IETF list was how utterly uninformed most of it was. You didn't miss much. R's, John
John, Patrick and all, I have to agree with John here largely. The IETF has largely been less than well informed on a number of topics and issues for several years. However the IETF feels it is the standards organization that does the informing. So there is a bit of a cunundrem here. Chicken or egg, as it were... John Levine wrote:
One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
But this isn't a new issue. The address n@ai has been in use for a decade.
I have to say that what particularly impressed me about the discussion on the IETF list was how utterly uninformed most of it was. You didn't miss much.
R's, John
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
On 4 Jul 2008, at 13:36, John Levine wrote:
I have to say that what particularly impressed me about the discussion on the IETF list was how utterly uninformed most of it was. You didn't miss much.
A lot of the discussion / coverage of the new gTLDs seems to be very misinformed and very misleading. I'm seeing threads on spam-l, nanog and a bunch of other places Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Michele and all, This was to be, and should be expected, as the decision was not well delineated in Paris. Nor have IDN gTLD's been very well flushed out to date. And the fast tracking of some IDN gTLD's is reasonably worrisome for a number of reasons such as UCE increases initially and likely for the long term forseeable future, Security concerns to service providers and their customers, and other forms of Email dilivered/based abusive activities. And btw, I have also seen/read nznog, nanog, ect., some very excellent insight as to the impact vis a vi Email and P2P. Many Service providers will the making some significant routing table changes and throtteling decisions in respect to IDN gTLD's that will with some larger access and service providers mean not routing IDN gTLD traffic, or significantly throtteling such traffic as purely a matter of security. Michele Neylon wrote:
On 4 Jul 2008, at 13:36, John Levine wrote:
I have to say that what particularly impressed me about the discussion on the IETF list was how utterly uninformed most of it was. You didn't miss much.
A lot of the discussion / coverage of the new gTLDs seems to be very misinformed and very misleading. I'm seeing threads on spam-l, nanog and a bunch of other places
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
John Levine wrote:
One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
But this isn't a new issue. The address n@ai has been in use for a decade.
John, This may not be new, but the domain you mention is an exception. Actually, of the 30 or so I tried, ai was the only TLD I found with an associated MX record. So, do I understand correctly that, because one obscure non-RFC compliant e-mail address has been out there for a decade this is enough of a test to guarantee, there will be no issues with the current market leading MUAs and MTAs (and legacy ones) ? Patrick
So, do I understand correctly that, because one obscure non-RFC compliant e-mail address has been out there for a decade this is enough of a test to guarantee, there will be no issues with the current market leading MUAs and MTAs (and legacy ones) ?
There will certainly be issues with MTAs and MUAs, since there are plenty of them that implicitly or explicitly assume that every domain name contains a dot. What we do know is that the existence of such addresses doesn't cause any global problems. Why does this issue need the ALAC's limited time, rather than being just one more minor question for the purchasers of new TLDs to deal with? If they'll be spending $100K or more on their new domain, I think it's reasonable to assume that they can do their own due diligence. R's, John
John and all, You would think that indeed new registries could do their own due diligence. But of course experience clearly shows that they rarely do. Ergo, diligence of users and perhaps the ALAC is necessary. Secondly, as ICANN doesn't do the oversight it should do, especially given the fact that they can't even keep track of their own Domain Names as was reported earlier this past week, someone needs to either fill in the gaps in oversight, or ICANN needs to step up much better than they have been doing over the past 9+ years. I can't see that how much $$ a proposed registry puts up really has anything what so ever to do with their creditability, after all any drug dealer or cartel can back any proposal with $$ easy enough. So your logic as far as price for a gTLD has little to do with doing good due diligence. John Levine wrote:
So, do I understand correctly that, because one obscure non-RFC compliant e-mail address has been out there for a decade this is enough of a test to guarantee, there will be no issues with the current market leading MUAs and MTAs (and legacy ones) ?
There will certainly be issues with MTAs and MUAs, since there are plenty of them that implicitly or explicitly assume that every domain name contains a dot.
What we do know is that the existence of such addresses doesn't cause any global problems. Why does this issue need the ALAC's limited time, rather than being just one more minor question for the purchasers of new TLDs to deal with? If they'll be spending $100K or more on their new domain, I think it's reasonable to assume that they can do their own due diligence.
R's, John
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
I have a hard time believing that Apple or Yahoo or any other major customer-facing business would roll out a branded TLD with an email service that wasn't compliant with major RFCs. Bret
Bret and all, Than you need to review Yahoo.com's DNS configuration, for example. I certainly believe that Apple or Yahoo would do just exactly whatever they wanted irrespective of compliancy of major RFC's. So either you are not paying attention very closely or just unaware for whatever reason. For yahoo.com's DNS see: http://private.dnsstuff.com/tools/dnsreport.ch?domain=yahoo.com&token=27a011... Bret Fausett wrote:
I have a hard time believing that Apple or Yahoo or any other major customer-facing business would roll out a branded TLD with an email service that wasn't compliant with major RFCs.
Bret
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
I have a hard time believing that Apple or Yahoo or any other major customer-facing business would roll out a branded TLD with an email service that wasn't compliant with major RFCs.
Over on the IETF mailing lists, there is surprising disagreement about what the RFCs say. Nobody seems to have thought much about domains without dots, even though there have been addresses like n@ai and http://museum/ for quite a few years. R's, John
On 7 Jul 2008, at 19:25, Bret Fausett wrote:
I have a hard time believing that Apple or Yahoo or any other major customer-facing business would roll out a branded TLD with an email service that wasn't compliant with major RFCs.
You've heard of Google, haven't you? :) Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Michele and all, I am fairly sure that Bret has heard of Google. An yes, they are not RFC compliant i.e. Gmail and Googlemail. Of course they don't seem to really care that they are not. But more and more they are finding it difficult to find loyal customers for their Email product line, not to mention their search engine. Maybe someday Vint Cerf will have a "Religious" experiance, and "Evangelize" to the rest of Google's managment, of which he is a part of, and they will become good Internet citizens. However I remain amazed that Bret, a good fellow, seems to be rather uninformed or lacking what is relitively common knowledge... Michele Neylon :: Blacknight wrote:
On 7 Jul 2008, at 19:25, Bret Fausett wrote:
I have a hard time believing that Apple or Yahoo or any other major customer-facing business would roll out a branded TLD with an email service that wasn't compliant with major RFCs.
You've heard of Google, haven't you? :)
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
Dear Patrick, this point is a key point because it means that one of the main Internet applications will be hampered by the new TLD policy. This new TLD policy also includes ML-TLDs. I don't really see IETF issuing a solution that supports xxx@ASCII-TLD and not xxx@UNICODE-TLD. As a consequence every mail oriented software will have to be updated to support TLD only mail names. These TLD can be ASCII or punycoded UNICODE. It would seem very odd if this mail system update did not consistently extend to the other Internet host logics and did not support both ASCII and UNICODE TLDs. It would be surprising if the consensus was not to use the same logisitic effort to deploy a fully consistent Multilingual Internet. We (with James Seng and Vint Cerf) identified at the WG-IDNABIS [http://wikidna.org] that: - (a) the IDNA proposition was not the ML-DNS france@large identified as the world expectation (a DNS to delivers the same QoS in every language and scripts as it does in English ASCII) - (b) france@large was perfectly legitimate according to the IETF process to give a try to such a development [we are lead users, not engineers]. We confirmed that this was our intent at our 2008/07/02 meeting. We committed that our effort will strive to stay IDNA interoperable and will be based upon LS640 (Linguasphere System 640) which is the bassis for the now reduced ISO 639-6 and now an open standard. The basic difference between IDNA and ML-DNS is that IDNA is not end to end (what the user types is not what the other end receives). This is to support a possible lack of understanding of IDNA by the receiving end, specially in the mail case. This leads - (1) to an impossible entropy problem: Unicode is degraded by punycode and has no way to restore the intial entrry on the other end - (2) an increasing barely sustainable set of complex constraints in order to limit the cases where this may happen. The confusion also is that these constraints only apply at adhering registries' level. Would the end to end be acceptable (the ML-DNS hypothesis) most of the multilinguisation oriented issues would be addressed at the internet and not at the user application layer. This is because there would not be a specific presentation layer need anymore: we would be back to the internet as a single shared space (one single presentation and session default layer). This conforms with the IETF core values documented in RFC 3935, which makes a feature from the 4 layers internet model. In this case the need is only for transition management: 1. it will be a matter of a few months period once it has been documented, tested and validated. This is because I do not think we can repeat the January 1st, 1983 approach. However, we could "virtualize" it, for example in using legacy/Multilingual Internet OPES Gateways (work is to be resumed as the WG-OPES which favored SMTP over the DNS as their second and currently last protocol support documentatoin after HTTP). 2. I fear that the community starts thinking about many other needs such a deployment could help (security, IPv6, semantic, etc.). This means, not to confuse and to overload the project, that the initial deployment would be conceived as a pilot experimentation towards a permanent Internet update process (this is part of the france@large plan to be detailed hopefully before September). jfc At 08:57 04/07/2008, Patrick Vande Walle wrote:
There is an interesting discussion currently on the IETF list about the consequences of the approval of the new gTLD process by ICANN. One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
This may be confusing to email clients and MTAs which try to be "smart". Currently , the current standard is defined in RFC 2821 as such:
2.3.5 Domain A domain (or domain name) consists of one or more dot-separated components. [...] The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable.
The new gTLD context is addressed in the draft RFC2821bis, which states:
2.3.5. Domain Names A domain name (or often just a "domain") consists of one or more components, separated by dots *if more than one appears*. (emphasis added)
Unfortunately, the current implementations are based on the original RFC2821, not the revised draft. There may be a lot of software out there that would treat user@tld as a local e-mail address (ie not FQDN).
I am not aware of any study by SSAC on that matter (pointers appreciated). Where I think it matters for the user community is that we actually expect our e-mails to complaints@ebay or support@apple to be delivered. I see here an opportunity for the ALAC to ask ICANN for a report on this.
Patrick
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
Patrick, This reminds me (probably with no technical justification or relevance whatsoever!) of the problem a few years back when TLDs longer than three characters were introduced and some applications failed to recognize the new "long" tld string <http://www.icann.org/topics/TLD-acceptance/>. Perhaps worth considering possible technical acceptance issues? Adam
There is an interesting discussion currently on the IETF list about the consequences of the approval of the new gTLD process by ICANN. One possible issue may be with vanity gTLDs like apple, ebay etc. In this context, an email address may just be user@tld
This may be confusing to email clients and MTAs which try to be "smart". Currently , the current standard is defined in RFC 2821 as such:
2.3.5 Domain A domain (or domain name) consists of one or more dot-separated components. [...] The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable.
The new gTLD context is addressed in the draft RFC2821bis, which states:
2.3.5. Domain Names A domain name (or often just a "domain") consists of one or more components, separated by dots *if more than one appears*. (emphasis added)
Unfortunately, the current implementations are based on the original RFC2821, not the revised draft. There may be a lot of software out there that would treat user@tld as a local e-mail address (ie not FQDN).
I am not aware of any study by SSAC on that matter (pointers appreciated). Where I think it matters for the user community is that we actually expect our e-mails to complaints@ebay or support@apple to be delivered. I see here an opportunity for the ALAC to ask ICANN for a report on this.
Patrick
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
On 8 Jul 2008, at 16:29, Adam Peake wrote:
Perhaps worth considering possible technical acceptance issues?
A lot of form validation tools are going to fail / break miserably Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
participants (8)
-
Adam Peake -
Bret Fausett -
Jeffrey A. Williams -
JFC Morfin -
John Levine -
Michele Neylon -
Michele Neylon :: Blacknight
-
Patrick Vande Walle