Subject: [Asrg] Consent systems

From: [email-masked]
Date: Tue, 01 Jul 2003 23:08:22 -0500

> 	1. If consent can be "expressed" in some sort of a document or
data structure, that "expression of consent" can be communicated or
moved from the local periphery of the system into the more global core.
Thus, I, my ISP, or my organization, might prepare an "expression of
consent" that states that mail will not be accepted if it exceeds
certain sizes, contains certain elements (such as attachments) or is of
a "commercial" nature. 

I think an important aspect of such a consent-based system is precisely that the 
sender (or spammer or whoever) MUST NOT BE ABLE TO INQUIRE IN ADVANCE regarding 
what (hypothetically) would and would not be accepted.

A classical problem in computing is when one system misleads another into making 
an irrevocable, wrong decision.

One example of such a problem is where the sender inquires about what I'm 
allowing today, and finds out that I've turned off HTML from unlisted senders.  
They proceed to send me plain ASCII text.  The problem comes from the fact that 
I could change my policy regarding that sender AT ANY TIME.  So they might ask, 
for example, if they can send HTML... my server says "sure!  You're approved" 
and meanwhile I turn off their permission.  Now they send me HTML-burdened mail 
and it says "sorry!  Not allowed" and they look bewildered and say, "WHAT 
GIVES?!"

Here's another example.  A common request to system designers is "tell me how 
much free space is on such-and-such-a-volume".  The OS returns a message saying 
"I have this much" and the application then presumes it can write a file that 
big.  But by the time it gets there, the space has already been used by someone 
else... a far better solution is to go ahead and create the file you want, 
position out to the end of it and write the last sector to allocate the space 
(presuming that it DOES that in your system!) and THEN proceed to transfer your 
data into your (now assured!) disk space.  That way, you don't get caught short, 
and you don't make a (perhaps irrevocable) decision based on data which later 
turns out to have been inaccurate.

I think that the RECIPIENT should adjust the permissions to gate in what they 
EXPECT the sender to send, based on their knowledge of what that sender DOES 
send.  (And hopefully can set the options so their sender will send plain ASCII 
text!)  The point is that you allow what you want and expect, and simply gate 
out everything else as unexpected and atypical and therefore probably wrong.

As an example, Aunt Gertrude is on AOL and sends their stupid default 
HTML-burdened E-mails, but those never have anything in them much beyond 
boldface, italics, maybe a couple of font changes... never scripting or 
convoluted hyperlinks, tables, ActiveX, or such.  If she ever sent me an 
attachment, it would be nothing more scary than a JPG file.  So ideally I could 
set her permissions to allow her to do [only just!] what she's likely to do.

It's not unlike a credit card company which develops a feel for the pattern of 
your use of your credit card, and then when they suddenly see a highly atypical 
purchase for $500 worth of tequila at a liquor store in the far other end of 
your city... they might call you at home to try to verify that the charge is 
yours, and that you still have your card.  That's really the goal of the 
permissions system... to allow the people you know and trust to (just) do what 
you expect them to do, and send you what they send you.  People who you don't 
know (yet) can still reach you by using least-common-denominator, safe and 
universal stuff like plain ASCII... and once you've developed a relationship, 
you can upgrade their permissions (if appropriate and necessary) to allow them 
somewhat wider range of expression if the recipient deems that appropriate.

But I do NOT believe that "just anybody" on the Net should be able to inquire 
about what you do and don't permit.  They ought to (like creating the big file) 
simply try it and it will either work or it won't.  (Or, better yet, simply send 
the COMPATIBLE UNIVERSAL format to begin with, and never PRESUME that they can 
send anything else unless they clear it with the intended recipient first...)

Besides, for privacy reasons, I don't want anybody else but me and my ISP or 
domain provider looking at my personal permissions list.

> If this expression can be accessed by arbitrary
nodes, then either sending nodes or intermediate nodes would be able to
determine what had been consented to and decide whether to originate or
relay any particular message.

I think that approach, while it might sound appealing, is a VERY bad 
architectural model.

>	A very simple version of such a system would be created if we
were to adopt something like the "donotcall.gov" system which is used to
block telemarketing calls in the US.

There is a BIG difference, though.  There, everyone is pretty much in the same 
boat ("a telemarketer is a telemarketer") and there is a Federal law waiting to 
prosecute those who misuse the phone numbers on the list they get.

>	2. If systems that rely on "licenses to send" or
recipient-issued tokens are deployed, then depending on the way these
things are implemented, upstream nodes would be able to inspect the
licenses and determine whether or not a particular message was, in fact,
authorized. 

Except for the fact that they probably CANNOT.

Again, consider the case of a Yahoogroups mailing list.  Messages are either 
delivered individually (bearing the name of the sender) or as a digest (and thus 
bearing the name of the list).  Another point is that a digest might have a 
largeish number of messages from different people, and IF those people are in 
fact known (or some of them known) to the recipient, they MIGHT have different 
permission rules.  

And like the challenge-response issues I mentioned in an earlier post, there is 
really no way in general for a recipient (or even his ISP) to reach back and 
figure out how to contact (directly) the "original" SMTP server which originated 
the message (at least certainly not by the return address).

> Depending on implementation choices, non-authorized messages
could be either discarded, subjected to more or greater "spam-detection"
inspections, or routed at lower quality of service.

Actually, the solution I like best of the ones I've heard so far for this is 
(again) the solution I proposed... where periodically a "digest" of suspected 
spam messages (say, one or two lines each) is sent in an E-mail to the intended 
recipient, so that they can vet them in a sort of triage and ask their ISP to 
move false positives back into their 'to be delivered' queue.  This allows the 
recipient to (in a single E-mail) quickly scan down a list of maybe as many as a 
hundred or more E-mails and decide which ones they want to look at.

In a way, this is like the newspaper.  If you get a daily newspaper, few if any 
people read it cover to cover.  Instead, you can leaf through it and 
pick-and-choose the articles and items that look like they might be interesting.

(And HOPEFULLY, legitimate senders will quickly learn that sending unanticipated 
mail in anything other than plain ASCII will reduce dramatically the likelihood 
that it will ever be read...)

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: "Jon Kyme" <[email-masked]>
Date: Wed, 02 Jul 2003 09:56:20 +0100

>what (hypothetically) would and would not be accepted.

I'm not sure that this is necessarily true. It would certainly take the
wind out of the "legitimate mass mailers" if it could be shown that they
could have ascertained that their mailing was unwanted before they sent it.
Equally, knowing in advance that a message with particular
characteristics will be blocked need not (of itself) help the spammer in
constructing a message that will get through. If we're worried that
spammers can deduce the anti-spam function of a system in some way
shouldn't we also be concerned that spammers can (a) read this list (b)
freely download widely used spamtools?

I believe that your objection may be answered by having some sort of
"scope" field in a consent expression. You can choose to set the scope of
your expression to be (say) "local" which might be equvalent to configuring
your MUA or MDA. You might choose to set it "organisational" in which case
your expression might be propagated to your firms (ISP?) mail system. Only
a "global" scope for expression has any of the risk that you're worried
about, and only then if the expression includes filtering criteria
explicitly, rather than references to "message classification" engines
which an arbitary entity won't necessarily have access to.

--

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 02 Jul 2003 09:58:48 +0100

"(b) freely download widely used spamtools?"

of course I meant "anti-spam tools"

--

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 2 Jul 2003 11:02:04 -0400

Gordon Peterson wrote:
> I think an important aspect of such a consent-based system 
> is precisely that the sender (or spammer or whoever) MUST 
> NOT BE ABLE TO INQUIRE IN ADVANCE regarding what (hypothetically) 
> would and would not be accepted.
	I assume that any consent based system would provide you with a
means to determine just how widely your expressions of consent would be
diseminated. Thus, if you really don't want people to know what you
consent to, you would be able to ensure that they are left wondering.

	Bob asks: "Gordon, can I send you mail?"
	Gordon says: "I won't tell you. Try it and see."
	Bob says: "I sent you mail, but got no reply. Does that
	   mean you're ignoring it, or was it rejected?"
	Gordon says: "I won't tell you..."
	Bob says: "Is this a Turing test?"

> Actually, the solution I like best [...] periodically a 
> "digest" of suspected spam messages (say, one or two 
> lines each) is sent in an E-mail to the intended 
> recipient, so that they can vet them in a sort of triage
> and ask their ISP to move false positives back into their
> 'to be delivered' queue.
	While this may be a procedure that *you* are willing to endure,
I suggest that the average email user would find it much too burdensome.
It should also be noted that if any extraction of the incoming mail is
performed (i.e. "one or two lines each") you will inevitably have
problems since it may not be possible to ascertain the real purpose of
the message from the extract and it is also likely the spammers will
adjust their message composition style to take into account the
algorithm for constructing an extract.

		bob wyman

---

From: [email-masked]
Date: Wed, 02 Jul 2003 11:05:50 -0500

>	Bob says: "Is this a Turing test?"

That's not the situation.

If someone asks ME, then I can find out who they are and decide whether I want 
to tell them (and/or what special provisions I *might* be willing to make to 
accommodate them).

What I don't want is something where some mindless bot at my ISP tells all 
requesting spammers just what it would take for their spam to slip through my 
filter.

If someone is going to send me E-mail, and hasn't got an established 
relationship with me, then I want it in plain, compatible, efficient ASCII text 
(at least INITIALLY)... no exceptions.  And I'd like that to be the accepted 
standard, for ALL unestablished E-mail relationships.

>I suggest that the average email user would find it much too burdensome.

I think it's a safe bet that most any filtering or triage scheme is going to 
create at least some false positives on mail that in fact isn't spam.  Instead 
of just trashing it without a trace, I think that most users would like to at 
least have the option of a summary of some kind of what things the system thinks 
they probably don't want... so that they can at least scan down the list to see 
if there's anything that looks like it was incorrectly judged.

Especially in the case of a sender-per-sender permission list, at the beginning 
this will help immensely in getting the permission list initially set up.

Choices for each message on the "held" list might include:

   1)  go ahead and send me this one.
   2)  send me this one, and all future messages like this from this sender.
   3)  delete the message
   4)  leave it in the held list for now

The idea is to quickly get a feel for what's there and to rapidly get 
familiar/repeated stuff so it sails right through, while minimizing the time one 
takes to blow off the stuff that's pretty obviously spam.

>algorithm for constructing an extract.

I'm not talking about extracting the content of the mail... I was thinking more 
of a summary of subject/from/replyto/etc and perhaps any other useful indicators 
that might be extracted (one useful one would be a short indicator of why the 
message was held instead of being delivered, such as the content filter picking 
up on hgh spam, or getrichquick, or Nigerian-type spam, or Viagra/sex 
enhancement, or mortgage spam, or HTML-burdened, or obscured to evade filtering, 
or whatever.  That indicator, coupled with who supposedly sent it and what 
subject line they used, would probably help in rapidly performing the necessary 
triage.

Usually a nondescript/unfamiliar/"lure"-type subject combined with an unknown 
sender, ALONG WITH a clue about what generated the spam flag from the message 
content, is all one probably needs to concur that it's spam and they don't want 
or need to see it.

(But this is ALSO why the filtering doesn't want to be done at multiple places 
in the Net, but at one place... probably upon arrival at the To: destination 
domain... so that they can generate and send the "held/suspect items" list every 
once in a while.)