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.
I think that's what a large number of them will do eventually. Many of those
of
us which have been around long enough to experience the problem (maybe several
times) have already done so. A lot of them are (relative) newbies... compared
to us here at least... and have yet to discover the hassles of changing their
E-mail address. (I used to think it only was a penalty for US changing our
ISP,
but the majority of my changes have been ISP acquisitions, which obviously I
had
little or no control over).
And we are trying to define a system for internet users, not "us".
In any case, the change-of-address problem happens whether we have anti-spam
systems or not.
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.
In my system, one doesn't NEED to notify senders (other than to get them to
change the E-mail address they send to, I suppose).
I understand that this doesn't apply to the system you proposed,
Right. One of the advantages of my system... it's pretty much one-ended, and
(especially useful for big mailing lists etc) the senders don't have to do
*anything* different than they otherwise would.
...since it assumes that consent is limited to html vs. non-html.
No, it could be MUCH finer-grained than that, if desired. (basic HTML but no
scripting, no tables, no frames, no images, no ActiveX, etc etc.) I also
proposed that (specifically) attachments (executable vs 'safe' etc) and base64
encoding also be "special" privileges available only to trusted senders.
However it does apply to the other consent systems that we were discussing.
Well, some of them maybe.
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.
If they could put it in the To: field, they ought to be able to equally well
put
it into the Bcc: field.
So those people who've figured out that they can do it by mailing to
everyone are actually being rather clever.
Except that everyone they write to gets a complete copy of the sender's full
address book....!!
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.
Then that's a good reason to NOT give them a consent token at all. (Another is
the need to someday maybe revoke or modify consent...)
If you need to change the consent, you obviously need to do that on a
per-sender
basis, which means you have to look up their sender address anyhow (or else
have
each sender have a unique token... same difference!) so if you've got to look
up
the e-mail address anyhow... to ensure that the token hasn't been revoked...
the
token itself is TOTALLY redundant!
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.
Or, more typically, to allow them to send you a 'basic form' E-mail which is
non-bulky, hard-to-cloak, and universal. That means plain ASCII, no HTML, no
attachments, no encoding.
Managing a system like that manually is not feasible.
It is *100%* feasible if the sender E-mail address (perhaps combined with the
recipient address) *is* the consent key.
It's even moreso when the recipient has their own domain with a "catch-all"
account where "any" E-mail address within their personal domain will come to
them. That allows them to get "all" the E-mails, and use the complete E-mail
address (which can be given uniquely to each sender) as the consent key.
(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.)
So who needs a "+"? Use a dash, or an underscore, or most anything for that
matter. For example, I could give someone gep2-ebay(_at_)terabites(_dot_)com,
and all that
E-mail will come in clearly marked with the indication of who I originally gave
that E-mail address to. For that matter, I could give them
gep2ebay(_at_)terabites(_dot_)com and it would be every bit as good. If you
wanted to make
it less obvious it could be gep21750 or something where the appended 4-digit
number had a checksum or something embedded in it, and where the number's
assignment wouldn't be so obvious.
Therefore I concluded that a consent token would degenerate to a password.
I don't think that solves the problem.
I'd be very happy if someone could show me a reasonable way whereby that
wouldn't be the case.
Sure. Just have catch-all accounts and private domains. It's just NOT that
hard, and there's really no reason why (with domains costing as little as about
$7 a year, I think that's maybe the lowest I've heard so far at least) why they
can't be nearly universal.
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
:-).
On a business card is an interesting case, although when you post to a mailing
list (like this one) is a similar one... where you want to have a generic
address that (by design) multiple "untrusted" senders may reach you. But
that's
not a big problem, you just post your "for general contacts" address and then
update your address (or your permissions table) when you have an established
relationship.
But still, it simply makes more sense to do it the way I proposed... to have
your E-mail address, and establish the permissions list associated based on the
SENDER (since that's what matters, anyhow) rather than trying to key it off
some
kind of token or special addressee E-mail or something (again, having a special
set of permissions associated with (only!) a given destination addressee still
creates problems when you wish to CHANGE or revoke entirely the permissions you
grant to a single sender... and you might not want to make them aware of that,
as you might by telling them to suddenly start sending to a different E-mail
address.
....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.
So what's the point of making it a URL?
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.
I *strongly* disagree. For example, most Yahoogroups mailing lists (and they
are surely the largest single operator of mailing lists) are subscribed by
E-mailing to:
groupname-subscribe(_at_)yahoogroups(_dot_)com
Even in the Unix world, most majordomo mailing lists take the majority of their
commands by E-mail rather than a Web-based interface.
Therefore a consent system needs to take that into account. That's all. The
system itself should *not* be web based.
OK, on that part we agree. A Web *option* is fine, but it shouldn't REQUIRE a
Web interface.
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 which case, you might want to grant different permissions to different
people
within the company. For example,
to me(_at_)mydomain(_dot_)com
from sales(_at_)company(_dot_)com
allow HTML safe
from softwaredevelopment(_at_)company(_dot_)com
allow HTML
allow attachments
Alternatively, there's no a priori reason why one couldn't implement an
extension like:
to me(_at_)mydomain(_dot_)com
from *(_at_)company(_dot_)com
allow HTML
allow attachments
In *general*, I don't much like regular expressions (which I consider a *truly*
braindead form of pattern matching) although in a specialized case like this,
the frustrations of regex might not be too annoying, and it might not be too
difficult to deal with from a programming standpoint.
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.
First, I doubt they change *very much*.
Second, nothing PREVENTS you from opening your permissions window wide (and
being consequently widely vulnerable). The best policy, though, is to keep
your
windows of vulnerability as narrow as you possibly can.
Third, if what you say is true, then it is because they haven't seen a
disadvantage to doing it that way. The widespread adoption of a permissions
scheme based on sender address might be an enticement to put their unique stuff
WHERE IT BELONGS... in the subject, or perhaps in some other header line or
something, depending on their requirements.
(They appear to be encoding not only the recipient (for bounce removal) but
also the id of the message they sent.)
They could do that equally well (better, actually) in the subject of the
message.
Obviously we could require that those systems change. But it's yet
another complication to consider.
Sure. (Actually, even THOSE kinds of things wouldn't need to change, under my
plan, if they were willing to send their stuff in responsible, efficient,
universal and compact plain ASCII text. They'd only need to change if they
wanted to send stuff in a format that REQUIRED special permission on the part
of
the receiver to get it into the recipient's Inbox).
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
I believe that the more thought you give it, the more you'll finally end up
agreeing that it is probably the idea that gives us the most, for the least
cost, and with the greatest ability to actually get busy and implement it
without requiring a nearly unachievable worldwide consensus. What's more, it
has the antivirus/antiworm/antitrojan advantages, AND it's easy enough to
explain to a user that even fairly clueless types should rapidly develop an
intuitive kind of feel for how to use it.
(although I think the HTML side of things is a red-herring, but we'll agree
to
disagree there).
One could offer it in an advanced, finer-grained form, as we've discussed...
where one could have "classes" of HTML tags based on increasing levels of
annoyance/cloaking/risk. Clearly things like Javascript, ActiveX and the like
are among the more dangerous stuff. Things like embedded images or links to
images at URLs (often used for text-as-image to confound content scanners) are
another thing that ought to be viewed with some suspicion. One could probably
define a subset of HTML (the kind of stuff that typical AOL users or Hotmail
users are most likely to have used, probably without their real awareness)
which
might be allowed in a relatively "HTML but vanilla stuff" category. But it IS
important that scripting or the types of HTML tags which spammers use (invalid
tags, lots of comments embedded within words, hex or decimal character
specifiers, links with other forms of obscured URLs, etc) be sufficiently
elevated in terms of permission requirement that they still be usable as a
clear
indicator of "spam!" Any of the numerous familiar tricks that spammers use to
cloak or obscure their message (and these are things that are virtually never
found in legitimate HTML-burdened E-mails) are pretty clear indicators that a
message is from spammer scum.
And I *do* think that as a matter of policy, anything we can do BY DESIGN to
discourage the GRATUITOUS use of HTML-burdened E-mail and MIME alternative
attachments (at a consequent about quadrupling of the size of typical E-mail
messages) is a good way to cut E-mail costs overall.
I also don't find that "content" filtering is that
necessary,
I think it is a good final "polishing" filter to remove a great percentage of
the spam E-mails that would otherwise slide through. Especially once the HTML
cloaking/obscuring tricks are denied to the spammers, I think that the content
filters will help to reliably t-can a *large* percentage of what's left.
but certainly filtering of one sort or another can be very
effective for an end user.
Absolutely, especially once they figure out good strategies for dealing with
the
spam based on the content filtering program they choose to use.
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.
I don't think it will work to have much of anything required on the part of the
sender (some of which will be "free" Yahoogroups-type community mailing lists
which simply won't screw with it). I think it makes more sense to hold the
questionable stuff and then send a periodic list of "pending decision" stuff to
the recipient, to allow and help them to fine-tune their permissions list.
Otherwise I don't feel that a great deal of
change is required to fix the system.
I *certainly* don't like the idea of having "separate but equal" E-mail systems
for "business" vs "personal" use, etc etc. I think one of the MOST IMPORTANT
aspects of the Internet is precisely that it gives comparable capabilities to
individuals, small non-profit groups, community activists and tiny companies
that the biggest corporations enjoy... I don't want to see that lost and have
the Internet be a game where only the "big guys" can play.
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).
I think that we can make a BIG dent in spam profitability (and volume) with a
relatively simple strategy (my permissions list) and I think that moreover we
can do that fairly quickly.
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