On Thu, 10 Apr 2003 12:28:21 -0700
Chuq Von Rospach <chuqui(_at_)plaidworks(_dot_)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(_at_)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(_at_)kanga(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg