Subject: [Asrg] Consent Systems and permission list

From: [email-masked]
Date: Fri, 04 Jul 2003 14:16:38 -0500

> Sleeping on this I came up with some more issues (okay, I didn't 
sleep very well).

> 1. Like many systems, this ties in tightly with identity.  If I move 
to a new ISP (or Comcast gets sold *again*) my email address changes. 
How do I manage notifying all of my contacts.  

This is a familiar problem but completely only peripherally related to the issue 
of spam and permissions lists.

What *most* of us do (sooner or later) is to simply buy a domain name which is 
PERMANENTLY yours (well, as long as you pay the renewal fees...) and eliminates 
your need 'forever' to send out change-of-address notices.  I've changed my ISP 
(actually, *they* have generally been the one who sold out and sold their 
customer base to the new buyer ISP) at least five times since moving back to the 
United States almost ten years ago.  Having my own domain name has insulated 
totally my correspondents (including mailing list subscriptions, etc) from four 
of those five changes.

CLEARLY one doesn't want to use your employer's domain, and I think it's just 
about as clear that you don't really want to commit to maintaining forever the 
same ISP either.

For those people who aren't clever enough to have their own permanent domain 
name, then they have to notify their correspondents.  But that's no different 
for the sender than if they DIDN'T have a permissions list or other anti-spam 
technology in place.

The only difference is that that the recipient needs to have some reasonably 
efficient way to update the sender's address in the permission list.... but 
that's a fairly straightforward thing to do, regardless.

> Some people seem to 
think the address book model works, but I correspond with several 
orders of magnitude more people than are in my address book, and some 
of them I only send mail to every few years--

Sure... and how about that acquaintence you gave a business card to on that 
cruise ship or European holiday several years ago, urging them to get in touch 
if they ever made it to Dallas (or whatever)?  Obviously it's not only 
impractical, it's basically IMPOSSIBLE to update everyone on the E-mail address 
change.

But hey, if you got caught up in the attbi.com to comcast.net change, you 
probably also had been hit when it changed from home.com to attbi.com too, so 
you ought to know ther routine by now.

> I don't want to have to 
notify them all of a change, nor is it clear to me *how* I would 
notify them of a change without hitting the consent system again. 

Clearly you need your own domain name.  Just as I own terabites.com, gep2.com, 
and defend-democracy.org (in addition to several other domains which I own on 
behalf of various of my consulting clients).

> It's probably technically feasible, albeit difficult, to do so if I 
know in advance of the change--but that doesn't always happen.  Right 
now people struggle with simple things like transferring their 
address book, never mind transferring consent.  

Obviously the SENDER cannot transfer consent.  That can ONLY (meaningfully!) be 
done by the RECIPIENT, who controls absolutely who they do and do not approve.

> A regular occurrence 
on wormalert is mail from someone to all of their contents with a 
brief comment like "sorry, just mailing myself a copy of my address 
book".  That's how they do it--they put everyone in the to, including 
their new address.  

Yeah, I just got an E-mail earlier today from one of my neighbors with his 
E-mail address change (also from attbi.com to comcast.net) with no less than 
almost 17k of To: addresses...!  (Nothing too embarassing to him though, I 
looked...!  ;-) )  Some people really are clueless.

> So.  Without a persistent concept of identity, 
consent is rather transient to the recipient, never mind the sender.

> 2. If a consent token does degenerate to a password, then two 
problems occur.  One, it can be sold along with your email address, 
just as email addresses are sold now.  

That would only be true if the token were not specific to a given sender.

> You've basically made it 
simple for someone to transfer your consent.  the only way around 
that is to tie a consent token to the sender, which means complicated 
software, 

Oh, give me a break... it could be as simple as some kind of a hash function or 
checksum or something.  Compared to many of the other things we discuss here 
routinely, that's child's play.

But I still think that the sender's E-mail address is just fine as a token all 
by itself.

> ....and a knowledge of what addresses will be used to contact 
you.  (Again, I think people working on this should focus first on a 
URL scheme for whitelisting.  E.g. 
whitelist:some-piece-of-information-identifying-senders.)  

Why are some people SO determined to make this Web-based?  While that is a fine 
*option*, things related to E-mail (IMHO) ought to be manageable with something 
no more complicated than an E-mail client.  I don't want to be FORCED to use 
HTML to manage ANYTHING related to E-mail.

> Secondly, 
a single password doesn't contain information about what you've 
consented to.  Did I tell them I want a receipt for my order, or that 
I want a daily advertisement?

And you need to be able to change that permission set, for ANY specific sender, 
at ANY time.  To me, that sounds like their E-mail address IS their token, and 
the MUA/MTA at your client end/ISP/destination domain simply looks up the 
current permissions associated with THAT sender.  Simple, direct, efficient.

