Slashdot Mirror

ISOC Official Page
IETF Official Page
IESG Official Page
IRTF Official Page
IAB Official Page
RFC Editor Official Page
ICANN Official Page
IANA Official Page
W3C Official Page
W3C encyclopedia article
ICANN encyclopedia article
IANA encyclopedia article

• ISOC Official Page
• IETF Official Page
• IESG Official Page
• IRTF Official Page
• IAB Official Page
• RFC Editor Official Page
• ICANN Official Page
• IANA Official Page
• W3C Official Page
• W3C encyclopedia article
• ICANN encyclopedia article
• IANA encyclopedia article

ISOC Official Web Page

IETF Official Web Page

IESG Official Web Page

IRTF Official Web Page

IAB Official Web Page

RFC Editor Official Web Page

ICANN Official Web Page

IANA Official Web Page

W3C Official Web Page

W3C encyclopedia article

ICANN encyclopedia article and IANA encyclopedia article

ISOC Official Page IETF Official Page IESG Official Page IRTF Official Page IAB Official Page RFC Editor Official Page ICANN Official Page IANA Official Page W3C Official Page W3C encyclopedia article ICANN encyclopedia article IANA encyclopedia article

There are many technical problems with this change. It essentially undermines IDNA, which is now on standards track, by adding a level of guessing to the DNS that IDNA is explicitly designed to avoid. Further, it makes it appear that IDNs are only useful in domain names for web sites (and only for sites in .com and .net), and only at the second level. VGRS has said that their plug-in will not work with most of the ccTLDs, for example.

For example, if you enter .com in Internet Explorer for Windows, where "" is the single hex octet 0xE5, you see the screen shown in the attached file called "[lynn-message-to-iab-06jan03-]e5.tif". (Sorry about the TIFF image, but it's the only reliable format for PC screen dumps.) As you can see, VGRS makes wild guesses about what the user wanted, some of which are very clearly impossible. Worse yet, they do not include all of the legal guesses that they could have made. And, just to make it completely confusing to the user, not all of the choices work.

The DNS is not supposed to be a best-guess service, yet VGRS has turned .com and .net into this just before IDNA is to be an RFC. VGRS should not be allowed, through its monopoly on the .com and .net gTLDs, to destroy the coherence of the DNS for its own short-term profit. ICANN should demand that VGRS immediately stop giving incorrect answers to any query in .com and .net, and should instead follow the IETF standards. If VGRS refuses, ICANN should re-delegate the .com and .net zones to registries that are more willing to follow the DNS standards.

Unfortunately, you don't know what you're talking about. Afilias runs all of their registries on Postgres, and has done so since day one. (I know, I was there helping them go live with .info.)

If you want independent confirmation, check out their bids for the registries, such as
http://www.icann.org/tlds/org/questions-to-applica nts-13.htm#Response13TheInternetSocietyISOC
They got considerable flak for this the first couple times (orchestrated none too subtly by Oracle) ... but the competitors seem to have figured out that that argument isn't winning.

www.icann.org/transfers/policy-12jul04.htm

Instances when the requested change of Registrar may not be denied include, but are not limited to:

* Nonpayment for a pending or future registration period

* No response from the Registered Name Holder or Administrative Contact.

* Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.

* Domain name registration period time constraints, other than during the first 60 days of initial registration or during the first 60 days after a registrar transfer.

* General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration.

The bottom line to all of this is to provide accurate information with your domain registrations, and, lock the domain so that if your Registrar gets a notice that another Registrar wants to transfer your domain, it can't be transfered, even if you are not contactable (say, on a cruise or something).

Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer.

In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed.

Its not that domain owners have 5 days to respond to a transfer request. Its the Registrar where the domain is *currently* registered that has to respond within 5 days to approve or deny the transfer.

This policy was put in place because some Registrars were not being very forthcoming in transfers. In essense, this makes the originating Registrar in a domain transfer not be able to block a transfer by simply ignoring the request.

Registrars are still required to get explicit permission from the domain owners for a transfer. Read the entire policy at the provided link.

... [here] on the transfer process.

I have sent them my comment as follows:

One of the features of the recent PANIX domain hijacking which was particularly egregious was that the gaining registrar, Melbourne IT, did not have any technical staff on duty over a period of in excess of thirty six hours who had authority to review the transfer.

It seems to me that it would be reasonable to require registrars to have competent and authorised staff available at all times - '24/7' - to handle problems that arise. It also seems to me that it would be reasonable to require the gaining registrar to give the losing registrar and the registered owner of the domain seven days clear notice before executing a transfer request.

It is not as though the possibility of domain hijackings had not been flagged up as a possible consequence of the new less stringent process for domain transfer; ICANN has a duty to the Internet community to ensure that we don't see a spate of PANIX-style incidents.

ICANN is soliciting comments on the revised transfer policy: RFC. Let them know what you think.

Usually becoming a reseller requires little or no investment upfront (free signup, free software).

Becoming an ICANN accredited registrar means large fees and you also need to prove a substantial amount of working capital in order to be approved. Financial Requirements.

And, just to be nit-pickey, unless the company is ICANN accredited they are not actually a registrar (just a reseller).

Hmm, I smell a new google bomb! Theiving Bastards

ICANN's projected budget for 2003-2004 was in the region of $6M, and they looked pretty close to be breaking even.

What the holy badger-fuck are they going to do with another $3.8M? A 63% budget increase? Is the internet going to get 63% bigger? Or are they going to try to have 63% more fun? (from this looks of this, they need to try......)

ICANN's projected budget for 2003-2004 was in the region of $6M, and they looked pretty close to be breaking even.

What the holy badger-fuck are they going to do with another $3.8M? A 63% budget increase? Is the internet going to get 63% bigger? Or are they going to try to have 63% more fun? (from this looks of this, they need to try......)

I'm still waiting for it.

You simply have to look at it from ICAAN's point of view. They get money for domains. Even though they are supposedly a not-for-profit organization, they are collecting hundreds of thousands of dollars for silly things such as writing the RFP for .NET maintenance. The more domains that there are, the more money the "not-for-profit" organization can collect and spend. Network Solutions had problems... but at least they were somewhat beholden to a democratic body and was price regulated (and so is ICANN to an extent, I know -- but it just smells wrong when they collect $$$ just to "give" the rights to run .NET to Verisign for another five years).

If you go read the ICANN Policy on Transfer of Registrations between Registrars http://www.icann.org/transfers/policy-12jul04.htm it's quite explicit regarding the circumstances in which a registrar (aka Network Solutions, Dotster, Tucows, GoDaddy, etc - not the Registrant, billing or technical contacts) could deny a move request as well as under what circumstances they could not deny such a request (Nonpayment, No response from the Registered Name Holder or Administrative Contact, etc).

I'm no rocket scientist but the policy clearly intends to prevent Registrars from hijacking the domains of their clients, as some have been wont to do, or simply refusing move requests by passively ignoring said requests.

Here is some of the verbiage of the policy that indicates its clear intention to anyone who is capable of reading above a 5th grade level.

"Registered Name Holders must be able to transfer their domain name registrations between Registrars..."
"The Administrative Contact and the Registered Name Holder, as listed in the Losing Registrar's or applicable Registry's (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar."
Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer.
In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed.

Jump in, if you think this is a bad idea! Here's the letter I just sent to icann@icann.org:

Good afternoon:

I stringently oppose the new ICANN Policy on Transfer of Registrations between Registrars, specifically the section 3 line:

"Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer. In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed."

This policy is an extraordinarily bad idea, for several reasons:

1) It puts more responsibility on registrar to wade through spurious domain transfer requests, many of whom will not take the pains to actively sort legitimate from non-legitimate requests.

2) It will mean trouble for domain owners who don't closely manage their records. Domains with incorrect e-mail addresses and outdated administrative contact information are at particular risk of hijacking.

Please reconsider this decision. Domains have become far too valuable to companies to introduce such a disruptive and potentially damaging policy.

I went to the ICANN link, http://www.icann.org/transfers/policy-12jul04.htm and actually read the policy. It certainly DOES NOT mean that you will lose control of your domain name without your explicit permission as the owner. It seemed to say that if a registrar does not reply to a request for a registrar transfer in five days, the move will be approved. This may not be smart either -- but not as bad as some folks made it sound.

Policy on Transfer of Registrations between Registrars, I don't find the part that states that the transfer is approved if the domain owner (i.e. the administrative contact) does not respond in time.

I do find language that states the transfer will be approved if the Registrar of Record does not respond within 5 days. This, however, is a Good Thing, as it makes it harder for the losing registrar to prevent you from transfering your domain. Of course, they can still just deny your request and hope they get away with it.

The way I see it, this gives domain owners (a little) more control over their domains. I don't see what's wrong with that. I never understood why transfers need to be approved by the losing registrar anyway - why would they ever approve losing a customer?

I COMPLETELY agree. First, the rant: DNS names are designed to give an administrator-friendly label for an IP address (or other network-related record). Domains are there to define an administrative scope within DNS. The top-level domains are there to define, very broadly, some different types of administrative scopes within DNS. The original designations seemed very logical.

DNS DOMAINS ARE NOT FUCKING CONTENT LABELS. DNS IS NOT A FUCKING INTERNET KEYWORD.

Now, with the rant portion of my post concluded, here's the reality:

There is no unique, persistent "keyword-style" web site lookup mechanism on the Internet. All attempts to create one have been plagued with litigation, jurisidicational, and cross-industry trademark ambiguity problems. The best we have is DNS, and something needs to fill that role. ICANN seems to think that continuing to warp DNS is the best way to do that.

A proper solution might entail a "proper" directory mapping real-world names to DNS domains (and letting SRV records do the rest). Then we can throw all of the intellectual property issues and the full weight of America's mighty litigation tendencies onto this directory service and keep it out of DNS. The directory service itself could be architected across geopolitical boundaries and thus tailor its regional scope/namespace to whatever country's laws happen to be in effect there (much like others' suggestions of eliminating the generic TLDs entirely in favor of ccTLDs). A directory like X.500 or LDAP, in conjunction with a country's trademark/service mark scheme, could offer users a guaranteed way to persistently and uniquely identify a mark's owner or an organization by name on the Internet. It would even allow for multiple organizations with the same name (as is allowed in the US for companies of different industries), which is impossible with DNS (and another whopping reason why DNS is unsuitable for this role). There remain some usability issues with an approach like this, though, so maybe that's why no one's figured out a way to make it work and take off.

But once DNS is taken out of the picture here, it can revert to being a simple host label and none of these stupid TLDs will matter. But that isn't going to happen any time soon. DNS will continue to be (ab)used as a content label and an Internet keyword, so long as there are companies willing to pay to keep/make it that way and so long as there are organizations out there willing to put those interests ahead of others.

Why has this been modded funny? .xxx domains were considered by ICANN.

Try a Google search for xxx tld to find out about them. Searching for site:xxx shows that no sites have been indexed (when search for along with other terms such as +a or +the) and only have their root included in Google.

Here (http://www.icann.org/tlds/report/report-iiib1c-09 nov00.htm) is a report on the .xxx TLD suggestions as well as a suggestion for a .kids domain (both of which were rejected at the time).

It is definitely free speech.

It is definitely cyber-squatting.

Free speech is protected by the constitution, but your ability to maintain control over a domain is not. That is a job for ICANN.

The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and coordinating the Domain Name System (DNS) to ensure that every address is unique and that all users of the Internet can find all valid addresses. It does this by overseeing the distribution of unique IP addresses and domain names. It also ensures that each domain name maps to the correct IP address.

ICANN is also responsible for accrediting the domain name registrars. "Accredit" means to identify and set minimum standards for the performance of registration functions, to recognize persons or entities meeting those standards, and to enter into an accreditation agreement that sets forth the rules and procedures applicable to the provision of Registrar Services.

According to this link, Verisign has control of .com until 2007, and must put up .net up for bid in late 2006. I believe they don't currently control .org, but I might be wrong.

I assume if Verisign violated their contract with ICANN in some way, their control over .com and .net could be revoked.

Maybe someone can fill me in, I have been following this, but I still don't get how one company can control all the .com and .net domains....Isn't that illegal?

There has to be one central Registry for each TLD, to make sure different people can't register the same domain, and to operate the authoritative nameservers for that TLD. The .com and .net TLDs were originally created by the US government, and the US Department of Commerce is the organization ultimately responsible for managing them. Since the Commerce Dept would prefer not to handle this themselves, they contracted with a private company (Network Solutions) to do it for them. Since this wasn't going so well and different organizations were managing different things, a private non-profit company was established (ICANN), and the Commerce Dept handed control over to ICANN. ICANN then contracted with Network Solutions to continue to operate the domain registry for .com and .net domains, but has been making some changes (such as transferring the .edu and .org TLDs to other registries, and introducing new TLDs like .info and .biz).

Does that clear things up at all?

Oh, and a link to Oracle's FUD when they were trying to keep control of the .org comain: "PostgreSQL is used primarily in the embedded system market because it lacks the transactional features, high availability, security and manageability of any commercial enterprise database... Jenny Gelhausen Oracle Marketing" Seems Oracle didn't even do the homework to see which open source database she was talking about.

Oh, and a link to Oracle's FUD when they were trying to keep control of the .org comain: "PostgreSQL is used primarily in the embedded system market because it lacks the transactional features, high availability, security and manageability of any commercial enterprise database... Jenny Gelhausen Oracle Marketing" Seems Oracle didn't even do the homework to see which open source database she was talking about.

Here's the ISOC's response to Oracle FUD.

We believe that the key point relating to databases for the .ORG
redelegation is not which database the operator is using, but,
rather, whether the database will support the .ORG registry in a
stable, scalable, and highly available manner.

Afilias has over a year of experience running a large scale gTLD
registry--the .INFO registry. This direct experience, the load &
stress tests conducted by Afilias (and listed in our proposal
<http://www.icann.org/tlds/org/applicati ons/isoc/section3.html#c17.10>),
and Afilias' compliance with ICANN's service level requirements clearly
demonstrate that the PostgreSQL database used by Afilias performs
at the level of reliability and availability required for the
mission critical operations of a global gTLD registry.

Further, the actual operating performance record of Afilias compares
very favorably to the records of the other .ORG applicants, many of
whom use commercial databases. A review of each bidder.s answers to
Question 14 <http://www.icann.org/tlds/org/questions-to-applic ants-14.htm>
illustrates the kind of hard data and real world registry experience
that ICANN is basing its decision on. Afilias has delivered this level
of performance based in part on its stable, reliable database, PostgreSQL.

The successful operation of a registry extends beyond simply which
database software is in use. It also requires a skilled operating staff
with the ability to design and implement reliable systems as well as
establish clearly defined resolution paths should problems occur.
Afilias' solid operating performance lends support to the claims in our
.ORG proposal regarding our ability to effectively manage the .ORG domain.

We do not take issue with the recitation of the many features and
benefits of Oracle's products. However, any suggestion that PostgreSQL
is unsuited for registry use is in direct contradiction to the facts.

Since the .com domain is US centric, in many situations the US would be argued as pre-eminent in disputes. Why would this be any different?

"In the 1980s, seven gTLDs (.com, .edu, .gov, .int, .mil, .net, and .org) were created. Domain names may be registered in three of these (.com, .net, and .org) without restriction; the other four have limited purposes.

It's probably not every corporation their after. Just a few.

It's the Security and Stability Advisory Committee of Icann which issued the report not the Board of Icann! This committee is literally filled with top-notch DNS experts (see here: Members of the Committee) and I don't think they give a rat's ass about Icann's issues with VeriSign. Btw, 2 VS employees are also members of the SSAC...

Now keep on flaming!

Well, they own the DNS root, so in a sense, you're right. However, this is purely based on free will. If you disagree with this, use an alternate root.

the universe or even the Internet doesn't revolve around America.

Yes but the WWW does! ICANN.org

• "Four years ago as part of the approval of the 1999-2000 budget, the Board stated: "It is the intention of the ICANN Board to create a reserve account of at least one year's operating expenditures, to be funded over several fiscal years." Approval by the Board of the 1999-2000 budget implied that the Board accepted this statement about the appropriate level of reserves."
• 2002 .com domains: 33,333,000, 2003 .com domains: 31,819,000
• An increase in both staffing and expenditures to accommodate the additional programmatic requirements imposed by the new reforms and the new bylaws, that is, the transition from ICANN 1.0 to ICANN 2.0. This would require up to an additional 10 FTE (see below).

ICANN doesn't run the DNS servers -- it's just reponsible for policy, assigning numbers and address ranges to avoid conflict, etc.

I would guess that the costs go to pay for engineers who know what they're talking about.

Of course, the ICANN meeting locations look like the typical VP-wants-to-tour-the-world-on-the-company-dollar deal.

However, in general, while ICANN isn't perfect, I'd have to say that they're a lot more The Good Guys than, say, certain other folks...and their entire yearly budget is probably less than what certain other folks (*cough* Verisign) pick up through misleading or netabuse-encouraging sales in a week.

Why would a (I presume) for-profit corporation like ICANN be preferable to a system controlled by governments?

Actually, ICANN is a non-profit according to their website. I'm guessing they want to jack up their salaries 20 fold and the easiest way is to try and hold everyone at gunpoint.

.xxx is once again one of the new TLDs being considered by ICANN, but everybody with a brain knows it won't work. Among other things, you'll never get a world-wide definition of "XXX content", let alone a world-wide law for keeping XXX content in a .xxx TLD. (The nations of the world still can't agree on the what's a "good war" and what's a "bad war"; there's no way they'll agree on the difference between "good nudity" and "bad nudity".)

In fact, the TimBL paper we're supposed to be talking about includes a link to one explanation of why .xxx won't work as advertised. There's also RFC 3675.

If you look at the recently closed public comment period on .xxx, you'll notice a frightening progression: .xxx supporters say ".xxx will protect children." Saner people point out how it won't. Lusers respond with increasinly draconian suggestions for regulating the Internet, like blocking all connections between the United States and countries that don't abide by U.S. laws about adult content.

Support for .xxx is support for Internet censorship. Please don't encourage those people.

.xxx is once again one of the new TLDs being considered by ICANN, but everybody with a brain knows it won't work. Among other things, you'll never get a world-wide definition of "XXX content", let alone a world-wide law for keeping XXX content in a .xxx TLD. (The nations of the world still can't agree on the what's a "good war" and what's a "bad war"; there's no way they'll agree on the difference between "good nudity" and "bad nudity".)

In fact, the TimBL paper we're supposed to be talking about includes a link to one explanation of why .xxx won't work as advertised. There's also RFC 3675.

If you look at the recently closed public comment period on .xxx, you'll notice a frightening progression: .xxx supporters say ".xxx will protect children." Saner people point out how it won't. Lusers respond with increasinly draconian suggestions for regulating the Internet, like blocking all connections between the United States and countries that don't abide by U.S. laws about adult content.

Support for .xxx is support for Internet censorship. Please don't encourage those people.

.xxx is once again one of the new TLDs being considered by ICANN, but everybody with a brain knows it won't work. Among other things, you'll never get a world-wide definition of "XXX content", let alone a world-wide law for keeping XXX content in a .xxx TLD. (The nations of the world still can't agree on the what's a "good war" and what's a "bad war"; there's no way they'll agree on the difference between "good nudity" and "bad nudity".)

In fact, the TimBL paper we're supposed to be talking about includes a link to one explanation of why .xxx won't work as advertised. There's also RFC 3675.

If you look at the recently closed public comment period on .xxx, you'll notice a frightening progression: .xxx supporters say ".xxx will protect children." Saner people point out how it won't. Lusers respond with increasinly draconian suggestions for regulating the Internet, like blocking all connections between the United States and countries that don't abide by U.S. laws about adult content.

Support for .xxx is support for Internet censorship. Please don't encourage those people.

ICANN made an announcement about this in 2002, and the information on the mentioned domains were still invalid in late 2003. Most of the information was updated this year, maybe to prepare for this lawsuit (to have clean hands).

Verisign/Netsol should have had their accreditation status yanked last year!

Yep, I have the same prob but hope help is on the way, have your ISP look at:

https://www.bondedsender.com/

or

http://www.spamhaus.org/tld/index.html

Second one run by Spamhaus seems good. There's a comment board here, but most posters don't seem to get how it works... or have bothered to read the FAQ... hey sounds like Slashdot! ;->

cb1

I'm just not getting how this proposal would do much. I read through the text of the proposal, which is written in fairly obtuse language I just couldn't quite plod through right now.

• OK, so we'll have this .mail TLD. Since any domain name just resolves to an IP address, this proposal would just boil down to keeping a list of trusted IP addresses. In other words, a list of trusted mailservers, which can easily be done with what exists now.
• What happens when spam originates from a .mail address? Because it will, if only from a virus-compromised machine. It seems the only recourse would be the revocation of the .mail domain.
• And if so, what is to stop a spammer from signing up, sending off a one-shot spam run, and losing the domain? It will just raise the cost of each spam run by the cost of registering the .mail domain. That certainly might *help* reduce spam, but it depends on the amount of spam they could send through before losing the domain.
• I assume each ISP will have a .mail domain of the sort isp.com.mail, and their customer's email will be routed through it. So what happens when a customer of an ISP decides to spam? Will this committee be tasked with determining whether the ISP terminates their spamming customer within an "acceptable" timeframe?
• It is already known that there are a number of less-than-entirely-responsible ISPs and even some that are explicitly spam-friendly. For a sufficiently large organization, they could afford to go through .mail domains at a fairly high rate.
• The cost also seems to be a problem. It seems that this proposal can ONLY work if the cost of the .mail domain is fairly high. It seems that the cost will probably be somewhere between $200 and $2000. This seems prohibitive for individuals, non-profits, and third-world orgs.

I was just reading the .mail STLD RFP application and am finding myself suprised by the people associated with the hair-brained idea.

Initial Board of Directors

Steve Linford, founder of Spamhaus.org

Joseph E. St. Sauver, Ph. D, Director, User Services and Network Applications Unv of Oregon

Already consented to be special advisors to the SO

John Levine, Chairman of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF)

Wietse Zweitze Venema, Ph.D, Postfix author among other things

Other

Justin Mason or Daniel Quinlan of SpamAssassin.org

Eric Allman of Sendmail.org

Ted Galvin of SpamCon.org

Suresh Ramasubramanian of OutBlaze.com

That list amazes me. I can't believe those people would have anything to do with this project. I also can't believe they are intentionally involving Verislime. I wonder if this is an attempt to counter Microsoft's e-stamp proposal...

See this CA district court judgement regarding .web. I don't know if this has been upheld by a higher court but the judgement references several sources as support including 9th Circuit judgements and the USPTO.

There is no "opt" according to the spec, that's just the way it is. the x.com gets x.com.mail and the x.net gets his .mail.

Not annoying since its not used for websites or email addresses, just server-to-server chatter.

Not a bad plan IMO. Maybe some Chinese email will make it to me if it comes from "checked out" companies. I personally refuse all email from Chinese IP space. Ain't worth my time.

>1. Who would verify the requests (worldwide)?

Since Spamhaus in UK seems to be involved, they would probably do it. Since I use and trust them to bounce stuff that's crap, I'd trust them to let in the good stuff.

>2. How do you REALLY verify an account is never going to be abused?

It's not that hard to see who's spamming. That's the basis for several blocklists.

>3. Where do you draw the line? Is a company of 20 allowed email? How about 4? How about just me?

The proposal seems to say anyone who's not a spammer.

>4. How do you persuade EVERYONE who currently uses email to change?

Does not look like any change is required. It's just a validation check.

>5. How much do you think it would cost to make the switch globally?

Not much. Modify a Sendmail release to do it, most of the globe is now "switched" :-)p

Not the way I read it. It looks as if it only applies to what ones email server is called. In fact, it seems to say one cannot have .mail email addresses. It's less a true domain and more of a trusted email path.

Looks okay, have to see how it works in practice, heck I hate to lose any emails from online-chicks just cuz they're talking dirty to me! :-)

Not at all. If everyone just implemented SMTP-SPF every spammer would have SMTP-SPF in their DNS.

SPF is a validation that the sender is who he says he is. This proposal seems to be that too, but also that spammers won't be able to get the .mail TLD.

At least that's what I read here.

say i have abracadabra.com and you have abracadabra.net - which one of us gets abracadabra.mail? Or are we talking abracadabra.com.mail and abracadabra.org.mail?

According to the proposal, you'd get abracadabra.com.mail:

The names registered will be of the form "key.mail" where "key" is of the form "sld.tld" and where "tld" is an ICANN top-level-domain with certain attributes and where "sld" is a second-level-domain which is already registered in "tld". The registrant of the "key" domain must be the same as for "key.sTLD"

It's apparent that the knee-jerk rejections of .mail are coming from people who haven't bothered to actually read the .mail proposal, or else who conclude that any anti-spam initiative that will not cause an immediate, total, worldwide cessation of spam is not even worth considering. All the .mail domain proposes is a more reliable locus for distributing whitelist information. It is expressly not intended to be user-visible, but rather to be solely for the purpose of automatic sender validation by mail receivers.

Whitelists work. Do they eliminate all spam? No. Are they part of a framework for reducing spam? Yes. Snide remarks about the futility of any possible approach to the spam problem may be amusing, but they obscure the fact that real (not perfect, but real) progress is possible. A .mail domain can be part of the solution.