Components of a solution:
1. consent expression
2. policy enforcement
3. source tracking (authentication/identification/non-repudiation)
-does the consent-based communication viewpoint sufficiently generalizes the
problem?
It seems like a stretch of the way 'consent' is normally used. One aspect of
it with which I agree is that spam is in the eye of the beholder. We
probably do not want a system that presumes that certain kinds of content are
spam. It's not clear to me whether we even want a system that allows
recipients to declare 'consent' for certain kinds of mail and that permits
upstream filtering of their mail that doesn't meet those criteria. I can see
where such a system might be useful, but I doubt that it would be a good idea
to rely on it as the only mechanism for reducing spam.
-do the three components cover the requirements?
It's too early to tell.
I suspect that 'consent expression' (if I understand what it means) is
essential to any approach that allows filtering of messages prior to delivery
of messages to the recipient. I don't want some upstream MTA filtering mail
that is sent to me without my consent.
'Policy enforcement' as defined in the charter seems to me to be too
restrictive. I am not going to trust a remote MTA operated by another ISP to
'enforce policy' for me. Here's another way to think of it: it might be
useful to have a feedback path from recipients into the message transfer
system (MTS) which helps the MTS prioritize traffic so that the MTS does not
waste resources transmitting mail (or by extension, waste resources that
recipients use in dealing with mail that is delivered) which will not be read.
Similarly, there's no need for the MTS to immediately deliver mail which the
recipient is not willing to immediately accept.
And *some* kind of 'source tracking' (but not necessarily authentication,
identification, or even non-repudiation in any strong sense) is essential to
any approach that tries to penalize or marginalize those who send spam
(regardless of the granularity with which this is done). But it's not yet
clear whether we should recommend this as part of the solution.
I think these are fine as examples as possible components (as indicated in the
charter), but we should not expect a priori that these are the only components
or even that all of the above will be necessary. Which is not to say that I
disagree with them, just that the charter should not anticipate the outcome of
the group.
Milestones/Deliverables:
1. problem statement/ requirements document
2. taxonomy of existing approaches
3. taxonomy of proposed approaches
4. evaluation of existing and proposed approaches ( to include usefulness,
monetary cost, affect on normal use of email, legal support of the solution
and vice versa)
5. transfer of technology (possibly through standards proposals to the IETF)
Please, please, please, let's take the word "requirements" out of #1. It's
bad enough that working groups get caught up in trying to define requirements
of problems they do not understand. We're not even a working group. If
we identify a couple of requirements in the problem statement that we can all
agree on, that might be okay. But focusing on requirements will tempt us to
nail too may things down, and invite ratholing.
I suggest that 2 and 3 be combined, with a clear indication of which
approaches are existing and which are merely proposed - partially because I
think it will be more useful to have all of the approaches side-by-side, and
partially because I think existing/proposed is a spectrum rather than a bit.
I am seeking individuals that are interested in taking a more active role in
managing one of the first four deliverables mentioned above.
I've informally started trying to do 2&3 already with the idea of producing a
draft after a couple of iterations on the list.
Keith
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg