On Wed, 07 May 2003 21:20:22 -0600
John Fenley <pontifier(_at_)hotmail(_dot_)com> wrote:
Yes a mailing list could give this and that, and it could be checked
this or that way. But a standard method, with standard tools, and a
standard method of accessing it would be usefull to many more people.
As I've previously mentioned I've been noodling on a consent token
protocol. It here follows:
--<cut>--
I'm sending this now, in its rough'n'ready state as if I don't I likely
won't get to send it at all. This is a set of loosely structured notes.
If you want EBNFs and protocol FSM diagrams, this isn't going to be it.
If you'd like to help phrase this in more IETF/RFC friendly form, I'd
welcome your assistance. As I mentioned, this is primarily a set of
workin notes.
Premises:
No such system is perfect. This system is in particular very
imperfect. The definitions that humans use to define their
relationships, preferences and value sets are subjective and
contextual. This system cannot and does not attempt to reflect
such concerns. Instead, this system merely attempts to provide a
method which allows relationships to be recorded as a set of
"rights granted", and for subsequent manipulation of those granted
rights by manipulation of the records of the granted tokens.
This is not Challenge/Response:
This is not about challenge/response systems, does not require or
define a challenge response system and in fact has little to do
with challenge response systems. That said, a challenge response
system could trivially be used in close cooperation with this
system.
This system describes how consent tokens can be encoded in
messages, manipulated by messages and MUAs, and otherwise used.
It does not state the processes required to generate a consent
token, either on the part of the humans involved, or the software.
Challenge response systems could be used, but are not required.
This is not PKI or crypto:
There is no need or requirement in this system for crypto or PKI
beyond a possible use of one way hashes in constructing consent
tokens. There is also no need or use of custom DNS entries at any
point in the system.
Basic model:
People can agree, explicitly or tacitly, to accept email from each
other. To express this agreement they give each other tokens
which we'll call, "consent tokens". Subsequent email from each
party bears the token the other gave them, thus demonstrating that
they are someone who has been granted permission/consent by the
recipient.
Very loosely the model can be described as, "Here is a special
key. When you see me a again, bring this special key with you
so I can recognise you."
To a large extent the possession of the token could be considered
a "what you know" in the standard security model of
identification. To prevent replay/spoof attacks, the consent
tokens may contain (implementation dependent detail) one way
hashes of key difficult to forge data, like Return-Path and From:
(both), thus providing an easy method of validating a token in a
given message against the message.
The following proposal discusses how such tokens may be defined, how
they can move between people's systems, and thusly, how they may be
used.
Purposes:
The fundamental purpose of the consent token protocol is to allow
messages to be identified as consensual or not. By this is meant
that the recipient of the message can determine if a given message
he receives is a continuation of a prior relationship which he
approved of, or is a message from a stranger or unwelcome source.
Attempts to deduce consent by any other means than, "continuation
or expansion of prior relationship" is not addressed by this
protocol.
Requirements:
Resistant to forgery and obvious attempts to evade, manipulate, or
compromise.
Does not require PKI.
Friends must be able to easily email friends.
People must be able to establish consensual relationships.
People must be able to encode tentative consensual relationships
for things like printed media, business cards, and the like.
Mailing lists must work, well.
Replies to a prior post must be able to be recognised as such.
Email sent to an address provided by means other than SMTP (eg web
based subscription or response to web-base marketing) by the
service the address was passed to should not be interfered with.
The protocol should be friendly to people using software and
systems which DON'T support the consent token protocol, and should
fail gracefully for those using non-supporting systems.
Throw-away addresses should be easy (eg for use in posted small
ads, conference registrations, etc) and should not require ISP
involvement.
Consent Token Definition:
A consent token is a 7-bit clean string which is assumed to be
opaque to everyone but the author of the token.
Opacity in this regard simple indicates that meaning can be
extracted from the consent token string by the creator of the
token, but that no such meaning is necessarily (reliably)
derivable by others. Opacity is not a requirement of a consent
token, but is easy to achieve and has a number of values when
present.
The basic use of a consent token is as a frank on messages sent to
the originator of the token to show that you are party to the
shared secret encapsulated in the token.
What this proposal defines:
When and how consent tokens are originated.
When and how they may be requested.
How consent tokens can be used to facilitate naturally friendly
human communication.
How the protocol supports maintenance of consent tokens.'
The consent token protocol is not intended to define:
How a consent token is constructed.
What a consent tokens looks like (beyond being a 7bit clean
ASCII string suitable for use in email addresses and
Message-IDs).
How meaning is encoded into a consent token.
How meanings are to be encoded into consent tokens.
Loosely, this is a definition of a means of transport, not what
the transport may carry.
Note however that a number of basic "meanings" are suggested for
consent tokens, and are used to exemplify and illustrate how the
consent token protocol functions. These are however
implementation specific details that are beyond the scope of this
article, and are used for illustrative purposes only.
Consent token types used in discussion and possible implementations
of types:
Intellectually this proposal is built on the work of TMDA and its
use of special strings encoded in plus address to encode various
forms and levels of consent. It is strongly suggested that
readers review TMDA, its capabilities, and in particular the
various forms of consent TMDA can encode.
For the purpose of this article the following forms are assumed
encodable in a consent token.
- The token is valid for mail from a specific Return-Path
(called a "sender address token").
- The token is valid for mail from a specific From: (called a
from address token).
- The token is valid for mail for a specific date range from the
time of origination of the token (called a "dated token")
- The token has no validity criteria, but does encode a value
(typically a word or some other human-useful character sequence)
which can be used to differentiate it from other always valid
consent tokens (called a "keyword token").
In addition all the above types may be combined in the various
permutations, producing such things as a, "dated sender and from
address token", or a "dated keyword token", and so forth.
A given token type, embedded in an email address, creates an
address of that token type. eg a dated address, a sender address,
etc.
A simple way of encoding such data is via an one-way hash of the
relevant data with a secret. A received token is first parsed to
see what sort of data is encoded in it, the relevant data is then
extracted from the message, and a duplicate token computed using a
constant secret. If the two tokens match, then the stated consent
relationship is validated.
Note: TMDA has a rather clear implementation of this sort of
arrangement for almost all of the above token types.
Please note that these are are not required consent token forms,
they are merely used as models and examples in showing how the
consent token protocol works. Implementations may freely choose
their own consent token definitions and encodings. None of the
above are necessary for the protocol.
Acting on Consent Tokens:
This proposal does not define how a supporting MUA will act upon
consent tokens it successfully or unsuccessfully validates. There
re many possibilities and this is one of the many areas left as an
implementation and end-user configuration choice.
Several possible handlings are envisioned for messages with tokens
that fail to validate:
- Message is rejected/bounced.
- Message is discarded silently.
- Message is held pending a successful response to a challenge
response system.
- Message is filed by the MUA in a location or with an
annotation that its token is bad (there could be several
grades of such annotations, for example depending on how far
expired the dated token was)
- Message is filed normally.
As there are many possible types and degrees of consent token
validation failures, the number and range of possible responses
could be equally large. This is a question for end-user
implementation and configuration, as it doesn't affect or define
the protocol.
Note that this ground has already been partially explored by
TMDA. Additionally its also very easy to build complex and
rather arcane systems using consent tokens, as the TMDA
documentation amply shows. The intent of this protocol is not
to require such complex systems, but to build a very simple base
that people can use and adapt as they need and want.
Consent Token Embedding:
Consent tokens are encoded in three basic places:
1) Message-IDs.
2) Plus addresses (care is taken to make this human-friendly)
3) A small range of X- headers for specific protocol state
transforms.
Note:
Tokens are encoded in email addresses (or Message-IDs which are
like email addresses) as plus addresses. In particular consent
tokens are not dealt with as discrete items by anything other
than the system which generated that specific token and bearing
address. As far as recipients are concerned, a token can be
considered inseparable from its bearing email address. More
particularly, it is assumed that there is no necessarily
reliable way for a third party to examine an arbitrary address
which is carrying a consent token (via plus address) and
determine which bits are the consent token and which the base
address.
No definitions are made about how plus addressing is to be
accomplished or what plus addressing character is to be used.
That is an implementation detail that only concerns the
receiving MTA and MUA in that they have to be able to recognise
addresses for delivery (MTA) and to extract consent tokens for
analysis (MUA). It has no bearing or relation to the rest of
the world, and is outside of this protocol definition. That
said, typical choices for plus address characters are '+' and
'-'. The TMDA FAQ contains a useful commentary on the use of
each and their impact on currently deployed mail systems.
Use of Message-IDs:
The use of consent tokens in Message-IDs provides the ground work
that much of the rest of the system is built on. A supporting MUA
will:
1) Encode a Message-ID which contains a consent token in every
message it originates. As Message-IDs have the same structure
and encoding limits as email addresses, a plus addressing form
may be used to encode the consent token into the Message-ID
value.
The explicit assumption here is that subsequent systems will
not remove or alter any Message ID so defined. This is
already known to be an unreliable assumption. Specifically
some list servers on broadcasting a message will generate a
new Message-ID for the broadcast message. This is explicitly
allowed by current standards, but is censured by this
protocol.
Note that the meaning encoded into the consent token is an
end-user configuration, but would likely be either a dated
token, a keyword token, or a dated keyword token.
2) Check the Message-IDs in the In-Reply-To and (optionally)
References: headers, and extract and check any consent tokens
from the current system.
The assumption here is that replies to a message generated
by the local system will have a correct In-Reply-To header,
and that subsequent messages in the thread will have correct
References: headers. These assumptions are known to be
unreliable. Some commonly used MUAs don't generate
In-Reply-To or References headers at all.
3) Correctly generate In-Reply-To: and References: headers for
replies.
In the handling of consent tokens in sending mail to addresses
which have extant consent relationships there are three choices
here, none fully elegant. The local system can rewrite the public
headers (To:, Cc:, Bcc:) to use a plus-address provided by the
other end of the consent relationship, an X- header can be used to
encode the token on a per-address basis, or the SMTP envelope can
be set by those MUAs which speak SMTP to use the appropriate
consent tokens.
Taking them in reverse order:
Encoding the consent tokens in the envelope runs into the
problem that there is no standardised way for LDAs and MDAs to
encode Envelope-To: in a message for MUA processing. Envelope
encoding is also fragile across .forwards and aliasesq, and this
system needs to be robust in those cases.
Encoding the consent tokens in X- headers is effective, but has
the slightly displeasing problem of encoding BOTH the flat
version of the address and the tokenised version of the address
in the same message, which is an unwelcome information leak fir
third parties, and acts as a tacit consent for addresses bearing
consent tokens to be sent to third parties, uninvolved in the
relationship expressed by the consent token.
Principle: The only people who should ever see an address
bearing a consent token are the people involved in the
relationship expressed by the consent token.
Rewriting the public headers to encode the consent tokens can be
offensive if consent data is encoded in headers of a message to
sent to someone outside of the relationship. Using the
consensual forms of an address in public headers to someone
outside of the relationship creates a utility problem in that it
makes published a consent address as if it were a base address
for those people. Not good.
Some explanations via example
For example if a given message is sent to Bubba and CC'ed to
Boffo:
From: me(_at_)domain
To: bubba(_at_)domain
Cc: boffo(_at_)domain
The system could rewrite all the headers at once:
From: me(_at_)domain
To: bubba+consent-token(_at_)domain
Cc: boffo-consent-token(_at_)domain
This presents a problem. If Bubba wants to privately email
Boffo, and he didn't previously know him or his address, he's
going to email boffo-consent-token(_at_)domain which is wrong, as
Boffo's system will fail to validate the consent token if it
was unique to me(_at_)domain
Ergo, the correct behaviour is to send to discrete messages,
each with separately rewritten headers:
1) Envelope-To: bubba+consent-token(_at_)domain
From: me(_at_)domain
To: bubba+consent-token(_at_)domain
Cc: boffo(_at_)domain
2) Envelope-To: boffo-consent-token(_at_)domain
From: me(_at_)domain
To: bubba(_at_)domain
Cc: boffo-consent-token(_at_)domain
This way each recipient sees the "public" forms of the
addresses for other people he expects/recognises, and the
consent-token address for himself that his system recognises.
Notes:
This effectively requires that MUAs not deliver mail via
`sendmail -t`, and instead only use SMTP or `sendmail -bm`.
This makes some forms of system optimisation more difficult
(RCPT TO bundling).
The problem with rewriting the public headers for the current
recipient is that there are no public headers for the current
recipient in the case of a BCC (such as in the mailing list
case). In the BBC case the consent token has to be encoded
somewhere else, such as in an X- header.
Use of X- Headers as a Command Layer:
X- headers are fundamentally useful for negotiations in the
consent protocol. A core problem is that the consent token
protocol needs to usable by end-user systems which don't support
it, across language barriers, and across human disability
barriers (eg blind). The problem then is to encode data into a
protocol negotiation message which can be reliably machine
parsed so that a supporting MUA can Do The Right Thing, while
also encoding human-comprehendable data in the same message so
that humans using non-supporting systems can process the message
intelligently and usefully.
The basic idea here is that the machine parse-able data is
encoded in canonical forms in defined X- headers, leaving the
message body free to contain something human friendly, which can
be adapted to foreign languages, users with disabilities,
suitably localised, etc. In this line the message body would
communicate the meanings of the below X- headers as appropriate.
Note: By default, messages between consenting parties will
need no special X-headers to express the consent
relationships, as that data is encoded in the rewritten public
headers on each message.
The basic consent token negotiations (ie the arcs on the finite
state machine graph) are:
1) Grant/send a consent token
2) Request a consent token for the sending address.
a) Request a consent token for a third party address.
3) Update/change an already granted consent token
4) State that a previously granted consent token has been
revoked.
5) State that a received message has failed consent validation
(for whatever reason).
6) Apply a consent token to a previously received message
which didn't bear a token (or bore an invalid token).
The lexicon of consent token protocol X- headers is:
X-Consent: <address(_at_)domain>
States the consent-token address which can be used in future
correspondence. A receiving MUA should update its internal
data with this address so that it can automatically
substitute it in future mail sent to the address in From:.
User's of not-supporting MUA's can manually enter the
address into their email aliases/list so that their MUA can
do the Right Thing at alias expansion time.
X-Consent-Token: address
In the case that the recipient of the message is not present
in the To: or CC: headers (ie a BCC), meaning that no
there's no direct opportunity for encoding a consent token,
the consent token address used may be placed in an
X-Consent-Token: header for the BCC'ed address. The
__ONLY__ time an X-Consent-Token: header should be used is
for BCC's to the receiving address. Use of this header in
all other cases is an error.
Note: In the case where a mailing list sends a message to
an address which is already present in the public headers
(eg courtesy copy), an X-Consent-Token: header should be
used as, as those headers don't apply to this instance of
the message over this transport.
X-Consent-Update: <address(_at_)domain>
Explicitly states that the receiving MUA should discardand
previously acquired consent token for the address and
replace it with this header's value. A receiving MUA should
update its internal data with this new consent token address
for future use. Note that the received message should have
a validating consent token to update. Users of
non-supporting MUAs can manually update their email alias
lists.
Typically this header would be used when upgrading someone's
consent token to a more privileged form (eg extended or
changed date range, removal of date range etc). This header
should only be used on messages which contain no other data
(ie messages which are dedicated to handling a token update)
so that receiving systems can be safely configured to handle
then automatically.
X-Consent-Request: from(_at_)domain return-path(_at_)domain
States that the sender wants a consent token address from
the recipient, and encodes the value of From:/Return-Path:
that may be used in encoding the consent token (token
generator's choice as to what data he uses if any).
Typically a reply to a message bearing this header will
contain an X-Consent: header. Depending on implementation
and end-user configuration, this may happen automatically,
or after an end-user confirmation or some other process such
as a challenge/response.
X-Consent-Request-For: <address(_at_)domain>
A message bearing this header requests that a message
containing an X-Consent: token grant be sent to the stated
address. Note that received message should bear a
validating consent token.
This header should only be used on messages which contain no
other data so that receiving systems can be safely
configured to handle such requests automatically.
X-Consent-Revoked: <address(_at_)domain>
Tells the recipient MUA that the stated consent token
address has been revoked and should not be used any more.
If it is accompanied by an X-Consent: header, this is
effectively analogous to an X-Consent-Update: header. Note
that the received message should have a validating consent
token.
This header should only be used on messages which contain no
other data (ie messages which are dedicated to handling a
token update) so that receiving systems can be safely
configured to handle then automatically. The receiving MUA
is of course not obliged to honour the request. This is an
informational header only. Enforcement and application of
token semantics occurs with the MUA that originated the
token.
X-Consent-Release: message-id
Instructs the receiving MUA to consider that a message with
the stated Message-ID is carrying the consent token that the
current message is carrying. Note that message bearing this
header should have a validating consent token,.
This header should only be used on messages which contain no
other data (ie messages which are dedicated to handling a
token update) so that receiving systems can be safely
configured to handle then automatically. Typically this is
used in automatic (unattended) response to a message with an
X-Consent-Held: header. See below for details.
X-Consent-Held: message-id
Typically sent to the Return-Path: of the received message,
optionally with the held message attached as a
message/rfc822 part (useful if the sender doesn't have a
consent token for the recipient, unnecessary if he does have
a consent token for the recipient), this header tells the
receiving MUA that a message with the stated Message-ID is
being held or potential-spam-filed etc due to consent token
failure or absence.
This header, along with X-Consent-Release: can form (not
required) the grounds of a basic fully-mechanised consent
token challenge/response system. If the received message
bears a validating consent token, the receiving MUA can
safely reply with an X-Consent-Release: header. If the
received message doesn't have a consent token, then the
receiving MUA may present the choice to the user or act as
configured by the user.
This header should only be used on messages which contain no
other data (ie messages which are dedicated to handling a
token update) so that receiving systems can be safely
configured to handle then automatically.
Deployed MTA requirements:
Deployed MTAs would require the following configuration aspects:
1) Support for plus addressing. Happily all current versions of
all common MTAs support plus addressing, and have done for
several years.
2) Do not replace MUA-generated Message-IDs.
3) Encode the return path from the message envelope in a
Return-Path: header in the received message. Exim and I'm told
Qmail do this by default. I've not yet checked other MTAs.
Examples:
Note that in the folloing examples the string "consent-token" is
mean to indicate the prsence of some form of consent token. It
states nothing about the value of the token, or how it relates to
other values of "consent-token".
Bubba emails Boffo (a stranger) requesting help:
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: boffo(_at_)domain
X-Consent: <bubba+consent-token(_at_)domain>
Message-ID: <bubba+consent-token+someothergarbage(_at_)domain>
Subject: Please help me.
Boffo has is his mail forwarded to weird_address(_at_)domain, and
further, doesn't use a an MUA which supports the consent token
protocol. He replies:
Return-Path: weird_address(_at_)domain
From: weird_address(_at_)domain
To: bubba(_at_)domain
In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
Subject: Re: Please help me.
Bubba's MUA doesn't recognise the weird_address(_at_)domain, but does
recognise the Message-ID in the In-Reply-To: and successfully
extracts the consent token from it and handles appropriately.
Bubba emails Bernie (a stranger) requesting help:
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: bernie(_at_)domain
X-Consent: <bubba+consent-token(_at_)domain>
Message-ID: <bubba+consent-token+someothergarbage(_at_)domain>
Subject: Please help me.
Bernie has is his mail forwarded to some_guy(_at_)domain, and
further, uses an MUA which supports the consent token protocol.
He replies:
Return-Path: some_guy(_at_)domain
From: some_guy(_at_)domain
To: boffo+consent-token(_at_)domain
In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
X-Consent: <boffo-consent-token(_at_)domain>
Subject: Re: Please help me.
Bubba's MUA doesn't recognise the weird_address(_at_)domain, but does
recognise the consent token address in the To: field, and
successfully extracts and handles the consent token. Further,
Bubba's MUA notices the X-Consent: header that Bernie's MUA
added, and sores that address away for future use so that the
next message Boffo sends Bernie will automagically be sent as
follows (even tho Bubba enters bernie(_at_)domain):
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To:: boffo-consent-token(_at_)domain
X-Consent: <bubba+consent-token(_at_)domain>
Subject: About something else...
Bubba wants to setup a consensual email relationship with Billy
(a stranger):
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: billy(_at_)domain
X-Consent: <boffo+consent-token(_at_)domain>
Message-ID: <boffo+consent-token+othergarbage(_at_)domain>
X-Consent-Request: bubba(_at_)domain bubba(_at_)domain
Subject: Let's work together
Billy's MUA doesn't support consent token negotiations, and so
he sees (lame attempt at an example human friendly message
body):
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: billy(_at_)domain
X-Consent: <boffo+consent-token(_at_)domain>
Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
X-Consent-Request: bubba(_at_)domain bubba(_at_)domain
Subject: Let's work together
bubba(_at_)domain would like to exchange email with you in a
trusting spam-free way. If you want to send mail to him in
future, please use the following address:
boffo+consent-token(_at_)domain
bubba(_at_)domain's email system will automatically recognise mail
sent to that address as from you and not forged or spam.
What address would you like bubba(_at_)domain to use in emailing
you? Please reply with the particulars. If you'd like
bubba(_at_)domain to continue using the address this message was
sent to, billy(_at_)domain, you don't have to do anything.
If Billy used an MUA which supported the protocol, his MUA would
recognise the X-Consent-Request header and act upon it. It
could query Billy for the appropriate action (perhaps by pop-up
dialog), or if configured to, perhaps even reply automatically
with a consent token with a short date range validity (say 2
days).
Bubba subscribes to a mailing list run by a list manager which
supports the consent token protocol:
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: list-request(_at_)domain
X-Consent: <boffo+consent-token(_at_)domain>
Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
Subject: subscribe
Return-Path: list-admin(_at_)domain
From: list-admin(_at_)domain
To: bubba+consent-token(_at_)domain
In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
X-Consent: <list-admin-consent-token(_at_)domain>
Message-ID: <list-consent-token+someothergarbage(_at_)domain>
X-Consent-Request: list(_at_)domain list(_at_)domain
Subject: Please confirm your subscription by replying
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: list-admin-consent-token(_at_)domain
X-Consent: <boffo+consent-token(_at_)domain>
Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
In-Reply-To: <list-consent-token+someothergarbage(_at_)domain>
Subject: Re: Please confirm your subscription by replying
Note how the consent tokens are automatically negotiated and
maintained without the human user's involvement. The user's MUA
primes the pump (and thus tells the list manager that he
supports the consent protocol) by having an X-Consent: header in
the initial subscribe message. Similarly, the list server
primes the pump for the user's MUA by providing the relevant
details in its X-Consent-Request: header so the MUA can reply
with a suitably generated consent address, potentially using
that data.
Bubba subscribes via web form to a mailing list run by a list
manager which supports the consent token protocol:
Your email address: bubba(_at_)domain <SUBMIT>
Return-Path: list-admin(_at_)domain
From: list-admin(_at_)domain
To: bubba(_at_)domain
X-Consent: <list-admin-consent-token(_at_)domain>
Message-ID: <list-consent-token+someothergarbage(_at_)domain>
X-Consent-Request: list(_at_)domain list(_at_)domain
Subject: Please confirm your subscription by replying
Return-Path: bubba(_at_)domain
From: bubba(_at_)domain
To: list-admin-consent-token(_at_)domain
X-Consent: <boffo+consent-token(_at_)domain>
Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
In-Reply-To: <list-consent-token+someothergarbage(_at_)domain>
Subject: Re: Please confirm your subscription by replying
Again the consent process is kicked off in the initial mail
transaction with all the tokens being generated and tracked from
there. The fact that Bubba didn't provide a consent token via
the web form actually doesn't matter.
A list server upgrades to a new version which supports the
protocol. All that need happen is that X-Consent*: headers
start being injected in standard list traffic, with supporting
MUAs picking up the slack/line as they go, and the rest silently
not noticing (ditto for users that start using MUAs that support
the protocol):
Return-Path: list-bounce(_at_)domain
From: some_guy(_at_)domain
To: some_other_guy(_at_)domain, list(_at_)domain
X-Consent: <list-admin-consent-token(_at_)domain>
Message-ID: <some_guy-consent-token+someothergarbage(_at_)domain>
In-Reply-To: <some_other_guy-garbage(_at_)domain>
X-Consent-Request: list-bounce(_at_)domain list(_at_)domain
Subject: [LIST] Re: I heard a funny joke...
Requirement satisfaction:
Resistant to forgery and obvious attempts to evade, manipulate, or
compromise.
Answer: Consent tokens are encouraged to be one way hashes using
a per-user secret. Given reasonable choices for the hash
algorithm and secret size, compromise is difficult.
Friends must be able to easily email friends.
Answer: If they both use supporting MUAs, it all happens for
free. If they don't, then token encoding in Message-IDs takes
up most of the rest of the slack, with the encouragement for
them to enter the consenting addresses in their email address
books being used to fill the rest of the gap. If they don't use
their address books in this way, then the system is no worse
than it is currently.
People must be able to establish consensual relationships.
Answer: That's what the consent tokens do.
People must be able to encode tentative consensual relationships
for things like printed media, business cards, and the like.
Answer: Use of a simple plus address form can do this. For
example bubba(_at_)dom(_dot_)aim when hading his business card to a
colleague at a conference could quickly pen in an alternate
address to bypass his consent/spam filters:
bubba+word(_at_)dom(_dot_)ain(_dot_)
Its not a one-way hashed consent token, but if he uses a
different word every so often, and tells his mail system what
his current word choice is, it can and will cover a very large
part of the gap (personal experience).
Mailing lists must work, well.
Answer: See examples above. Very little changes with the
exception that mail to consent token supporting users becomes
per-recipient customised (header re-writing). This is a
marginal incremental cost over list servers that already use
VERP, but could be considered expensive by those that don't.
Replies to a prior post must be able to be recognised as such.
Answer: Encoding consent tokens in Message-IDs does this for
responding MUAs that properly generate In-Reply-To: and
References: headers. Currently broken MUAs continue to be
broken. For everybody else the world improves.
Email sent to an address provided by means other than SMTP (eg web
based subscription or response to web-base marketing) by the
service the address was passed to should not be interfered with.
Answer: See the list subscription case above. It does require
an additional round of email exchange to prime the consent token
pumps, but given the current mandate on double-opt-in, this
seems reasonable.
The protocol should be friendly to people using software and
systems which DON'T support the consent token protocol.
Answer: This is accomplished by requiring that specific arcs in
the FSM (ie token negotiations) occur via messages which don't
carry any non-token-related content. Because of this the
message payloads can be human-friendly and explanatory for
non-supporting MUAs (supprting MUAs will likely hide the message
entirely and either handle them automatically or present the
user with a custom dialog with help links).
Throw-away addresses should be easy (eg for use in posted small
ads, conference registrations, etc) and should not require ISP
involvement.
Answer: Dated addresses solve this need.
--<cut>--
--
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