RFC for List Message Header Fields
Folks,
I just discovered a new RFC for List Message Header Fields. Here is
the form letter for List Managers trying to drum up support for this
proposed standard. This idea seems to fit with the list-centric vs.
server-centric model that Mailman currently seems to be heading in.
However I have seen the *-subscribe and *-unsubscribe aliases before,
in LISTSERV which I think of as server-centric. Also, note the use
of *-request (in *-archive) as a conduit for commands, rather than
feedback for a human.
In any case, for what it is worth, here's that letter...
Cordially,
The List Server Admin
list.admin@unh.edu
(currently Bill Costa)[ http://www.nisto.com/listspec/letter-listmom.txt ]
This is a request for you to implement support for the List- header fields defined in RFC2369. This will make mail list access easier for your users.
<ftp://nis.nsf.net//internet/documents/rfc/rfc2369.txt>
The List- fields provide you with a standard method by which you can consistently describe your mailing lists' command syntax so that client applications can implement an interface to make list access easier for users.
As they are adopted and supported by email software developers, the List header fields will make it easier for users to interact with email lists.
The currently defined fields are List-Subscribe, List-Unsubscribe, List-Help, List-Post, List-Owner and List-Archive. They describe commands for subscribing, unsubscribing, retrieving help information, posting to the list, contacting a human administrator and accessing message archives.
For your list, the fields would appear as:
List-Subscribe: <mailto:list-request@server?Body=subscribe%20list> List-Unsubscribe: <mailto:list-request@server?Body=unsubscribe%20list> List-Help: <mailto:list-request@server?Body=help> List-Post: <mailto:list@server> List-Owner: <mailto:listmom@server?Subject=listname> List-Archive: <mailto:list-request@server?Body=archives>, <http://server/list-archive/>
Implementation guidelines for list managers and administrators are available at:
<http://www.nisto.com/listspec/list-manager-intro.html>
Extended details on the List header fields are available from:
<http://www.nisto.com/listspec/>
A mailing list for discussion is available at:
<http://www.nisto.com/listspec/mail> or <mailto:list-header@list.nisto.com?Subject=help>
Information on the format of mailto URLs:
<ftp://nis.nsf.net//internet/documents/rfc/rfc2368.txt>
Thanks!
[EOM]
fields defined in RFC2369. This will make mail list access easier for your users. : : List-Subscribe: <mailto:list-request@server?Body=subscribe%20list> List-Unsubscribe: <mailto:list-request@server?Body=unsubscribe%20list> List-Help: <mailto:list-request@server?Body=help> List-Post: <mailto:list@server> List-Owner: <mailto:listmom@server?Subject=listname> List-Archive: <mailto:list-request@server?Body=archives>, <http://server/list-archive/>
Perhaps its just me but I find the use of URL's in the headers disturbing.
Darren Henderson darren@jasper.somtel.com
Help fight junk e-mail, visit http://www.cauce.org/Perhaps its just me but I find the use of URL's in the headers disturbing.
Good point. When I looked at it, I thought they were using it as
just a short hand -- i.e. this address, this command in the message
body. But maybe not.
Cordially,
The List Server Admin
list.admin@unh.edu
(currently Bill Costa)
On Wed, 24 Mar 1999, Darren Henderson wrote:
Perhaps its just me but I find the use of URL's in the headers disturbing.
Can you quantify that objection? Ie. can you explain what about it disturbs you?
It would seem to me to make automated unsubscriptions extremely simple on the part of the MUA, especially considering that most modern MTAs (Pine, Mutt, nearly every graphical client, etc) have support for at least parsing URLs at this point. Hence, getting this kind of feature to an easy-to-use point in MUAs should be extremely simple.
But maybe someone has a better way of representing it (without inventing a new notation standard) such that it's still machine-parsable?
-- Edward S. Marshall <emarshal@logic.net> [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ]
Linux labyrinth 2.2.3-ac4 #2 Sun Mar 21 13:08:37 CST 1999 i586 unknown
9:45am up 2 days, 18:06, 3 users, load average: 0.29, 0.18, 0.12On Wed, 24 Mar 1999, Edward S. Marshall wrote:
On Wed, 24 Mar 1999, Darren Henderson wrote:
Perhaps its just me but I find the use of URL's in the headers disturbing.
Can you quantify that objection? Ie. can you explain what about it disturbs you?
It would seem to me to make automated unsubscriptions extremely simple on the part of the MUA, especially considering that most modern MTAs (Pine,
I can try though some of it boils down to a philisophical position.
Email is not the web the web is not email. I don't like bluring the distinction. It assumes a lot about about users and the state of the world. It may lead people to think that embeding html in email is a good thing.
While a lot of people use netscape etc to do mail a lot of people don't. Yes, the latest versions of pine have the capability of dealing with urls but the older ones don't and a lot of sites aren't upgrading.
Most people see their mail with a limited number of headers, these won't be visible to them. Yes they can look at the other headers but most don't know too. Eventually mua's could be altered to display those paticular headers by default as it stands currently I don't think any of them do.
No earth shattering reasons really. Mostly personal preference I guess.
Darren Henderson darren@jasper.somtel.com
Help fight junk e-mail, visit http://www.cauce.org/
Darren Henderson wrote:
Email is not the web the web is not email. I don't like bluring the distinction. It assumes a lot about about users and the state of the world. It may lead people to think that embeding html in email is a good thing.
I concur, sort of. E-mail services should have e-mail methods to operate. In the same time, those having reliable access to the web would benefit from list software supporting web-based administration. What I think they tried to achieve by using URLs in the headers was to allow a richer description of what's required to do to stuff, like what address, what to write as subject, what to write in the body, and such. Of course, URL is not useful for WWW only. It's a pretty generic format for all kinds of network services. E-mail is a sort of a network as well, no? The big win using a standard format like URL is that it can be interpreted by a machine, and used to automate services like subscription and unsubscription. Today, as a user, you mostly have to guess the behavior of each type of list software. I missed one optional header though: List-URL for the list homepage.
Tomas
Darren Henderson <darren@jasper.somtel.com> wrote:
Email is not the web the web is not email. I don't like bluring the distinction.
That's an interesting POV for a Mailman user.
It assumes a lot about about users and the state of the world. It may lead people to think that embeding html in email is a good thing.
Embedding html might well be a bad idea, but it's inevitable. Whatever minor encouragement the List-* headers provide will be insignificant in the grand scheme of things.
While a lot of people use netscape etc to do mail a lot of people don't. Yes, the latest versions of pine have the capability of dealing with urls but the older ones don't and a lot of sites aren't upgrading.
URL's, especially mailto URL's, are human-readable. If you're going to put an e-mail address in a new header, why not do it as a URL so a few more users will be able click them and avoid copying errors and tedium?
Most people see their mail with a limited number of headers, these won't be visible to them.
This is a new standard. A few years down the road, if it catches on, these headers won't be hidden--or, if they are--the MUA will have an "Unsubscribe from list" button that will Do The Right Thing.
Yes they can look at the other headers but most don't know too. Eventually mua's could be altered to display those paticular headers by default as it stands currently I don't think any of them do.
So you argue against them because MUA's don't support them? Catch 22.
-Dave
participants (5)
-
Darren Henderson -
Dave Sill -
Edward S. Marshall -
The List Server Administrator＠UNH -
Tomas Fasth