https://web.archive.org/web/20060521073344/http://www.spamhaus.org/tld/faq.lasso
Frequently Asked Questions (FAQ)
The .mail TLD
Why is this needed? The .mail domain is intended to carve out an identifiable domain and underlying system to help differentiate legitimate email from spam. The plan proposed, even if used by a portion the full email community, will still be a benefit to the the entire community.
Some spam blocking and filtering systems will sometimes bounce or flag legitimate non-spam email due to any number of reasons: country of origin, excessive HTML, "bad" keywords in subject or body, etc. The .mail system addresses this problem by allowing non-spam to be passed around filter systems, thus reducing this overhead on emails known to be "clean".
The .mail domains helps promote the use of accurate "Whois" identification data for every domain. Spammers love to hide behind fake information; this domain will make that next to impossible for them to do.
Finally, .mail assists new "sender authentication technologies" (such as: SPF/Sender-ID & DomainKeys) in proving their effectiveness and in day-to-day operations.
Who needs a .mail domain? Any place that wishes to send non-spam email unencumbered by blocking/filtering systems that will sometimes bounce or flag legitimate non-spam email due to any number of reasons. Country of origin, excessive HTML, "bad" keywords in subject or body, etc.
If you currently have no problems sending email and having it accepted - which probably means you don't live in China, Korea, Brazil or Africa, or send large volumes of non-spam, but similar looking email, or send email for the "How to cook using SPAM" mailing-list - then save your money as you don't need a .mail domain.
Will this stop spam? No. Nor is it designed to. But if will prevent spamming from places who use this domain and the system behind it. If any domain holder uses the system to spam, the domain's use is revoked.
The idea is that messages authenticated through the .mail system could be delivered without expensive and time-consuming filtering, making recipients more likely to allow them in. In other words, the .mail namespace supports the free flow of spam-free electronic mail. With proven success and the cooperation of our supporters (who make and distribute the majority of mail transport agents), we anticipate rapid adoption and use of the .mail sTLD.
Okay. How does .mail benefit me? One problem with the myriad of filters and other methods to try to control spam at the recipient-level is the likelihood of false positives. That is, email that is received and marked as spam, when it is actually not. With the .mail system, all email received via a .mail-enabled domain is, by definition, not spam. Consider the number of submissions to mailing lists that are often misidentified as spam. A mailing list using the .mail system would be assured that posts were not so misidentified. Consider, also, confirmation email after making an online purchase (or bidding in an online auction), which is often falsely identified as spam by some filters. With the .mail proposal, such email would not become another false positive.
Won't spammers just forge .mail domains to send spam? They can try, but it is meaningless to forge the text "example.com.mail" as this is not what the system is based upon.
Places that do not yet have the .mail check implemented will accept forged spam as they do currently. Places that have the .mail validation check implemented will see the attempt at a forgery and can either reject the connection, thereby not even bothering to download the email associated with the forgery attempt, or they can accept the email and run it though their normal checks to detect spam (blocklists, Bayesian, SpamAssassin).
Spammers will learn quickly that their very attempts to forge .mail domains will be a red-flag that works against them in their efforts to deliver spam. They will go back to using other TLDs that do not have this built-in "no spam" system.
What is The Anti-Spam Community Registry? It will be a non-profit organization set up to sponsor the TLD upon ICANN approval. It will enable the participation of the greater email community at large rather than just that of the Spamhaus Project.
Why is this sTLD run by the Anti-Spam Community Registry and not the Spamhaus Project or another trusted entity I know about? The Anti-Spam Community Registry was founded by the Spamhaus Project to be the Sponsor Organization for the .Mail TLD and will be made up of other anti-spam entities you will know. This was done for a few reasons, first being to insure the continuation of the .Mail sTLD into the future even if one or more of the underlying organizations choose to discontinue work or are no longer involved in this part of the anti-spam effort. It was also done to encompass more than just the goals of the Spamhaus Project. The community the .Mail sTLD wants to serve is made up of many segments: Software authors and companies who design mailserver software and anti-spam filters, Internet Service Providers, Mail Service Providers and networks who have to deal with the spam and "false-positives" on a daily basis, anti-spam proponents and educators in organizations and in academia. To insure broad appeal and acceptance, having each segment represented is the best way to run a sTLD such as .Mail.
Why is the Spamhaus Project supporting the creation of this TLD? Although Spamhaus is known for helping stop spam and the systems we've built allow users worldwide to reject billions of spam emails each day, we've always felt it's even more important to insure that legitimate, non-spam, emails are properly routed. The idea behind this TLD is to enable email recipients to accept email and route it around spam filters without fearing it may be spam.
Can anyone get a domain? Actually, no. Use of the domains is reserved for people, companies and organizations that do not spam or have a direct role in supporting spammers. Additionally, the Supporting Organization will perform a rigorous verification of all WHOIS data. For example, applicants must have verifiable physical address contact information, telephone contact information, and also must have owned the key domain for a period of six months before being granted the use of a domain under .mail.
Can anyone request any domain they wish? No. Only the verifiable owners of an existing domain ("key" domain) under a set of other TLDs will be granted the use of a domain under this TLD.
Also, one must have owned the existing domain for a period of six months before being granted the use of a domain under this TLD.
What does a domain cost and why? The plan is that .mail domains will cost approximately $400 per domain per year, but there will be a five year minimum registration period (therefore total cost for 5 years will be approximately US$2,000).
The price may vary depending on the registrar one uses.
This high initial cost will insure that most spammers will not bother to attempt to sign up for one, and if they do and fraudulently get past the vetting proceedure, it will be a high cost for what will be a very short time period of spamming.
The cost also pays for the much greater than normal vetting procedures places requesting this domain will go though before one is granted to them.
Where would one apply to purchase these domains? If approved, the use of these domains will be sold though many of the usual registrars where one currently obtains other domains.
Will there be .mail websites and email addresses? Yes, but they are reserved for the use of the .mail system, not for the domain holder.
Each .mail domain will have a website that will display up-to-date contact information for the domain holder and a way to email them.
Each .mail domain will have an abuse@ and postmaster@ email address that will go not to the domain holder, but to the .mail Sponsor Organization. In this matter, people - and automated spam reporting systems - will be able to file a spam complaint with "abuse@example.com.mail" if they feel that the domain holder has been spamming.
Can this be used by an ISP for all its customers? Maybe. Since the domain can be revoked due to spamming, and ISP will have to have very low limits on the number of emails a customer/account can send per day.
If this is not feasible to manage over all customers/accounts, an ISP can probably set up a smaller sub-set of users, and their own corporate servers, to use this domain.
Can senders use this even if recipients are not using it? Yes. This TLD works the same way as any other during an email transaction. It's only when the recipient checks its validation status that it gives the extra "not spam" value.
Can this prevent legitimate non-spam email getting filtered? Yes. That is a main reason for this TLD. As mailservers and spam filter systems implement its easy-to-use check, less legitimate emails will be rejected as spam.
If this is used to bypass spam filtering, is spam filtering bad? Absolutely not. Most spam filtering is good and very needed. But as the spam problem just continues to grow, and as spammers get sneakier in their attempts to foil the filters, tighter filtering is being used to control the problem. This leads to a greater number of legitimate emails being bounced or tagged as spam. The idea behind this system is to allow recipients to run as much spam filtering as they wish to, yet keep legitimate, non-spam email from getting filtered as spam.
Why do you need a TLD for .mail? Why not do this with a second-level domain? First and foremost is the issue of control over the zone. Were this proposal to be made under an existing TLD, that zone would be subject to removal or revocation by the registry. Additionally, it would be subject to UDRP or other legal action that might force the registry to remove or suspend the domain, rendering all registrations useless. Clearly, this isn't an option.
.mail is designed to be a wrapper around other TLDs', which provides assurance that the TLD being wrapped is not a known spam source.
In truth, *any* TLD could really be a SLD (second-level domain). In fact, many are (example.co.uk). The concept behind TLDs is to differentiate them, and their users - especially in the case of an sTLD (sponsored TLD) - from the internet at large and the other TLDs.
An honest answer must also include the issue of perception. In creating a namespace in which responsible electronic mail is enforced, doing so under a 2nd-level domain may not give the perception of a credible system. Setting up the system behind .mail as a TLD will also help insure its acceptance and its longevity. It will be an ongoing effort run by a sponsoring organization rather than just a smaller entity. Also, psychology tends to show that "example.com.mail" will be accepted more readily than something like "example.com.this-is-not-spam.com"
As stated above, running a system like this on an existing TLD would bind it to the rules and regulations of that TLD. Each existing TLD has some rules and regulations that are not compatible with the stated rules and regulations of the .mail TLD as it is to be used in anti-spam.
On the technical side, a TLD's infrastructure is also set up to be more robust and attack resistant than a normal domain from the outset. Whenever dealing with spammers, one must expect some level of attack.
It's the same sort of answer with 3rd-level domains. www.example.com is for the web, ftp.example.com is for FTP, why not mail.example.com?
In order to maintain control over the authentication records, everything must be under a single TLD. While individual entities could agree to set up a common third-level domain to indicate responsible email, there would be nothing preventing an irresponsible sender from setting up the same domain and sending large amounts of spam. When it comes to spam, a deficiency of the Sender Authentication Technologies (SAT) is that they do nothing to prevent a spammer from registering a large number of "throw-away" domains, setting up SAT records on them, spamming from them until they are blocked, and then moving on to the next domain.
The .mail sTLD Sponsor Organization-monitored zone is really the key that makes this system function spam-free. If you spam, you lose the use of the domain.
Couldn't this be done using a DNSBL-like system instead of creating a TLD? Yes... but in reality no. DNS based "whitelist" systems (we call them DNSWLs) have been done and do work if used. But the work involved in building them is even greater than the work in building a DNSBL such as the Spamhaus Block List.
The use and worldwide acceptance of a DNSWL would also be far slower than use and worldwide acceptance of a widely known and recognizable concept such as a .mail TLD.
On the technical side, a TLD's infrastructure is also set up to be more robust and attack resistant than a DNSBL based lookup system. Whenever dealing with spammers, one must expect some level of attack.
There are also other goals with this TLD based system:
One it to insure that the all reports of abuse are sent to the sponsoring organization, not to the domain user. This will insure a quick shut-down of any place who tries to abuse the .mail TLD.
Another goal is to provide internet users with proper, correct and validated "Whois" contact info. This will help many segments of the internet in many different ways. Hosting companies can better vet prospective clients. Law enforcement agencies can better track down the criminal abusers. Legal service will be much easier to effect upon spammers who violate laws. An added benefit will be that the places who apply for use of a .mail domain must also have proper, correct and validated information in their underlying "key" domain (.com, .net., etc.) - this will help people and places not using or even aware of the .mail TLD.
How does the system work? In simple terms, it works during an SMTP transaction between an email sending server and a recipient server using a DNS check.
DNS for all domains under this TLD are run by the TLD sponsor, not by the people running the email sending server. This is how the validation, or lack there of, is controlled.
Does this change the SMTP protocol in any way? Not at all. Email flows as it always has. This TLD and system provide the means to validate that the email sent with this TLD is spam-free. It is one more way recipients can enforce their email policies.
How are subdomains handled? Subdomains are all managed by the user of the top-level .mail domain. The user of the top-level domain (eg. example.com.mail) is responsible for the emailing practices of all subdomain users (eg. remote-factory.example.com.mail).
Will this take a lot of effort to implement on current systems? Doesn't it require everyone to participate in a particular protocol? No. Most current email server software and much email filter software can be modified to use this system right now, and many implementations have already indicated their intent do to so. As these implementations add the .mail to their default configuration options, it'll be easier yet.
Must everyone use a particular anti-spam technology with .mail? Absolutely not. It is important to note that the sTLD is both the platform as well as the community in which responsible use of email can be monitored and enforced, but is also technology-agnostic in how that responsible use is accomplished. By providing a secure DNS zone for the sTLD, the appropriate records to implement a wide variety of sender-authentication and authorization technologies may be entered and maintained. All of the major, current proposals are suitable for use in the sTLD. In this light, we are confident that the sTLD will play a key role in the proving and use of these technologies, and a solution can and will be found to the ongoing spam problem.
Won't most places just reject all email from non-.mail validated domains? Won't non-users be left out? No to both. Email from .mail validated domains is expected to be spam-free and will be accepted as such. Sadly, the fact is that more than 50% of all other email is spam, email from non-.mail domains will be "suspect" as it is nowadays. But this does not mean it will or should be rejected, it will flow though the normal filtering channels that are in use currently.
Places that implement a well run email filtering policy based on commercial tools, or done in house, deliver a very small percentage of sent spam to their user's email boxes. There is no need to reject non-.mail domain email. But even the best run email filtering can on occasion produce a "false positive", this is what the proposed sTLD system is meant to address.
Will the cost for domain use ever be changed? Higher or lower? Higher - No, ICANN rules governing every TLD state that the price cannot be raised at any time.
Lower - Yes, we are working on solutions based on other verification processes and other ways or running the TLD system to minimize costs. We belive that an increasing volume of registrations will also help bring the price down to a level where more can afford the cost, but a level that will still allow us to keep the spammers from using the system.
The ideal pricing model for use of the .mail TLD would be less than it is currently set at, but since the price cannot be raised, in the application to ICANN it was listed at the highest end of the range needed to cover the costs of starting a new TLD, building the infrastructure and the ongoing costs validating applications.
Again, how will you stop spammers from forging this domain? Nothing can stop a spammer from forging a .mail domain, but the entire TLD DNS system - the thing that controls all domains under this TLD - is run by the Sponsor Organization. What this means is that a system that tests to see if the connecting .mail domain is a valid, "no spam" domain, will be able to spot an attempt to forge it right at the start of the SMTP transaction. Attempts to forge can be rejected on the spot, or passed on to further spam-filter checks.
We have a dozen different domain names, does this mean we have to apply for a .mail domain for each one? Not at all. The .mail domain is only used to identify your mailserver(s). You will still be able to send mail using all your other domains. To gain the benefit of the .mail system, you'll just use an outbound server that announces itself as a ".mail" server.
For example, if your email address is "joe@joesdeli.eat", your .mail server could be called "mailserver.joesdeli.eat.mail", the IP address associated with this name will be your outbound server's IP address. If you also had addresses at domains like "joespizza.eat" and "joeshotdogs.eat" you could use the same server to send email from, or you could use another server, at another IP address, and name that one "secondserver.joesdeli.eat.mail".
All the domains will have the benefit of using the .mail system.
One more thing, let's say you provide free email service at "joesdeli-free-email.eat", and you fear that someone may sign up and spam using it, you can send that email though a server that does not announce itself as a .mail server.
How many mailserver IP addresses can be associated with a .mail domain? An unlimited quantity. One will be able to assign name/IP combinations for each of ones servers. For example:
mailout-01.example.com.mail A 233.0.42.41 mailout-02.example.com.mail A 233.0.42.42 mailout-03.example.com.mail A 233.0.42.43 remote-factory.example.com.mail A 2.111.244.10 list-server.example.com.mail A 127.0.14.1
When can I get detailed information on the TLD system? A whitepaper on the system is due out soon, pending ICANN approval.
Have there been press articles published on this proposal? Yes:
Computer Business Review - SpamHaus Seeks to Put Spam Reputation in the DNS
The Register - Anti-spammers press for own domain
The Register - SpamHaus lobbies for .mail TLD
TechNewsWorld - Proposed Top-Level Domains Target Porn, Spam, Jobs
NW Fusion - ICANN considers domain name extensions
Computer Business Review - Ten Applications Filed for New Internet Domains
Heise Online (.de)- ICANN stellt Bewerber für neue Top Level Domains vor
Computerra News (.ru)- ICANN изучает проекты по созданию новых доменных зон
PCWorld (.hu) - Az ICANN új tervezett doménnevei
Punto Informatico (.it) - Un dominio per chi non spamma
JB Online (.br) - Icann analisa novos domínios primários
PC Pro - New .mail top-level domain offers hope for spoiling spam
The WHIR - Spamhaus Pitches Anti-Spam Domain
The Washingtonpost.com - Dot-Mail Domain Proposed as Spam Solution
MSNBC - New .mail domain designed to slow spam
Spammers are rich. These rich spammers will just sign up for a bunch of these domains and spam won't they?
Unlikely. First, most spammers are not rich, that is a myth. The few who do profit from their network abuse, or crime in many cases, are very well known to Spamhaus and others who will verify the applications; their applications would not be approved. The sponsor organization intends the vetting process to be very thorough.
Secondly, if a new spammer, or a known one who's managed to cloak his identity though one fraudulent way or another, gets a .mail domain, he'll find it was a wasted investment. The moment he starts to spam using it, the sponsor organization will get the reports of the spamming and immediately suspend/remove his .mail domain from the DNS and the zone. The spammer will still be able to send, but recipients will see his attempts to connect as an attempt to forge a .mail connection and either reject the connection based on that, or, depending on policies, let it though but test it against spam blocklists and run it though other spam filtering systems.
If this spammer signed up for a bunch of .mail domains, his loss has really been magnified.
How does this work at the MTA level? What's happening behind the scenes? When a mail server wishes to send electronic mail in a responsible manner under the .mail system, it establishes a Simple Mail Transport Protocol (SMTP) connection with the recipient's mail server. Upon connecting, the sender identifies itself as a .mail-enabled server by using the .mail domain corresponding to the sender's actual domain name. In other words, if the sender is steve@example.com, the sending mail server might be mailserver1.example.com, and would identify itself as mailserver1.example.com.mail. This informs the receiving server that the sending server is saying it supports responsible email. The receiving server may then verify this claim by comparing the DNS value of mailserver1.example.com.mail with the IP address the sending mail server has connected with.
If this verification checks out, the receiving server should have high confidence that the mail being sent is not spam.
At this point, the receiving server will also know that the sending server should have available one, or more, of the different sender-verification technologies available for use.
Isn't this just the same as SPF or the other Sender Authentication schemes? No. Although there is similarity in the DNS implementations, the systems work to authenticate different things.
Current Sender Authentication Technologies (eg. Sender-ID [SPF + Caller-ID] & DomainKeys) authenticate that the email being sent is being sent from a mailserver that allows the domain used in the "envelope-sender" or the "header-from" to send email from it.
The "envelope-sender" is part of the SMTP transaction defined by RFC2821 (i.e. the return address for bounces.). The "header-from" is what most people see when they look at the From: line in their email program. Different SATs can authenticate one or both of these depending on how they are implemented.
It is hoped that these Sender Authentication Technology (SAT) systems take root and are widely used as they can help curtail much of the forged spam from open-proxies and virus-infected machines - and the "bounces" this type of forged spam creates. Most, if not all, .mail domains will have at least one of these SATs in their DNS records to help promote their wider use and to offer further validation options to email senders and recipients.
Although SATs will allow recipients to verify that the named sender domain matches the server, they do not tell the recipient if the email is spam or non-spam. A big difference is that SATs are controlled and implemented by the sender, meaning any spammer can set up a Sender Authentication record in his DNS. The .mail sTLD records are controlled by the Sponsor Organization, not the sender. In this way, at any sign of abuse their use can be disallowed. The recipient, after validating that a .mail domain is in the .mail DNS zone, will now know that there is almost no chance the email message is spam.
What the .mail sTLD does not do is tie the named sender domain to the sending server. Places using .mail can do this themselves by using one, or more, of the SATs.
A further technical difference is how the TLD approach works at the "root" level of the domain name as opposed to the DNS level controlled by the sender. This allows the Sponsor Organization to receive all the spam complaints about the domain, which is the key to enforcing the rules for .mail domain use.
But can the systems work together? Certainly! SATs and .mail can be used together to authenticate both the sender's domain, the message content and the non-spam nature of the message - a great combination.
Won't bad people forge a .mail domain in a spam run to get someone else in trouble? They may, but places who have the .mail validation check implemented will see the attempt at a forgery and not be fooled. Also, it is easy for both the Sponsor Organization and email administrators to check the headers of these forgeries and see that the IP address used to send the email does not match the IP addresses the real .mail domain users have specified are theirs. Forgeries of this type will prove bad intent and can aid in legal actions against the forger.
Why is the DMA worried about .mail? The policy for use of a .mail domain is that the Sender does not engage in transmission of Unsolicited Bulk Email (UBE), aka spam. The USA's Direct Marketing Association supports the sending of UBE and indeed calls spam "Freedom of Commercial Speech". The DMA's support of spamming has always put the DMA at odds with the Internet and all Internet ISPs, since all ISP Policies ban the sending of UBE. Therefore if a DMA member requested a .mail domain we would need to ensure the DMA member fully understood that the sending of Unsolicited Bulk Email, aka 'spamming', is not permitted with this TLD on penalty of instantly losing the use of the domain and registration fee.
But the DMA and indeed the spammer community as a whole should not worry, .mail does not stop them from sending as much UBE as they wish to using their normal com/net domains. They just cannot use the .mail method to broadcast UBE.
