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

Scott Nelson <> Wed, 04 June 2003 16:36 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA00269 for <>; Wed, 4 Jun 2003 12:36:31 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h54Ga6i32148 for; Wed, 4 Jun 2003 12:36:06 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h54Ga6B32145 for <>; Wed, 4 Jun 2003 12:36:06 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA00188; Wed, 4 Jun 2003 12:36:01 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NbDJ-0005LB-00; Wed, 04 Jun 2003 12:34:13 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NbDI-0005L8-00; Wed, 04 Jun 2003 12:34:12 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h54GY1B31979; Wed, 4 Jun 2003 12:34:01 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h54GVNB31846 for <>; Wed, 4 Jun 2003 12:31:24 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA29865 for <>; Wed, 4 Jun 2003 12:31:19 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Nb8l-0005Fm-00 for; Wed, 04 Jun 2003 12:29:31 -0400
Received: from ([] by ietf-mx with smtp (Exim 4.12) id 19Nb8j-0005Fg-00 for; Wed, 04 Jun 2003 12:29:30 -0400
Message-Id: <aT5vaIe86J8qbrGKL02@x>
From: Scott Nelson <>
Subject: Re: [Asrg] Re: TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)
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: Wed, 04 Jun 2003 09:31:26 -0700

At 06:50 AM 6/3/03 -0600, Vernon Schryver wrote:
>> 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.

I didn't ask "Why, do you want a better reason?",
I asked, "Why do you want a better reason?"

Perhaps if I phrased it thus;

"Why are asking for an explanation of hope?"

Before I launch into a bizarre and probably hopeless off topic tangent
explaining why hope hasn't been crushed out of me even after many years 
of having my suggestions ignored, I'd like some assurance that I'm not just
confused as to what it was you were asking.  

>> 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.

You're not even responsible for that, and I am glad that 
you're willing to spend the time and effort to do it.
I might quibble about the style, but the function you are performing 
is IMO, vital, and I think you are doing an impressive job.

>> 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?

I've always assumed that it's sufficient that the balance
of good outweigh the balance of harm.  In other words,
I try to evaluate the cost/benefit of the suggestion.

The ideas were suggested as a possible solution to a problem 
that was raised regarding challenges - that most people have
trouble remembering what email they've sent, and that spammers
might therefore take advantage of the challenge vector to send more spam.

Since the suggestions are part of a larger system of changes 
involving challenge response, the "good" is dependant on how 
wide spread C/R becomes.  However, there is some good even 
without that, as I've already explained.  There might be more,
but it seems likely that those are going to be the biggest.

The next logical question from my perspective is 
"how much will it cost" (what's the exact amount of harm).

All changes have a cost, just by virtue of being changes.
(yet another way of saying "why not? isn't good enough".)
The cost here would be smaller than a normal change, 
since it's a proposed change to a proposed change, 
but I'm painfully aware that there will be an implementation cost.  
However, I'm also aware that it's easy for people (especially me) 
to overlook /other/ costs.
In particular, I wonder if there's some unobvious reason why
including messages-ids in a "in-reply-to:" header for a DSN is bad,
would damage some part of the mail system, not work over UUCP,
or ... well if I knew what else, I wouldn't need to ask.
Learning about these unknown costs is the most important from 
my perspective.  The cost of change is much easier to estimate, 
since change has been tried many times so there's a lot of history 
to compare against.

>> >> 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?  

Both I think, and a lot of other things too.
Volunteer resources aren't limited in the same way as paid ones.
Having someone work on C/R doesn't detract from work on a taxonomy
which doesn't detract from work on RMX.  There might be a few people 
who are deciding what to work on based on the general consensus of
value, but mostly people only work on things they personally feel
are a good idea.  Convincing someone that their pet solution 
is a bad idea is more likely to result in them just going away 
than in them working on something else.  Unless they're pet idea 
is actually harmful, it's usually better to encourage them in their
folly than try and stop them.

>That's a serious question, because
>it seems almost all of proposals made in this list are what Barry
>Shein meant by testosterone ranting.  

As Theodore Sturgeon remarked, 90% of everything is crud.
This group doesn't appear to be an exception, 
but that doesn't mean there are no useful proposals being made.

>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.

Don't kid yourself, there would be complaints about your
behavior even if you were handing out twenty dollar bills and
telling everyone how nice they were.  People always want more, 
and complaints about not getting it seem inevitable to me.
Likewise, there will always be a broad spectrum of the clueless,
the hand wavers, the speech writers, and the chest thumpers in
any public group.

>> ...
>> >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.)

I hadn't, but I have now that you've pointed it out.

The major difference is that my suggestions are in response
to a perceived problem, rather than a "wouldn't it be great if"
scenario.  I wouldn't be surprised though if no one used them
until after spammers actually started counterfeiting challenges,
and then counterfeiting message-ids.  Yes, I said I /hoped/ people
would adopt them much sooner than that, but with the possible exception
of challenge response systems themselves, 
that's not what I /expect/ to happen.

>> >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.

Yes, and the best models I've seen claim the number of communications 
that are made increases as N log(N) of the number of nodes that
one might wish to communicate with, which means even normal communication
has a theoretical scaling problem as cost approaches zero, 
and the size of the net approaches infinity.

But that much more modest exponential growth doesn't compare to
the spam problem, which is growing at close to Moore's law rates.  
That's why I qualified it with "quibble".

Scott Nelson <>
Asrg mailing list