ICANN ICANN Email List Archives

[stld-rfp-mail]


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

We hope .Mail is approved...

  • To: stld-rfp-mail@xxxxxxxxx
  • Subject: We hope .Mail is approved...
  • From: AccuSpam <support@xxxxxxxxxxxx>
  • Date: Mon, 19 Apr 2004 01:52:23 +0800

We hope .Mail is approved, so that our criticisms will be given a chance to be
proven.  The worst possible thing that can happen for AccuSpam and myself, is
for .Mail is be denied and then people accuse of us of trying to protect our
own interests.

The *non-factual* (opinion) politics is not our area of expertise.

So we do urge the approval of .Mail.


> Herbie Robinson wrote:
> IN MY OPINION, The comments provided by AccuSpam are inaccurate


Facts?


> Herbie Robinson wrote:
> and appear to be an obvious attempt to preserve their
> revenue stream.


We currently have no revenue stream (free product).  We lose $ on AccuSpam.

The currently released algorithm on AccuSpam is horrible for most people
(unless you get all your new contacts from your web page, then it is perfect). 
We plan to replace it by next month with a drastically improved one.


> Herbie Robinson wrote:
> In other words, take into account that it is in their
> best interest to shoot down all alternative spam solutions.


Absolutely false.  In fact, our coming new algorithm actually depends on the
widespread adoption of any anti-spam in order to discentive spammers from ever
resorting to widespread forgery by placing a relatively higher cost on the
spammer's ROI for widespead forgery.  By "widespread forgery", what we mean is
where the spammer forges from every individual on his mailing list to everyone
on his mailing list, e.g. 1st entry is sender to 2nd entry, 2nd is sender to
3rd, etc..


> Herbie Robinson wrote:
> I think the proponents are seriously underestimating
> the momentum they will have to overcome to get this to
> actually work,


Agreed, except even with the momentum, it can not work well, for the reasons we
pointed out in previous emails.

The bottom line is that the only thing .Mail offers over sender authentication,
is a centralized person or groups of persons to decide what is spam for every
individual.  There are emails which some people think are spam and others think
are not spam.  For example, my mother loves to get offers of prices specials
for the airlines.  I think that is spam.  There will be arguments about whether
companies really do keep people off lists after they opt-out. Etc.  With .Mail,
a corporation who has the right influence and politics may be able to get their
"spam" to pass through .Mail with a stamp of "non-spam" approval on it.

If you want sender authentication, there are other proposals for that which do
not involve the need for every sender to use .Mail domain and do not involve
the centralized judging of what is spam and not spam.


> Herbie Robinson wrote:
> but it's the best idea I have seen, yet.


What part?  The sender authentication or the central judging of what is spam?


> Herbie Robinson wrote:
> It can't hurt to give it a try.


Agree.  It can "hurt", but let us please "try", so it will not debatable.


> Herbie Robinson wrote:
> I run a very small home business and spam
> is costing me way more than $2000 per year now.
> Even if it actually cost me $2000 to solve the problem,
> I would probably grudgingly spend the money;


Wow!  For a company in anti-spam, that makes us feel our work is very
valuable.  Thanks.  So all we have to do is provide a solution that really
works.  BTW, have you looked at BrightMail.com?  In our testing, it really
works as they claim with 95% deletion and only 0.0001% (1 in million) false
positives.  It is the only anti-spam system I have know of that has such a low
false positive rate coupled with high detection rate.  All other anti-spam
(including .Mail will) generate a very high false positive rate, which is
untolerable for most people.

I think the argument of desperation, "no other anti-spam works so we might as
well try any proposal" is what may be driving your comments?


> Herbie Robinson wrote:
> however, if I understand this scheme right,
> I would only need to get a .mail domain if


If you want your outgoing mail to be treated with "more trust" (by spam filters
and humans), then the proposal says you need a .Mail domain and you must use it
for all your outgoing email.

If you do not want to .Mail enable your outgoing email, then you do not have
to.

As a recipient, you do not need a .Mail domain.


> Herbie Robinson wrote:
> ...The dreamers out there who think SMTP servers
> should be open commodities are either spammers or
> don't realize that open servers invariably get 
> black listed and can't effectively send mail anyway.


I think you may have misunderstood what I meant in previous post where I said
most people have an occassion to use a different SMTP server as their relay
mail server.

I did NOT mean unauthenticated use of open relays.  I meant for example if I
use the relay server of the dialup providers I am using when traveling on
business in a foreign country.

Yes there are technical ways to always route email back through your home
(approved and verified) mail server for the domain of your email address, but
this isn't always the most practical for most people, not to mention educating
*everyone* (in the corporation or ISP whose domain is .Mail enabled) how to do
it.

To make it clear, I was not saying people need to use open relays, although if
we did develop an anti-spam that worked 99+% that did not care about open
relays, then we could go back to the glory days of when black listing of open
relays was unnecessary.  AccuSpam is actually developing and will soon release
an algorithm that proposes to restore those glory days!


> Herbie Robinson wrote:
> I am making the assumption that I will never have
> to use a .mail TLD as part of an e-mail address
> (i.e., name@xxxxxxxxxxxxxxx). I wouldn't like that one bit,
> but doesn't solve any technical problem; so, I can't imagine
> they are proposing that.


They are proposing that.  You must use .Mail on your outgoing email if you want
it to be "more trusted".


> Herbie Robinson wrote:
> ...I don't see what the problem is with ISPs providing servers
> for their customers to send mail with.


The problem is that the ISP a sender connects with is not always the same ISP
that their domain is hosted on.  The .Mail proposal says that if you wish to be
.Mail enabled as a sender, then the approved and verified servers for the
domain of your email address must be listed in their centralized database "a
priori" (before hand).  You can not just use some other ISP while you are
traveling, unless you use some technical trick to route your email back through
your home (approved and verified) mail server for the domain of your email
address.


> Herbie Robinson wrote:
> They do it, now, and virtually no spam comes through
> those servers.

You think no spam comes from ISP's customers?

You are misinformed then.

A significant amount of spam is coming these days from ISPs because of accounts
bought with stolen credit cards and computers that are running as virial spam
proxy.


> Herbie Robinson wrote:
> ...I don't think that the use of the .mail domain
> should be limited to large bulk mailers. I think ISPs
> should be encouraged to use .mail for their SMTP servers
> (along with a policy for the occasional slip ups that will
> occur). To this end, I think there should be fines for sending
> spam from a .mail domain, an all-or-nothing take it back
> approach doesn't seem workable. People do make mistakes...


You just proved the logic in my previous posts in this forum.

You agree there will be mistakes, yet for .Mail to be a 100% spam-free
guarantee, then there can not be mistakes.  If the mistake is a spam gets
through, then that is a false negative.  If a mistake is that sender does not
use an approved and verified mail server, then email is deleted and that is a
false negative.


> Herbie Robinson wrote:
>...[snip]


Shelby Moore
http://AccuSpam.com



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

Privacy Policy | Terms of Service | Cookies Policy