Subject: [Asrg] What would consent look like?

From: "Jon Kyme" <[email-masked]>
Date: Mon, 10 Mar 2003 10:45:34 +0000

I'd be interested to know if anyone thinks this is a stoopid idea 
- so I don't waste any effort on it.  Be warned, there's a fair
amount of hand-waving below.
 
Consent might look something like this:

applies-to:  [email-masked]
classes:     set of message classifications
access:      allow | deny 
scope:       local | organisational | global

I (or my MUA) compose such a token and the infrastructure
propagates it subject to the scope field.

i.e. if scope is "local" it probably doesn't propagate beyond 
my MUA and this is equivalent to setting user preferences for 
the application.

If scope is "organisational" then this consent is propagated 
only to (or made available to) my organisations mail infrastructure.

"global" ... you get the picture

I can generate many (or none) such tokens.
They can be "folded together" in some way.
The applies-to field could be wild-carded ([email-masked])

The token is authenticated by some method. 
  Perhaps by mail-back to (and reply from)
  the address it applies to. This would only happen once
  for each token.
  Or perhaps it's signed.
  Or perhaps it's authenticated by some local or organisational
   "special knowledge".

Propagation is secure.
    This would require signing I guess, but would only need to be 
    signed per domain (per organisation?).  
    We don't *need* a key per recipient addresses.

The sender need not (if malevolent - won't) consult the consent
infrastructure.

Intermediate systems (relays) should consult but wouldn't be
required to.

My organisational mail systems will probably (but can't be 
required to) consult.

My MUA will always consult. Or I get one that does.

Any agent that consults must be able to make a classification of 
the message (or be able to access an acceptable, verified 
classification). Perhaps a (signed) classification set can be 
transported with the message?

I don't propose an implementation for the consent infrastructure.

I believe it's interesting because it doesn't 
require all the entities to be capable of signing stuff, seems 
capable of "covering" current systems and something along these
lines might be deployed incrementally.
"Filtering" on the basis of consent / classification will occur 
as near source as possible (as far away from me as I allow 
- via scope).

It does, of course, rely on an accepted system of message 
classification. In the absence of which it's useless. Oh well :-)

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2003 09:55:19 -0500

On Mon, 10 Mar 2003 10:45:34 +0000

> scope:       local | organisational | global

well, my initial reaction is that for 'applies-to' you need to be clear
about what this means.  is it:

a. the address that appears in the From field (regardless of who
   actually sent the message)
b. the address that appears in SMTP MAIL FROM / Return-Path
   (regardless of who actually sent the message)
c. the address that sent the message (assuming some way to
   identify/authenticate that party)
d. some other address
e. more than one of a-d

here's what I think consent looks like.  this would be placed on a
net-accessible server in some place where it could be found using
the address [email-masked] - probably you'd do a dns lookup
for {something}.cs.utk.edu and get the address of a server that
could answer queries of the form "give me the consent statement
for recipient [email-masked]".  which would return something
like the following (in a well-defined, machine-readable format)

--------------------------------------------------------------------------
recipient [email-masked] consents to having messages matching any
of the following criteria not delivered normally, with the following 
actions taken:

a) any message with more than 5 non-ASCII characters in the subject field
   (action=discard)
b) any message with a MAIL FROM address that is invalid (action=discard)
c) any message with a From header address that is invalid
   (illegal syntax, no such domain, or fails SMTP check)
   (action=bounce)
d) any message containing an attachment with a filename attribute ending
   in .com, .exe, .pif, or .bat
   (action=discard)
e) any message with a From header address or MAIL FROM address matching
   [email-masked] 
   (action=discard)
f) any message containing the regexp
   /See.http://cr\.yp\.to/docs/copies\.html\./
   (action=discard)
g) any message which is entirely in some other language besides English
   (action=bounce)
h) any message that SpamAssasin rates higher than 8 (action=bounce)
i) any message from a sender-id whose issuer is in my whitelist
   (action=deliver)
j) any message from a sender-id whose ISP has declared to be a spammer
   (action=bounce)
k) any message from a sender-id whose ISP says the sender is a new account
   (if (text-only and size < 2k) action=delay else action=bounce)
l) any message from a sender-id whose ISP hasn't agreed to implement an AUP
   prohibiting spam and to support the protocol reporting spammers
   (if (text-only and size < 2k) action=delay else action=bounce)
m) any message from a sender-id issued by ISP's A, B, or C
   (if (text-only and size < 2k) action=delay else action=bounce)
n) any message with a From address in my whitelist
   (action=deliver)
o) any message lacking a sender-id tag
   (if (text-only and size < 2k) action=delay else action=bounce)
p) any message which was sent to > 200 recipients and which is not
   sent from one of the mailing lists in my whitelist
   (action=bounce)
q) any message containing text/html that contains a script (action=bounce)
--------------------------------------------------------------------------

and the whole thing could be signed.  (granted, details of establishing
reasonable trust in the signature could be tricky)

this is a deliberately complex example, but I wanted to illustrate 
several things:

1. a variety of kinds of criteria, some based on content, some based
   on ability to identify the source, some based on trustworthiness
   of the source, some based on volume, some based on criteria specified
   elsewhere

2. a variety of actions: e.g. bounce, delay, discard, deliver,
   and/or limit the kinds of messages I will accept

3. filtering things that aren't of interest to me, whether or not they
   meet anyone else's criteria for "spam".  (like the annoying message 
   from djb insisting that everyone should adopt his method of composing 
   replies)

btw, the sender-id tag is a tag that would be supplied by the sender
ISP's MTA that would reliably associate the message with a particular
sender (as in, the name/address/billing info that the ISP knows).
it would not expose the sender's identity to recipients, but it would
allow recipients to make queries to the ISP about the sender.

again, this is a complex example.  I'd expect the casual user's criteria
to be much simpler, for instance:

--------------------------------------------------------------------------
a) whatever criteria SpamNukers, Inc. recommends
--------------------------------------------------------------------------

now, the purpose in supplying these criteria is to allow filtering
of the message *at any point upstream*.  essentially it's saying
"I'm going to discard these anyway, so there's no point in sending
them to me."  so one or more MTAs could query a recipient's filtering
criteria and then optionally apply whatever criteria they understood 
and wished to apply - thus saving them bandwidth, etc.

(it would be important to specify this carefully -in my example there
are criteria for delivery that are meant to pre-empt later criteria
for pessimal handling - e.g. if you're on my whitelist I want the message
delivered even if your ISP is untrustworthy.  it would not be good to
have some MTA ignore the whitelist and apply the later criteria.)

Keith

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 10 Mar 2003 15:34:21 +0000

>    identify/authenticate that party)

I meant the envelope recipient - the address in the RCTP TO

> the address [email-masked] - probably you'd do a dns lookup

I'm keeping away from any implementation details - it's way too 
early - I think. But yes, something like that, why not.

> -

These would come under the heading of message classifications.

> reasonable trust in the signature could be tricky)

I think it's possible to limit the signing requirement.
Organisations and local systems have more direct means of
authenticating the source of a consent (does it come from
one of our subnets, or something).

>    of the source, some based on volume, some based on criteria specified

all really part of some message classification component

>    and/or limit the kinds of messages I will accept

I only need to (accept | deny) really - the disposition of the 
offending message is an issue of configuring the consent seeking
entity - what it does when a "deny" is obtained 
- if this entity is my MUA that's covered separately.

If I need to control disposition, then I only ever issue consents
with local scope. Bingo.

>    from djb insisting that everyone should adopt his method of composing 

I can have my MUA (consulting a local consent) filter against local
classifications..  as well as more widely scoped ones.

> btw, the sender-id tag is a tag that would be supplied by the sender

I have problems with identifying senders (as do others 
- there's a lot on the list about this)
So I'm concentrating on the intended *recipient*

> and wished to apply - thus saving them bandwidth, etc.

Yes.

> have some MTA ignore the whitelist and apply the later criteria.)

This just needs "accept" to have higher priority than "deny" - I think?
I should have made that clear.  I skipped that - it's probably in the
"folding" mechanism... 

Thanks for your feedback.

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Mar 2003 10:45:14 -0500

> entity - what it does when a "deny" is obtained 

I think the middle ground (e.g. accept but only after a delay, 
accept with small probability, else tempfail, accept only short messages
and/or only with a limited set of contents) is very important  -
if nothing else, during a transition phase.  If we have a situation
where only X% of the ISPs support mechanisms to allow standardized
sender-identification and query of senders to see if they're spammers,
we need a way to handle mail that comes from the other 100-X% 
which isn't as drastic as bouncing/discarding but still penalizes them.

> >    meet anyone else's criteria for "spam".  (like the annoying
> >    message from djb insisting that everyone should adopt his method
> >    of composing replies)
> 

indeed.  what you advertise to the world that you're willing to have
filtered on your behalf and what you filter locally can be different.

> - there's a lot on the list about this)

which is why my sender-id doesn't actually identify senders.
(I suppose I need a better name - at one time I was using
originator-info, but that's kind of long.)

> So I'm concentrating on the intended *recipient*

well, of course the recipient specifies the filtering criteria.

> > -in my example
> > there are criteria for delivery that are meant to pre-empt later
> > criteria for pessimal handling - e.g. if you're on my whitelist I
> > want the message delivered even if your ISP is untrustworthy.  it
> > would not be good to have some MTA ignore the whitelist and apply
> > the later criteria.)
> >
> 

actually, no.  if an MTA doesn't understand how to implement the
accept criteria, it must also ignore any of the following deny
criteria.  either that or we need to specify the criteria in such
a way that they're independent of one another, with no ordering.

so instead of saying

if (x) accept
if (y) deny

say 

if (!x && y) deny
 
Keith
-- 
"Of course the people don't want war.  But ... it is always a simple 
matter to drag the people along.  All you have to do is tell them they
are being attacked, and denounce the pacifists for lack of patriotism
and exposing the country to danger... It works the same way in any
country."

- Hermann Goering, 1947.