Subject: Re: [Asrg] TitanKey and "white lies"... (..."improves" C/R utility?)

From: "John Fenley" <[email-masked]>
Date: Sun, 01 Jun 2003 10:52:57 -0600

This is in response to the entire thread, not any particular message.
One major problem I see with Titan Key is that it relies on SMTP. If at some 
point SMTP is superceded by another protocol this type of system will no 
longer be useful (Perhaps the idea would be useful, but not the actual 
implementation.
This implies the broader question: Should the ASRG support methods that rely 
on the SMTP protocol to work? Many have pointed to the SMTP protocol as a 
source of problems, and I personally believe the chances of SMTP being the 
standard email transfer method in 20-50 years are slim.
I see any solution that cannot stand on it's own, independent of protocol, 
as a temporary bandaid on the larger problem (unless that protocol is 
perfect and will never ever be changed for all of time). Any support for an 
old protocol simply extends it's life, and SMTP is showing it's age.

Also, changing how SMTP is handled to do extra checks can make MTAs more 
vulnerable to resource consuming Denial of Service attacks because every 
mail message received requires more resources in the receiver than the 
sender.

I see the solution to this as a decision about whether or not ASRG should 
invest it's time and effort in a protocol that is old, and subject to abuse. 
If the answer is no, then i believe much of the constant bickering over 
specific details in SMTP can be avoided. Solutions discussed here might be 
more forward looking, and less reliant on squeezing as much as possible from 
what we have.

I have often theorized that people can be divided into a spectrum by how 
much effort is put into making money, and how much is put into saving money… 
People at the extreme ends of the spectrum use almost all of their energy on 
one or the other. There are people who almost live on coupons, and free 
deals, and there are people who are so focused on making the money that even 
taking the time to go shopping would be a waste.
It is the people in the middle who seem to struggle the most with the 
balance. They are not as efficient at either one, so their less effective 
saving of less money combine to cause money problems.

I believe the way to go is the production of resources, rather than the 
saving of resources. In this group I believe we should not scrape the bowl 
to find every last crumb of good in what we have now... Enough people are 
doing that. I believe that we, as a Research group, should be the most 
forward looking group that we can be.

John Fenley

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 1 Jun 2003 14:47:23 -0400

John Fenley wrote re: SMTP and SMTP related research:
> a decision about whether or not ASRG should invest it's time 
> and effort in a protocol that is old, and subject to abuse.

	Whatever our individual feelings about the long-term utility of
SMTP may be, the reality is that the output of this group is going to be
judged based on its ability to point to solutions that can reduce the
level of spam in the short to medium term. People feel the pain today
and want it to go away soon. To tell people that we have a solution that
will work in some far distant future, after everyone has converted to
some new and "better" protocol, may be intellectually satisfying,
however, it will be perceived as having limited utility.
	I believe that the research needs, at this stage, to focus on
how one can best respond to spam given the current environment
(including SMTP) and small deltas to that environment. This research may
be informed and assisted by observations concerning how spam might be
prevented in some "ideal" environment that might include new protocols,
however, the focus should be on solving the present problem. Once the
present problem is solved, or alleviated as well as possible, it would
then, and only then, be appropriate to focus the majority of effort on
addressing the issue of constructing a future "ideal" set of protocols.
	The issue here, as almost always, is a trade-off between
tactical short-term and long-term benefits. It is very much like
computing the present-value of some quantity of money. For instance,
what has more value? $100 in your bank account today? Or, $1,000 in your
bank account in 20 years? The answer, of course, depends on what you
think the interest rate or cost-of-capital is. Similarly, when thinking
about spam, you can ask which is more valuable: A system that rapidly
limits spam to 50% of its current level or one that eliminates it
completely in five years? In the context of spam, the cost-of-capital or
interest rate is the "pain and cost" of the growing levels of spam. If
you think that this pain is low, then you would be more likely to focus
on the long-term goal, if you think it is high, then you should focus on
the short term problem (i.e. at least try to reduce the "interest
rate"). 
	I believe there is much evidence that the average email user
believes that the "cost of spam" is high enough that the value of
immediate solutions outweighs the value of even a "perfect" system in
the future.
	Yes, it would be wonderful to solve the problem permanently.
However, it would be more "useful" or "valuable" to limit it in the
short term. 

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Fenley
Sent: Sunday, June 01, 2003 12:53 PM
To: [email-masked]
Subject: Re: [Asrg] TitanKey and "white lies"... (..."improves" C/R
utility?)

This is in response to the entire thread, not any particular message.
One major problem I see with Titan Key is that it relies on SMTP. If at
some 
point SMTP is superceded by another protocol this type of system will no

longer be useful (Perhaps the idea would be useful, but not the actual 
implementation.
This implies the broader question: Should the ASRG support methods that
rely 
on the SMTP protocol to work? Many have pointed to the SMTP protocol as
a 
source of problems, and I personally believe the chances of SMTP being
the 
standard email transfer method in 20-50 years are slim.
I see any solution that cannot stand on it's own, independent of
protocol, 
as a temporary bandaid on the larger problem (unless that protocol is 
perfect and will never ever be changed for all of time). Any support for
an 
old protocol simply extends it's life, and SMTP is showing it's age.

I see the solution to this as a decision about whether or not ASRG
should 
invest it's time and effort in a protocol that is old, and subject to
abuse. 
If the answer is no, then i believe much of the constant bickering over 
specific details in SMTP can be avoided. Solutions discussed here might
be 
more forward looking, and less reliant on squeezing as much as possible
from 
what we have.

much effort is put into making money, and how much is put into saving
money. 
People at the extreme ends of the spectrum use almost all of their
energy on 
one or the other. There are people who almost live on coupons, and free 
deals, and there are people who are so focused on making the money that
even 
taking the time to go shopping would be a waste.
It is the people in the middle who seem to struggle the most with the 
balance. They are not as efficient at either one, so their less
effective 
saving of less money combine to cause money problems.

I believe the way to go is the production of resources, rather than the 
saving of resources. In this group I believe we should not scrape the
bowl 
to find every last crumb of good in what we have now... Enough people
are 
doing that. I believe that we, as a Research group, should be the most 
forward looking group that we can be.

John Fenley

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 1 Jun 2003 15:09:23 -0400

In my previous note, which suggested an objective economic
analysis as the basis for deciding between a short or long term focus, I
should have noted that it appears that the "cost of spam" is increasing
at a compound rate. Some suggest that this rate is equal to as much as
50% per year.
	Given compound growth in the "cost of spam", the present-value
of any future solution is drastically reduced as the time to implement
and deploy that solution increases. Similarly, the future-value of any
short-term reduction in the cost-of-spam is drastically increased as the
time to implement the short-term reduction is reduced relative to the
time-to-implement the long-term ideal solution.
	I suggest that an economic analysis of spam argues clearly and
unambiguously for the greater value of even the smallest short-term
reductions in spam rather than more perfect solutions that may be
possible in the long-term.

		bob wyman

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 1 Jun 2003 15:41:57 -0400

At 10:52 AM -0600 6/1/03, John Fenley wrote:
>This implies the broader question: Should the ASRG support methods 
>that rely on the SMTP protocol to work? Many have pointed to the 
>SMTP protocol as a source of problems, and I personally believe the 
>chances of SMTP being the standard email transfer method in 20-50 
>years are slim.

Reliance on SMTP is fine.  Any new protocols will presumably attempt 
to deal with the problem from the ground up, rather than by patching. 
The chances that they'll have any need or desire for whatever systems 
we propose are slim.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Sun, 1 Jun 2003 23:57:44 -0400

> longer be useful (Perhaps the idea would be useful, but not the actual 

This is the contrapositive of the "it would take too long for a
significant number of end-users/servers to adopt XYZ".

I think it's safe to say that SMTP will be in use for a long, long
time, particularly since there's absolutely nothing at this time even
on the horizon to replace it.

And my educated guess is that any evolution of SMTP will be
incremental and backwards compatible. Since SMTP is basically just
<VERB> <NOUN>* it's hard to see what brilliant insight would obsolete
it. The VERB part has already been co-opted to say from here on we're
doing a major extension of the protocol if it's ok with you (i.e.,
EHLO).

Put another way, to paraphrase the old joke about Fortran, I don't
know what people will be using to deliver email 20 years from now, but
they'll probably call it SMTP (and it'll probably be mostly backwards
compatible.)

But...I COULD BE WRONG.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Mon, 2 Jun 2003 00:23:02 -0400

On the other hand, spam has been around for almost 10 years, and has
certainly been a major concern at public sites since at least 1997,
almost seven years ago.

So, although a quick solution of some magnitude is almost mandatory
just to stop something major kicking over the entire chessboard (death
of the net and all that), let's not completely rule out so-called
long-term, slow adoption approaches with 5-10 year horizons or even
longer.

For example, if someone came up with a really clever anti-spam
strategy which 25% of the net adopted in 2 years and 50% in 5 years
and perhaps 98% in 10 years that should be seriously considered w/o
the usual "it'd take 5-10 years for most of the net to adopt something
like that!"

It really depends on how much good it might do along the acceptance
curve. Some approaches won't do much good until most everyone accepts
them, others might do a lot of good if just some early adopters adopt
them such as major ISPs.

The shape of that curve can be as important as its final outcome.

-- 
        -Barry Shein

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 2 Jun 2003 11:52:30 -0400

> The shape of that curve can be as important as its final outcome.
	Yes. That is precisely the point that I was making by suggesting
that one use an economic analysis in comparing the utility of short-term
vs long-term solutions. In many cases a "perfect" solution/outcome far
in the future will be "less valuable" than a partial solution in the
more near-term.

> Some approaches won't do much good until most everyone 
> accepts them, others might do a lot of good if just some 
> early adopters adopt them such as major ISPs.
	And some approaches produce immediate value whenever a single
individual adopts them. For instance, filtering systems, whitelists, and
"single-use addreses" like those of TMDA, provide immediate and
substantial short-term benefits. For those users, the present value of
using such solutions if massively greater than the present value of any
"perfect" solution that might arrive, or begin to arrive, several years
in the future.

		bob wyman

---

From: Barry Shein <[email-masked]>
Date: Mon, 2 Jun 2003 19:42:27 -0400

Well, we could propose a simple, three-dimensional model for any spam
solution whose axes would be:

	 1. Adoption (perhaps percentage of servers or clients.)
	 2. Spam reduction (percentage of spam)
	 3. Time (years or whatever.)

and try to judge the merit of a proposal on that basis.

Obviously one can't predict such a curve with any great accuracy but
at least we'd be estimating the same parameters for discussions' sake.

As an example, I think RMX would have a fairly steeply rising curve
over time for Adoption, particularly if # of servers was weighted by
the number of clients they represent (e.g., if AOL adopts it then
that's a big jump), and then adoption would probably slow down a lot
(i.e., early adopters adopt early and everyone else ignores it
mostly), and the (measurable) spam reduction would be small to zero
because I don't think it's a spam-reducer.

Others no doubt have another opinion, but if accepted this might be
some grounds for a common criteria.

I'll dub it the "Effectiveness Axes" or E-Axes for short.

-- 
        -Barry Shein

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 3 Jun 2003 09:43:57 -0400

Trying to come up with the right place to shim in the CRI control headers.
It seems we can do the following:

1) Use SMTP headers: beyond the deployment issues, CRI is not limited to the
envelope and there are often many mail relays in the path that could remove
such headers.  We do not want to restrict mail clients from implementing
CRI.

2) Use RFC 2822 headers: we could possibly introduce a new field altogether
or use an optional field as spec'd in 3.6.8

3) Use MIME headers (registered or private): though CRI has little relavancy
with MIME.  Private headers can not become a standard.  There isn't such a
limitation on 2822 3.6.8

Thoughts?

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 3 Jun 2003 09:12:05 -0600 (MDT)

> From: "Eric Dean" <[email-masked]>

> with MIME.  Private headers can not become a standard.  There isn't such a

If the goal is to get a CRI protocol defined and deployed to stop some
spam, why do you care about the fact that private headers (presumably
X-whatever) cannot become a standard?

I thought you guys were clever to use MIME for more than one reason.
Pushing a new official RFC 2822 header (other than an ad hoc X-whatever)
through the IETF would take a year or more and you might fail.  That
you are sure challenge/response systems will be effective against spam
will be a weak response to Last Call criticisms.  However, I've the
impression that MIME headers don't have that bureuacratic problem to
the same degree.  That should be checked.

MIME in either or both directions might allow you to pass more data
than a header.  For example, do you have cryptographic authenticators
of either the challenge or the response?  What about an authenticator
of the original sender for the receipient/challenger's whitelist for
subsequent mail?

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 03 Jun 2003 13:56:13 -0400

>X-whatever) cannot become a standard?

Inter-operability is a key, if X- headers are used (or MIME "x." type) then 
nothing stops someone from making their own ones. The whole point of such 
protocol is that it would be a standard that cannot be changes at the whims 
of some vendor.

>the same degree.  That should be checked.

According to section 2.1.1 of RFC 2048, there is plenty of bureaucratic 
problems involved. I am assuming that we would want to register this MIME 
type under the IETF tree, if so the following from RFC 2048 applies:

"The IETF tree is intended for types of general interest to the Internet 
Community. Registration in the IETF tree requires approval by the IESG and 
publication of the media type registration as some form of RFC."

The MIME type would have to go through the standards process anyway. 
Additionally, all MIME types of type "message" which I am assuming will be 
used for CRI, have been registered based on RFCs (take a look at 
http://www.iana.org/assignments/media-types/message/).

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
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)
---------------------------------------------------------------------------------------------------

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 3 Jun 2003 12:12:52 -0600 (MDT)

> From: Yakov Shafranovich <[email-masked]>

> ...

No, that is not the point of such a protocol, because the IETF does
not have an army.  The whims of vendors are not prevented by words in
documents labelled "RFC." The only people who really pay attention to
RFCs are programmers trying make things compatible and users, often
out of a misplaced religious reverence.  There are no "netcops" who
will disconnect non-conformant systems.  There have been and always
will be many cases where vendors have blandly ignored the clear words
in standards track RFCs.

More important, any vendor that wants to build a protocol with some
(other) X-header is always absolutely free to do so, no matter what
other protocols have been designed or are in use.  That is by design
and intent.  A stanards track challenge/response RFC or official SMTP
header would have no effect on anyone who doesn't want to play your
game by your rules.

The only effective purpose of an RFC is to document things so that
people who do want to play by other people's rules can learn what
those rules are.

> ...

That is mistaken.  IESG approval and writing an Informational or
Experimental RFC is very quick and easy compared to getting consenus
in the appropriate WG for an official and so Standards Track SMTP
header.