Jon Kyme wrote:
Wouldn't a standard way of communicating consent between the MUA and MTA
help?
I'm not convinced that we need anything beyond what we already have. (And
non-compliant points in the path are STILL going to need to map any
"extended
result codes" to one of the current basic set of results anyhow).
Let's put it like this:
Would it be a "good thing" to reject unwanted mail as near the sender as
possible?
yes / no
Will it be impossible (in most cases) for a recipient to directly configure
an upstream MTA
yes / no
Will MUA / MTA be from a diverse set of vendors
yes / no
If you answered mainly "yes" then you'll likely need a standards based
consent /policy expression do-dad.
If you answered mainly "no" then you'll need to think about the problem
more.
The "end-to-end consent" systems are particular cases of the general
"consent in the MTS" question. If you don't believe that end-to-end consent
is workable or required (although the consent-token / proof-of-work / CR
crew will disagree with you) - you're still left with the general question.
Just wanted to add that the notion of consent in messaging is not new.
Various Instant Messaging (IM) systems have that notion although not as
detailed as we are planning on doing in email. EVEN though most of
today's IM systems are run by a single service provider, Jabber and
similar systems do not. Also, the IETF IMPP WG defined a bunch of RFCs
and IDs for IM services that operate on many servers - kind of like the
current email system. For example, take a look at RFC 2778, in
particular the section 4 - "Security Considerations":
<snip>
This document provides a model and vocabulary for systems with
certain intrinsic security issues. In particular, presence and
instant messaging systems must deal with "the three S's": STALKING,
SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER
INFORMATION are intended to deal with STALKING. The several kinds of
authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE
SERVICE are intended to deal with SPOOFING. DELIVERY RULES are
intended to deal with SPAM.
<snip>
With the three problems being a subset of our issues as follows (the
spam definition might be useful for us as well):
<snip>
o SPAM: unwanted INSTANT MESSAGES.
o SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.
o STALKING: using PRESENCE INFORMATION to infer the whereabouts of a
PRINCIPAL, especially for malicious or illegal purposes.
<snip>
They use several mechanisms to address these problems. While STALKING is
not an issue for us, SPAM and SPOOFING is. The following mechanisms are
used for controlling SPAM and SPOOFING which are similar to the consent
rules we discussed some time ago within the consent framework:
<snip>
o DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE
delivers received INSTANT MESSAGES to INSTANT INBOXES. For each
INSTANT INBOX, the applicable DELIVERY RULES are manipulated by
the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT
INBOX.
Motivation: We need a way of talking about filtering instant
messages.
o INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES.
-- May require authentication of SENDER USER AGENTS and/or INSTANT
INBOXES.
<snip>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg