Subject: Re: [Asrg] 1. Inventory of Problems - Input Needed

From: "Alan DeKok" <[email-masked]>
Date: Thu, 06 Nov 2003 10:57:26 -0500

"Jon Kyme" <[email-masked]> wrote:
> >   That document needs to be expanded to talk about specific network
> > configurations used to deliver mail, which protocols are involved
> > where, and which fields of those protocols are open to what kind of
> > abuse.  Once we have such a document, we can then proceed with
> > "solving the problem in diagram X, protocol Y, abuse of field Z".
> 
> Isn't email path verification in the domain of the msgtrk group?

  Sure, but message tracking has nothing to do with prevention of
abuse.  Message tracking includes a way of tracking down abuse among
*cooperating* entities, but even that tracking doesn't help when
spammers don't cooperate.

  My reason for drawing network "tracking" diagrams for email is to
write down the problem we're trying to solve.  Currently, the charter
is vague, and very unhelpful.  Witness the huge volume on the list,
for the first few months.  Most of that volume was caused by people
talking at cross purposes, because no one agreed on a problem
statement.

  By drawing diagrams of entities & protocols in the network, we can
say "spammers are abusing diagram X, protocol Y, and field Z".  We can
then come up with a solution which addresses that abuse, and doesn't
affect anything else in the network.

> I'd like to raise a couple of issues with it as it stands:
> "False Claims - regarding opt-in" duplicates "Inadequate opt-in"
> "Not a real business" doesn't seem to mean anything.

  Are we to solve the problem of consent to *business* communication,
or are we dealing with protocols on the Internet?

  I believe that social issues (like lying about opt-in) should be
outside of the scope of this group.  There's little to nothing we can
do to address those problems.  And anything we CAN do to address those
problems will involve protocol changes on the net.

  Alan DeKok.

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

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 06 Nov 2003 20:20:31 +0000

AD wrote:
> outside of the scope of this group.  

Right.

> Currently, the charter
> is vague, and very unhelpful.  

I can't agree with that. Generalising the problem as a consent / policy /
enforcement thing means we don't start by talking about spam, spammers and
what spammers do. We just (!) need to identify opportunities for
(recipients) policy expression, transmission and enforcement in (or
alongside) the MTS. This isn't vague (it may not be what a lot of people
want to see) and I don't see why this can't be helpful.

For instance, C/R and and other Consent-token schemes don't know anything
much about *spam* and the only thing they assume about *spammers* is that
the business model precludes the human or other resources required to get
through.

A filtering system based on the use of a filtering engine doesn't know
anything about the content of *spam* except that it differs somewhat from
*non-spam* (the particular engine used will know more than this).

> Witness the huge volume on the list,

I agree somewhat. As I remember, much of the traffic was produced by people
touting their own silver bullets or, like you say, talking at cross
purposes - because they weren't using the consent model.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 06 Nov 2003 15:29:27 -0500

> want to see) and I don't see why this can't be helpful.

It is hard to explain consent to someone when all the legal efforts are 
talking about consent. People tend to misunderstand the concept. 
However, I think that both of you are right - we need to look at what 
spam and spammers do AND at how we start looking at the entire email 
system as one with consent.

> *non-spam* (the particular engine used will know more than this).

Do you think that the current draft of the consent framework seems to be 
heading in the right direction?

Draft: http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html

---

From: David Maxwell <[email-masked]>
Date: Thu, 6 Nov 2003 15:38:38 -0500

On Thu, Nov 06, 2003 at 08:20:31PM +0000, Jon Kyme wrote:
> Alan DeKok wrote:
> what spammers do.

I agree with John, that the charter is helpful. However, I agree with
Alan, that the charter is vague.

I see what Alan proposed as a set of use cases for messaging.

Once you have them, you can identify which use cases are abused by
spammers. You can look at which proposed solutions affect which cases.
You can look at which cases suffer side-effects from each proposal.
Instead of 'A is better than B', you get to 'A fixes 1,2,3 - B fixes
3,4,5 - seems that we need a bit of both'.

 We just (!) need to identify opportunities for
> want to see) and I don't see why this can't be helpful.

A set of use cases would allow definition of trust diagrams, which would
show which attributes of the communication are trustworthy at each
transition (between hosts/organizations/programs/protocols). It's not
that what you said can't be helpful - I think it needs to be more
specific.

> *non-spam* (the particular engine used will know more than this).

It's possible that some sub-set of the solutions affect all the use
cases equally. Their side-effects probably effect all uses-cases equally
as well.

-- 
David Maxwell, [email-masked][email-masked] --> The only difference I see
between voodoo and marketing research is that voodoo sometimes works! 
						- Leonard Stern

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 06 Nov 2003 15:45:30 -0500

> I see what Alan proposed as a set of use cases for messaging.

Someone already wrote a document with a set of use cases! See this message:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg07695.html

The document is available at:

http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

We need to think how that can be intergrated with the inventory of 
problems work.

---

From: David Maxwell <[email-masked]>
Date: Thu, 6 Nov 2003 15:57:15 -0500

> We need to think how that can be intergrated with the inventory of 

It can certainly be used. I don't think it's quite specific enough for
the final version - as we need to cover protocol specific issues.

In other words, the use cases there will need to be split into each
method that a user currently has available for delivering a message
appropriate to that use case.

-- 
David Maxwell, [email-masked][email-masked] -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
					      - Jamie Woods

---

From: Eric Allman <[email-masked]>
Date: Thu, 06 Nov 2003 15:57:04 -0800

| The document is available at:
|
| http://studenti.lboro.ac.uk/~coada/project/usecases.pdf

I believe this (quite good) document misses at least one very 
important use case:  Sender Alice ([email-masked]) sends a message 
to Bob ([email-masked]), but he has a new account and has 
forwarded his old address to his new address ([email-masked]).

eric

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 7 Nov 2003 12:36:12 +0000

> forwarded his old address to his new address ([email-masked]).

Ah, many thanks... Someone else had separately pointed this out to me. I
shall add it as an additional scenario.

I've been getting behind with my ASRG mail, but will make a more determined
effort to catch up :-)

Andrew

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 7 Nov 2003 12:47:06 +0000

> appropriate to that use case.

I think I understand what you mean, but could you perhaps give a more
specific example?

The problem I've found in writing those scenarios was that there is a huge
number of configuration permutations. Hence they're currently rather
general. Any suggestions for how to manage the complexity in generating a
large number of similar (but subtly different) scenarios would be appreciated. 

I had considered rewriting the document in the form of a table whose columns
represent different aspects of the scenario and whose rows correspond to
each scenario, e.g.:

Sender address | Recipient address | Forwarding? | Mailing list?
----------------------------------------------------------------
[email-masked]    | [email-masked]         | No          | No
[email-masked]    | [email-masked]         | Yes, by Bob | No

Given suitable explanations of what each column means this might make it
more manageable. Any thoughts?

At the moment the document isn't very good, but given some more work and
ideas I'm sure it can be improved.

Thanks

Andrew

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 07 Nov 2003 10:43:29 -0500

> I think I understand what you mean, but could you perhaps give a more

  My take on it is that your document talks about what the users do,
and what their intentions are.  I'm a protocol guy, so I don't have
access to the users intentions.  Therefore, the diagrams I need are
diagrams of network boxes, and the protocols they use to interact.

  That is, machines on the network don't see intentions.  They see data.

  When "bob" sends "alice" email, he may do so through any number of
methods.  Roaming, webmail, ISP, vpn, etc.  All of those scenarios
have the same intentions, but they also have drastically different
implementation diagrams.

> Sender address | Recipient address | Forwarding? | Mailing list?

  Again, you're focussing on intentions.  This makes it difficult to
figure out what to do.  It also makes it difficult to talk about it on
the list, as the situations are wide-open for personal
interpretation.  "Well, MY mailing list works, and YOURS doesn't, so I
don't see why you would want to change anything..."

  Keeping things on a protocol level means that personal issues are
largely avoided.  It also means that you have something concrete to
talk about: "Box A talks to box B, using protocol C, which has fields
D, E, and F, used to send messages.  Field F can be forged
undetectably, so we propose solution G to address that forgery..."

  In contrast, a "mailing list" means many different things to
different people.  Such lists are implemented and configured
differently, all due to the intentions of the administrator.  This
means that no one can agree on the definition of a "mailing list", as
everyone uses them in slightly different manners.

  Alan DeKok.

---

From: David Maxwell <[email-masked]>
Date: Fri, 7 Nov 2003 13:18:12 -0500

> I think I understand what you mean, but could you perhaps give a more

I think Alan's message covered what I was going to reply with, so I'll
just give an example.

In your list, [email-masked] -> [email-masked] forwarding=no, list=no has at
least the following configurations...

alice and bob log into a unix host to read their mail, and a.com and
b.com are on the same server...

alice and bob log into a unix host to read their mail, but are on two
servers with a UUCP connection.

alice and bob log into a unix host to read their mail, but are on two
servers with an SMTP connection.

etc.

> large number of similar (but subtly different) scenarios would be appreciated. 

The total number will be large, but I suspect that a lot of cases can be
lumped together in the end, because whether 'my mbox file is on a local
hard disk / my mbox file is on an nfs mounted volume' doesn't have any
attributes that differ, as far as SMTP/spam is concerned.

Start from first principles, and focus on the attributes of the
implementation - then you'll get why architectural changes have been
made in the past, and where the _real_ differences are.

-- 
David Maxwell, [email-masked][email-masked] --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville