on 6/3/2003 10:07 AM Dave Aronson wrote: > Iljitsch van Beijnum <iljitsch@muada.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 >> to. > > 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/