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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg