Subject: Re: [Asrg] ASRG work items

From: "Jon Kyme" <[email-masked]>
Date: Thu, 10 Apr 2003 14:05:15 +0100

> 
> 
> 
> Here is the list of work items that have been identified. If there are
> other
> items that should be added to the list, please propose them. All
> conversation on this mailing list must be regarding one of these items.
> The
> subject of each email should begin with the number of the appropriate
> work
> item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -

Ah, those were the days.
Seriously, I'd like to propose a work item that we need adding to the list:

Consent - definition and determination

This is a key term for which we need a broadly agreed definition.
Particularly since the group is chartered to deal with consent-based
communication
(or rather communication which isn't consent based)

I look forward to your response.

Regards,
Jon Kyme

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

---

From: Liudvikas Bukys <[email-masked]>
Date: Thu, 10 Apr 2003 11:38:30 -0400

I have been thinking about explicit consent models and representations.

The one place that I think is crying out for explicit machine-verifiable
consent is opt-in and opt-out.  Because current practice is so free-form
and unconstrained, there is a (growing) grey area of deniability where
even well-meaning mailers make it too hard to opt out, are too tempted to
share their opted-in information.

As I composed this note, I noticed that it touches on work item 5.b.:
  5.b. Opt-out. The idea here is that there should be a standard method of
  opting-out so that it can be done by a program. There should also be a way
  to systemically verify compliance. volunteer?

HOWEVER, I'm thinking larger:  codify both opt-in and opt-out practice to
(1) make consent creation explicit,
(2) make opt-out uniform and unequivocal,
(3) reduce the inventives to share indiscrimately, by making it obvious
    who shared what.

Here is a minimal consent model, that happens to map cleanly onto current
"best practice" confirmed opt-in, while extending it in desirable ways.
Automated support at the MUA is not required (but is a desirable outcome).

a. Consent means that a proposal has been presented and accepted.
b. Initial email contact is not really known to be consented to, but
   recipients can help senders through their filters by supplying
   a proto-token as a free pass through incoming filters.
c. A consent token (representing a security association) should contain
   opaque data from both proposed sender and accepting recipient.
   Both ends have the opportunity to encode information for future reference.
d. The handshake between sender and receiver also offers the opportunity
   to generate a shared secret (e.g. via Diffie-Hellman protocol), which
   may be useful for HMAC or other purposes.
e. Every message should provide the consent token, AND annotate it with
   URIs (at least mailto, optionally other methods) for (i) unequivocally
   revoking consent [no dialogs, are-you-sures, checkboxes, etc] and
   (ii) examining the sender's current understanding of what is consented
   to.
f. A DSN-like structured representation of proposal text may be a good idea.
g. Potentially automated management of all those emailed passwords
   (initial password and output of "forgot-your-password?" resets) should
   probably be included, as it is a common feature of email-based authentication.

This would be attractive to legitimate list owners, as a (standardized
non-proprietary) legitimizing technology to avoid overzealous filters.
It is not hard to implement, is not different in principal from the numerous
implementations already in place, and confirmed opt-in sofwtare could adopt
as a "small matter of programming".

This is an end-to-end idea (tokens contain opaque data), but there are
opportunities for delegating processing, by sharing some information with
MSAs/MTAs.  (E.g. recipients share information with MTAs too, and embed
MTA-useful information in what the sender thinks is opaque data).  That's
similar to the HMAC Message-ID ideas already succinctly summarized by Phillip
Hallam-Baker and others.

It does not require any third-parties, trusted or otherwise.

I have much more specific ideas, and after hearing some feedback will decide
whether to write this up more formally myself or in a small offline group.

Of course, if someone says it's not worthwhile, I guess that'll be it ;-}.
Keep those cards and letters coming.

Liudvikas Bukys
[email-masked]

---

From: [email-masked]
Date: Thu, 10 Apr 2003 22:43:23 -0400

On Thu, Apr 10, 2003 at 11:38:30AM -0400, Liudvikas Bukys wrote

>    a proto-token as a free pass through incoming filters.

  Can't the mailing list mention on its website what (sub)domain or
machine their mail is coming from ?  rDNS can be forged, as can
envelope-sender.  However, if you say that email will be coming from
machine bad.example.com, then it's a simple matter of comparing output
from a domain lookup of bad.example.com against the IP address of the
MTA sending you the email.  Note the following...

[m1800//home/waltdnes]host cnn.com
cnn.com has address 64.236.16.84
cnn.com has address 64.236.16.116
cnn.com has address 64.236.24.4
cnn.com has address 64.236.24.12
cnn.com has address 64.236.24.20
cnn.com has address 64.236.24.28
cnn.com has address 64.236.16.20
cnn.com has address 64.236.16.52

..yes, one name can return multiple addresses.  This allows backup MTAs
and load-balancing.  Going via DNS also means that...

  1) You can change IP addresses, and DNS will still get you there.

  2) During a switchover, you can list both old and new addresses.

-- 
Walter Dnes <[email-masked]>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg