Simple explanation of technical ramifications of .mail proposal

[AccuSpam <support@xxxxxxxxxxxx>]

The public comments in this forum thus far have apparently focused in majority 
on the $2000 fee, because I assume people want a solution to spam, but 
apparently many feel they will be shut out by the high cost.

This indicates to me a very high probability that most people do not understand 
the technical details of the .mail proposal.

As I understand the .mail proposal, let me make some simplifying explanations:

1) The vast majority of senders will not be able to use a .mail domain for 
technical reasons as explained below.  It has nothing to do with the $2000 fee.

2) .mail domains are to be certified spam-free.  I think this is 
impossible/impractical to guarantee even with the $2000 fee and 6 month entry 
delay, but assuming the certification policies will work, then follow the logic 
below.

3) If an ISP offers it's .mail domain for use by all it's customers, then that 
ISP must be able to insure that not one (1) spam will be sent by any customer.  
The proposal provides no technical means for which an ISP could insure this.  
ISPs already are trying very hard and not able to stop all spam coming from 
it's own customers.  For example, most of us have seen the "sbjhbjh" jibberish 
in spam and these are ISP hash busters.

4) Thus, no (or very few) ISP will be able to offer .mail to it's own 
customers.  Certainly big ISPs such as Earthlink, MSN, etc will not be able to 
offer .mail to it's customers.

5) For a sender to use use a .mail domain, the sender must send all the email 
for the .mail domain through the mail server for the .mail domain.  This is the 
anti-forgery method of the proposal.  This is technically impractical for most 
senders of email who could get a .mail domain.  See why below.

6) Since most people connect to the internet via their ISP, and since their ISP 
can not offer them use of the ISP's .mail domain, then the only way these 
customers can send using .mail is for them to own their own .mail domain.  
However, when they send using a domain which is not hosted by their ISP, then 
they fail the basic requirement of #5.

7) Taking #6 logic further, for most senders to be able to send using a .mail 
domain, everyone would have to buy their own domain and it would require that 
the hosts of their domains would have to implement authenticating mail relay 
servers, using either the arcane SMTP authentication or "POP before SMTP" or 
similar hack.  Most senders can not implement such non-standard ways of sending 
email.

8) With or without the $2000 fee, it simply isn't realistic that most senders 
of email could ever send using a .mail domain.  Thus most senders of email are 
shut out from the benefits of the .mail proposal.

9) In order for the few senders who can use .mail to have their email filtered 
differently (i.e. in order for the .mail proposal to have any benefit for those 
few senders), then *ALL* recipients of email have to change their filtering 
methods.  This also involves the actual minds of many recipients, because many 
of them do not use a computerized spam filter and instead they have to remember 
that when they see a .mail domain, that they are supposed to trust it.  And 
when they see a not .mail domain, then they are not supposed to trust it as 
much.  So this means the majority of email becomes non-trusted and the few 
senders email becomes trusted.

10) It is a huge cost to place on the email community of recipients for the 
benefit of a few senders.  It also involves changes to either every SMTP server 
and/or to every email MTA/MUA to support the anti-forgery requirement.  It also 
involves changing and updating every anti-spam software and rule to exclude 
.mail domains.  It also involves educating every recipient to treat .mail with 
more trust.

11) We believe there is a much simpler way to handle anti-forgery for those few 
corporations (and ALSO for every sender) that does not have the community-wide 
cost and impractical technical hurdles of the .mail proposal.  Look for an 
announcement of this new technology soon.  In short, .mail is unnecessary in 
our view, as well as the cost and technical problems reasoned in 10 points 
above.

Shelby Moore
AccuSpam.com