Subject: Re: [Asrg] Consent Systems and permission list

From: [email-masked]
Date: Fri, 04 Jul 2003 23:31:05 -0500

>>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 [email-masked] 
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 [email-masked], 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 
[email-masked] 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:

   [email-masked]

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 [email-masked]
	from [email-masked]
		allow HTML safe
	from [email-masked]
		allow HTML 
		allow attachments 

Alternatively, there's no a priori reason why one couldn't implement an 
extension like:

to [email-masked]
	from [email-masked]
		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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg