At 2:16 PM -0500 7/4/03, gep2(_at_)terabites(_dot_)com wrote:
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
That is definitely not what "most" internet users do. And we are
trying to define a system for internet users, not "us".
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.
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.
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.
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.
> 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.
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 address+theirdomain(_at_)somewhere(_dot_)com
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.
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.
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
:-).
> ....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
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.
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.
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.
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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg