Re: [Asrg] Re: TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)

Vernon Schryver <> Tue, 03 June 2003 12:55 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id IAA01457 for <>; Tue, 3 Jun 2003 08:55:20 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h53Csrn10887 for; Tue, 3 Jun 2003 08:54:53 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h53CsrB10884 for <>; Tue, 3 Jun 2003 08:54:53 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA01375; Tue, 3 Jun 2003 08:54:49 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NBHi-0005JF-00; Tue, 03 Jun 2003 08:53:02 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NBHh-0005J9-00; Tue, 03 Jun 2003 08:53:01 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h53CqDB10684; Tue, 3 Jun 2003 08:52:13 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h53CoWB10572 for <>; Tue, 3 Jun 2003 08:50:32 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA00996 for <>; Tue, 3 Jun 2003 08:50:29 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NBDV-0005BG-00 for; Tue, 03 Jun 2003 08:48:41 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19NBDU-0005BD-00 for; Tue, 03 Jun 2003 08:48:41 -0400
Received: (from vjs@localhost) by (8.12.10.Beta0/8.12.10.Beta0) id h53CoPXL015804 for env-from <vjs>; Tue, 3 Jun 2003 06:50:25 -0600 (MDT)
From: Vernon Schryver <>
Message-Id: <>
Subject: Re: [Asrg] Re: TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)
References: <aT5vaIe86J8qbrGG302@x>
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: Tue, 03 Jun 2003 06:50:25 -0600

> From: Scott Nelson <>

> ...
> >I'm not saying it can't happen, but
> >asking for a better reason than "it would be nice" and "maybe someday
> >it will help somewhat."
> Why do you want a better reason?  

yes, that's what I asked.

> Do you think the idea has merit?
> Is it worthy of further investigation?

If the idea can be specified and deployed before spam melts the net,
it's worthwhile.  Otherewise, it's irrelevant in an anti-spam research
group.  My responsibility for your idea stops with my pointing out
problems that have apparently been overlooked.

> Would implementing it cause problems for the mail system in general?

According to my rule book "why not?" is never a design justification
and "nice" and "neat" are pejorative words when applied to a design
feature.  If "Will it do any harm?" is not a form of "why not?",
"nice," or "neat," it's not directly relevant to "will it stop spam
in the lifetime of the net?"  Is your purpose in advancing the idea
to fix the spam problem?

> >> All these things are changes, and changes take time.
> >> But the costs are small, and the potential benefits large.
> ...

> >realized there are two kinds of changes, those that I can make personally
> >or that can be made by people I know and can convince, and very long
> >shots that are almost always wastes of time to even talk about except
> >while "shooting the bull."  
> Is there some other topic you feel is more worthy of discussion?

Are we shooting the bull or looking for spam solutions that will have
significant effects with 5 years?  That's a serious question, because
it seems almost all of proposals made in this list are what Barry
Shein meant by testosterone ranting.  If this mailing list were about
stopping spam in our lifetimes, then not only would there be no
complaints that I'm not being "constructive" by pointing out lacks of
likely effects, obvious gotchas, irrelevance (e.g. measurements of
what spammers do today but could easily change tomorrow), but people
would self-censor ideas that will have no significant effects.  On
the other hand, if this mailing list is about proving that we each
understand a subject that the general public thinks is very mysterious
and quite important, then any sort of criticism is wrong.

"Research" is not a "bull session," no matter what TV and movie writers
might think.

> ...
> >Yes, and C/R systems are unlikely to ever be widespread.
> I prefer to discuss the problems they can generate and potential 
> changes that lessen the impact of those problems, 
> even if the probability of wide spread deployment is remote.
> Talk is cheap, and I prefer to try the cheap stuff first.

That talk is cheap is the fatal problem with most talk about spam

Your notion of Message-IDs could easily be written as an "Individual
Submission" for an "Informational" RFC.  It would be more interesting
that most RFCs in the RFC Index, but in 5 years I doubt 1% of mail
would carry your Message-IDs.  Have you noticed the reference to
"Recommendations for generating Message IDs" in RFC 2919?  How does
your proposal differ from draft-ietf-usefor-message-id-01.txt?
seems to be an outlaw copy.  Notice its date.

(By IETF canon law, Internet-Drafts "expire" or go down the memory
hole after 6 months.)

> ...
> >On the contrary, junk mail from your correspondents "scales."
> Assuming that they don't increase the volume of spam they send
> based on their ability to do so.

No, it still "scales"

> But even if they do, still better than the current situation.

Yes, but spam would not be the problem it is without the "scaling" issue.

> >Practically no one's correspondents increase with the size of the
> >Internet (at least not this century).  
> >
> Quibble:  Most models I've seen suggest that the number of 
> interactions increases as the cost of communication decreases, 
> but it would be considerably more modest growth.

A "scaling problem" is one that gets worse with the growth of the net.
The host table had a scaling problem.  The size of a default-free
routing table may have a scaling problem.  Spam that grows with the
number of spammers on the net is a "scaling problem."

> ...
> Most people would be unwilling to de-whitelist their bank, insurance
> company, or domain registrar even if they started getting spammed
> by them. ...

> average customers pain threshold.  No out right fraud,
> or illicit come ons, but not an end to spam.

As others have said repeatedly, ending spam is impossible and not
a goal.  We can at most hope to end spam as a major problem.

Vernon Schryver
Asrg mailing list