Subject: Re: [Asrg] New take on emerging idea. (yet another C-R system?)

From: "John Fenley" <[email-masked]>
Date: Wed, 09 Apr 2003 16:00:43 -0600

>From: Kee Hinckley <[email-masked]>

>This doesn't make it less insulting or inappropriate.  No matter how you 
>mask it, it's a "game" that I have to play in order to talk to you.  It 
>implicitly assumes that your time is more important than mine, and that my 
>message is less important to you than avoiding spam.

for me personaly:
yes, I would rather have neither than both.

>If the only thing you care about is inconveniencing the receiver, then 
>you've completely missed the point.

personaly:
If i spent the time to write an email to someone, who then asked to verify 
my humanity, I would spend the extra 10 seconds to make sure my previous 
efforts were not wasted.

>Turning it into a cutesy game is actually worse.  If you're going to do it, 
>do it cleanly.  I'd far rather interpret some word in a graphic than sit 
>there trying to figure out what obscure historical figure some idiot picked 
>out for me to guess.  *Especially* if the reason I'm contact the person is 
>to do them a favor.

This is going to require a longer explanation.
Looking ten years down the road I see ai programs that can respond to the 
"type the word" type requests easily.
I see spam as coming directly(avoiding relays altogether) from spammers who 
stick around at a real $10 domain just long enough send out 100 million 
spams(with 300 million decoys to mess with baysean filters) and answer the 
tests, then change their ip's(possibly by moving their equipment physically) 
to avoid RBLs(or any sort of blacklist).

Farfetched? you tell me.
Nobody would ever go that far to send spam.....
yeah right.

That is why I propose to let everyone be responsible for thier own test. any 
inconvinience you experience will be felt 400 million times by a spammer.

if people get used to the idea of server generated tests, then it will just 
be that much harder to get them to make their own later on.

perhaps we might actually turn spammers into the worlds best ai programmers, 
but not likely. I think it will just stop spam.

>>That is an impimentation decision. a good system might have a special tool 
>>to handle mailing lists.
>
>???!!  You clearly weren't hear last week when everyone who posted to the 
>list got a challenge from someone on the list.  Dealing with mailing lists 
>isn't an "implementation detail".  It is something that has to be designed 
>into the system from the very start.  If you haven't figured out how to 
>deal with mailing lists, bounce messages, vacation notices, challenges that 
>respond with challenges from other similar systems and other automated 
>email, then you need to go back and do some more thinking.  These aren't 
>options--they are requirements of the real world.

ok... so i didn't have the solution then, I'll post it later today, or 
tomorrow.(already fairly in depth)

>>Mail delivery needs to occur without human intervention.
>>
>>Mail begins and ends with people.
>
>Trite, but not useful in the real world.  Especially when you get that 
>automated notice from your ISP telling you that your credit card is about 
>to expire and you need to give them a new one.

This situation won't be a problem at all.

John Fenley

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Templeton <[email-masked]>
Date: Wed, 9 Apr 2003 16:19:47 -0700

On Wed, Apr 09, 2003 at 04:00:43PM -0600, John Fenley wrote:
> tests, then change their ip's(possibly by moving their equipment 
> physically) to avoid RBLs(or any sort of blacklist).
> 
> Farfetched? you tell me.

My view is that arms races aren't as bad as you depect.  More to the point,
if what we do to stop spam will have some "collateral damage" then in fact
we want to be in the arms race, because we want to use the minimum change
to cause the minimum collateral damage, until such time as that minimum is
no longer working, and then move to the next phase.

What that means is that a proper spam design system may well contain a
series of steps, worked out in advance, though not necessarily revealed
to the public, which can be applied when needed, but not before.

Challenge/response is like this.  In fact, today, C/R works by simply
asking for any reply at all.   Eventually that will cease to be true, but why
make users jump through any hoops before we need them.    We can even
announce that our next plan, after simple-reply fails, is a turing test,
without naming the test.   One could even have a service that keeps upgrading
your turing tests.

Of course another good idea is to give users options.  For example, one
could include in a challenge both a turing test (What is this picture?) or
a request for proof of CPU time (run this java applet in the background,
it will report to me when it is finished and your mail will be delivered.)

The user can choose to do either.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Wed, 09 Apr 2003 20:45:32 -0700

On Wed, 9 Apr 2003 16:19:47 -0700 
Brad Templeton <[email-masked]> wrote:

> asking for any reply at all.  

Then we should head forward.  Taking challenge/response first:

  1) Are we sufficiently agreed that challenge/response will be a part
  of the solution that we can move ahead on its design?

  2) Do we need to define a taxonomy of the rights and forms of consent
  being acquired, or are we content with a simple, "I can send you
  mail?"

  3) Is there more needed within the challenge/response system for spam
  prevention other than/outside of the simple challenge response (eg
  some sort of testimonial or contract on the basis of the responder)?

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 9 Apr 2003 22:40:31 -0600 (MDT)

> From: J C Lawrence <[email-masked]>

> ...
> ...

If consenus existed on that premise (which definitely has not been
established), that assertion assumes or implies things that range
from dubious to probably false to obviously false:

  - the IRTF is where protocols are designed.

  - designing challenge/response protocols fits the charter for this RG.
     See http://irtf.org/charters/asrg.html

  - it is time to consider designing or refining the design of any spam 
     defense protocol in this RG.

  - the word "protocol" in the sense it is used around here fits the
     notion of challenge/response spam defenses.

  - there will be single challenge/response protocol or even style
      of challenges and responses.

  - it would be a good thing for there to be a single challenge/response
     protocol or style.

  - if it were a good thing to have a single protocol or style, the
     IETF or IRTF could stifle others.

Whatever you mean by designing a challenge/response protocol, if you
want to do it, then the next step is for you to do do it.  You and
anyone working with you might (or might not) want to write down your
protocol as an ID, but that is certainly not required, as demonstrated
by the many challenge/response spam defenses currently in use.

The IETF is definitely not a legislature, and the IRTF more so.  
It is not the lack of voting that makes that a true statement.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Templeton <[email-masked]>
Date: Wed, 9 Apr 2003 22:42:31 -0700

>   of the solution that we can move ahead on its design?

People are free to run C/R systems.  A system designed for widescale use
should indeed follow a set of principles:

    a) Properly handle mailing list mail
    b) Never challenge a reply to an E-mail you sent, even if you sent
       it from elsewhere and a different account which aliases over to
       the real mailbox.
    c) Include protections against loops, obviously and challenging other
       challenges, autoresponses etc.

    d) Provide a means to allow the user to review all their blocked mail
       (sorted by spam score) to catch the people who did not respond
       to the challenge.  Yes, these happen regularly even with simple
       challenges, and not because the other person is lazy.

    e) If you don't do (d), provide some other means for anonymous mail
       and yes, mail from people with broken mailers, to make it to you.
>   being acquired, or are we content with a simple, "I can send you

    Simpler is better
>   some sort of testimonial or contract on the basis of the responder)?

Nope.

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 9 Apr 2003 23:04:58 -0700

I think this is a key issue -- if you send an e-mail to someone, I 
think there has to be an assumption of consent to accept a response. 
But OTOH, I'm not sure it implies a permanent willingness to accept a 
communication relationship.

so perhaps there ought to be two forms of consent here: a one time use 
key and a revocable consent key, something that can be embedded in a 
header or in some other way in the return mail to unlock the door.

---

From: Brad Templeton <[email-masked]>
Date: Wed, 9 Apr 2003 23:26:46 -0700

> header or in some other way in the return mail to unlock the door.

You're making it too hard.   There are too many mailers.  In fact, you want
to try every possibly means to accept replies to mails you actually wrote.

That starts with of course, putting a unique string in your outgoing 
message-ids, time-encoding, and accepting anything with that in the in-reply-to.

Also good is whitelisting all mail targets of course, and remembering all
outgoing subject lines, and outgoing bodies (to see replies that include
text from your messages.)

Now you keep a different standard for mail you send to a list than mail you
send to ordinary people.  You want to try _everything_ to accept replies to
mail you wrote to ordinary people.  There is nothing more aggravating than
having somebody mail you, and you reply, and you get back a challenge or
frankly any autoresponder.

There is of course a very simple solution here.  Use a different address
for your person to person mail, a totally unfiltered address.  You just have
to be sure people don't put that address out in public and not use it to
mailing lists.  If they do, you need another one.

I believe Zoemail is using a technique of a different address for each mail
out.  That's overdoing it but can be useful with list mail.

---

From: J C Lawrence <[email-masked]>
Date: Wed, 09 Apr 2003 23:49:45 -0700

On Wed, 9 Apr 2003 22:42:31 -0700 

>> Are we sufficiently agreed that challenge/response will be a part of
>> the solution that we can move ahead on its design?

> People are free to run C/R systems.  

Which doesn't answer the question.

> A system designed for widescale use should indeed follow a set of
> principles:

>     a) Properly handle mailing list mail 

Precedence header, or a heuristic of List-* headers, precedence header
and others?

> b) Never challenge a reply to an E-mail you sent, even if you sent it
> from elsewhere and a different account which aliases over to the real
> mailbox.  

There's some ambiguity there.  Consider:

  Bubba email Bruce and Bruce replies (the simple case).

  Bubba emails a list and several list members reply.

  Bubba emails Boffo, Boffo forwards to Bernie, and Bernie replies.

Which means:

  1) There has to be some way that transient consent it copied to the
  receiver

  2) That there needs to be some form of copy control on the consent
  token which is copied by the receiver (so that it can't be freely used
  as a get-spam-in-free token.

> challenges, autoresponses etc.

Not to belabor the obvious, but this would seem to be true for C/R
systems which use email as the transport for both directions.  I don't
see that we need to define or mandate that both the challenge and the
response need to be email-based.

> (sorted by spam score) to catch the people who did not respond to the
> challenge.  Yes, these happen regularly even with simple challenges,
> and not because the other person is lazy.

While I agree as a user, that seems like an implementation choice, not a
question for a standards definition.  Certainly if we go so far as to
arrive at or give the nod to a reference implementation it wouldn't hurt
if this were present...

> and yes, mail from people with broken mailers, to make it to you.

Would this be better expressed as:

  A C/R system should provide a method for the user protected by that
  C/R system to review mail held pending a response in case the
  challenged sender is unable to respond correctly (eg due to foreign
  language or disability reasons).

I'm imagining a two fold system here:

  A challenge has standards-defined identifying characteristics which
  clearly state that it is a consent challenge.  Because of these
  characteristics mail systems can distinctly recognise challenges as
  different from other mail traffic.

  An emailed reply to a challenge can attempt to be an answer to the
  challenge, or can be an indication that there was some problem with
  the challenge.  Obviously an attempted response would be handled on
  its own merits, however a commentary on a challenge might cause the
  held message to be flagged for the receiving user's attention. eg:

    Bubba mails Boffo.

    Boffo sends Bubba a challenge.

    Bubba can't understand Boffo's challenge (he's blind).

    Bubba uses his MUA's challenge-query feature to send a
    challenge-problem reply back to Boffo.

    Boffo upon reviewing his challenge-held mail sees a message from
    Bubba which is flagged (MUA implementation detail) for his
    attention.

Of course spammers who operate MXes, or who retain use of an MX long
enough can send similar challenge query messages, but that's acceptable
at the protocol level.  We're in the realm of heuristics, and there's
nothing to say that receiving MUAs can't also provide additional hinting
heuristics in their processing of the display of challenge held messages
etc.

>  Simpler is better

Yes-ish.  I tend to think that there needs to be at least a concept of
date ranging, of a consent token being valid for only a limited period.
One possible use of such a date prevention would be partial prevention
of nefarious reuse of a consent token by others (see above forwarded
mail reply case).

> Nope.

What about subscribing to a list?  I'm tending to think that the
subscription negotiation for a list should also establish the
appropriate consent tokens (and perhaps filtering defaults?), and if
dated consent tokens are supported, a means for refreshing consent
tokens over time.  Similarly for commercial bulk mail (of the zealous
marketing dept variety, not address harvested spam), I could easily see
legislative support for such if the mail self-identifies itself as
commercial bulk.  Lastly of course come chain letters and variations on
the Nigerian email.  Surely those should state up front that they are a
chance in a lifetime opportunity to earn millions and get the girl(s).

---

From: Brad Templeton <[email-masked]>
Date: Thu, 10 Apr 2003 00:38:28 -0700

> Which doesn't answer the question.

To be more specific, since these are endpoint systems, they can be run
without much need for standardizaton on the other end.   One can imagine
laying down some standards for other ends that would like to do something
special but it's not a big pressing demand.   Normally we would see some
established implementations and look to standardize there.  If an MUA
did challenge response, it could have other copies of the MUA recognize
and do "something" with the challenge, though of course autoresponse is not
normally the course on turing test challenges.

>   Bubba email Bruce and Bruce replies (the simple case).

That should always work or you have a broken system.  That includes however,
that bubba mails bruce's alias, and the real bruce replies.  Ie. simply
whitelisting bruce's alias is not enough.
>   Bubba emails a list and several list members reply.

This is under the "it would sure be nice" category, but in general not as
much of a mandatory.  Most designs in this area effectively let replies come
in to a public message for some period of time, then challenge it after that
amount of time.    You run the risk of spammers harvesting mailing lists
and replying to every message with some spam during the window, making it
look like a reply.  Though that bridge should be crossed when we come to it.

For private lists, this is more doable, and more desireable.

>   Bubba emails Boffo, Boffo forwards to Bernie, and Bernie replies.

I presume you mean not forward but what some mailers call a bounce, where
it looks like the mail came from Boffo.   This is similar to the above.
Nice to do.  Easiest solution -- all private mail comes from an unfiltered address.

>   1) There has to be some way that transient consent it copied to the

Not really, because as I said, you don't need to use a filtered address
in mail that's not going to be exposed to the public.
>   as a get-spam-in-free token.

As long as this is rare, you just turn off such addresses.
> arrive at or give the nod to a reference implementation it wouldn't hurt

None of this is standards stuff, actually.  Just best practices.  And
not causing mail to vanish without a trace is good practices.
> dated consent tokens are supported, a means for refreshing consent

This comes back to the question of whether this is about consent or not.

You want to rescind consent to somebody or mail containing some token?
Just program your mailer to reject their mail.   The rest of the world
does not need your consent to mail you, at least not for person to person
mail.  This is a hard truth that some people in the anti-spam community
don't wish to embrace, unfortunately.

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 10 Apr 2003 09:27:52 -0400

>Precedence header, or a heuristic of List-* headers, precedence header

Don't give the spammers a way to get out of the system by faking List headers.

>response need to be email-based.

Keep in mind that just because you can read email does not mean that 
you can use the web.  Company policies can and often do restrict web 
use.  Many people read email off-line, and of course not all email 
users are on the internet.

-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 10:05:52 -0700

On Wed, 9 Apr 2003 23:04:58 -0700 
Chuq Von Rospach <[email-masked]> wrote:

> think there has to be an assumption of consent to accept a
> response. But OTOH, I'm not sure it implies a permanent willingness to
> accept a communication relationship.

Quite, and its this logic, along with the risk of consent tokens being
leaked to and abused by spammers which persuades me that consent tokens
must be able to be date limited.  Without that a consent token becomes
an infinite get-into-my-mailbox-free card.

> header or in some other way in the return mail to unlock the door.

Currently I'm thinking about consent tokens having three potential
properties:

  1) Date range

  2) Sender address

  3) Date range and sender address

Those three would seem to cover the bases, from list posts, to bounce
forwarded messages, to tardy repliers etc.  MUAs would handle the dirty
work of tracking etc.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 10:19:28 -0700

On Thu, 10 Apr 2003 09:27:52 -0400 

>> Precedence header, or a heuristic of List-* headers, precedence
>> header and others?

> Don't give the spammers a way to get out of the system by faking List

Quite.  My tendency is that we should sketch out a protocol by which the
subscription process can establish and maintain a consent token.

  ObNote: I'm want to stay very carefully clear of how a consent token
  is expressed, encoded, transfered, etc at this point.  Let's first get
  the grammar of the consent protocol down, how the damn things move
  about, when, etc before we worry about implementation.

>>> c) Include protections against loops, obviously and challenging
>>> other challenges, autoresponses etc.

>> systems which use email as the transport for both directions.  I
>> don't see that we need to define or mandate that both the challenge
>> and the response need to be email-based.

> users are on the internet.

True.  However I don't see it as our business to get messed in with the
details of how the challenge reply is phrased, over what transport, what
forms challenges can take, how it is communicated to the mail system,
etc etc.  We can reasonably leave that space alone and unstandardised.
If some want to use the web, so be it.  Ditto for others with image
tests which select against the blind or language tests which select
against foreign language users.

Not our business and not our interest -- especially since we know that
the field of challenge definitions MUST not be standardised or even very
slightly to be remain profitably resistant to automation.

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 10 Apr 2003 10:39:26 -0700

plus syntax?

<consent token hash>[email-masked]?

Recipient user maintains a database of hashes with allowed addresses 
they'll accept that hash from. Since a user (like me, or like a list 
with monthly admin postings) might have more than one email address to 
send from legitimately, allowing a token to map to more than one 
address simplifies things. Allows users to manage access, revoke or 
modify consent, and allows some flexibility in the use of the token 
based on the real world. You could potentially flag some tokens as 
being filtered to a folder for review, while other tokens filtered to 
c/r and others to blacklist, based on why you generated them.

Given this, I think you could also create "good until" tokens, too, now 
that I think about it. Maybe re-invent the web site mailto with a token 
that's got some way of seeing when it was generated and can only be 
used for, say, 24 hours after generation. That'd solve most of the 
problems we see with role accounts without forcing everyone through c/r 
stuff. Spammers would have to scrape and spam in real time, which is 
still possible, but a lot harder.

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 10 Apr 2003 10:58:02 -0700

And now that I think about it a bit more, for addresses you know, a 
straight whitelist will do. this is only necessary where you're giving 
consent to an entity where the reply isn't necessarily known, or the 
consent isn't without limits.

You could also, I think, allow a token that says "when you see this, 
add this address to the whitelist", so it only gets used once and 
allows a user to add themselves to your whitelist.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 11:45:24 -0700

On Thu, 10 Apr 2003 10:39:26 -0700 
Chuq Von Rospach <[email-masked]> wrote:

> plus syntax?  <consent token hash>[email-masked]?

Sure, that's one way (and the way that TMDA does it), but I'd rather not
get messed in with implementation of how to encode consent tokens at
this point.  What we need to resolve now is how tokens move about, when,
etc.  How for instance list subscriptions are negotiated, how consent
can be audited, all that crap.

Then we can mess with an implementation that does all that.

> c/r and others to blacklist, based on why you generated them.

<nod>

> Given this, I think you could also create "good until" tokens, too,
> now that I think about it. Maybe re-invent the web site mailto with a
> token that's got some way of seeing when it was generated and can only
> be used for, say, 24 hours after generation. That'd solve most of the
> problems we see with role accounts without forcing everyone through
> c/r stuff. 

There are horrors in UI complexity here, but yes, these are the sorts of
things I'd like to see hit.

> Spammers would have to scrape and spam in real time, which is still
> possible, but a lot harder.

Frankly I don't think its possible to build a system which can prevent
spam which doesn't also prevent valid/desirable communication.  There's
a scale.  You get to pick a point on the scale with its associated
tradeoffs.

If spammers need to do near-realtime scrap and send, I have little doubt
they will, especially as bandwidth and MIPs continue to plummet in
price.  However, that's not todays problem, nor tomorrow's, and I
suspect the legal and other surrounding contexts might be a lot
different then.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 12:13:46 -0700

On Thu, 10 Apr 2003 00:38:28 -0700 

> without much need for standardizaton on the other end.

I disagree.

> One can imagine laying down some standards for other ends that would
> like to do something special but it's not a big pressing demand.
> Normally we would see some established implementations and look to
> standardize there.  If an MUA did challenge response, it could have
> other copies of the MUA recognize and do "something" with the
> challenge, though of course autoresponse is not normally the course on
> turing test challenges.

I'm not interested in challenge formation, or even response type.  Those
are things for individual implementors to deal with, not us.  I'm
thinking of things like:

  -- How does my MUA acquire a consent token?

  -- How does my MUA send a consent token to someone else?

  -- How are consent tokens established and exchanged for:

    -- a list subscription via email

    -- a list subscription via non-email (eg amazon, ebay, etc)

  -- How are consent tokens maintained over time?

  -- How are consent tokens revoked, and is that transparent to
  possessors of that token?

  -- How is a consent token requested?

    -- Can specific lesser rights be requested?

    -- Can a consent token request state or announce what/why the token
    is being requested (contract statement)?

    -- Can consent token requests be forwarded? 

  -- How can consent tokens be shared (someone forwards their copy of a
  token to a third part for temp/one-time use)?

  -- Can a consent token be used to generate a one-time valid consent
  token for a third party?  ("You need to talk to my friend...")

  -- If a contract is made at token-request time, can their be automatic
  enforcement of that contract, with revocation clauses?  (ie what are
  the contract nouns?)

  -- What rights can be granted by a consent token, are there ranges and
  flavours of rights, and if so what are they?

  -- How can someone try and work thru a C/R system when they fail or
  can't satisfy the challenge (eg foreign language, blind, etc)?
  (ie can there be a hinting layer?)

  -- To what extent can consent token processing be extended to or
  shared by MTAs and LDAs as distinct from and separate from the human
  user's client MUA?

  etc...

Then once that lot and other related questions are answered we can look
at how consent tokens and requests can be encoded into email, what the
range of expression types are, etc.  (plus addresses, Message-IDs, new
custom headers, etc)

> That should always work or you have a broken system.  

Quite, but we have to remember that.

> That includes however, that bubba mails bruce's alias, and the real
> bruce replies.  Ie. simply whitelisting bruce's alias is not enough.

Yup, that's a variation on the forward/bounce example I gave later.

> This is under the "it would sure be nice" category, but in general not
> as much of a mandatory.  

I disagree but I also think this one can be handled fairly cleanly
without contorting anything.

> You run the risk of spammers harvesting mailing lists and replying to
> every message with some spam during the window, making it look like a
> reply.  Though that bridge should be crossed when we come to it.

Exactly.  Realtime spamming remains a risk, and not one I think we can
handle at this level.

> For private lists, this is more doable, and more desireable.

Yup, yea, and verily.

> I presume you mean not forward but what some mailers call a bounce...

Yeah.  I keep forgetting that I'm talking to people who actually know
about mail systems.

> ... where it looks like the mail came from Boffo.  This is similar to
> the above.  Nice to do.

I consider it identical to the alias case you first mention.

> Easiest solution -- all private mail comes from an unfiltered address.

People get attached to their email addresses.  JoeSixpack humans have
real problems with the mental distinction between role addresses (which
is essentially what you are advocating) and their personal identity.
I'd rather not go down that path if we don't have to.

> does not need your consent to mail you, at least not for person to
> person mail.  This is a hard truth that some people in the anti-spam
> community don't wish to embrace, unfortunately.

Excellent point.

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 10 Apr 2003 12:28:21 -0700

On Thursday, April 10, 2003, at 11:45  AM, J C Lawrence wrote:

> this point.

agreed -- I only took it to the point where I understood if it required 
infrastructure changes or other non-local things, because that 
significantly impacts workability and complexity. Once we can see a way 
of building it "in place", we can leave the details for later...

> things I'd like to see hit.

not necessarily. dynamically generate the mailto using SSI, when it's 
generated the token gets stuffed in the database until it expires. it 
wouldn't take much more work to do it in a way where tokens weren't 
generated until "asked for".

> a scale.  You get to pick a point on the scale with its associated

exactly. At this point, I'll take a system where I can put a role 
account on a web page, and know ten years from now it won't be getting 
spam unless the spammer is grabbing the account right now. That solves 
90% or more of the problems with role accounts (and other accounts 
stuck on web pages) we see. And it means the spammers are going to have 
to work harder to hide. If every email on a page has a unique token 
generated for every page scrape, it's not much more work to track when 
it was scraped, where it was scraped from, and that makes the spammer 
that much more visible and exposed, with very little window to wiggle 
in, grab and find a new hole to hide in.

> they will,

but it gives us new tools to fight that, too, because then we can start 
tracking and blocking the scraping as well.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 12:41:40 -0700

On Thu, 10 Apr 2003 12:28:21 -0700 

>> Sure, that's one way (and the way that TMDA does it), but I'd rather
>> not get messed in with implementation of how to encode consent tokens
>> at this point.

> agreed -- I only took it to the point where I understood if it
> required infrastructure changes or other non-local things, because
> that significantly impacts workability and complexity. Once we can see
> a way of building it "in place", we can leave the details for later...

True.

Please understand that I don't want to go down this route yet.  However,
I've been noodling having consent tokens, requests, and advertisements
expressed as plus addresses (TMDA-style), encoded in Message-IDs, as
gobbledegook in Subject: strings, and custom headers.  My suspicion is
that we are going to have to have and use all of them as phrasings and
transports for different, specific use cases.  __BUT__ I'm not abot to
declare that until we've gotten some grammar and protocols worked out
against a well rounded set of use cases.

>>> now that I think about it. Maybe re-invent the web site mailto with
>>> a token that's got some way of seeing when it was generated and can
>>> only be used for, say, 24 hours after generation. That'd solve most
>>> of the problems we see with role accounts without forcing everyone
>>> through c/r stuff.

>> There are horrors in UI complexity here, but yes, these are the sorts
>> of things I'd like to see hit.

> not necessarily. 

Umm, I was mostly referring to the prior paragraph I quoted which you
trimmed.

  BTW: Do you have any idea how many web forms and other tools won't
  accept a plus address (using a "+" character) as a valid email
  address?

> ... dynamically generate the mailto using SSI, when it's generated the
> token gets stuffed in the database until it expires. it wouldn't take
> much more work to do it in a way where tokens weren't generated until
> "asked for".

Absolutely.  If the token is built via plus addressing this works
perfectly and very natively with a TMDA-like setup.

>> Frankly I don't think its possible to build a system which can
>> prevent spam which doesn't also prevent valid/desirable
>> communication.  There's a scale.  You get to pick a point on the
>> scale with its associated tradeoffs.

> exactly. 

<bow>

> At this point, I'll take a system where I can put a role account on a
> web page, and know ten years from now it won't be getting spam unless
> the spammer is grabbing the account right now. 

That requires a dated address with a fairly small window.  There are
problems there -- such as someone simply taking a while to compose their
message, or forwarding the address to a third party.  Not necessarily
fatal problems, but troubling to me.

> That solves 90% or more of the problems with role accounts (and other
> accounts stuck on web pages) we see. And it means the spammers are
> going to have to work harder to hide. 

Aye.  I still have fond hopes for my forward chained Received: headers
proposal as well for the same reasons.
  
> If every email on a page has a unique token generated for every page
> scrape, it's not much more work to track when it was scraped, where it
> was scraped from, and that makes the spammer that much more visible
> and exposed, with very little window to wiggle in, grab and find a new
> hole to hide in.

This is precisely why I'm looking at having my web archives for my lists
to generate dynamic TMDA-based dated addresses for email addresses in
the message.  Sure you can scrape the archives for addresses, but all
you get are a set of <crap>@kanga.nu addresses which forward to
real_address@domain for 24hrs before turning into a C/R system.

>> If spammers need to do near-realtime scrap and send, I have little
>> doubt they will,

> but it gives us new tools to fight that, too, because then we can
> start tracking and blocking the scraping as well.

Weaponry is Good.

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 10 Apr 2003 16:39:09 -0400

>Currently I'm thinking about consent tokens having three potential

There's at least one existing system out there that creates N-use 
email addresses.  It's an interesting idea in the consent space. 
Even more interesting (although we run the serious risk of getting 
two general here) is N-use/time-period.  In other words.  I don't 
mind the fact the Buy.com sends me email.  But I don't need to hear 
from them every *week*.  So I might consent to hear from them once a 
month.

Frankly though, I think simple is the way to go.  I wouldn't do date 
range at all.  I'd just do sender address.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 14:50:56 -0700

On Thu, 10 Apr 2003 16:39:09 -0400

> email addresses.  It's an interesting idea in the consent space. Even
> more interesting (although we run the serious risk of getting two
> general here) is N-use/time-period.  In other words.  I don't mind the
> fact the Buy.com sends me email.  But I don't need to hear from them
> every *week*.  So I might consent to hear from them once a month.

Hurm.  Cute.  That makes the list of potential poperties:

  Date range

  Sender address

  Keyword

  Use count

> range at all.  I'd just do sender address.

At a spec level I don't see a particular problem with having a large
number of properties.  Nothing need break if one end of a communication
channel doesn't support properties that the other end does, and thus
nothing need mandate that any "supporting system" needs to implement, or
even expose to its users, the whole panoply of permutations.

If we come up with more than one property, some implemented systems are
__guaranteed__ to skip implementing at least one of the set.  We can
trust that with certainty.  This doesn't mean we should make the base
property set huge, or the number of permutations huge, or in fact that
we should work very hard to derive a full dictionary of all the possibly
interesting properties.  But, if we have a grammar and a set of exchange
protocols for establishing, transmitting, and maintaining consent
tokens; where those tokens are (for the sake of argument opaque
strings), and we propose a reasonable set of base properties and show
how they may be encoded in such an opaque string and how an MUA might
manipulate them in interesting and user-friendly ways...then the MUA
authors of the world can pick that up, implement some fraction of it and
run with it any damn way they want and a) we both don't have to care,
and b) we can reap the benefits.

  My worry is how horrendously hard it will be to get AOL or MSN or
  Hotmail to support plus addressing.  Heck, can MS Exchange handle plus
  addressing in any useful fashion?