on 6/3/2003 10:07 AM Dave Aronson wrote:
Iljitsch van Beijnum <iljitsch(_at_)muada(_dot_)com> wrote:
One way would be solicited == whitelisted. Remember that this is only
necessary for bulk mail. So everyone would need to create a
whitelist of all the mailinglists and newsletters they're subscribed
This could be eased somewhat with something I was trying to get at
earlier. This is separate from the idea of fixing or replacing SMTP,
or other spamfighting, but what I envision is some standard format of
data about a mailing list. (MLML, for Mailing List Markup Language?)
Upon reading this in an email or on the web, the user can take some
sort of action (click, reply, etc.), whereby he would be subscribed,
and his MUA would whitelist the address the email would come from (or
some other such tag, but usually the From addy so as to enable PGP-type
authentication). Something like:
First point is that whitelisting should be one of the optional "locks"
which are enabled by architecture, rather than being core features of any
service. Whitelists don't work for everybody (customer service desks, for
example) so they need to be optional, and there are probably going to be a
variety of whitelisting "applications" (such as what you describe in your
detail) that embedding any of them would make it difficult to develop
alternative whitelisting applications.
For these kinds of reasons, it would be best to provide architecture (in
particular, providing authenticated identity and end-to-end option
encapsulation), and then people could use whatever mechanisms they want
(including hashcash, e-postage, whitelist negotiation, whatever) within
their own administrative space according to whatever works for them.
Whitelisting and mailing-list automation services would be two different
applications, I think, although they should be able to communicate with
each other for the kind of reasons you cite.
Anyway, the overall point is that we should separate the applications from
the message-transfer network architecture and develop them in parallel,
making sure that the architecture can provide what the applications need
for successful deployment.
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/