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

[J C Lawrence <claw@kanga.nu>]

On Thu, 10 Apr 2003 12:28:21 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> On Thursday, April 10, 2003, at 11:45 AM, J C Lawrence wrote:

>> 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.

>>> 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.

> 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.

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