ICANN ICANN Email List Archives

[stld-rfp-mail]


<<< Chronological Index >>>    <<< Thread Index >>>

ASCR REPLY: Individual responses from the Anti-Spam Community Registry

  • To: stld-rfp-mail <stld-rfp-mail@xxxxxxxxx>
  • Subject: ASCR REPLY: Individual responses from the Anti-Spam Community Registry
  • From: ASCRegistry <info@xxxxxxxxxxxxxxx>
  • Date: Thu, 15 Apr 2004 08:34:06 +0000 (GMT)

Greetings,

A number of comments on the .Mail proposal have been critical of some aspects. Most of these criticisms are well-founded while also being based on presumptions and occasionally incorrect information. We would like to address these issues in the hopes of continuing the civil dialog that has been started in this forum. We would like to point out that even though there have been critical comments posted, we remain convinced that this dialog is both proper as well as productive, and helps us identify areas for improvement as well as areas where, because of misunderstandings, we can strive to be more clear on what we propose.

In his previous messages, Shelby Moore from AccuSpam noted, "Even if they eliminated the $2000 fee, the problem is that most people are unable to always send email from the relay mail server MX which is listed for their domain in DNS. Some examples are when people travel or if they use a different ISP for their domain (web site) than the ISP they connect to internet with."

Shelby, what you're missing is that .Mail is not a "forgery prevention system" like SPF. It's not intended, at the onset, for individuals - and we've said that. Corporations like eBay, Amazon, Microsoft, Sears, and United Airlines (to name a few examples) *do* send mail from the same, known servers. Those are the initial users of .Mail. We hope to quickly offer solutions for smaller businesses and individuals as we lower the cost after a successful initial roll-out.

But to refute your point, .Mail does not require senders to send email from the mail server of their domain. These things are not tied together. A sender can send email though any server where they have been authorized to send email though. This is the way it works today, and that won't change. The only difference is the mail server can now be a validated, "this mail server does not send spam" one. Also, please research the use of the "MX" record in DNS, it's used for incoming email, not outgoing.

Mr. Moore also noted, "We have a theory that ANY anti-spam is successful only to the extent it increases costs on the spammers more than the aggregate increase cost on the community for legitimate email."

While this is an interesting theory, it's not germane to our proposal. The cost to spammers for the .Mail system is functionally infinite as well as zero, as they're not allowed to use it in the first place.

Mr. Moore goes on to say, "As I understand the .mail proposal, it requires ALL recipients to incur a new cost for a very small number of senders."

Then we would say that you don't understand the proposal, as it requires no such thing. Those users who wish to take advantage of the .Mail system will add it to their filters, but are under no obligation to do so. Those ISPs who wish to do so, will. And those MTAs who wish to participate will encode it as part of their defaults. Indeed, the inventor of the most widely-used MTA (Sendmail) has already stated in a number of public media stories that he likes this proposal. This proposal does nothing to change how mail works and forces nobody to make any changes, cost-incurring or otherwise. The only "cost" users who wish to take advantage of the .Mail system will have would be that of a DNS lookup, and since most DNS traffic is cached locally, this cost will be far less than the cost to process non-spam email or the cost of bouncing or trashing a non-spam email.

Mr. Moore also notes that this would be impossible for an ISP to set up for its users. Again, we've stated many times that this is not for individual users in its build-out phase. It's for larger senders of responsible mail who are finding that their legitimate, non-spam mail is not being delivered because it's being falsely identified as spam. The .Mail proposal is one for a sending system that is intended to be spam-free.

Mr. Moore then states, "Besides, anti-forgery detection can already be done using "reverse DNS."

Actually, not really. Anyone who has control over IP space pointers can forge a reverse DNS value. We'd be happy to set up the reverse DNS, for "forged.accuspam.com" on an IP to demonstrate. The key to the .Mail system is that the Sponsor Organizations retains control over the DNS as well as the validation procedures. Indeed, that's the crux of the proposal.

Jeff Breitner notes, in his comment, "This proposal cures spam by again placing the burden upon the recipient. In this case, not only must concurrent mail systems be run to support a .mail domain, but an onerous fee of $2000 and stiff domain registration requirements must be met. This puts relief for unsolicited junk mail out of the reach of many domain holders..."

We're a bit confused by this statement, as none of it is correct. This proposal puts the burden on the sender, not the recipient. Any sender who want to send spam-free, responsible mail can get a .Mail domain for that purpose. Concurrent mail systems need not be run (indeed, we're not even sure what Mr. Breitner means by "concurrent" in this context). The stiff requirements are precisely what guarantees that senders do not spam. That's the whole intent.

Mr. Breitner continues, "A true solution to spam is only going to come when the burden of identification and its costs are met by the sender. This solution would be a system of credentials either placed at the ISP or upon the domain itself that would allow the recipient to determine the origin of the message. Trust levels could be imparted upon that message and would allow for filtering based upon the tastes of the recipient. This prevents false-positives and troubles seen with rejecting messages with blacklists, shares some of the processor time required for the credentials with the end-client/recipient and eliminates the biggest contributor to spam; the implicit trust in the mail protocol."

We couldn't agree more - Mr. Breitner just described the .Mail proposal. The credentials you mention are validated and maintained by the .Mail registry, simply because if ISPs control them, then the spammers will simply become their own ISP (as many already have).

Andrew Dowling gets to the heart of the vast majority of comments. His comment is representative of most, when he says, "While vetting people before they can get a .mail extension is an excellent idea paying $2000 for the privilege seems to be punishing the innocent and not the guilty. Shouldn't we be fining the spammers and not legitimate business users. And what about individuals who have there own domains? They can't be expected to fork out that kind of money but ultimately I see many organizations only accepting mail with the .mail extension."

If the last sentence is the crux of your worries, we would suggest that you sleep easier, as this is just not going to happen. We feel that there will be little chance organizations and ISPs on the internet would only accept email with the .Mail extension and validated using its underling system, simply because there will always be a large number of senders that don't use the .Mail system and whose email is perfectly valid. No one will want to refuse their emails.

All .Mail does is allow recipients accept mail coming from the .Mail domain, knowing that it is from a validated sender who does not send spam. This will eliminate the chance of a "spammy" looking email being flagged as spam. This is an issue that really concerns and is very costly to places who will get a .Mail domain. This issue is not a large concern to normal Internet users who don't spam or don't send large quantities of email that looks like spam.

"Copy Caps Customer Baseball Caps" takes the cost issue one step further by stating, "I think this sounds like a good idea but the registration fee is much too high. I think the fee should cover Spamhaus' costs to administer the program but not be so high that only large companies can afford to register with the program (lest we forget that many of those same large companies send out a lot of unsolicited email)."

Absolutely, and that's been the plan all along. As we've pointed out, ICANN does not allow prices to be increased by a registry, but prices may be decreased. We have had to make a "best guess" at what the costs will be during the initial phase. We intend that these costs will be met by larger corporation who want their legitimate mail to be received. As the system proves itself, costs will go down, and offerings to smaller businesses and even individuals can be introduced. Remember, the Anti-Spam Community Registry will be created as a non-profit. There is no intention of keeping prices artificially high.

Robert Lahmann notes, "I want the freedom to set up my own email accounts without waiting six months for my domain to be cleared by a third party. I definitely do not want to pay $2000 for the privilege. Paying for something that is already free goes against my free internet ideals."

Mr. Lahmann seems to be under the impression that we will be taking over the entire email system and will be requiring everyone to get a .Mail domain and pay $2000 for their mail to go through. Not true. The .Mail proposal does nothing to stop anyone from setting up their own email accounts and their own domains as is done by millions each year. It also does nothing to restrict the flow of email from these accounts or its acceptance at the other end.

In the .Mail FAQ answers 1 & 2 at the webpage set up by Spamhaus.org at: http://www.spamhaus.org/tld/faq.lasso one will see that email users who do not send millions of email messages a day (such as airlines, banks, newsletters, and places like eBay an Amazon), or email messages that "look" the same way spam does (heavy HTML, many links and images) do not need to use a .Mail domain.

But .Mail will still be a good thing for users who don't need to have a .Mail domain. How? FAQ answer 4 addresses this. By not having to "test for spam" mail flowing from .Mail validated servers, ISPs save the costs associated with this testing and one hopes will pass on savings to users. Also, uses who may have lost non-spam email due to ISP or personal filtering in the past (hotel reservation confirmations, action bid announcements) will be able to avoid this as .Mail rolls out and more legitimate, non-spamming, emailers start using it.

This costs you, the user, nothing.

