ietf-asrg
[Top] [All Lists]

Re: [Asrg] A New Plan for No Spam / Velocity Indicator

2003-04-27 20:24:13
On Sun, 27 Apr 2003 16:41:15 -0700 
Phillip Hallam-Baker <Hallam-Baker> wrote:

I don't see the validity of the argument.  The problem is mta
filtering, so the mua issue is moot. If the message gets to the mua
this problem is solved.

I disagree rather explicitly.

Spam is an inherently subjective definition that can easily be
subjective to and specific to a particular message.  More simply in
defining consent, it is the user of the MUA who defines, communicates
and arbitrarily waives or enforces his consent rules, not the MTA.  The
MTA can be an agent of the human, but the human trumps, and in all cases
is the final arbiter.  The human user might communicate his consent
rules to the MTA for more efficient processing, but the root remains the
human behind the MUA, not the service provider's.

These aspects convince me that consent definition and enforcement has to
occur at the MUA level.  Its the closet point to that fickle and
technology-ignorant luddite human.  Certainly the rules etc can be
communicated up to the upstream MTA for efficiency, but that's not
actually required for correct operation -- its just an attractive
option.

Equaly people who upgrade their mta filters are going to upgrade their
mta if that is required.

My current thoughts lead me to classify end users into two camps: Those
that can natively support a formalised consent definition, and those
that can't.  As that choice, as above, is to be made at the MUA level,
the only requirement of the MTA then is that it be configured such that
the consent expression "payload" (for want of a better term) can
actually get thru and reach the end user's MUA for appropriate
processing.

I've been beating on this particular point for weeks, and the only
reliable transport I can come up with is variants of plus addressing,
but I'll post more on this soon as I finish scraping time together for a
consent token protocol proposal which is layered atop SMTP and RFC 2822
without violating either.

I doubt that 2822 would have specified anything that broke legacy
systems.  So it appears to me that we have a solution here.

The problem is how a consent token expressed at initial MTA delivery
time can be received, extracted, verified, and analysed, umpty MTA
transitions later, perhaps on a disconnected system, when it finally
reaches the MTA immediately upstream of the human user (ie the one the
human user has the ability to communicate his consent preferences to).

Unless I'm blind or careless (very possible) I don't see that there is
any currently standard way for extended RCPT TO semantics to be encoded
in the resultant message or its envelope for subsequent downstream
receipt and processing, or that one could be defined and deployed
without requiring widescale NTA __and__ MUA upgrading.

-- 
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