At 10:44 PM 6/4/2003 -0600, Vernon Schryver wrote:
> From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
> ...
> These four accounted for about 84% of all MTAs with the other MTAs were 1%
> or less. Of these, qmail and sendmail account for 59.28% of all MTAs, with
> the Windows ones accounting for the other 24.27%.
>
> IF a CRI protocol is implemented and both qmail and sendmail support it,
> that would mean that a sizable majority of the Internet would support it.
> ...
There is a very large difference between the the current versions of
a package supporting something and installations of the package
supporting it. It is not only that I suspect most SMTP servers are
more than a year behind in current releases, but that having facilities
available in the code is not at all the same as turning them on.
My original post ended off with:
"The question remains, taking the impact of qmail and sendmail, and the
propagation rates for admins installing the newest versions, how long would
deployment take?"
That is my question exactly, how long will it take for such feature for
propagate if it were included in sendmail and qmail. Dave Crocker begun to
address adoption issues in his draft but more work needs to be done. The
adoption/propogation of features is an issue not just with CRI but with any
anti-spam protocol or proposal. However, I believe that ISPs and end-users
have a bigger incentive to turn-on such features due to the amount of spam
today.
A good case study is SMTP-TLS. Sendmail and other STMP implementations
have supported SMTP-TLS for a year or two. Turning on SMTP-TLS
in sendmail is easy, one you figure it out the OpenSSL documentation.
It is entirely upward compatable and a Good Thing(tm) for a bunch
of reasons. However, as far as I can tell the vast majority of
the Internet does not support SMTP-TLS and practically none of the
minority that does has done the trivial additional work to make
available their certs. It's only a slight exaggeration to say that
I see almost as many signs of SMTP-TLS in my logs from spammers as
from legitimate SMTP clients. In truth I see little of either,
but some of both.
Before you say that everyone cares about spam but not about mail
confidentiality and security and so your protocol would be different,
please say why ISPs that would have to turn on your protocol have
not done what's necessary to find and crush spammers. Why did
Earthlink reportedly spend months and millions of dollars of
technician and inside lawyer time chasing the Buffalo Spammer while
the outside lawyer pin him in days?
I tend to disagree with SMTP-TLS example. Confidentiality of email via
SMTP-TLS is something that most end-users or ISPs do not care about. Even
though every single time that I send an email, the National Security Agency
or some hacker who hacked a router on the way can listen in, that does not
affect my every day life. Most users are not affected by SMTP-TLS presence
or absence since you do not see the NSA or hackers publishing people's
private email in the National Enquirer. Thus, there is not incentive for
them to do anything which is not true with spam. Whatever is true for
SMTP-TLS is also true for PGP and S/MIME, which have not become widespread.
People do not go through the added burden of setting these things up
because of lack of incentive.
As for the Earthlink example, I am not sure exactly what you mean. I was
not aware that Earthlink used outside lawyers which successed in several
days after spending money on doing it in-house. Please provide some links
for the story.
Yakov
---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research(_at_)solidmatrix(_dot_)com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg