Re: Why are we here? What are our goals?

On Fri, 30 Jan 2004 08:58:24 -0800 
Chuq Von Rospach <[email protected]> wrote:
> On Jan 30, 2004, at 1:53 AM, Hector Santos wrote:

> And that's the rub at putting anonymity down at the transport
> layer. you open up a huge hole for the spammers to use; they'll simply
> start setting up trust engines using bogus real world data, and use
> that to relay spam in to you. And as fast as you figure out that
> you're trusting something untrustworthy, they'll move on and replace
> it with a new bogus trust handler.

Slightly tangentially, the current approach defines a strict division of
responsibilities among the MTS, MTA, LDA and MUA, to a point where,
effective, none of them talk to each other.  This doesn't make sense.
The whole system exists in service of the human behind the MUA, and yet
that human has no direct way of influencing the solution stack that is
supposedly working on his behalf.  This is, in IBM terms, Broken As
Designed.  Currently MXes accept mail for their users with no way of
knowing if that mail is desired or not (and thereby operate with
horrible inefficiency), or of communicating that information back over
the transport layer.

The definition of spam is subjective to the end user.  One man's spam is
another man's ham.  As a very simple example, frequently that definition
of "spam" includes mailing lists which that end user explicitly
subscribed to.  There are many other equally silly/useful/painful
examples that consume postmaster and abuse dept time needlessly.  Humans
are like that.  The core of the mail problem and value isn't payload
definitions or audit methods or even of transport anonymity, but of
policy definition, communication and enforcement.  The current email
system allows no particularly useful ways of determining between "I want
to receive this message" and "I don't want to receive this message"
without consulting the end using human or his MUA proxy and that's just
dumb.

In this line specifically for email (a certain payload type) what we're
really talking about is consensual communication and the ability of the
end user to not only express his consent, but to have that relationship
enforced by the system.  To do that effective;y needs three things:

  1) Ability to express the desired relationships.

  2) Ability to encode the relationship data across the transports, both
  to the transport system itself, and to the MUAs that are proxying for
  the foreign users.  

  3) Ability for the policy defined by those relationships to propagate
  up the stack toward the boundaries of control areas (eg to his
  company's or ISPs receiving MXes (all of them) such that those nodes
  may act directly in his email interest.  (There may also be a value in
  public promulgation of end-user policies, tho that raises privacy
  concerns)

Questions of authority and identification are part of the consensual
algebra.  Consent relationships can be expressed (and enforced) in terms
of authority, identity, and anything else the end user wants.

Sample policies might contain statements like:

  Accept all company announcements (over-rides individual preferences).

  Reject all mail from my ex-wife.

  Don't accept mail with headers that fail to audit.

  Accept anonymous mail that bears this token: XYZ.

  Refuse mail from the MillionJokesADay list with a "EndUserRejected" RC
  (which prompts the MLM to auto-unsubscribe that address).

Yeah, this sounds like firewall rules territory.  The parallel is
direct: firewalls are concerned with accepting and (variously) rejecting
packet streams, just as email systems are for messages.  The difference
is that firewall policies don't currently generally propagate and have
little reason to.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email protected]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.