Subject: RE: [Asrg] 4. Consent Framework - General

From: [email-masked]
Date: Mon, 25 Aug 2003 23:09:44 -0500

> As part of the work on consent frameworks, is there a proposal somewhere
to allow a user or delegated administrator) to see the consents that
s/he has in place? 

The process I proposed involves a normal flat file file, editable locally by the 
recipient, that allows them to have a complete local copy showing all their 
granted permissions and (likewise) restrictions.  That could be simply uploaded 
to the ISP or domain provider, should the filtering be done there rather than by 
a local application running at the user's own site.

The file could be manipulated with a simple ASCII editor, or I suppose someone 
could write a VB app or something to update it with a GUI or something.

In any case, the idea would be that the user would have all their permissions, 
locally and in one place, both as a backup in case of problems and also should 
they ever wish to change to another ISP perhaps.

Normally, they could simply upload the complete file to their ISP, whether by 
FTP or via an E-mail attachment or even perhaps through a Web site upload link 
or something.  Obviously, if they are running the filter as a local app they 
would use the file locally.

And if the filtering is done by their ISP or domain provider, they should offer 
some way for the user to export it also, again whether by Web page link, or by 
E-mail autoresponder, or by FTP.

> Rather like Credit reporting. I periodically receive
my credit report and check it out to see if there is anything weird on
it. I would also like, periodically, to see the consents that I have in
place and to be able to tweak them (or revoke them).

> Scenario:

> I have just bought a business and the previous owner has "consented" to
receive some email that I really don't want. He is on every one of the
dating services, and several pornographic sites too. They regularly send
him mail. Trouble is that he used a "functional mailbox"
([email-masked]) to sign up for these things. Even with a nice
consent framework, he can have consented to all of this stuff. Now as
the business owner, I suddenly find that my [email-masked] mailbox
has been inundated with mail that has been legitimately consented to,
but I don't want. I actually have no idea what consents that mailbox
has. I just know that I would really like not to have them extant any
more.

Central to understanding the consent/permissions system as I've proposed it is 
the distinction between the "permission" that you (or your predecessor) 
"supposedly" gave to the sender, versus the ACTUAL and DEFINITIVE permissions 
that apply to your Inbox (and about which the sender has *no* authority or 
override capability whatsoever).  You can certainly try to get these senders to 
stop sending this garbage to you (good luck!) but it might just be easier to set 
your own Inbox permissions so that anything they send you goes straight into the 
bit bucket.  (I've had to do that with several particularly pernicious E-mail 
abusers who continue to insist that they have the right to send to me... 
regardless, I have the absolute and OVERRIDING right to never have to actually 
see their crap!)  Now it IS true that they're still wasting your bandwidth, and 
it would be nice to get them to leave you alone, but at least you still can make 
yourself totally otherwise unaware of their B.S.!

> Of course, it is quite possible that the previous owner did this on
purpose, because he was forced to sell the company - it wasn't a going
concern and the other investors wanted their money out.

It's conceivable, although it's more likely that he was already being victimized 
by these abusers.

> Every one of the current customers knows that [email-masked] is
the way to get in touch when they want to buy things from us, so the
email address is itself, a thing of value and an asset that was valued
in the asset purchase agreement.

Sure, and there's no particular reason to have to abandon it.  Again, I'd simply 
set that incoming E-mail address to strip HTML-alternative attachments (indeed, 
probably attachments of ALL kinds).  If there is (for whatever bizarre reason) 
someone you want or need to get attachments or HTML from to that address, you 
can list those approved senders with those specific appropriate permissions.

> End of scenario

> There are plenty of scenarios like this, so I think the ability to find
out the "consents" (even for a fee, like the credit reports) could be
quite valuable. I really don't want to see a "yes you did, no I didn't"
kind of war breaking out between email address holders and marketers if
at all possible.

Again, once you understand that WHATEVER the sender claims you consented to, you 
STILL have the right to bar the door to YOUR Inbox, for ANY reason that you 
choose.

> At least a reasonable consent framework might prevent me from getting
the interminable emails from companies that I have never done business
with, but who have my email address because they were harvested by klez
or one of the other viruses from the mail box of a colleague.

Yup, for example.  And even if they DO come across your wire, you ought to be 
able to still trash them immediately under the specifications of your 
permissions list, without ever seeing them.

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: "Tom Thomson" <[email-masked]>
Date: Mon, 1 Sep 2003 21:05:20 +0100

>  3) the DATA: stage provides the body *AND THE HEADERS*, at which point
>     we can apply header and body filters.  A common misconception I've
>     seen is that "Received:", "Subject:", "From:", "To:", and all the
>     "X-" headers are somehow separate from the body of the message.
>     MUAs display them that way, but in reality, they are sent in the
>     DATA section along with "the message body".

A Common misconception?  Certainly not!  The standard frormat for internet
messages is quite clear - a message consists of some header lines
(possibly folded) followed by a null line followed by a message body.

The fact that the headers, the separator, and the message body are all part
of the data phase of the SMTP protocol is neither her nor there.  Once you
look at the content of the data phase, you are looking at something which
is structured by RFC2822, not by RFC2821, and RFC2821 has nothing to say
about that structure.

Confusing the levels in a protocl stack is a sure recipe for a spaghetti
implementation resulting in a bug-ridden disaster. Claiming that the
recognition of this very clear separation of levels is "a common
misconception" is nothing but arrant nonsense.

Tom Thomson