ietf-asrg
[Top] [All Lists]

RE: consent expression (was RE: [Asrg] ASRG next steps)

2003-03-05 11:11:57
Sorry if all of this has already been covered. I am just beginning to go
through the archives of these discussions to gte up to speed. It is kind of
ironic how much email can be generated by a discussion ABOUT spam. 
In an attempt to step back from specific implementation proposals for a
minute and here is an attempt to describe what a solution might include
based on the charter of this specific group.
1) Authentication/non-repudiation of the sender of an email. For individuals
or very low volume email it might be enough for the ISP to verify that the
sender listed in the envelope really is who they say they are (which implies
that open relays become basically impossible to manage). For larger volumes
of email from a specific envelope sender such as mailing lists, purchase
confirmations, etc.. this may mean involvement and verification against some
trusted certification authority(ies).
Anonymous email would still be possible, but individual senders would get to
decide whether or not to accept unverifiable senders.
2) Some expression of "mailing type" from the sender. Part of validating
that a sender is who they say they are would also be validating that they
don't lie about what kind of email they send. On the recipient level you
could decide not only whether you want to accept a given mailing type, but
whether you trust the certifying authority to actually certify a specific
sender.
3) The system itself should be non-judgemental. Basically whatever is put in
place should not be making decisiosn for me about whether a piece of mail is
good or bad. That should be left either to the ISP and ultimately to the
individual email recipient to decide what types of email they want to
accept. To meet this goal the system should be a means to convey the
information necessary for those groups to make meaningful decisions
4) The ability on the receiving side to "express consent" in a way that
validates against the information in #2.


In this world basically the flow of a piece of email would be:
I am a sender. I send a piece of email and in some way communicate what it
is I am sending.
If I doing the actual sending myself (so I am someone running my own
mailserver) I connect to destination mail transfer agent.
I announce who I am along with some means to verify that information (either
in the helo or the envelope)
I announce what I am sending and to whom.
Recipient mail transfer agent optionally validates my identity and
determines whether they trust me to honestly describe what mailing type I am
sending.
Recipient mail transfer agent optionally decides whether the mailing type is
one that they will accept.
If the mail is accepted, this same information is passed along to
destination user so that if the end user has their own rules their mail user
agent can apply them.

This flow is basically based on one evening of throwing away everything I
know about spam filters and trying to create a data flow consistent with
this groups charter. It is admittedly shallow on details and is only
intended as a talking point for a more general discussion of what goals a
solution should meet to be considered.

Regards,
Robert


-----Original Message-----
From: Paul Judge [mailto:paul(_dot_)judge(_at_)ciphertrust(_dot_)com]
Sent: Tuesday, March 04, 2003 4:52 PM
To: 'Vernon Schryver'; asrg(_at_)ietf(_dot_)org
Subject: consent expression (was RE: [Asrg] ASRG next steps)




What is "consent expression"?  

Consent expression means that someone can state which communication they
wish to receive or not to receive. This allows a very granular definition by
each user(individual or organization).


If it is not a trivial boolean like 
"I do [not] like spam," how can it not be a magnet for abuse ranging
from minor privacy violations to more spam to literal visits from
death squads reducing their political enemies?

trivial boolean? spam can not be expressed as a boolean. We realized that
the definition is inconsistent and people in this community have spent many
years debating "unsolicited bulk" versus "unsolicited commercial bulk"
versus a host of other definitions seeking some form of optimal cover set of
everyone's personal definition. The problem is that while these broad
definitions are good, they are not perfect. There are many messages that
people consider spam that do not fit these definitions (this leads to false
negatives). Likewise there are messages that fall within these definitions
that are not considered spam (this leads to false positives). Spam is in
many cases an individual preference. It is a subjective opinion of unwanted
messages. One approach is to continue to try to confine the definition to
one that covers only the subset of what everyone considers spam without
including anyone's wanted messages. A different approach is to step away
from the binary decision of spam and non-spam and realize that communication
can be more granularly defined. For example, "product offers", "chain
letters", "mailing lists", "newsletters", "greeting cards", "fradulent
offers", "unauthenticated messages", "unverifiable messages", etc. By
developing a robust categorization of messages, we can allow users to
express consent for certain types of communication. This allows the common
lack-of-consent policies to be implemented as close to the source as
possible. From there, we require an architecture that can support these
policies. This architecture may very well be a combination of current and
new approaches.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg