Subject: [Asrg] Consent systems

From: [email-masked]
Date: Fri, 04 Jul 2003 12:57:07 -0500

>> In the case of a person that I don't know, that means that they will 
> have to provide a summary of *why* they want to talk to me.  (E.g. 
> reporting a bug in your software, your system sent me a virus, our 
> company changed its name, this is your grandmother sending mail from a 
> cruise ship....).

>> I see absolutely no way to provide that information without providing a 
> big enough window for spammers to send ads.

>> What am I missing?

Nothing, really.  You're right.

BUT:

You can require that messages from unknown/untrusted people: 

   1)  do not contain HTML or other risky/cloaking-friendly techniques;

   2)  do not contain attachments or encoding;

   3)  are able to pass through content filters (SpamAssasin-like) that 
recognize familiar spam and t-can it.

Now, it's TRUE that IF you are able to get messages from previously unknown 
people, then SOME of those messages COULD be ads or spam.

OTOH, nothing says that you necessarily have to READ the message itself to find 
out.

I've already proposed in conjunction with my Permissions List that you could 
have (as a second-level implementation) that "held" messages (those which failed 
your permissions test) be summarized periodically to permit a quick triage by 
the recipient.  You could alternatively treat ALL untrusted mail that way, 
perhaps.

That way, to get an unexpected message through, someone would need to make their 
case to read it in the subject... and something more specific and personal than 
typical spammer lures like "You were right" or "Is this your E-mail?" or "I love 
you!" or whatever.

> I have proposed a message type that is limited to text only. (see
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05814.html)

I think that recipients should ABSOLUTELY be able to bounce or T-can unexpected 
mail from untrusted senders if it contains HTML.  HTML is generally used to 
obscure or cloak the content of spam messages.

> It is limited to a fixed number of characters, enough for a
name/identification and reason for correspondence. 

That's fine, although up to this point I'll mention that a lot of spam (once you 
get rid of the HTML) is pretty small as individual e-mails.

> No URLs are permitted. 

That's certainly reasonable enough.  What about Hotmail/Yahoo/etc that tend to 
append banner ads incorporating URLs?

> The only way to respond and give consent is by return
email to the from email address provided. No one can ask for
permission without a valid email address to provide a way for
consent to be returned.

In my Permissions List concept, you don't have to send a specific "notice of 
permission" back to the unknown person.  They just have to send you plain ASCII 
text, no HTML, no attachments.  You can adjust their permissions at any time, as 
you the recipient feel is necessary and appropriate.

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: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Jul 2003 13:58:30 -0400

Gordon Peterson wrote:
> In my Permissions List concept, you don't have to send a 
> specific "notice of permission" back to the unknown person. 
	In the framework for "consent based systems" it should be noted
that consent need not be communicated to senders. i.e. you should be
able to express consent to your ISP or your mail software without having
to tell anyone else. The communication of consent and the scope of any
communication would be personal choices made by specific users. The mere
fact that a consent based system may permit communication of consent
should not be taken to be a requirement that such communication occur.

		bob wyman

---

From: [email-masked]
Date: Fri, 04 Jul 2003 13:36:32 -0500

>should not be taken to be a requirement that such communication occur.

Absolutely.

And more specifically, the recipient ought to be able to change that permission 
at any time... making it either more restrictive, or less, as they think 
appropriate.

This actually suggests against a token-based system, since once you've given a 
token to a particular sender you might need to be able to revoke it or modify 
the permissions associated with it.  At that point, their own E-mail address 
(along with the recipient address) is plenty enough "token", I think, in order 
for the associated current permissions to be looked up.  :-)

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 04 Jul 2003 21:23:29 +0100

> should not be taken to be a requirement that such communication occur.

Absolutely, some kind of "scope" field in a consent expression is
essential.

--