ietf-asrg
[Top] [All Lists]

Re: [Asrg] What would consent look like?

2003-03-10 08:03:30
On Mon, 10 Mar 2003 10:45:34 +0000
"Jon Kyme" <jrk(_at_)merseymail(_dot_)com> wrote:

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:  user(_at_)domain(_dot_)example
classes:     set of message classifications
access:      allow | deny 
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 moore(_at_)cs(_dot_)utk(_dot_)edu - 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 moore(_at_)cs(_dot_)utk(_dot_)edu".  which would return something
like the following (in a well-defined, machine-readable format)

--------------------------------------------------------------------------
recipient moore(_at_)cs(_dot_)utk(_dot_)edu 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
   JimFleming(_at_)ameritech(_dot_)net 
   (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

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>