ietf-asrg
[Top] [All Lists]

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

2003-04-10 12:30:56

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

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

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.

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.

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.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>