Things that MTAs and MUAs can do differ radically.
Yes, that's true and you need both to deal with a wide variety of
consent-related policies.
B. each plug-in provides for some type of policy
definition, related
to the plugins purpose. This can range from filtering to CR
to all the
other methods mentioned below.
"Plug-in" worries me. At best it suggests an implementation
mechanism instead of a protocol notion. At worst it suggests
an intolerable security nightmare as is standard in commodity
desktop software.
You can call it something else if you want. But its pretty obvious to me
that a single-vendor, single-architecture solution will not solve the
entire "unwanted email" problem.
C. each plug-in can be configured by a hierarchy. Starting
w/ the ISP
(for instance), then perhaps a domain-level admin (for corporate
applications0 and then the end-user. We can decide on
varying levels
of defaults or override capability so that for example if an ISP
whitelists a source, the end-user may have the option to
blacklist it.
...
That needs to be made concrete in terms of protocols and
mechanisms so that it can be discussed by a technical group.
Agreed. Perhaps this group can start getting more specific on the
protocols and mechanisms.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg