J.C. and Art,
We may all be talking about the same idea... see also:
[Asrg] Gray list: rating of associates
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01552.html
Instead of using a plus-type email like "boffo+a90f234af57eee8bacab(_at_)there",
it uses a GUID like the one I'm sending my email from now.
I use this system now and it works whether other servers recognize this new
approach or not. Every email address is unique to the sender-receiver
pairing.
Dave
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]On
Behalf Of J C
Lawrence
Sent: Monday, April 07, 2003 3:28 PM
To: Art Pollard
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Turing Test ...
On Mon, 07 Apr 2003 12:05:52 -0600
Art Pollard <pollarda(_at_)lextek(_dot_)com> wrote:
After the Turing test or similar authorization process, you could
exchange the information needed for using / testing digital
signatures.
Then when any additional messages are sent, the new messages would
have a signature line. You could not only ensure that the person you
received the message from was "authorized" (as in the sense that one
would have in checking addresses) but also is who they say they are.
Absolutely, and this raises a critical distinction:
To what degree is the problem to be handled at the MTA level, the LDA
level or the MUA level?
To get the platitudes out of the way, earlier is generically better.
(Doh!) My expectation is that we're going to have to involve all three
camps, heavily and discretely. More specifically I expect that the
final strategies realised and deployed will be multiple and overlapping,
without consistent direction and design cooperation between the levels.
Consider the simple case of consent tokens:
Who generates the consent token? Who tracks it? Who checks it? Who
has audit oversight on the consent trail?
(I won't deal with consent acquisition at this point)
Crytpo techniques can certainly be applied to make processing of consent
tokens unidirectional (eg only one thing can generate them, any thing
may check their veracity). They can also be applied to the ends of
arranging mutual consent from a contact, as well as forming the visible
expressions and encodings of consent.
This would also help solve the problem of people with multiple e-mail
addresses. They could have lots of e-mail addresses and as long as
they had the proper signature set up at the different e-mail addresses
/ accounts then the fact that they had different addresses could be
entirely transparent.
<nods>
This is an interesting one -- the ability to make different addressing
forms invoke the same consent methods, or for them to be externally
resolvable as representing the same human -- but outside of the nice
efficiency aspects I'm not clear that its our business (yet).
Now, I am starting to get a budding idea here.....
Oh dear.
What if..... A new digital signature were issued to each new person
who you correspond with. Then if you start getting spam from that
person / organization, you could simply disapprove them. This would
get around any possibility of people sharing information to try to get
around the restrictions.
Aye, I proposed something of this when I talked about forward chained
Received: headers, to whit the use of TMDA-style sender addresses as an
expression of consent tokens. This could be expressed thru overloading
the SMTP envelope. Consider:
Bubba emails Boffo.
From: bubba(_at_)here
To: boffo(_at_)there
Subject: Hi!
...etc...
Assuming a consent negotiation has previously occurred Bubba's MUA
tags an envelope on his message ala:
Return-Path: bubba+deadbeef111abcdef978(_at_)here
Envelope-To: boffo+a90f234af57eee8bacab(_at_)there
Wherein the plus addressing tokens represent the consent tokens. The
payload, the message itself, is left unchanged. More specifically:
Bubba's token of "deadbeef111abcdef978"is opaque to Bubba, but
encodes the following information for Bubba:
This is one of my consent tokens, and not something someone
forged.
This consent token is for the exclusive use of bubba(_at_)there, and
use with any other sender address will fail.
But for Boffo, Bubba's token is compleatly opaque. Its merely a
string which Boffo's MUA knows to use with Boffo.
Similarly for Boffo's token of "a90f234af57eee8bacab" as regards
what it means for Boffo and Bubba.
Impacts at the server-level:
Everybody has to support plus-addressing.
ObNote: There needs be no standardisation on the plus addressing
character used ('-' vs '+' etc): the transform required of an
address to add a consent token can be stated/agreed-upon/etc at
consent negotiation/grant time.
Future servers and LDAs can add support for storing secrets for
processing consent tokens at SMTP or LDA time. THis is not required
for deployment however.
Niceties:
Plus-addressing is not exposed to the humans, just the transport
layers (and perhaps some headers for better tracking/auditing).
The addresses humans use don't need any change. They never see or
need to type the consent tokens.
Software, and in particular the MUAs do all the token tracking,
application, checking etc, so MUAs can revoke any previously granted
token as well. Humans don't need to.
If the secret required for encoding the consent token is shared with
upstream MTAs, they can execute the consent token checks (not
revoked) at receipt time. Or, for more slightly more paranoid
arrangements, the secret may be shared only with the LDA.
Now methods and means of establishing consent tokens, of the
negotiations required or a priori contacts or data are an entirely
different matter.
--
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg