ICANN opens up Pandora's Box of new TLDs
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006? -Jim P.
On Thu, Jun 26, 2008 at 04:09:30PM -0400, Jim Popovitch wrote:
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006?
Could someone point me to a reference (other than a very poorly written BBC article) that suggests that .ibm is even a valid possiblity in light of whatever ICANN actually *is* proposing? And no, companies *aren't* "forced to pay for another domain name" just because a new TLD appears -- they aren't doing it *now*, by and large, and thank ghod: a) it doesn't constitute a violation of Ford Motor's trademark that the Ford Foundation has ford.org or a Mustang club has ford.net and b) it's horrible DNS hygiene to do that in the first place; it re-flattens the TLD namespace. I certainly advise my clients not to do things that foolish. I'm sure Randy encourages me in this. Cheers, -- jra -- 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)
And no, companies *aren't* "forced to pay for another domain name" just because a new TLD appears -- they aren't doing it *now*, by and large, and thank ghod:
The last time I looked there were a few thousand companies protecting their intellectual property by using companies like Mark Monitor to insure that they had defensive registrations in all ccTLD's possible. -M<
On Jun 26, 2008, at 4:07 PM, Martin Hannigan wrote:
And no, companies *aren't* "forced to pay for another domain name" just because a new TLD appears -- they aren't doing it *now*, by and large, and thank ghod:
The last time I looked there were a few thousand companies protecting their intellectual property by using companies like Mark Monitor to insure that they had defensive registrations in all ccTLD's possible.
-M<
Whether some choose to do that or not, I believe that the point is that: 1. Nobody is FORCING them to do so. 2. Most are _NOT_ doing so. 3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd. Owen
Has anyone been able to figure out what it will cost to secure a completely un-contested tld? I haven't been able to find proposed fees anywhere. I think it will be a practical necessity for all organizations to secure their own TLD at the outset, lest someone else secure it for them and leave it up to the court of arbitration. .. And where, pray-tell, will the mega cash from the TLD auctions be going? Surely ICANN doesn't need a multi-billion $ annual budget, but if these TLD auctions go the way of the cellular auctions, there's a good potential for that kind of an outcome.
Hello; On Jun 26, 2008, at 7:28 PM, Ken Simpson wrote:
Has anyone been able to figure out what it will cost to secure a completely un-contested tld? I haven't been able to find proposed fees anywhere. I think it will be a practical necessity for all organizations to secure their own TLD at the outset, lest someone else secure it for them and leave it up to the court of arbitration.
.. And where, pray-tell, will the mega cash from the TLD auctions be going? Surely ICANN doesn't need a multi-billion $ annual budget, but if these TLD auctions go the way of the cellular auctions, there's a good potential for that kind of an outcome.
This gives an (unofficial) estimate : <http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pando...
.confusion: ICANN opens up Pandora's Box of new TLDs By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT <snip> Not every zany TLD will be immediately available to anyone who want to register a domain, however. Businesses must apply to register the TLD first, then go through a review process to ensure that it isn't offensive and doesn't infringe on anyone's intellectual property. If approved, registering the TLD will cost anywhere from $100,000 to $500,000, ICANN says, and the business or organization must prove that they are either capable of managing the TLD or can reach a deal with a company that will. This is no small beans—unless you're planning to fork over up to half a million dollars and put in the labor to manage everything that appears under the TLD, this task is probably best left to large organizations and governmental entities. The organization registering the TLD will also be responsible for determining whether it will be restricted to certain types of sites or open to the public. <snip> Regards Marshall
This gives an (unofficial) estimate :
<http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pando...
.confusion: ICANN opens up Pandora's Box of new TLDs By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT
<snip> Not every zany TLD will be immediately available to anyone who want to register a domain, however. Businesses must apply to register the TLD first, then go through a review process to ensure that it isn't offensive and doesn't infringe on anyone's intellectual property. If approved, registering the TLD will cost anywhere from $100,000 to $500,000, ICANN says, and the business or organization must prove that they are either capable of managing the TLD or can reach a deal with a company that will. This is no small beans—unless you're planning to fork over up to half a million dollars and put in the labor to manage everything that appears under the TLD, this task is probably best left to large organizations and governmental entities. The organization registering the TLD will also be responsible for determining whether it will be restricted to certain types of sites or open to the public. <snip>
Thanks for the info. Okay, well that kind of pricing will prevent most of the fraudsters from obtaining TLDs. But of course it doesn't prevent shady operators from setting up a TLD with lenient abuse controls - such as .info or .to. Imagine 40 .infos spamming away...
On Jun 26, 2008, at 7:58 PM, Ken Simpson wrote:
This gives an (unofficial) estimate :
<http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pando...
.confusion: ICANN opens up Pandora's Box of new TLDs By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT
<snip> Not every zany TLD will be immediately available to anyone who want to register a domain, however. Businesses must apply to register the TLD first, then go through a review process to ensure that it isn't offensive and doesn't infringe on anyone's intellectual property. If approved, registering the TLD will cost anywhere from $100,000 to $500,000, ICANN says, and the business or organization must prove that they are either capable of managing the TLD or can reach a deal with a company that will. This is no small beans— unless you're planning to fork over up to half a million dollars and put in the labor to manage everything that appears under the TLD, this task is probably best left to large organizations and governmental entities. The organization registering the TLD will also be responsible for determining whether it will be restricted to certain types of sites or open to the public. <snip>
Thanks for the info. Okay, well that kind of pricing will prevent most of the fraudsters from obtaining TLDs. But of course it doesn't prevent shady operators from setting up a TLD with lenient abuse controls - such as .info or .to. Imagine 40 .infos spamming away...
What I wonder is what that amount is going to ? Is that a fee, or is it an estimate of what it would take to set up a registrar ? If it is the latter, GoDaddy or Network Solutions may start offering TLDs for a lot less. I don't see much of an intrinsic reason why it should be more than 1 hour of person time to evaluate, thus a cost in the $ 100's of USDs, plus ongoing registry costs. This https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf makes it look like much of the process could be automated. Regards Marshall
3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd.
It doesn't seem to me to be "anti-social" behavior to ensure when your customers mistype your domain as a .net or .de (depending on the customer's locale) that they still end up at your site. Definitely, wouldn't ascribe it as corporate greed. -J ________________________ Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com Voice: 208.343.8520 Mobile: 208.863.0727 FAX: 208.322-8522 E-mail: williamsjj@digitar.com XMPP/Jabber: williamsjj@digitar.com
On Jun 26, 2008, at 4:30 PM, Jason Williams wrote:
3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd.
It doesn't seem to me to be "anti-social" behavior to ensure when your customers mistype your domain as a .net or .de (depending on the customer's locale) that they still end up at your site. Definitely, wouldn't ascribe it as corporate greed.
You are welcome to ascribe it to whatever you want. I will note that very few Non-profit organizations engage in such behavior. Very few governments do so, either. In fact, absent a corporate profit motive, this behavior seems very rare. It is my considered opinion that turning control of the Domain Name system over to WIPO and allowing them to decide that domains and trademarks had common namespace to ill-defined levels of degree with different categorical mappings that also had undefined translations was one of the biggest mistakes in internet history. Owen
You are welcome to ascribe it to whatever you want. I will note that very few Non-profit organizations engage in such behavior. Very few governments do so, either. In fact, absent a corporate profit motive, this behavior seems very rare.
Given the level of customer service most governmental agencies and non-profits provide, they¹ve got a lot of other usability holes to fill first before they start worrying about their ³clients² going to the wrong website. Secondarily, their clients going to the wrong location isn¹t going to put them out of existence. So on the level that profit=existence I¹d agree it¹s definitely profit motivated. But greed is pejorative term.
-J
________________________ Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com Voice: 208.343.8520 Mobile: 208.863.0727 FAX: 208.322-8522 E-mail: williamsjj@digitar.com XMPP/Jabber: williamsjj@digitar.com
Owen DeLong wrote:
Whether some choose to do that or not, I believe that the point is that:
1. Nobody is FORCING them to do so.
2. Most are _NOT_ doing so.
3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd.
Owen
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. -- Jeff Shultz
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc.. Oh - vomit - this is gonna hurt. Regards, Ken
Once upon a time, Ken Simpson <ksimpson@mailchannels.com> said:
Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc..
Somebody on /. mentioned .dot, so you could tell someone to go to: eych tee tee pee colon slash slash slash dot dot dot -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Once upon a time, Ken Simpson <ksimpson@mailchannels.com> said:
Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc..
Somebody on /. mentioned .dot, so you could tell someone to go to:
eych tee tee pee colon slash slash slash dot dot dot
Yea, I thought that was funny when I owned www . wwwdotnet . net too....Lost a bit later on trying to explain to people. Then again TTSG (PPFG? TPSG? TPFG?) and "T dash B dash O dash H" aren't so fun either. Tuc
On 27 Jun 2008, at 02:13, Chris Adams wrote:
Once upon a time, Ken Simpson <ksimpson@mailchannels.com> said:
Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc..
Somebody on /. mentioned .dot, so you could tell someone to go to:
eych tee tee pee colon slash slash slash dot dot dot
Or .dash ...
On Thu, 26 Jun 2008 17:16:52 PDT, Ken Simpson said:
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc..
Oh - vomit - this is gonna hurt.
A cow-orker of mine said: "How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot"
On 27 Jun 2008, at 11:22, Valdis.Kletnieks@vt.edu wrote:
"How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot"
To my mind, Tony Finch owns you all :-) http://dotat.at/ dot@dotat.at Joe
On Fri, 27 Jun 2008, Joe Abley wrote:
To my mind, Tony Finch owns you all :-)
http://dotat.at/ dot@dotat.at
The Austrians should not have given up on their hierarchial naming scheme. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ NORTH FITZROY SOLE: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.
On Fri, Jun 27, 2008 at 11:44:35AM -0400, Joe Abley wrote:
On 27 Jun 2008, at 11:22, Valdis.Kletnieks@vt.edu wrote:
"How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot"
To my mind, Tony Finch owns you all :-)
http://dotat.at/ dot@dotat.at
Well, I believe the gent whose email is "up@3.am" is tied with him... 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
I see an auction on that one. Marshall On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote:
Owen DeLong wrote:
Whether some choose to do that or not, I believe that the point is that: 1. Nobody is FORCING them to do so. 2. Most are _NOT_ doing so. 3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd. Owen
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
-- Jeff Shultz
Followed by .bites And .rules and .rules And so the DNS descends into anarchy, and search engines become more empowered. Cacophony merely empowers those who control the amp.
-----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Thursday, June 26, 2008 5:20 PM To: Jeff Shultz Cc: NANOG list Subject: Re: ICANN opens up Pandora's Box of new TLDs
I see an auction on that one.
Marshall
On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote:
Owen DeLong wrote:
Whether some choose to do that or not, I believe that the point is that: 1. Nobody is FORCING them to do so. 2. Most are _NOT_ doing so. 3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd. Owen
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
-- Jeff Shultz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Shultz wrote:
Owen DeLong wrote:
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr =h1Jn -----END PGP SIGNATURE-----
On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Shultz wrote:
Owen DeLong wrote:
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
Who wants to be the first to try to register *.local?
They should have been following RFC 2606. Regards Marshall
Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224
My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr =h1Jn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marshall Eubanks wrote:
On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote:
Jeff Shultz wrote:
Owen DeLong wrote:
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
Who wants to be the first to try to register *.local?
They should have been following RFC 2606.
Regards Marshall
Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause. Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhkxHAACgkQUVxQRc85QlPfmgCgiIUv7KYOz/U2vdk2DyA04D/O 8Q4An2wK8vilUCJne06qIn/67erB2rkt =ih+F -----END PGP SIGNATURE-----
On Jun 27, 2008, at 6:44 AM, Jon Kibler wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marshall Eubanks wrote:
On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote:
Jeff Shultz wrote:
Owen DeLong wrote:
On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it.
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
Who wants to be the first to try to register *.local?
They should have been following RFC 2606.
Regards Marshall
Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause.
.localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect.
If you can think of a list, it probably would... Marshall
Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224
My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhkxHAACgkQUVxQRc85QlPfmgCgiIUv7KYOz/U2vdk2DyA04D/O 8Q4An2wK8vilUCJne06qIn/67erB2rkt =ih+F -----END PGP SIGNATURE-----
On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote:
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
Who wants to be the first to try to register *.local?
They should have been following RFC 2606.
Regards Marshall
Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause.
.localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect.
If you can think of a list, it probably would...
Having had the need to construct a few TLDs for internal use, I hope that some new RFC will address this and reserve some (e.g. .internal, .internal# (where # is any fully numeric string), .local)? I really don't care what they are called, but I do need more than one.
Marshall
Jon
<snip> -- -=[L]=- Helping to interpret the lives of the animals.
Dear Lou; On Jun 27, 2008, at 12:21 PM, Lou Katz wrote:
On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote:
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
Who wants to be the first to try to register *.local?
They should have been following RFC 2606.
Regards Marshall
Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause.
.localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect.
If you can think of a list, it probably would...
Having had the need to construct a few TLDs for internal use, I hope that some new RFC will address this and reserve some (e.g. .internal, .internal# (where # is any fully numeric string), .local)? I really don't care what they are called, but I do need more than one.
There are 4 already, .test .example .invalid .localhost . I suspect that .local should also be reserved, which would make 5. It seems that .internal# should just be blocked, not reserved. Before, the feeling was that the best blockage was a reservation, but as I read the ICANN presentation, if .internal was reserved, .internal# could be blocked too without an explicit reservation. Regards Marshall
Marshall
Jon
<snip>
--
-=[L]=- Helping to interpret the lives of the animals.
On Friday 27 June 2008 17:13:10 Marshall Eubanks wrote:
.localhost is already reserved through RFC 2606, so this should not be a problem.
.localdomain shouldn't cause a problem, since most Unix systems that use it put it in the name resolution before the DNS is invoked (i.e. /etc/hosts). ICANN have a technical review step in the procedure, which hopefully would flag a request for ".localdomain", I don't think we want to try to enumerate possible brokenness. Probably appropriate for the review step is to ask the root name server operators if there is substantive traffic for a proposed TLD, as if there is it may reveal a problem. That said substantive traffic for a proposed domain need not of itself block a request, ICANN are tasked with maintaining the stability of the net, not the stability of every broken piece of software on the net. Does anyone has a specific operational concerns - otherwise I think this topic should probably be laid to rest on this list.
On Fri, 27 Jun 2008, Jon Kibler wrote:
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers.
.local is also used by MDNS. (Nice interop problem there.) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
If they assign .local, they will break the default for AD, especially SBS, Apple Rendezvous, anything using mDNS/Zeroconf, and a lot of other "local significance only" uses of DNS, or, which is more likely, the domains in .local will find themselves unresolvable from a very large portion of the Internet. .local should be reserved.
-----Original Message----- From: Tony Finch [mailto:dot@dotat.at] Sent: Friday, June 27, 2008 12:21 PM To: Jon Kibler Cc: NANOG list Subject: Re: ICANN opens up Pandora's Box of new TLDs
On Fri, 27 Jun 2008, Jon Kibler wrote:
Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using
the logic
that .LOCAL is safe because it cannot be resolved by the root name servers.
.local is also used by MDNS. (Nice interop problem there.)
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Owen DeLong (owen) writes:
Whether some choose to do that or not, I believe that the point is that:
1. Nobody is FORCING them to do so.
Trademark law is forcing you to - you have to make reasonable attempts to actively defend your trademark. Of course, no-one forces you to trademark your name in the first place. Not that I agree with the practice, either. Phil
On Thu, Jun 26, 2008 at 11:07:57PM -0000, Martin Hannigan wrote: [ quoting me ]
And no, companies *aren't* "forced to pay for another domain name" just because a new TLD appears -- they aren't doing it *now*, by and large, and thank ghod:
The last time I looked there were a few thousand companies protecting their intellectual property by using companies like Mark Monitor to insure that they had defensive registrations in all ccTLD's possible.
Sure; MarkMonitor has a great sales staff. But the methods by which you can violate a trademark are *very* clearly defined, and the mere existence of a domain name doesn't seem to be one of them. IANAL. 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
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006?
How will ICANN be allocating these? An auction format? It will be a blood bath otherwise.. And for abuse and spam, this is a nightmare.
I hear from my friend's attending ICANN in Paris that there are tons of business folks who want to scoop up a gTLD. I haven't heard of anything that will be structured so looks like it will be a blood bath. Zaid On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006?
How will ICANN be allocating these? An auction format? It will be a blood bath otherwise.. And for abuse and spam, this is a nightmare.
On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:
How will ICANN be allocating these?
https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf Regards, -drc
David Conrad wrote:
On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:
How will ICANN be allocating these?
https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf
and http://www.circleid.com/posts/86262_launch_of_paris_domain_icann/ and http://www.circleid.com/posts/86269_icann_approves_overhaul_top_level_domain... and well the rest of CircleID. Some people are going to get very rich over this. I hope that they drown in the money just as the Internet will drown in all the crap TLD's, not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) And of course the people who like to grab typos will also have a field day with this. Thank you people doing all the ICANN politics for destroying the Internet. Greets, Jeroen
</lurk>
Thank you people doing all the ICANN politics for destroying the Internet.
You know, last time someone ( Robert Metcalfe <http://en.wikipedia.org/wiki/Robert_Metcalfe>) prophesied the death of the Internet, when it didn't come true... we made him eat his words. You up for a repeat ? :-P
Greets, Jeroen
<lurk>
R. Irving wrote:
</lurk>
Thank you people doing all the ICANN politics for destroying the Internet.
You know, last time someone ( Robert Metcalfe <http://en.wikipedia.org/wiki/Robert_Metcalfe>) prophesied the death of the Internet, when it didn't come true... we made him eat his words. You up for a repeat ?
Wow, you are comparing a nobody like me to a person like Dr. Metcalfe, I am honored, though I don't even start to think that I even compare to him in any way, thus why you come up with that comparison? Just amazing. That said, 'destroying' is not 'death at 11', also I am not so silly to do bets on things. Nice try, but it doesn't work for me. I guess you better stick to the lurking. As for destroying the Internet, it is going to work out that way, as the .com as we know it won't exist any more, and most people only think ".com" when they think Internet. Then again they also only know WWW and nothing else, which is why I really don't like this DNS change which is already solved with search engines. Greets, Jeroen
Some people are going to get very rich over this.
How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. In such a scenario, nobody makes much money unless they somehow link the TLD product to something else which is profitable. --Michael Dillon
Some people are going to get very rich over this.
How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck.
You might enjoy my blog entries about the .TRAVEL domain: http://weblog.johnlevine.com/ICANN/travelcroak.html http://weblog.johnlevine.com/ICANN/travelnotdead.html http://weblog.johnlevine.com/ICANN/traveldrain.html http://weblog.johnlevine.com/ICANN/travelstillnotdead.html
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. If only there was a way to get the cruft to move over into the new ones... On Fri, Jun 27, 2008 at 1:05 PM, John Levine <johnl@iecc.com> wrote:
Some people are going to get very rich over this.
How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck.
You might enjoy my blog entries about the .TRAVEL domain:
http://weblog.johnlevine.com/ICANN/travelcroak.html
http://weblog.johnlevine.com/ICANN/travelnotdead.html
On Jun 27, 2008, at 8:22 AM, Alexander Harrowell wrote:
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. If only there was a way to get the cruft to move over into the new ones...
Hey, please don't ignore .tv. No cruft from me, at least. Marshall
On Fri, Jun 27, 2008 at 1:05 PM, John Levine <johnl@iecc.com> wrote:
Some people are going to get very rich over this.
How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck.
You might enjoy my blog entries about the .TRAVEL domain:
http://weblog.johnlevine.com/ICANN/travelcroak.html
http://weblog.johnlevine.com/ICANN/travelnotdead.html
.tv is heavily used by the burgeoning Internet TV industry (including by yours truly). It may contain cruft, but it is certainly not all cruft. Regards Marshall On Jun 27, 2008, at 12:12 PM, John Levine wrote:
Hey, please don't ignore .tv. No cruft from me, at least.
The two letter country codes are a swamp all of their own, with no help from ICANN.
I hear that Tuvalu approximately doubled its GNP the year they sold the rights to .tv.
R's, John
Hi, On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote:
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst.
Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Of those messages that have origins (as extracted from the appropriate Received header) that do reverse map, the majority are in com and net. The mail origins of the top 10 TLDs from the last 30K spam messages I've received): unknown: 12487 net: 2586 com: 1664 pl: 1093 ru: 917 it: 851 br: 652 de: 479 th: 372 fr: 226 Biz, info, and name don't show up at all. Looking at the 'From' lines, I get: com: 13432 de: 8819 net: 1959 org: 1902 uk: 256 it: 246 nl: 240 edu: 229 au: 181 ca: 180 What cruft are you filtering using top-level domains? Thanks, -drc
already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Of those messages that have origins (as extracted from the appropriate Received header) that do reverse map, the majority are in com and net.
this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam. randy
Randy Bush wrote:
this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam.
Because it's Friday, I checked the last few weeks or so of logs from my personal mail server (located in the US), and broke the list of unique IP addresses rejected by zen.spamhaus.org up by registry: 49.2% RIPE 22.2% LACNIC 13.8% ARIN 13.5% APNIC 1.3% Afrinic ARIN's share may be slightly overstated, as it includes most of the legacy blocks. For what it's worth .... Jim Shankland
Jim Shankland (nanog) writes:
Because it's Friday, I checked the last few weeks or so of logs from my personal mail server (located in the US), and broke the list of unique IP addresses rejected by zen.spamhaus.org up by registry:
... spam coming from US computers vs. spam coming from botnets which are being rented by american spammers. There is a distinction. Don't think that legitimate american businesses aren't the only ones who've outsourced. A lot of people around the world running XP just don't know that they're doing the outsourcing :) P.
On Sat, Jun 28, 2008 at 08:41:28AM +0900, Randy Bush wrote:
this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam.
Globally, yes, but anti-spam measures aren't global: they're local. Everyone's mix is different: for example, during the past week, informal comparison of the incidence of pump-and-dumps spams revealed that one correspondent's have dropped to almost nothing, while another's continue to steadily increase. Global generalizations about spam trends are interesting, but not of much use in crafting local policy. The only thing that works for that is log analysis, in order to identify the composition of traffic and thus craft a policy (and then presumably implement it) that attempts to minimize the local FP/FN rates. (Note that FP/FN are always defined locally; there is no such thing as a general definition.) That said, global trends can provide some idea of what to look for in local traffic: for example, given the massive infestation of .info by spammers, phishers, spyware, adware, trojans, typosquatters, link farms, drive-by-downloaders, etc., it's very likely that most people will see a significant reduction in spam by blacklisting the TLD. ---Rsk
Randy Bush <randy@psg.com> writes:
this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam.
The US is also the largest single source of email-that-I-want. Conversely, it's safe to assume that anything encoded in BIG5 format is something I'm totally uninterested in. There are indeed entire countries that I could block with a false positive rate of less than one every five years, which is a lot better than some other antispam technologies. Not that I'm doing this though. RBLs, SA, and greylisting with a carefully crafted list of organizations I've found that don't play well, works "well enough", and having everything wired up so it runs at or before the end of the DATA phase means I don't get left holding the bag for anything. -r
On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote:
On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote:
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst.
Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map.
Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server. After that, other sanity checks (such as matching forward DNS, valid HELO, proper wait for SMTP greeting, etc.) also knock out a good chunk of spam. Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs. Beyond that, blocking of various gTLDs and ccTLDs and network allocations works nicely, depending on what your particular mix of inbound spam/not-spam is. Understanding of your own inbound mail mix is crucial to deciding which ones are viable for your operation. Locally, I've had .cn and .kr along with their entire network allocations blacklisted for years, and this has worked nicely; but clearly it wouldn't work well for, say, a major US research university. Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it. ---Rsk
Rich Kulawiec (rsk) writes:
Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server.
No, that's utterly stupid. You're excluding countries which have poor infrastructure or clueless ISPs (usually legacy telco operators) who can't be bothered to administrate IN-ADDR.ARPA delegations for their customers. It doesn't help, and only encourages people in these countries to go for @{hotmail|yahoo|gmail}. Millions of botnet PCs have valid reverses.
Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs.
You're kidding, right ? They don't give a rat's ass.
Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it.
"Bomb the bridge, salt the earth" approach ?
On Sat, Jun 28, 2008 at 01:56:53PM +0200, Phil Regnauld wrote:
Rich Kulawiec (rsk) writes:
Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server.
No, that's utterly stupid. You're excluding countries which have poor infrastructure or clueless ISPs (usually legacy telco operators) who can't be bothered to administrate IN-ADDR.ARPA delegations for their customers.
I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server.
Millions of botnet PCs have valid reverses.
Yes, I'm well aware of this, especially since I was AFAIK one of the first people to document the use of botnet PCs to send spam. And of course That's why this particular measure doesn't work for them, but other best practices do, e.g., rejecting mail from known-dynamic/generic IP space or known-dynamic/generic namespace unless it's your own customer or is being submitted with authentication non-port 25
Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs.
You're kidding, right ? They don't give a rat's ass.
Then they should not be troubled that their mail is being rejected.
Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it.
"Bomb the bridge, salt the earth" approach ?
I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide "information"?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else. I'm not the one responsible for failure to enforce any meaningful requirements on registrars to control abuse by their customers. And so on. I suggest laying blame on the people who are responsible for the current state of affairs, not on the recipients of abuse. ---Rsk
Rich Kulawiec (rsk) writes:
I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server.
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. Not that RFCs are ideal references for mail operation in general. Rejecting on missing or incorrectly formatted HELO/EHLO is legitimate, as well as unknown sender or recipient domain, as these are within the control of the sender, or the sender's organisation. Reverse DNS is not. It's all subjective of course.
people to document the use of botnet PCs to send spam. And of course That's why this particular measure doesn't work for them, but other best practices do, e.g., rejecting mail from known-dynamic/generic IP space or known-dynamic/generic namespace unless it's your own customer or is being submitted with authentication non-port 25
"known-dynamic" is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable. Probably bounces will be the next thing to disappear.
Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs.
You're kidding, right ? They don't give a rat's ass.
Then they should not be troubled that their mail is being rejected.
The operators don't care. The customers do. The customers don't have a choice, often. So you're right, the operator is not troubled that their customer's mail is being rejected.
"Bomb the bridge, salt the earth" approach ?
I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide "information"?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else.
Because .org and .com don't do that as well ?
I suggest laying blame on the people who are responsible for the current state of affairs, not on the recipients of abuse.
I'm not laying blame here, just pointing out that rejecting mail from IP addresses for which no PTR delegation exists is unwarranted, but it's your system, so of course it's up to you. Don't go preaching it as a best practice, though. Phil
ob spam... Spam is viral marketing for CHoRD? DNS can deal w/ billions of entries... order magnitude IPv4 space, with relative ease (note well the use of the term "relative") not at all convinced that unmodified DNS can deal w/ spaces on the order of magnitude of IPv6 space... *and yes, there is -zero- correlation btwn numbers and names, except if you want the pants whole. The analogy? Forward DNS is like the front half of your pants.... and the reverse map is the back half. Some folks are comfortable wearing only chaps, but I really want a complete pair thanks. --bill
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. Not that RFCs are ideal references for mail operation in general.
You're right, documents published by an organization whose goal is to design internetworking protocols are not the best place to find operational advice. For that you would be better to go to an organization like MAAWG which publishes this BCP: http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pd f On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry. Perhaps the RFC series doesn't have as many gaps as we think.
"known-dynamic" is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable.
If collateral damage is acceptable, then how is this absurd? Once you accept that it is better to reject good email than let bad email through, the game has changed. It may end up by destroying the business usefulness of the existing email architecture, but not without a push from someone who has a better mousetrap.
I'm not laying blame here, just pointing out that rejecting mail from IP addresses for which no PTR delegation exists is unwarranted,
This is quite simply, wrong. It is warranted.
Don't go preaching it as a best practice, though.
Too late, the MAAWG has already published this as a best practice for quite some time. If you don't follow the MAAWG best practices then you are not a serious email operator. If email is mission critical to your business, then you really should be an MAAWG member as well. --Michael Dillon P.S. I personally have nothing to do with the MAAWG although my company is an active member.
michael.dillon@bt.com (michael.dillon) writes:
http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf
Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction.
On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry.
Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR).
Perhaps the RFC series doesn't have as many gaps as we think.
For mail operations, we're half a galaxy away from "be conservative in what you send, be liberal in what you accept".
absurd, but I guess colateral damage is acceptable.
If collateral damage is acceptable, then how is this absurd?
Apologies, I was being sarcastic.
Once you accept that it is better to reject good email than let bad email through, the game has changed. It may end up by destroying the business usefulness of the existing email architecture, but not without a push from someone who has a better mousetrap.
Yep.
This is quite simply, wrong. It is warranted.
Not agreeing :) But fair enough, any site is allowed to operate mail the way it wants.
Don't go preaching it as a best practice, though.
Too late, the MAAWG has already published this as a best practice for quite some time. If you don't follow the MAAWG best practices then you are not a serious email operator. If email is mission critical to your business, then you really should be an MAAWG member as well.
We work for several customers and operate large mail installations. We implement quite a few requirements that are fairly strict, but rejecting based on missing PTR is not one of them. Neither is blacklisting entire TLDs for that matter, but I digress. I still feel like a serious mail operator, just because I don't conclude that I as the receiver should reject mail from a host with a missing PTR, because the MAAWG *Senders* BCP says that hosts should have a reverse. Phil
Comments in-line. -----Original Message----- From: Phil Regnauld [mailto:regnauld@catpipe.net] Sent: Saturday, June 28, 2008 1:02 PM To: michael.dillon@bt.com Cc: nanog@nanog.org Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs michael.dillon@bt.com (michael.dillon) writes:
http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf
Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. FB> You do have an option -- ask the sender to clean up their act. Then the operator/ISP will happily receive the sender's e-mail. When one of our business customers complains to us (ISP) that they can't send e-mail to an external third-party and I find out it's due to poor configuration on their part (almost 100% of the time -- the sole exception that I can recall is a business customer's IP address being blocked by a GoDaddy RBL even though another properly SWIPed customer was sending the spam. Apparently GoDaddy's minimum block size is /24 and they can't bother to look up the ranges), I don't complain about the external third-party, I educate our business customer on best practices.
On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry.
Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). FB> The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure? Of course, the inverse it not true. <snip>
On Sat, Jun 28, 2008 at 2:21 PM, Frank Bulk - iNAME <frnkblk@iname.com> wrote:
FB> The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure?
And to that point, a valid rDNS entry can easily be removed by the netblock holder at smal co-lo facility. This is an easy, although not widely used enough, means for co-lo providers to retain control over leased (mail) servers without worrying about the legal issues with pre-maturely taking a customer offline. I've never seen a posted service delivery statement that guaranteed PTRs. In fact, IMHO, PTRs are a courtesy from the netblock owner, not a given. -Jim P.
re: reverse DNS and emails. There are well documented and fairly simple tasks to reduce spam. requiring rdns, using rbls and blocking certain IP blocks goes a long way. The biggest problem however are outfits like microsoft whose hotmail/msn properties have undocumented logic which confirm reception of the message at the SMTP/821 level but then proceed to discard the email instead of delivering it to the person's inbox (or spam folder). Because they are unfortunatly popular, this means that sending email to users of those systems has become untrustable since you need to phone them to ensure they got the email. And it is impossible to talk to a "postmaster" at hotmail to know why hotmail sometimes/often doesn't like your emails even though you abide by standard rules. (rdns, spf etc) Spam getrs you more than you bargained for, but you still get your legitimate emails. But hotmail/MSN discard legitimate emails without warning and that makes SMTP untrustable and this is a far more serious issue. The original mantra of either discarding the email during SMTP conversation, or sending a non delivery notification should be strictly adhered to. When email becomes unreliable (thanks to microsoft), people stop using it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 28, 2008, at 4:56 PM, Jean-François Mezei wrote:
The biggest problem however are outfits like microsoft whose hotmail/ msn properties have undocumented logic which confirm reception of the message at the SMTP/821 level but then proceed to discard the email instead of delivering it to the person's inbox (or spam folder).
At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null? Yesterday I received 4,932 emails. 294 of those went into my inbox. 36 of those went info my quarantine folder. The other 4,602 went straight to /dev/null (actually many of them went through various blacklist building scripts first). Had I put the full 4,638 into a "spam folder" that would have been completely worthless. It would be impossible for me to actually review all those emails. Ultimately, there wouldn't be any difference between that and /dev/null. The only difference is I would have deleted them later rather than when they came in. So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com). The size of the problem presented by spam is just enormous. Before we started selective greylisting, we used to accept a million messages a day. Of those we only delivered about 50,000. And that's for a system only handling about 5,000 email accounts. I can't even imagine having to do that on the scale hotmail is talking about. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkhmukwACgkQElUlCLUT2d0yNgCfRhVBqk3lo3X4p6pVJ8i32c4F MIEAn18tJAhIhgvWtIbuqLxFR7TKJB/q =Cump -----END PGP SIGNATURE-----
some folk on this list are network operators. i.e. what you do with your personal mailbox is not highly interesting. we have this silly problem called "paying users." the issue is what an mta operator does for hundreds, thousands, or more of these pesky critters. at least in my world, they seem to have significantly higher tolerance for 100 spams than one dropped ham. they may whine about blow-back from a joe job, but they will go bleeping nuts if they lose one message from a legitimate contact. and i suspect that this aversion to beta errors is not irrational; think postal mail. the issue, at least to me, is keeping mail drop alpha error reasonably low while keeping beta error as close to zero as possible. so please excuse me if i do not take talk about blocking some form of dns silliness, or a continent of ip addresses, or ... very seriously. we now return you to our regular channel of telling icann what it should do at layer fourteen, a subject on which we have deep expertise. randy
So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com).
Of course not. You should have rejected them. Note that rejection doesn't keep you from using them to tune your filters. My MTA does much of its filtering at the end of data, and if it decides the message isn't going into the nominal recipient's mailbox, it returns a 553 status, then dumps the message into the spamtrap. R's, John
On Sat, 28 Jun 2008 17:25:16 -0500 Chris Owen <owenc@hubris.net> wrote: [snip]
So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com).
Of course you shouldn't accept and bounce them; you should not accept them at all. Reject them up front. -- John
[Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen <owenc@hubris.net> wrote a message of 53 lines which said:
At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null?
To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it". In a professional environment, I would not accept the idea of email disappearing without being able to recover it.
Stephane Bortzmeyer wrote:
It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it".
In a professional environment, I would not accept the idea of email disappearing without being able to recover it.
In my view of a "professional environment" (what ever that turns out to mean) a log file would enable that, without any of the problems holding mail text might engender. "Did you get the email from...to...? "Yes" "Please tell the court what it said." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
You mean, you don't employ *any* spam mitigation techniques besides sorting? Because if you do anything, even as basic as RBLs, you're not being consistent with your stance. Frank -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Sunday, June 29, 2008 3:08 PM To: Chris Owen Cc: nanog Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs [Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen <owenc@hubris.net> wrote a message of 53 lines which said:
At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null?
To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it". In a professional environment, I would not accept the idea of email disappearing without being able to recover it.
On Sun, Jun 29, 2008 at 03:30:15PM -0500, Frank Bulk - iNAME <frnkblk@iname.com> wrote a message of 35 lines which said:
Because if you do anything, even as basic as RBLs, you're not being consistent with your stance.
The typical use of RBLs is to reject email at the SMTP level, when it matches an entry in the RBL. That way, the sender is warned that something went wrong, email does not disappear silently.
On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen <owenc@hubris.net> wrote a message of 53 lines which said:
It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it".
In article <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAA AATbSgAABAAAACflLoEBLafQbWWwpT+evpQAQAAAAA=@iname.com>, Frank Bulk - iNAME <frnkblk@iname.com> writes
You mean, you don't employ *any* spam mitigation techniques besides sorting? Because if you do anything, even as basic as RBLs, you're not being consistent with your stance.
I agree completely with Chris Owen's approach, even though I use spam mitigation techniques. The reason for this is because those "lost" emails that I very occasionally rescue from the spam bucket are: NOT sent by someone on an RBL NOT sent to an unpublished and unused address (eg sales@internetpolicyagency.com) etc. -- Roland Perry
Chris Owen <owenc@hubris.net> wrote
It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it".
The magic keyword: REJECT-ON-SMTP-DATA. Aka during the "DATA" phase of the email, also directly scan it, then when the spam/virus tool thinks it is spam/virus, you just reject it. This solves a couple of things in one go: - You don't have to handle bounces if you would send a bounce back to the sender "hey you had a spam/virus" because you already accepted the mail, thus less overhead at least there - The sending SMTP server will send a bounce back to the sender. The sender thus gets a SMTP rejection mail, with the rejection reason and knows that you didn't accept the message and why. They can then opt to change the content of the mail or contact you differently. - No more 'spam' folder, as the stuff that is spam is already rejected. You might get a few mails through that are actually spam, but this is mostly marginal. This thus solves completely that email "gets lost". Also note that if a virus/bot or something else silly is trying to send these mails it either has to handle the bounces, which they generally (afaik ;) don't, thus the faked sender doesn't get a swamp of failed deliveries either. This is a Win-Win situation in my ears. Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can better let sending SMTP servers queue a bit (or throttle them) then having to process them anyway later. Of course not all mail platforms can be fitted in this way, but people who have such systems probably already have other ways to handle things. For the excellent Spamassassin, read: http://wiki.apache.org/spamassassin/IntegratedInMta The 'milter' options (originally sendmail, but nowadays also available for other mailers) can do this for you. Other anti-spam tools might also be able to do similar things. YMMV. Oh and of course as a access-ISP, one should also employ this trick to the customers, that way they know that they are sending spam ;) Greets, Jeroen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 1, 2008, at 4:54 AM, Jeroen Massar wrote:
Chris Owen <owenc@hubris.net> wrote
I did not write this FYI.
It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it".
The magic keyword: REJECT-ON-SMTP-DATA.
Aka during the "DATA" phase of the email, also directly scan it, then when the spam/virus tool thinks it is spam/virus, you just reject it.
This solves a couple of things in one go:
- No more 'spam' folder, as the stuff that is spam is already rejected. You might get a few mails through that are actually spam, but this is mostly marginal.
The lack of a spam folder is one of the problems with such a solution. Having a middle ground quarantine is actually quite nice. However, the biggest problem is these solutions are global in nature. We let individual customers considerable control over the process. They can each set their own block and quarantine levels, configure their own white and blacklists and even turn the spam controls completely off. For various reasons none of that would be possible with this solution and all the implementations you link to all run with a single global configuration. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkhqPvIACgkQElUlCLUT2d2nTQCfVq/dXvpBSVZnbgMyblgwhSp2 hD8AoIBxoz9UupxznPpZ9cC4FJ6fMc1y =Ze+j -----END PGP SIGNATURE-----
Chris Owen wrote:
The lack of a spam folder is one of the problems with such a solution. Having a middle ground quarantine is actually quite nice.
However, the biggest problem is these solutions are global in nature. We let individual customers considerable control over the process. They can each set their own block and quarantine levels, configure their own white and blacklists and even turn the spam controls completely off. For various reasons none of that would be possible with this solution and all the implementations you link to all run with a single global configuration.
Chris, I can think of one spam filter that does give both you and your users individual control over all of these settings while still rejecting mail during the SMTP dialog including the DATA phase: CanIt-Pro. http://www.roaringpenguin.com/ CanIt-Pro is a mail filter or 'milter' in Sendmail-speak. It essentially connects into Sendmail from the side. Sendmail calls on it during the SMTP dialog with the remote MTA, giving CanIt-Pro the opportunity to work its magic before the message is accepted for delivery which allows from rejecting mail right up until the last second RFC 2821 permits it. I use CanIt-Pro for this very reason. Each user can have their own individual mail "stream" in CanIt terminology. Each user can define white/blacklists by senders, domains and hosts. Users can block or permit by MIME types or perform actions based on attachment suffixes. They can write their own rules with regexs against the headers or body as well as checking to see if a sending domain matches that of the relaying MTA (not always accurate but often is; ebay.com is a good example). Users can enable or disable individually configured DNSBLs or change the score. They can even define rules based on SPF values. Each user gets their own bayesian DB as well. You as an admin can disable any of the above features on a per-user basis so you can make it as simple or as complex as you want. You can also pre-define streams with specific settings that users can subscribe to if they don't want the more fine-grained control. I created a stream that only tags suspect spam. I also created 3 streams with varying levels of aggressiveness. Have you ever heard the phrase "a pilot's plane"? Well I would liken CanIt to being the equivalent for mail admins and their spam filters. I first started using the OSS predecessor to CanIt back in late 2000 or so called MIMEDefang. MD is still the underpinnings of CanIt. When you buy CanIt you also get the source code so you have the ability to code in custom things if you have the need and desire. It's perfect for SPs. BTW, I'm not a Roaring Penguin employee. I'm just an impressed user of their products so they've earned my loyalty. Justin
On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote:
The magic keyword: REJECT-ON-SMTP-DATA. [snip description on how to reject during DATA phase]
Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can
More than that: you also need to have all users in the domain (indeed all users who share an MX server) agree on the accept/reject policy. If users are free to use different spam filtering techniques and tune them to their liking (e.g. someone uses SpamAssassin with a low threshold, someone else uses it with a high threshold, someone else uses bogofilter instead) then what do you do with mails that are addresses to more than one user? You can have some users reject the message during the RCPT phase and others accept it, but if you've waited until the DATA phase, it's too late for that. -Phil
Phil Vandry wrote:
On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote:
The magic keyword: REJECT-ON-SMTP-DATA. [snip description on how to reject during DATA phase] Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can
More than that: you also need to have all users in the domain (indeed all users who share an MX server) agree on the accept/reject policy. If users are free to use different spam filtering techniques and tune them to their liking (e.g. someone uses SpamAssassin with a low threshold, someone else uses it with a high threshold, someone else uses bogofilter instead) then what do you do with mails that are addresses to more than one user? You can have some users reject the message during the RCPT phase and others accept it, but if you've waited until the DATA phase, it's too late for that.
Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin
I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message and another is going to reject it, you have lost the ability to communicate this back to the sender (at least without an NDR). Thus the problem of mails disappearing into spam folder black holes is back in the multirecipient case when one is dealing with DATA and recipients have differing spam policies. - S -----Original Message----- From: Justin Shore [mailto:justin@justinshore.com] Sent: Saturday, July 05, 2008 2:05 AM To: Phil Vandry Cc: nanog@merit.edu Subject: Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin
I'd have to think of this one. I'm not sure what CanIt would do in such a case. A NDR may be the only way in that scenario. I'll sleep on it. Justin Skywing wrote:
I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message and another is going to reject it, you have lost the ability to communicate this back to the sender (at least without an NDR). Thus the problem of mails disappearing into spam folder black holes is back in the multirecipient case when one is dealing with DATA and recipients have differing spam policies.
- S
On Sat, Jun 28, 2008 at 05:56:23PM -0400, Jean-Fran?ois Mezei wrote:
The original mantra of either discarding the email during SMTP conversation, or sending a non delivery notification should be strictly adhered to. When email becomes unreliable (thanks to microsoft), people stop using it.
I agree with your sentiments -- that notification is essential in order to provide a heads-up about problems (and that once problems are noticed, cooperation is essential in order to fix them). But mail should never be discarded without notice, and NDN's should never be sent (MTA-to-MTA, which is a different matter than MSA-to-MTA): it should either be accepted (and delivered) or rejected (and not delivered). This provides accurate notification to the sending MTA of the disposition of the message, and it avoids outscatter spam. Of course, this doesn't do anything to elicit cooperation from either side, but at least it makes problems visible (provided nobody's MTA mangles or drops the reject notice) so that there's a decent chance of figuring *whose* cooperation is needed. ---Rsk
Phil Regnauld wrote:
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC.
As a practical matter, I've found that sending out email from a host without rDNS doesn't work: too many sites bounce the mail. It will not come as news to anyone on this list that the world of SMTP is hardly well-defined or well-regulated in practice. Like Rowlf the dog, we can't live with it, we can't live without it, but we're stuck until something better comes along: http://www.youtube.com/watch?v=1vvV9LjBsNw Jim Shankland
On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote:
Rich Kulawiec (rsk) writes:
I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server.
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC.
There are de jure requirements (e.g., RFCs) and de facto requirements (e.g., best practices). de jure: RFC 1912, I believe, indicates that all Internet hosts should have rDNS. de facto: attempting run a mail server without rDNS is increasingly a losing proposition, as everyone with any clue at all is refusing all mail from such misconfigured/broken/ hijacked hosts.
Reverse DNS is not.
Not directly, unless delegated, of course. But mail server operators who choose incompetent/lazy/cheap ISPs should not be surprised if they are given incompetent/lazy/cheap service. Quality ISPs are well aware of the de jure and de facto requirements and have no problem meeting them.
"known-dynamic" is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable.
There is no such thing as "collateral damage" because there is no such thing as "damage" in this context. I explained this in detail on the ietf-asrg mailing list a couple of months ago. And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication.
Probably bounces will be the next thing to disappear.
Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts.
The operators don't care. The customers do. The customers don't have a choice, often. So you're right, the operator is not troubled that their customer's mail is being rejected.
Then that's a matter between the customer and the operator. Customers who have chosen poorly are likely to have issues. Customers who have not availed themselves of other options (such as a third-party relay through a host whose operators actually knows what they're doing) will get...what they get.
I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide "information"?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else.
Because .org and .com don't do that as well ?
I see a fundemental difference here. .org is for organizations, .com for commercial operations, .net for network service operations. I see valid uses for those. I see none for .info. Its main reason for existence is to provide a cash cow to registrars.
Don't go preaching it as a best practice, though.
<shrug> It's been a best practice for years. ---Rsk
On 6/28/08, Rich Kulawiec <rsk@gsp.org> wrote:
On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote:
Rich Kulawiec (rsk) writes: ... And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication.
Probably bounces will be the next thing to disappear.
Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts.
Those two statements of yours directly contraindicate each other. If end user systems should use outbound mail relays, then the relay system is the one accepting the mail from the mail client, and will be responsible for sending out to the end system; it cannot make a determination as to whether the mail will be deliverable or not during the SMTP conversation with the client machine; it will only find out if the mail is actually deliverable when it in turn goes to establish an SMTP conversation with the receiving system, at which point if the receiving system indicates the message will not be deliverable, there is no way other than by generating a bounce message for the relay system to notify the original sender that the mail was undeliverable. Or, are you proposing that outbound mail relays hold the *client* connection state in limbo until they establish an outbound connection to the final destination, determine the deliverability of the final recipient, and *only then* acknowledge receipt of the message back to the client machine? If so, I think you may hear the distributed sound of every operator of outbound mail relay systems for ISPs of any scale *plonk*ing you in their "clueless" bucket. ^_^; In case it wasn't clear, a relay system like that simply won't scale at all, as the number of simultaneous pass-through connections required would increase as the ability to batch-process sending to common recipient systems would drop to near zero, End users would quickly cry foul and abandon operators who attempted such a system, as it would mean a slow-responding MTA box at the recipient end would hang their mail client as it waited to hear back from the relay host as to whether their attempt to send mail had succeeded or not. Until the entire concept of SMTP is replaced with something drastically different, along the lines of a real-time message passing system closer to IRC or IM, bounces are the only means for notifying a sender that a message could not be delivered. Matt
On Sat, Jun 28, 2008 at 01:12:39PM -0700, Matthew Petach wrote:
Those two statements of yours directly contraindicate each other.
No, they don't. Outbound relays (which are presumably used by client systems presenting appropriate authentication) know the identity of user presenting credentials. They can thus return a NDN (or similar) to that user, i.e., there's no concern about outscatter. But worth noting is that this works *because* the mail is being submitted with user authentication -- it won't work for a relay that doesn't do that. That's a very different situation from case where the same outbound relay is talking to a random mail server elsewhere on the 'net. Attempts by such random mail servers to "return" bounces to their origin (from when they never came) are outscatter, which is why rejects are much preferred. (Yes, I'm aware of various mail authentication proposals. Whatever they are/aren't, they're not the right solution to this specific problem: the solution is to always reject, never bounce.) ---Rsk
On Jun 28, 2008, at 6:48 AM, Rich Kulawiec wrote:
On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote:
On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote:
Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst.
Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map.
Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server.
After that, other sanity checks (such as matching forward DNS, valid HELO, proper wait for SMTP greeting, etc.) also knock out a good chunk of spam.
Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs.
Beyond that, blocking of various gTLDs and ccTLDs and network allocations works nicely, depending on what your particular mix of inbound spam/ not-spam is. Understanding of your own inbound mail mix is crucial to deciding which ones are viable for your operation. Locally, I've had .cn and .kr along with their entire network allocations blacklisted for years, and this has worked nicely; but clearly it wouldn't work well for, say, a major US research university.
Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it.
Hmm. Looking at the recent spam collection plus email archive for the accounts I host for SPAM (recent messages only) 13864 messages - 57 from .info rate = 0.4 % 13864 messages - 8761 from .com rate = 63.1 % Non-SPAM (going back ~ two years) 122846 messages - 607 from .info - rate = 0.5 % 122846 messages - 71888 from .com - rate = 58.5 % I don't see any strong reason to drop .info traffic here. Note, btw, that at least Joe Abley, Andrew Sullivan and Brian Dickson post to NANOG repeatedly from .info Regards Marshall
---Rsk
On Thu, 26 Jun 2008, Jeroen Massar wrote:
thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :)
.exe has the same security properties as .com Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ TYNE DOGGER FISHER: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.
Tony Finch wrote:
On Thu, 26 Jun 2008, Jeroen Massar wrote:
thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :)
.exe has the same security properties as .com
not exactly, as a lot of users know that there is something like a .com domain. they will expect something else from .exe but for automated security, i quite agree. cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________
On Jun 28, 2008, at 4:19 AM, Raoul Bhatia [IPAX] wrote:
Tony Finch wrote:
On Thu, 26 Jun 2008, Jeroen Massar wrote:
thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :)
.exe has the same security properties as .com
not exactly, as a lot of users know that there is something like a .com domain. they will expect something else from .exe
I'm not sure I understand the security threat here. Is the theory that someone will click on "foo.exe" and the fact that it is a URL is somehow worse than if it is an actual executable? If that's not it, can someone explain (small words, with subtitles -- I'm not a security geek). Thanks, -drc
On Thu, Jun 26, 2008 at 11:53:06PM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 49 lines which said:
not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ?
This requires serious elaboration. How could you use a domain in ".exe" to actually attack someone? (No handwaving, please, actual study.)
Thank you people doing all the ICANN politics for destroying the Internet.
The Internet, until now, resisted to forces much more powerful than ICANN.
On Jun 29, 2008, at 5:45 AM, Stephane Bortzmeyer wrote:
On Thu, Jun 26, 2008 at 11:53:06PM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 49 lines which said:
not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ?
This requires serious elaboration. How could you use a domain in ".exe" to actually attack someone? (No handwaving, please, actual study.)
I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ? Regards Marshall
Thank you people doing all the ICANN politics for destroying the Internet.
The Internet, until now, resisted to forces much more powerful than ICANN.
This requires serious elaboration. How could you use a domain in ".exe" to actually attack someone? (No handwaving, please, actual study.)
I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ?
I think this would be one of the TLDs that they'd refuse. Then again, there are DOS commands that do end in .com (CHOICE, COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : http://support.microsoft.com/kb/72188 Tuc/TBOH
On Sun, 29 Jun 2008, Tuc at T-B-O-H.NET wrote:
This requires serious elaboration. How could you use a domain in ".exe" to actually attack someone? (No handwaving, please, actual study.)
I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ?
I think this would be one of the TLDs that they'd refuse. Then again, there are DOS commands that do end in .com (CHOICE, COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : http://support.microsoft.com/kb/72188
What about .stupid? Gadi.
Tuc/TBOH
* Jeroen Massar:
Some people are going to get very rich over this. I hope that they drown in the money just as the Internet will drown in all the crap TLD's, not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :)
.exe abd .com are equivalent in this regard. Oops.
Thank you people doing all the ICANN politics for destroying the Internet.
I don't really see how this is substantially different from .me, .mobi, .cat or .eu. Basically, selling TLDs means that ICANN has some sort of implied non-technical obligation of keeping them relatively scarce, which is currently lacking AFAICT.
On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote:
How will ICANN be allocating these? An auction format? It will be a blood bath otherwise.. And for abuse and spam, this is a nightmare.
There's no doubt this last will happen since it has *already* happened, as I pointed out in a note to Dave Farber's IP list earlier today. For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing. It simply became too onerous to maintain a blacklist with hundreds of thousands of individual domains and hundreds of additions per day. We never needed a .info TLD and soon its existence will be moot -- well, except for all the money wasted dealing with squatters and typosquatters and spammers and phishers and other abusers. This follows on the heels of .biz, which is so broadly blacklisted that not even spammers tend to use it much any more. And so on. So the outcome of this is inevitable: expense, litigation, hassle, spam, abuse, and oh-by-the-way massive profits for registrars, which had nothing at all to do with ICANN's decision. Of course not. ---Rsk
On Thu, Jun 26, 2008 at 10:49 PM, Rich Kulawiec <rsk@gsp.org> wrote:
So the outcome of this is inevitable: expense, litigation, hassle, spam, abuse, and oh-by-the-way massive profits for registrars, which had nothing at all to do with ICANN's decision. Of course not.
Perhaps this is straying into OT land... (but I must push the envelope!) ;-) Is there any "full disclosure" clause in ICANN member contracts such that gifts from, or stock in, a Registrar would be declared? -Jim P.
On Jun 26, 2008, at 8:12 PM, Jim Popovitch wrote:
Is there any "full disclosure" clause in ICANN member contracts such that gifts from, or stock in, a Registrar would be declared?
Not sure who an "ICANN member" would be. ICANN as a California 501c(3) has to publish all it's financial details. The ICANN Board of Trustees (who makes the final decision within ICANN on TLD-related matters) must abide by a Conflict of Interest Policy (http://www.icann.org/committees/coi/coi-policy-04mar99.htm ). Regards, -drc
...which is why it might be a strategy to blacklist all new TLDs (if this proposal gets through) and whitelist just .com, .net, etc. Frank -----Original Message----- From: Rich Kulawiec [mailto:rsk@gsp.org] Sent: Thursday, June 26, 2008 9:50 PM To: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote:
How will ICANN be allocating these? An auction format? It will be a blood bath otherwise.. And for abuse and spam, this is a nightmare.
There's no doubt this last will happen since it has *already* happened, as I pointed out in a note to Dave Farber's IP list earlier today. For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing. It simply became too onerous to maintain a blacklist with hundreds of thousands of individual domains and hundreds of additions per day. We never needed a .info TLD and soon its existence will be moot -- well, except for all the money wasted dealing with squatters and typosquatters and spammers and phishers and other abusers. This follows on the heels of .biz, which is so broadly blacklisted that not even spammers tend to use it much any more. And so on. So the outcome of this is inevitable: expense, litigation, hassle, spam, abuse, and oh-by-the-way massive profits for registrars, which had nothing at all to do with ICANN's decision. Of course not. ---Rsk
On Thu, Jun 26, 2008 at 10:37:34PM -0500, Frank Bulk - iNAME <frnkblk@iname.com> wrote a message of 37 lines which said:
...which is why it might be a strategy to blacklist all new TLDs (if this proposal gets through) and whitelist just .com, .net, etc.
Interesting. I do not know if this strategy will be implemented or not but, if it is, it will be a big change in Internet governance. No longer will the TLDs in the root be decided by ICANN or by its master, the US government, but they will have to be "vetted" by an informal group of network operators. A boycott by this group could have devastating effects for a business. We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) It will be an interesting turn back to the european cities of the Middle Age, with guilds approving (or, more often, disapproving) every technical or business novelty...
We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN.
As an active participant in both the IETF and MAAWG, and a former member of the ICANN ALAC, I can assure you that MAAWG would be delighted to stop publishing its own BCPs about email and abuse management, reflecting the experience of the largest mail systems on the planet, if the IETF or ICANN would get their heads out of their navels and do so. A mail system configured according to current RFCs would be useless, since nobody would be able to find the trickle of legit mail in the torrent of spam, even assuming the mail system didn't melt down from the load.
I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.
All those mean old ISPs are, in case you hadn't noticed, delivering the mail you send them for free. If you find it too much trouble to configure your DNS in accordance with STD 13, which has been around for over 20 years, I expect they'll also find it too much trouble to try and tell your mail apart from the 99.999% of no-rDNS hosts that are spambots. Spam sucks, complaining about it won't make it go away. Indeed, the reason we're making so little progress against it is that far too many people just complain and expect someone else to solve the problem. R's, John
On Sun, 29 Jun 2008, John Levine wrote:
We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN.
As an active participant in both the IETF and MAAWG, and a former member of the ICANN ALAC, I can assure you that MAAWG would be delighted to stop publishing its own BCPs about email and abuse management, reflecting the experience of the largest mail systems on the planet, if the IETF or ICANN would get their heads out of their navels and do so. A mail system configured according to current RFCs would be useless, since nobody would be able to find the trickle of legit mail in the torrent of spam, even assuming the mail system didn't melt down from the load.
I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.
All those mean old ISPs are, in case you hadn't noticed, delivering the mail you send them for free. If you find it too much trouble to configure your DNS in accordance with STD 13, which has been around for over 20 years, I expect they'll also find it too much trouble to try and tell your mail apart from the 99.999% of no-rDNS hosts that are spambots.
Spam sucks, complaining about it won't make it go away. Indeed, the reason we're making so little progress against it is that far too many people just complain and expect someone else to solve the problem.
I for one am happy MAAWG and other less public groups are out there. Nature abhors a vacuume and if one is there it will be filled. Gadi.
R's, John
On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote:
We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half.
The IETF is not good at specifying operational best practice and usually avoids trying to do so, but even so, the MAAWG recommendations are in line with what most IETF email experts think. AFAIK ICANN has no remit to say anything about email. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FAEROES SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
You do have a choice if you're not concerned about the deliverability of your e-mail. Remember, the Internet remains a group of service providers/organizations/subscribers that voluntarily work together and can choose what goes in or out. And so if they decide not to receive traffic from you, for any reason at all, there's no legal requirement. If they require that all e-mail servers that want to send e-mail to them have rDNS entries then persons who want to deliver e-mail to that entity need to comply. Frank -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Sunday, June 29, 2008 11:32 AM To: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs <snip> We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) <snip>
You do have a choice if you're not concerned about the deliverability of your e-mail. Remember, the Internet remains a group of service providers/organizations/subscribers that voluntarily work together and can choose what goes in or out. And so if they decide not to receive traffic from you, for any reason at all, there's no legal requirement. If they require that all e-mail servers that want to send e-mail to them have rDNS entries then persons who want to deliver e-mail to that entity need to comply.
Frank
So can I change my SMTP greeting to be : 220-host.example.com SMTP 220-Company agrees to the following rate chart to accept mail : 220-EHLO - $5.00 220-HELO - $2.50 220-MAIL FROM:<*> - Free 220-RCPT TO:<*> - 1-5/$4.00 , 6-10/$6.00, 11-15/$8.00, 15+/$10.00 220-DATA: $.01 per character until final ".<CR>" 220-Delivery confirmation (Return-Receipt-To, X-Confirm-Reading-To, Disposition-Notification-To) - $1.50 220 Sending HELO/EHLO constitutes acceptance of this agreement Thanks, Tuc/TBOH
On Sun, 29 Jun 2008 17:55:53 EDT, "Tuc at T-B-O-H.NET" said:
220 Sending HELO/EHLO constitutes acceptance of this agreement
Even in a UCITA state that has onerous rules regarding shrink-wrapped EULA terms, I think you'd have a very hard time getting a court to enforce an alleged contract based on this. And it's different from the usual suggestion to put "all activity may be monitored" in your telnet/ssh login banners, because there's an expectation that the human will look at a login banner when they login, but there's no expectation that an SMTP server will look at the 220 banner any further than checking the first digit is a '2' (go read the section on SMTP reply codes in RFC2821). Feel free to cite any relevant case law (in fact, even the case law on login banners read by humans is a tad skimpy - in most cases, it does nothing for intruders, but it protects you from your own users complaining their privacy was violated)...
On Jun 30, 2008, at 12:54 PM, Valdis.Kletnieks@vt.edu wrote:
On Sun, 29 Jun 2008 17:55:53 EDT, "Tuc at T-B-O-H.NET" said:
220 Sending HELO/EHLO constitutes acceptance of this agreement
Even in a UCITA state that has onerous rules regarding shrink- wrapped EULA terms, I think you'd have a very hard time getting a court to enforce an alleged contract based on this. And it's different from the usual suggestion to put "all activity may be monitored" in your telnet/ssh login banners, because there's an expectation that the human will look at a login banner when they login, but there's no expectation that an SMTP server will look at the 220 banner any further than checking the first digit is a '2' (go read the section on SMTP reply codes in RFC2821).
Feel free to cite any relevant case law (in fact, even the case law on login banners read by humans is a tad skimpy - in most cases, it does nothing for intruders, but it protects you from your own users complaining their privacy was violated)...
I have found the biggest advantage of banners to be the fact that you learn to recognize your own devices *before* typing your password... It you *always* have a banner on *all* of your devices, you quickly learn to expect them... For example: ssh router1.example.net ************************************************************** * This device belongs to example.net. Don't login if you * are not supposed to be here... Blah blah blah. * <><><><><><><><><><><><><><><><><><><><><> ************************************************************* wkumari@router1.example.net's password: versus: ssh router1.exsmple.net wkumari@router1.exsmple.net's password: Having a cute, customized banner (not the default from the standard security templates) helps with this... W -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen
On Thu, Jun 26, 2008 at 10:49:41PM -0400, Rich Kulawiec wrote:
For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing.
The irony that MailScanner's domain is mailscanner.info is absolutely deafening. 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
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
This all should have been solved by allowing those who wanted/applied for TLDs to be granted them back in 1995 when originally requested : http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html There was a procedure, people followed it, and IANA decided to go other ways with it. Now years later there is all this red tape restricting things. And if the "powers that be" decide to go back to it, you can replace stormking.com with t-b-o-h.net and I look forward to it! ;) Tuc / Scott Ellentuch
On Jun 26, 2008, at 9:20 PM, Tuc at T-B-O-H.NET wrote:
Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
This all should have been solved by allowing those who wanted/applied for TLDs to be granted them back in 1995 when originally requested :
http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html
The SNR in the gtld WG was very low, which I think may have been an influencing factor. I do have to wonder, however, what Eugene Kashpureff thinks about this. Regards Marshall
There was a procedure, people followed it, and IANA decided to go other ways with it. Now years later there is all this red tape restricting things.
And if the "powers that be" decide to go back to it, you can replace stormking.com with t-b-o-h.net and I look forward to it! ;)
Tuc / Scott Ellentuch
http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html
The SNR in the gtld WG was very low, which I think may have been an influencing factor.
Yeah, it was dominated by a bunch of small-scale amateur greedy speculators, while the solution was ICANN which is dominated by a bunch of large-scale professional greedy speculators. We did come up with the registrar/registry split, though. http://www.iahc.org/contrib/draft-iahc-levine-shared-00.txt R's, John
A while ago, there was come debate about the introduction of a .XXX gTLD with some of the folks objecting to its formation. Does anyone know how if the new gTLD system will still give some "veto" power to some people over some domain names that are morally objectable to some people ? I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI .CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc. Religions will be interesting especially in cases where there is no central representative for a religion who can make the official registration. And in the case where there would be global conflicts, what happens ? For instance, in the USA "ABC" is the american broadcasting companies, but in australia, it is the Australian Broadcasting Corporation. Is it fair to hand .ABC to either one of the two ? (highest bidder) or will ICANN "lock" .ABC out so that neither can get to it ? I am sure there are many such gTLDs around the world that would conflict across countries. Finally, will there be any performance impact on DNS servers around the world (thinking of caching issues) ?
On Jun 26, 2008, at 9:01 PM, Jean-François Mezei wrote:
Does anyone know how if the new gTLD system will still give some "veto" power to some people over some domain names that are morally objectable to some people ?
See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf
Is it fair to hand .ABC to either one of the two ? (highest bidder) or will ICANN "lock" .ABC out so that neither can get to it ? I am sure there are many such gTLDs around the world that would conflict across countries.
See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf
Finally, will there be any performance impact on DNS servers around the world (thinking of caching issues) ?
Extremely unlikely (IMHO). Regards, -drc
hi drc, does anyone find it droll that the jr high school like clique of root server operators is gonna bear the burden of this, while billy et alia sank the iana usefully signing the root? randy
See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf
I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin
Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote:
See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf
I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer.
https://par.icann.org/files/paris/BoardMeeting_26June08.txt
Best,
Martin
On Fri, 27 Jun 2008 00:01:23 EDT, =?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?= said:
Finally, will there be any performance impact on DNS servers around the world (thinking of caching issues) ?
It should be almost identical to the current performance impact on the second level DNS servers that have to handle 140M .com entries...
On Fri, Jun 27, 2008 at 12:01:23AM -0400, Jean-Fran?ois Mezei wrote:
Does anyone know how if the new gTLD system will still give some "veto" power to some people over some domain names that are morally objectable to some people ?
I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI .CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc.
.WOMEN-WITH-VISIBLE-FACES?
For instance, in the USA "ABC" is the american broadcasting companies, but in australia, it is the Australian Broadcasting Corporation.
Is it fair to hand .ABC to either one of the two ? (highest bidder) or will ICANN "lock" .ABC out so that neither can get to it ? I am sure there are many such gTLDs around the world that would conflict across countries.
Sure, which is why that's not what should be being *done* with GTLDs. But engineering issues will be the very least of anyone's concern here. Cheers, -- jra -- ay 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
participants (48)
-
'Stephane Bortzmeyer' -
Alexander Harrowell -
bmanning＠vacation.karoshi.com -
Chris Adams -
Chris Owen -
David Conrad -
Eric Brunner-Williams -
Florian Weimer -
Frank Bulk - iNAME -
Gadi Evron -
Ian Mason -
Jason Williams -
Jay R. Ashworth -
Jean-François Mezei -
Jeff Shultz -
Jeroen Massar -
Jim Popovitch -
Jim Shankland -
Joe Abley -
John Levine -
John Peach -
Jon Kibler -
Justin Shore -
Ken Simpson -
Laurence F. Sheldon, Jr. -
Lou Katz -
Marshall Eubanks -
Martin Hannigan -
Matthew Petach -
michael.dillon＠bt.com -
Owen DeLong -
Phil Regnauld -
Phil Vandry -
R. Irving -
Randy Bush -
Raoul Bhatia [IPAX] -
Rich Kulawiec -
Robert E. Seastrom -
Roland Perry -
Simon Waters -
Skywing -
Stephane Bortzmeyer
-
Tomas L. Byrnes -
Tony Finch -
Tuc at T-B-O-H.NET -
Valdis.Kletnieks＠vt.edu -
Warren Kumari -
Zaid Ali