> Note that the latter problem is what I see as a major failing of 
do-not-spam-me lists.  How does a vendor know whether the presence of 
an address on that list applies to what aspect of an existing 
business relationship?  

Clearly that's up for negotiation between them and their customer.  But just 
because I've allowed Sears to send me my Sears credit card statements online 
does NOT automatically give them permission to spam me unceasingly about 
Allstate insurance, or a daily "on sale" flyer, or other financial services spam 
or whatever.  And if they abuse that permission, then I clearly need to be able 
to T-can *everything* they send me in the future (as I already do for several 
companies I once gave permission to mail me, and then they made nuisances of 
themselves.  One of them puts header garbage in insisting about how they have an 
absolute right to E-mail me, and that it's not spam.  But it just sits and spins 
on one of my hard drives in the "spam" folder, which basically is a 
dead-letter-box.  Yawn.).

> And if it doesn't, then what's the point? 
They shouldn't be sending you email anyway.  

Fair enough.  And a good content filter, perhaps, could differentiate between 
the type of stuff you're willing to accept from them versus the stuff you're 
not.

I really think that content filters, coupled with HTML-based or attachment-based 
permissions/restrictions, give us most of the tools that we need to distinguish 
between the stuff we might be interested in, versus the stuff we're not.

And with a periodic summary E-mail of "suspicious mail being held pending 
decision" that allows us to conduct quick triage and decide how to handle each 
of those... t-canning, accepting (once), updating permissions list to allow, 
bouncing, or whatever.

No matter how complicated these other technology-based solutions become, I don't 
see them as ultimately being very much more satisfactory, nor very much better 
at actually blocking the stuff that I don't want to see.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 4 Jul 2003 16:51:00 -0400

At 2:16 PM -0500 7/4/03, [email-masked] wrote:
>PERMANENTLY yours (well, as long as you pay the renewal fees...) and

That is definitely not what "most" internet users do.  And we are 
trying to define a system for internet users, not "us".

>for the sender than if they DIDN'T have a permissions list or other anti-spam

It is different in the context we were discussing.  What we were 
discussing was how to notify clients when it was necessary to 
reestablish consent to communicate.  I understand that this doesn't 
apply to the system you proposed, since it assumes that consent is 
limited to html vs. non-html.  However it does apply to the other 
consent systems that we were discussing.

>looked...!  ;-) )  Some people really are clueless.

Actually in those cases I think you need to look to the software 
vendor.  As far as I've been told, there is no way to export and then 
import an address book reliably from some major email packages.  So 
those people who've figured out that they can do it by mailing to 
everyone are actually being rather clever.

>That would only be true if the token were not specific to a given sender.

Which is precisely what I said.  Tracing my conversation back you'll 
see that I came to the conclusion that it would because there needs 
to be a way to give consent over the phone and to web sites.  Since 
web sites and web-related databases aren't going to suddenly sprout a 
consent key, there needs to be a way to embed one in the email 
address.  Managing a system like that manually is not feasible.  (I 
have enough trouble managing my [email-masked] 
system, given company name changes and problems with sites that don't 
like + in an email address.)  Therefore I concluded that a consent 
token would degenerate to a password.  I'd be very happy if someone 
could show me a reasonable way whereby that wouldn't be the case.

>routinely, that's child's play.

Not on a business card, over the phone or without a piece of software 
that will generate it for you and notify both the web browser and the 
email software.  (Okay, I'll grant you cut and paste in the last case 
:-).

>Why are some people SO determined to make this Web-based?  While that is a

I have no interest in making it web based.  I want to solve a very 
real problem.  I assert that the majority of mailing lists people 
sign up for are signed up for by entering their email address on a 
web page.  Therefore a consent system needs to take that into 
account.  That's all.  The system itself should *not* be web based.

>current permissions associated with THAT sender.  Simple, direct, efficient.

Except that the same vendor may use multiple different email 
addresses. In fact more and more of the vendor email I see not only 
is using per-recipient from addresses, they are changing every single 
time they send a message.  (They appear to be encoding not only the 
recipient (for bounce removal) but also the id of the message they 
sent.)

Obviously we could require that those systems change.  But it's yet 
another complication to consider.

>between the stuff we might be interested in, versus the stuff we're not.

I'm actually tending in that direction myself (although I think the 
HTML side of things is a red-herring, but we'll agree to disagree 
there).  I also don't find that "content" filtering is that 
necessary, but certainly filtering of one sort or another can be very 
effective for an end user.  I look at the C/R systems primarily as a 
way of dealing with gray lists, and the consent systems as ways to 
deal with subscriptions.  Otherwise I don't feel that a great deal of 
change is required to fix the system.  Assuming that we can protect 
enough user's mailboxes, I hope (although I could be wrong) that 
we'll cut off enough of the financial incentive such that the volume 
problems will drop for ISPs.  (I've got a lot riding on that bet, 
because somewhere.com is riding just behind striker on the volume 
curve).

-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.