RE: RE: [Asrg] 2. Problem Characterization - Defining spam within consent paradigm

["Tom Thomson" <[e-mail]>]

> > > the bottom line is that any message that a human
> > > receiver does not want - does not consent to, is
> > > considering spam according to that person.
> > 	I don't buy it. Such a definition erases the distinctions
> > between different kinds of unwanted messages and in so doing removes
> > from discussion what may be useful information.
> >  	It may be "politically correct" to say that all unwanted mail is
> > spam, however, I strongly believe that taking such a fundamentalist
> > position is not conducive to the normally objective process of design.
> > 	If you force all "unwanted messages" into the single category of
> > "spam" then you have either ignored existing distinctions or you have
> > just declared "spam" to be synonymous with "unwanted message". Thus,
> > your definition: "spam is any unwanted message" is simply a tautology.
> > i.e. "Spam is Spam".
>
> No, this is no more of a tautology than to say "Fish are aquatic creatures
> with fins". You may say that "Fish are scaly creatures with swim-bladders
> and spots", in which case we have somewhat different definitions (one a
> subset of the other). That's all.
>
> The purpose of the group is to discuss the problem of "consent-based
> communication". For these purposes people often use "spam" as a convenient
> sorthand for "communication without consent". If you get rid of this
"spam"
> then your kind of spam will cease to be a problem.

One trouble here is that one moment you write "does not want" and at another
you write "does not consent to" just as if they meant the same thing.  They
do not mean the same thing.

I consent to receiving bills from the people who supply my electricty, but I
don't want to receive those bills - I'd much rather have the electricity
free.  I don't think those bills are spam - in fact I believe that any
definition of spam that includes those bills is just plain wrong.  So spam
is NOT "email the recipient does not want".

Stick to conent, not desire.  A definition like "Spam is email the recipient
has not consented to" doesn't fall into that trap.

Of course there are issues about how consent is expressed, how we can say
that a user has consented to receive one email from one source he has never
heard of but hasn't consented to receive another email from another source
he has never heard of, and that probably brings us into the realms of AI,
probably requiring a level of sophistication in AI that hasn't been achieved
yet, but if we are lucky we may find that a good enough approximation will
be acceptable.

Then we will need some measure of goodness for approximations, which may
involve looking at how often the consent expression is misinterpreted (ie
our software "thinks" consent has been given when it hasn't, or "thinks" it
hasn't when it has).  We will find that what is good enough for some
purposes or some users is not good enough for other purposes or other users.
That leaves us right back with the same fundamental engineering issues we
have with content filters!

Of course some aspects of consent can be expressed cleanly:  "I do not
consent to receive mail which passed through a server which was, last time
MAPS checked it, an open relay" doesn't need sophisticated encoding to
represent it or clever AI to interpret it (although it does need more real
intelligence than exhibited by many sysadmins, as demonstrated by the large
number of corporate mail receivers that are using copies of the MAPS RSS
list that are over a year out of date - I imagine this pisses the people who
maintain MAPS RSS off as much as it pisses off the people who get messed up
by it).  Nor does "I do not consent to receive email from a server whose ip
address has no rDNS".  The trouble with these notions though is that the
average email recipient doesn't know what they mean, so he's not going to
express any part of his consent / non-consent (or his "consent policy" is
that's what we try to represent) in those terms.

Tom


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