Subject: [Asrg] The Consent 4-Tuple

From: "Alan DeKok" <[email-masked]>
Date: Thu, 06 Mar 2003 14:07:23 -0500

I'd like bring the discussion more on-charter, and to use
quantitative terms to describe the problem.

  Most of the discussion here has been about user-based consent.  The
charter (unclear as I find it) doesn't discuss in detail what is meant
by "consent".

  So having a background in Physics, I thought I'd come up with some
math-style new vocabulary to describe *whose* consent we're talking
about.  I don't have time to write a draft, but I was able to type up
a few short thoughts, in between other work.

----------------------------------------------------------------------

	The Consent 4-tuple
	-------------------

  The general model for email traffic is that there is an email
originator (end-user), a local SMTP gateway, a remote SMTP gateway,
and a final recipient of the email.  To use unique terms:

#--------
  email originator -> SMTP sender -> SMTP receiver -> final addressee/user
#--------

  In order to better discuss the issues involved, I will define a
"consent 4-tuple".  This allows us to make quantitatively descriptions
of consent in SMTP conversations.

  The consent 4-tuple is composed of 4 values:

  (O,S,R,A)  Originator, sender, receiver, and final email addressee

  We use tokens to describe consent of each party:

  -	made a statement to NOT consent to the traffic
  0	made no statement
  +	make a statement to consent to the traffic.
  *	all of the above.

- The majority of email today is (+,0,0,0)
  Originator consents to send it, sender/receiver make no statement,
  and the addressee makes no statement.
 
- Dictionary attacks on email addresses are: (+,*,*,-), or (+,*,-,)
  Originator consents, addressee doesn't consent,
  or addressee doesn't exist, and therefore can't consent.
  Note that unsolicited email from honest people may
  also be (+,*,*,-).

- User spam filtering is (*,*,*,-)
  Late in the traffic... bad idea.

- ISP spam filtering is generally (*,*,-,*)
  Do you really trust your ISP to filter your spam?

- Originating ISP blocking port 25 outbound is (*,-,*,*)
  Early in the traffic, good idea.

- RBL's are (*,*,-,*)
  Receiver administers consent.

- DUL's are (*,-,-,*)
  Sender declares non-consent, receiver agrees to not consent.

- Open relays are (+,0,*,*)
  Why should we care about the spammers consent?

- Open relays (or misconfigured proxies) behind a packet filter on
  port 25 are (+,-,*,*)
  This isn't a problem...

- RMX (reverse MX) is: (*,+,*,*)
  Sender consents to source SMTP, recepient may (or may not) agree.

- The naive "roaming user" is (+,,-,0)
  The sender doesn't exist, because the roaming user is the sender
  The receiver does NOT consent, because he's being lied to about
  where the mail is coming from.  (Lack of informed consent==no consent)

- The smart roaming user is (+,+,0,0)
  His sender consents to forward the email.
  This is also SMTP authentication of the originator.

- SSL certificates (client-server) are (*,+,+,*)
  Both S/R consent, because they've been authenticated.

- Spam from well-known domains is (+,+,0,-), or (+,+,+,-)
  (e.g. throw-away accounts at otherwise-respectable ISP's)
  Everyone consents to handle the data, but the addressee
  decides that it's spam. 

- Spam with forged "from" lines is: (+,0,-,*), or (+,*,0,-)
  The receiver did NOT consent to being lied to.

- Spam with forged "from" lines coming from spam hosts is (+,+,-,*)

- Spam filters like spamcop.net are (*,*,-,*), or (*,*,+,*)
  They consent to throw away bad traffic, or to pass only known good
  traffic.

- A happy world is (+,+,+,+)

  The problem is that (+,+,+,+) is a MUCH smaller space than
  !(+,+,+,+).  This means any implementation based on declared
  non-consent will be hugely more expensive than one based on declared
  consent.

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

---

From: Chris Fedde <[email-masked]>
Date: Thu, 06 Mar 2003 18:33:22 -0700

On Thu, 06 Mar 2003 14:07:23 -0500  "Alan DeKok" wrote:
 +------------------
 | 	The Consent 4-tuple
 | 	-------------------
 | 
 |   The general model for email traffic is that there is an email
 | originator (end-user), a local SMTP gateway, a remote SMTP gateway,
 | and a final recipient of the email.  To use unique terms:
 | 
 | #--------
 |   email originator -> SMTP sender -> SMTP receiver -> final addressee/user
 | #--------
 +------------------

I applaud your effort to make an algebra for spam. But I think that your
notation misses the target.

The common literature uses the terms Sender MUA, Sender MTA, Recipient
MTA, and Recipient MUA. I'm not sure that there is much to be gained by
changing the terminology. I think that there is room for definitions of
true sender and true recipient too. Also I'm fuzzy on the difference
between * and 0 in your notation.

Each of these components is an agent for "real people", namely: the
sender and the recipient. I might need a little hand waving here to cover
bots, reflectors, list managers and the like but even they are setup on
the behalf of real people.

The goal of the Sender MUA/MTA pair is to implement the wishes of the
sender and the Recipient MTA/MUA is to implement the wishes of the
recipient.

The sender always "consents" to send the mail (modulo accidents). So we
would never see mail that it is unlikely that the Sender MUA would work
in a way against the senders wishes. And it would be totalitarian indeed
if it did. The Sender MTA may choose to throttle traffic from the Sender
MUA on grounds of self preservation but it seems unlikely that it would
implement any higher policy that prevents it from attempting to achieve
the senders desires.

So the job for the senders MUA/MTA are simple: Get the mail into the
hands of the recipients MTA/MUA.

The recipient MTA/MUA on the other hand works for the recipient.
Its goals are more complex. It must attempt to meet two conflicting
wishes on the part of the recipient. First of these wishes is to
see mail that the recipient wishes to see. Second is to not see
what they don't want to see.  Because the recipient has not yet seen the
mail this is a problem of prediction and thus has lots of interesting
failure modes.

Both the recipient MTA and the recipient MUA and the network surrounding
them may provide some traffic shaping/blocking features to protect their
availability.  Then both the recipient MUA and MTA may run various
categorization and markup features that allow the recipient to
select/sort her email.

An algebra to describe spam will involve the recipients view of
email.  Mostly it will require notations for functions on the feature
space of the email message and the recipients wishes.

--
    Chris Fedde

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 06 Mar 2003 17:58:25 -0500

Chris Fedde <[email-masked]> wrote:
> changing the terminology.

  I'm not proposing changing the terminology, I was just avoiding the
work of recalling yet another series of acronyms.  I'll fix the
terminology...

> I think that there is room for definitions of true sender and true
> recipient too. Also I'm fuzzy on the difference between * and 0 in
> your notation.

  The '*' is intended to mean "the rule fits ANY value of consent at
this stage".  It's less of a statement about the consent of the party
involved, than a short-hand for simplifying rules/

  e.g. The description of the senders rule says (+,*,*,*), when the
recipient applies his rule (*,*,*,-), the result is (+,*,*,-).  It's
basically "set intersection".

  The end result is we have a shorthand description of the consent of
the parties involved.  We know the sender consented, we know the
recipient did not.  We don't know (and it may not matter) whether or
not the other parties consented, made no statement, or claimed
non-consent.

> The Sender MTA may choose to throttle traffic from the Sender MUA on
> grounds of self preservation but it seems unlikely that it would
> implement any higher policy that prevents it from attempting to
> achieve the senders desires.

  I disagree.  Unintentional open relays/proxies are (*,0,*,*).  The
'0' in the sender MTA consent results in the sender MUA being allowed
to send spam.  The relays consent SHOULD be (*,-,*,*).  The '-' in the
sender MTA consent results in the sender MUA being prevented from
sending spam.

  I tend to find this sort of quantitative analysis more productive,
and more informative than statements like "relays are bad!"

> space of the email message and the recipients wishes.

  Sure.  But it should also be able to describe open relays, SMTP
sourcing from dial-up accounts when the ISP failed to prevent that,
etc.

  I've found most of the discussion here focussed on the recipients
view of email.  I would like to change that.  My experience with spam
has been that there are other major players in the conversation who's
consent (or lack thereof) is being ignored in recipient-based models.

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 07 Mar 2003 09:23:57 +0000

> On Thu, 06 Mar 2003 14:07:23 -0500  "Alan DeKok" wrote:

Likewise.

> if it did. 

I'm not sure that that's always the case.  For instance,
If my webmail system enforces some policy on the content of outgoing mail 
(I don't want my users to send 419 scam stuff),
then this assertion is invalidated.

> space of the email message and the recipients wishes.

As has been said earlier on this list, we need to identify the entities
giving
and seeking consent (and the precise nature of that consent?), Alans
algebra works
towards that. We also need to characterise the "communication". This may
include
consideration of endpoints (or other traffic characteristics - rate?) as
well as
content.

--
Regards,
Jon Kyme

--------------------------------------------------------------------
Get your free email address at http://www.merseymail.com/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 07 Mar 2003 05:47:57 -0500

"Jon Kyme" <[email-masked]> wrote:
> I'm not sure that that's always the case.

  Take virus.  The email originator is often an individual with a
laptop, who *isn't* running mail/virus filters, so they're (0,*,*,*)
for viruses.  This allows the viruses to spam themselves to hundreds
of people.

  With a virus scanner installed, the originators are (-,*,*,*) for
that problem, and therefore don't contribute to the spam problem.

> As has been said earlier on this list, we need to identify the
> entities giving and seeking consent (and the precise nature of that
> consent?), Alans algebra works towards that. We also need to
> characterise the "communication". This may include consideration of
> endpoints (or other traffic characteristics - rate?) as well as
> content.

  I agree.  Without some kind of short-hand notation, we're left with
statements like "the originator failed to indicate non-consent, the
MTA's had no opinion, and the recipient filtered out the email as spam
from a virus".  I find it (0,0,0,-) much simpler, and much more
definitively descriptive of the situation.

  Alan DeKok.

---

From: Darren Henderson <[email-masked]>
Date: Fri, 7 Mar 2003 12:31:47 -0500 (EST)

> I'm not sure that that's always the case.  For instance,

If the concept is expanded slightly its most certainly not the case - if
the tuples are defined to represent the actual, real, one and only,
entities then non-consent would apply to items with forged identities.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg