Re: [Asrg] C/R Interworking Framework

Yakov Shafranovich <> Thu, 05 June 2003 15:02 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA29544 for <>; Thu, 5 Jun 2003 11:02:11 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h55F1lV11454 for; Thu, 5 Jun 2003 11:01:47 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h55F1lB11451 for <>; Thu, 5 Jun 2003 11:01:47 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA29524; Thu, 5 Jun 2003 11:01:41 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NwDV-0007fk-00; Thu, 05 Jun 2003 10:59:49 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NwDV-0007fh-00; Thu, 05 Jun 2003 10:59:49 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h55EpuB10604; Thu, 5 Jun 2003 10:51:56 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h55EjJB10274 for <>; Thu, 5 Jun 2003 10:45:19 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA28853 for <>; Thu, 5 Jun 2003 10:45:13 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Nvxa-0007W4-00 for; Thu, 05 Jun 2003 10:43:22 -0400
Received: from ([] helo= ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19NvxU-0007W1-00 for; Thu, 05 Jun 2003 10:43:17 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
To: Vernon Schryver <>,
From: Yakov Shafranovich <>
Subject: Re: [Asrg] C/R Interworking Framework
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Thu, 05 Jun 2003 10:44:51 -0400

At 10:44 PM 6/4/2003 -0600, Vernon Schryver wrote:

> > From: Yakov Shafranovich <>
> > ...
> > 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 

>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 Shafranovich / <>
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