[Mailman-Users] List-* headers

[sigma at pair.com]

I agree completely with the purpose and the future direction.  I intend to
explain the matter to our customers and encourage them to try to adopt the
new headers.

But what they see right now are two full screens of headers before the
actual message, and that's what *their* users see, and it trickles back to
us as dissatisfaction.  I want to be able to provide an option for each
list to disable these headers, at their own risk.

It's similar to how reply_to_list is considered harmful, but is still
supported because it's useful in some situations.  The RFC reflects this,
in that the List- headers are optional but encouraged.  Hopefully mail
clients will be catching up to the RFC - functionality can be added to
clients without any downside.

Thanks,
Kevin

----- Forwarded message from Chuq Von Rospach -----

>From chuqui at plaidworks.com Wed Dec 06 18:14:59 2000
Delivered-To: sigma at smx.pair.com
Delivered-To: sigma at pair.com
Message-Id: <p04330100b6543218ed3b@[17.216.27.234]>
In-Reply-To: <Pine.BSF.4.30.0012061159430.3081-100000 at qenni.pair.com>
References: <Pine.BSF.4.30.0012061159430.3081-100000 at qenni.pair.com>
Date: Wed, 6 Dec 2000 10:13:09 -0800
To: Matt Singerman <m at whiteywillpay.net>,
   "Sarah K. Miller" <techgrrl at beeze.com>
From: Chuq Von Rospach <chuqui at plaidworks.com>
Subject: Re: [Mailman-Users] List-* headers
Cc: <sigma at pair.com>, <mailman-users at python.org>

I strongly recommend you NOT do this:

he RFC for the list-* headers is RFC 2369. the purpose of those 
headers is to allow people who run mail lists to embed information so 
that mail clients can automate process for their end users -- whether 
it's setting up an "unsubscribe" button or creating a URL for a user 
to click to get list help. it's a new standard, but it solves a HUGE 
problem for mail list systems, which is how to help users get access 
to list-administration options, since we all know pretty much the 
only people who DO keep those "welcome" messages are the people who 
don't need them anyway.

Support for these headers in clients is still primitive at best, but 
it's a new, important standard, and if the list servers don't support 
it, there's no impetus for the mail client authors to do so, so MLMs 
like Mailman have to (and are) taking the lead in making that 
information available -- even on the internet, adoption of new 
functionality takes time. The added overhead is trivial compared to 
finally having a single, standard way of documenting these necessary 
data pieces and doing so in a way that allows automated use of that 
data for our non-techie/naive users.

The nice thing is, if you really, really want that, you have the 
ability to do things on the client end to do it. This would be pretty 
trivial to do with procmail, for instance. But I don't think we 
should gut things on the server end to the lowest common denominator 
("let's not do anything anyone doesn't like") because we might as 
well shut down and go home.

these headers are a new, emerging email standard. I'd like to suggest 
you get used to them, because I think over the next year or so, 
they'll become very common as MLMs add the feature and sites upgrade 
to the new software.

E-mail is a very dynamic area of the internet right now. It's scary 
how much it's changed in the last two years (he says, as a person who 
makes his living trying to keep up with it). This is just one piece 
of it, but it's a huge one in the long term, because it allows us to 
help build tools for those that don't know the techie details enough 
to do these things for themselves - and that's a huge problem with 
mail lists right now.

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com)
Apple Mail List Gnome (mailto:chuq at apple.com)

We're visiting the relatives. Cover us.

----- End of forwarded message from Chuq Von Rospach -----