Finally, we'd like to address the comments of Brandon Devnich, who begins his commentary with, "I may be writing this to fall on 'deaf ears'"

Not at all. We are reading each and every post to this forum, and answering quite a bit of email. Community involvement is what this is all about.

Mr. Devnich continues, "I have little faith in your .mail TLD if it were to use this $2000 domain license fee. I believe the .mail TLD has merit, but without the fee. Where did this seemingly arbitrary number of US$2000 come from?"

The fee is far from arbitrary. It is the high end of an estimate as to how much it will cost to do several things. One being the amount needed to pay a registry to run the sTLD. All TLDs require a registry operator, this one is no different. Another cost is that required to run the infrastructure behind the sTLD (also called the "back-end"). This must be built from the ground-up to service this specialized use of the TLD system.

Another major part of the cost of this sTLD is the vetting and validation that must be performed on every applicant before the use of a domain is allowed. This is not a cursory automated sign-off. Real people will review each application, check that the applicant is not a known spammer, ensure the contact information is correct and then verify this by physically making contact with the applicant by post, courier or phone.

Is $2000 too much for this? Right now it's hard to tell. If we erred, we attempted to error on the high side. If it turns out that our costs are lower, we will lower the cost. As a non-profit, that's the way it works. The more people and places we can bring under this non-spam sTLD system, the better.

Mr. Devnich adds, "Quite serious, most small businesses who rely on sending mail through their existing .net/.com email addresses could not afford to pay this $2000!"

We agree. Small businesses should not have to pay and will not be the ones who need a .Mail domain at its inception. The .Mail proposal does nothing to stop individual users or business from setting up their own email accounts and their own domains as is done by millions each year. It also does nothing to restrict the flow of email from these accounts or its acceptance at the other end.

Mr. Devnich asks, "And where has your research come up with the "very short time of spamming"? What do you mean "high cost for spammers", how do you know what the "budgets" of spammers are?"

The Spamhaus Project and other anti-spam groups represented in the Sponsoring Organization have been dealing with spammers for many years now. We are quite aware of the budgets needed by spammers to purchase "bulletproof" hosting, off-shore spam accounts, lists of harvested email addresses and other tools of their dubious trade. The costs associated with obtaining the use of a .Mail domain and losing it the moment they start spamming with it will not "scale" for spammers.

Following up, Mr. Devnich asks, "So you're saying that this "authenticated" system of having yourwebsite.com.mail is NOT guaranteed to prevent spammers? So then what is the point in subscribing to such a system?"

The point is to allow NON-spam email to flow freely. Spammers will still spam, but hopefully tighter filters and better laws will deal with that aspect of the problem. Furthermore, as we establish a "clean zone" for responsible mail, the burden of checking it will be lightened, allowing for more rigorous filtering of other email.

Mr. Devnich ponders, "Why not jack up the price to $50000 USD, that would surely stop the spammers. Still, us small businesses who use the system responsibly should not be penalized an outrageous fee of $2000 to have their email marked as 'quite likely not spam.'"

That's a very good point. As it stands now, ALL businesses small and large are being penalized by having their email marked as "quite likely is spam" due to the fact that over 70% of all current email is spam. If ones non-spam emails get rejected or trash-canned by mistake the cost is quite high. Again, as larger corporations adopt the .Mail system, the costs will be lowered to a point where small business can also enjoy the benefits without paying a higher fee. Much like business telephone users subsidize the cost for residential users (at least in the USA), the larger corporations will bear the cost for the creation of the .Mail system. We agree that it's hardly fair to charge a high fee to small business and individuals. We do not intend to do so.

Mr. Devnich proposes, "Maybe you should think about something a bit more intelligent like the "billing the sender" solution which has been proposed."

We don't feel that "billing the sender" is at all fair, as then you, a small business, WILL have to pay for all your outgoing mail. This proposal does not require you to. It has zero effect on your current status.

Unfortunately, this is not the civilized world we deal with here. This is the world of spamming. A large number of spammers are committing criminal acts to spam, they don't really pay bills. A number of spammers are now based in nations where their getting a bill would just make them laugh at it. Even in the USA, federal agencies who have been able to get judgments against spammers have found it hard to collect anything.

We hope that these responses have helped to clarify what we are proposing (and what we are not). We are understandably concerned at many of the misconceptions that many people have about this proposal, and appreciate your time in reading our responses.

Regards,

The ASCRegistry team



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy