Simple explanation of technical ramifications of .mail proposal
- To: stld-rfp-mail@xxxxxxxxx
- Subject: Simple explanation of technical ramifications of .mail proposal
- From: AccuSpam <support@xxxxxxxxxxxx>
- Date: Tue, 13 Apr 2004 15:41:27 +0800
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
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
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
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