Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 08:20 AM 5/11/01 -0700, Chuq Von Rospach wrote:
>But e-mail interacts with other email systems all over the internet. When
>you hose a mailman system, it affects the mail systems of all of the
>subscribers, which potentially hoses them AND the admins of THEIR mail
>servers.

But, with the exclusion of Nigel's generalized suggestion, what we've been 
talking about so far just doesn't do that.  Leaving the List-Subscribe 
header, to take just one example, off of a closed list that doesn't accept 
public subscription requests is not going to hose anyones system.  It will 
not affect the routing, transport, or delivery of the messages on that list 
or of anything else in the known universe.

It will simply allow a list admin to use the List-* headers in the way that 
they were intended.  Which is to allow the list admin to provide a useful 
and convenient tool to *his (or her) subscribers*, and at the same time 
reduce the headaches of being a list admin by reducing the number of "how 
do I unsubscribe"-type requests.

>That's why SOME of these decisions have to be made by the people who know
>the issues, instead of run off and make decisions based on the "I wanna, 
>so you gotta" style of management.

I submit that Grant Neufeld is one "who know(s) the issues" well enough 
that his published statement ought to at least merit consideration.  I 
personally think it merits more than that, but...

It's not about "I wanna, so you gotta."  I'm sorry if you see it that 
way.  Neither should it be about "we're the experts, we did it right, and 
you peons don't know what you talking about."  It is, at least I think it 
should be, about discussing the differing points of view and then making a 
decision that benefits the Mailman community as a whole.  That community 
includes people outside the development circle.  I've now spent a lot of 
time reading the threads about this issue back through the archive of this 
list, and I just don't see where that happened.  As far as I can tell the 
decision was made early on, and once implemented anyone who questioned it 
was promptly stomped on.

In any case, I believe that the case in favor of making the List-* headers 
configurable has been sufficiently made, and that Barry will indeed give it 
fair consideration.  That's all I ask.  I'm not demanding anything.

So, now I really am done.  Ya'll can carry on with this thread if you like, 
but I'm going to take a break and then see what kind of firestorm breaks 
out when I ask the other questions that I have on the back burner.

Happy Mailmanning!

--Bill
--
"The list administrator should be able to turn individual header fields on 
or off on a per-list basis." - Grant Neufeld, Author, RFC2369.
http://www.nisto.com/listspec/server-author.html


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 07:43 AM 5/11/01 -0700, Roger B.A. Klorese wrote:
>How far does that go?  Should you be allowed to turn off the "To:" header
>if you want?  "Subject:"?  "Date:"?

Oh, please.  Lets not get snide about this.  We are talking about a very 
specific set of headers and you know it.

We are talking about a set of headers that have their basis in RFC 
2369.  RFC 2369 is a *Proposed* Standard.  It isn't even a Draft Standard, 
which is the phase that it will have to go through next before it can 
become a Standard Protocol.  Even if it is eventually adopted as a Standard 
Protocol it will be *optional*.  Even the authors of RFC 2369 agree that 
the use of these particular headers should be *optional* on a *per-list* basis.

This simply doesn't compare to arbitrarily eliminating RFC 822 headers 
which are *required* by accepted standards.

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/11/01 8:07 AM, "Nigel Metheringham"
<[EMAIL PROTECTED]> wrote:

> This would allow people enough rope to completely hang themselves, and
> add a reasonably useful additional feature in.

If this were a web system, I'd be all for it.

But e-mail interacts with other email systems all over the internet. When
you hose a mailman system, it affects the mail systems of all of the
subscribers, which potentially hoses them AND the admins of THEIR mail
servers.

What you do to your own stuff I don't care about. But when  your stuff has
to safely and properly interact with other people's stuff as well -- you no
longer have the right to be an idiot, just because you want to be.

That's why SOME of these decisions have to be made by the people who know
the issues, instead of run off and make decisions based on the "I wanna, so
you gotta" style of management.



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Nigel Metheringham]

[EMAIL PROTECTED] said:
> How far does that go?  Should you be allowed to turn off the "To:"
> header if you want?  "Subject:"?  "Date:"? 

Actually maybe this points to a better approach

First we purely implement a fixed version of our list header cooking - 
no if (this) then add (that).

Then late on in the processing pipeline we have a per-list configurable 
generic header stripper and adder with some form of basic 
programmability - ie basic regexp to select whether or not something is 
added/deleted, and the use of the mailman template variables.

This would allow people enough rope to completely hang themselves, and 
add a reasonably useful additional feature in.

It also means you don't need to add a bunch of extra buttons and 
configurability in for every header you might wish to add.

And if people are stupid enough to modify the mime-headers based on 
this scheme, well they deserve all they get.

Nigel.

-- 
[ Nigel Metheringham   [EMAIL PROTECTED] ]
[ Phone: +44 1423 85 Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Dan Wilder]

On Fri, May 11, 2001 at 07:43:57AM -0700, Roger B.A. Klorese wrote:
> On Fri, 11 May 2001, Thomas Hillson wrote:
> > We are asking you to give us the option to turn off individual headers on some
> > of out lists where we have determined they are inappropriate.
> 
> How far does that go?  Should you be allowed to turn off the "To:" header
> if you want?  "Subject:"?  "Date:"?

Sure!

Let 'em paint their own nose blue, if they want to.

'Course the MTA will add some of those back in.  But that's not
your concern.

-- 
-
 Dan Wilder <[EMAIL PROTECTED]>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549URL http://embedded.linuxjournal.com/
-

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Roger B.A. Klorese]

On Fri, 11 May 2001, Thomas Hillson wrote:
> We are asking you to give us the option to turn off individual headers on some
> of out lists where we have determined they are inappropriate.

How far does that go?  Should you be allowed to turn off the "To:" header
if you want?  "Subject:"?  "Date:"?
-- 
ROGER B.A. KLORESE  [EMAIL PROTECTED]
PO Box 14309San Francisco, CA 94114
"There is only one real blasphemy -- the refusal of joy!"   -- Paul Rudnick


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Thomas Hillson]

Bill,

I must commend you for your continued discussions with the developers of
Mailman over the issue of the headers. I lost patients with them long before
you did.

Like you I am a user of Mailman, and I do not want to fight with the people
who think these headers are needed. I would just like to see a little more
flexibility in the way we can configure each individual list. Until 
they provide
us with the flexibility, we will just have to continue to hack their software
to give some control.  I do not have the time to learn enough about Mailman
to write a patch to selectively turn the headers off. My solution is to comment
out all code for the headers so they do not appear on any of my lists.

To the programmers of Mailman, Please listen to Bill, myself and the many
other people who have requested the flexibility to turn off the headers for
selected mailing lists.

We are not asking you to remove code for the headers from Mailman.

We are not asking you to stop promoting their use so that all mail programs
will recognize them and handle them correctly.

We are asking you to give us the option to turn off individual headers on some
of out lists where we have determined they are inappropriate.

thank you,

Tom 

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 05:32 PM 5/10/01 -0700, Dan Mick wrote:
 >So you have no problem.  So why are you complaining about them?
 >You can't have it both ways.

No.  I said that adoption was underway.  I didn't say it was 
complete.  Besides, there are other reasons to make the 2369 headers 
optional in addition to the short-term MUA issues and the associated user 
truculence.

People use real lists in a variety of ways.  In some of those situations it 
just doesn't make sense to be sending the whole set of 2369 headers to a 
list, and I don't think that it is possible to anticipate, and code for, 
all of the possible variations.  Only the list admin can determine which 
subset of the 2369 headers makes sense in light of the policies, 
procedures, and needs of a particular list.  The authors of RFC 2369 
recognize this.

The bottom line disagreement seems to be that some folks think that list 
admins are not capable of making that decision in a responsible way.  I 
happen to think that they are.  Especially if we work to educate them about 
the benefits of 2369 instead of immediately castigating them for asking the 
question.

 >Or maybe that set of people is merely misguided.  Who knows?

Then we are in good company with the misguided authors of RFC 2369.  I can 
live with that.

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Dan Mick]

> After further reading I've come to the conclusion that this notion that
> making the List-* headers optional will inhibit their adoption is a red
> herring.  A number of MUAs already have, or said they will, implement
> support for these headers including Eudora.

So you have no problem.  So why are you complaining about them?
You can't have it both ways.

> PS - Hey, maybe those of us who think that making the List-* headers
> optional is a Good Thing(tm) aren't so stupid after all!

Or maybe that set of people is merely misguided.  Who knows?

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[blaise]

On Tue, May 08, 2001 at 11:32:54PM -0700, Chuq Von Rospach wrote:
> 
> > It has always seemed childish to me for
> > someone to reply to a message only to say, in essence, "I know the answer
> > to your question but I'm not going to tell you because you are either not
> > worthy enough in some way, or I think you are going to do something silly
> > with the information."  Why not just answer the question, or ignore it?
> 
> We did answer the question -- just not with the answer you wanted. If we
> ignore it, it just gets asked again, louder, with a "why are you idiots
> ignoring me?" whine attached...

No, you didn't answer it -- you responded to it without answering it.
-- 
Jim Trigg  /"\
SKA Blaise de Cormeilles   \ / ASCII RIBBON CAMPAIGN
Hostmaster  X   HELP CURE HTML MAIL
Academy of S. Gabriel  / \

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 03:13 PM 5/9/01 -0700, Chuq Von Rospach wrote:
>On 5/9/01 1:33 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:
>
> > OTOH, a strident "hack it or take a hike" anti-configuration stance (some
> > of the messages in the archive are downright hostile) actually makes it
> > harder for me, and others, to migrate towards full 2369 compliance, which
> > means it ain't gonna happen anytime soon.
>
>Why? It creates dialog, which fosters education.

IMO, there are better ways to foster discussion & education.  The problem 
with zealotry is that it is more likely to alienate people than it is to 
convince them.

>Heck, you'd have done that anyway -- but now you know why they're there 
>and why we want them there, and you're doing it anyway. That's a net 
>positive towards adoption, because at least you're making an informed (if, 
>IMHO, wrong) choice.

After further reading I've come to the conclusion that this notion that 
making the List-* headers optional will inhibit their adoption is a red 
herring.  A number of MUAs already have, or said they will, implement 
support for these headers including Eudora.  The "List-Id" RFC 
(http://www.rfc-editor.org/rfc/rfc2919.txt), which is a follow-on to RFC 
2369 (http://www.rfc-editor.org/rfc/rfc2369.txt), was even written by a 
couple of guys at Qualcomm.  If Eudora supports this you can bet Micro$oft 
will too, in some form, and then claim they invented it of course.  So, 
adoption already seems to be underway.  And even if it wasn't, I simply 
don't believe that having a few Mailman admins turning these headers off on 
some of their lists would make any difference at all to the likes of 
Qualcomm, Micro$oft, or AOL.  In fact, I seriously doubt that they care 
about anything that Mailman does or doesn't do.

Even the authors of the revered RFC 2369 say, quite clearly I might add, 
that each individual List-* header should be optional on a per-list basis 
(http://www.nisto.com/listspec/server-author.html):

"The list administrator should be able to turn individual header fields on 
or off on a per-list basis."

The defense rests.

--Bill

PS - Hey, maybe those of us who think that making the List-* headers 
optional is a Good Thing(tm) aren't so stupid after all!

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Dan Lowe]

Previously, "Jürgen A. Erhard" said:
>
> PS: Wish I could remember the paper the List-Id header is described
> in... was a draft extension to 2369.  Mention here or on -devel, I
> think.

List-Id is discussed in RFC 2919.

 -d

-- 
If a mute swears, does his mother wash his hands with soap?  -George Carlin

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

["Jürgen A. Erhard"]

> "Barry" == Barry A Warsaw <[EMAIL PROTECTED]> writes:

Barry> But, Mailman could do a better job of conforming to RFC
Barry> 2369.  E.g. it could suppress List-Post: for read-only
Barry> lists, and it could get rid of the obsolete List-Id:
Barry> header.  I'll work on this for Mailman 2.1.

Barry, please tell me you're *not* serious about getting rid of
List-Id!

This is the one universal list identifying header I've been waiting
for... for once you can filter on a std header (X- headers can never
be std), *before* you even know what headers a msg of a mailing list
you're just subscribing to will bear (so even the very first posting
of a newly-sub'd list goes into the proper folder).

Bye, J

PS: Wish I could remember the paper the List-Id header is described
in... was a draft extension to 2369.  Mention here or on -devel, I
think.

PPS: Filtering on the other List-* headers?  Well, judging by 2369,
there doesn't need to be any obvious relationship to the
list... List-Post, for example, can be a moderator, which can be any
address, even the same as for some totally different list.  List-Id is
the only necessarily list-specific header.  So, please leave that one
in.

-- 
Jürgen A. Erhard[EMAIL PROTECTED]   phone: (GERMANY) 0721 27326
  My WebHome: http://members.tripod.com/Juergen_Erhard
  There's an NDA in the FSF...
   Free Software FouNDAtion.

 PGP signature

Re: [Mailman-Users] Re: remove this?

[Bob Puff @ NLE]

> The bottom line is, like the original poster of this thread, I
> want these headers to go away.  Unfortunately, I haven't been able
> to find where they are coming from.  If someone could simply tell
> me what I need to hack in order to get rid of these headers, I
> would be grateful.

http://nleaudio.com/bnotes/mailman.htm

Bob



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Barry A. Warsaw]

> "BW" == Bill Warner <[EMAIL PROTECTED]> writes:

>> But, Mailman could do a better job of conforming to RFC 2369.
>> E.g. it could suppress List-Post: for read-only lists,

BW> Or, as Chuq mentioned use the List-Post: NO syntax.

That's what I meant to say. :)

>> Whether that means adding for Mailman 2.1 a list-specific
>> configuration option (-1) or a site-wide configuration variable
>> (-0), I'm not sure.

BW> Thank-you, Barry, for reconsidering this issue.  Please cast
BW> my vote for a per-list option for the reasons outline in my
BW> message to JC.

Noted.  Thanks.
-Barry


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Wed, 09 May 2001 15:33:47 -0500 
Bill Warner <[EMAIL PROTECTED]> wrote:
> At 12:15 AM 5/9/01 -0700, J C Lawrence wrote:

>> Actually I buy and agree with both arguments, I just consider
>> them misplaced in this case.  They work very well elsewhere.

> I think they are appropriate here too.  It just seems to me that
> an adamant stance against configurability is actually more harmful
> to the stated goal of promoting wider acceptance of 2369 than
> allowing a per-list configuration would be.  

You may be right.  I look at it a little differently on the basis
that source is available, and that lsit admins, should they so need
to, can patch their source locally, and can find the relevant
instructions and patches in the archives should they so need to.
Unlike a closed source product the door is not slammed or locked
shut, there's just a lack of a neon sign telling you where the door
is.

> Here's why I say that:

> (a) Most mailman-owners will run with the defaults anyway, so all
> of their messages will still be 2369ized.

One of the advantages of the above
you-have-to-manually-patch-your-source approach is that most will
fail to maintain the patch across upgrades, and thus even if the
patch is variously adopted, it will self-select against itself over
time.  

> (b) Those of us that have problems in this area can 2369ize our
> lists one, or a few, at a time, where appropriate, and bring our
> users along at a rate that we can manage.  Since only we can
> determine what that rate is, only we can make that decision for
> ourselves.

Agreed.  Use of a good MTA ala Exim can also help here (you can put
in delivery time filters to strip the appropriate headers to do
whatever to the message(s)).  The question has never been about _IF_
you could do it, just about _HOW_.  

> So, bottom line, I agree that 2369 compliance is good for Mailman
> and a worthy goal for all mailman-owners.  A per-list
> configuration option would make it easier for me, and based on
> what I've read in the archive, others, to migrate towards full
> 2369 compliance, and therefore more likely that we'll do it.  That
> sounds like a good thing to me.

For reasons previously discussed, I'm not so keen.  Tho I do agree
that Mailman does not to properly support the concept of an
announce-only list, and should reflect that in the List headers.

> Anyway, , that's how the picture looks from where I sit.

>> Trade offs.  The high road.  Those that leave are typically
>> (experience) better off gone, and (experience) their replacements
>> are much more valuable and numerous.

> I don't disagree with anything you said here about FAQs, user
> education, or customer/list member relations.  I think you are
> right on all counts.  The problem is, that at this particular
> moment in time, I simply cannot afford (in time or $$) to take the
> high road without just a little bit of help to make doing so a
> little bit easier.  If I have to deal with this issue on an all or
> nothing basis, it's going to be nothing.



It is possible that Mailman is not the right MLM for your needs.

> In any case, Barry has said he'll consider the 2369 configuration
> issue for 2.1, and that's good enough for me!  

Given the current state of affairs, I would mildly encourage
(translation: I won't argue against it) the following:

  Arbitrary-person-who-is-not-Barry writes a patch to support
  2369 configurability and submits it at SourceForge.

  Minimal effort is excercised not to break the patch across Mailman
  versions.

Anybody who really thinks they need it can grab the patch and head
out on their own as/if needed.  

Its the old, "This is unsupported but you can do it" trick.

>> > We now return you to your regularly scheduled program about how
>> to > get Mailman to run on the Linux flavor-of-the-day...
>> 
>> Yea gods save us.

> Doesn't seem likely. ;-)



-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/9/01 1:33 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:

> OTOH, a strident "hack it or take a hike" anti-configuration stance (some
> of the messages in the archive are downright hostile) actually makes it
> harder for me, and others, to migrate towards full 2369 compliance, which
> means it ain't gonna happen anytime soon.

Why? It creates dialog, which fosters education. If we hadn't had this
discussion, but instead had a configuration option, would you have even
asked or researched? Probably not. By taking a hard line (and yes, sometimes
it's gotten snarky, but usually, someone snarks at the code maintainers
first. Usually...) it forces people to at least listen to the rationale
before making the decision...

> I'll simply hack the 2369
> headers out by the roots and that will be the end of it as far as I'm
> concerned.  And that, I submit, undermines the goal of rapid widespread
> compliance.
> 
> Anyway, , that's how the picture looks from where I sit.

Heck, you'd have done that anyway -- but now you know why they're there and
why we want them there, and you're doing it anyway. That's a net positive
towards adoption, because at least you're making an informed (if, IMHO,
wrong) choice. That's better than the option of making it in ignorance.



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 01:29 PM 5/9/01 -0400, Barry A. Warsaw wrote:
>On the larger question of the List-* headers, there's no doubt that
>the situation will not change for the 2.0.x maintenance branch.  If
>you want to get rid of the headers, hack the source.

Fair enough.

>But, Mailman could do a better job of conforming to RFC 2369.  E.g. it
>could suppress List-Post: for read-only lists,

Or, as Chuq mentioned use the List-Post: NO syntax.

>I still believe that Mailman is doing The Right Thing by supporting
>RFC 2369.  When the MUA vendors catch up, end users will benefit.

Agreed.

>Whether that means adding for Mailman 2.1 a
>list-specific configuration option (-1) or a site-wide configuration
>variable (-0), I'm not sure.

Thank-you, Barry, for reconsidering this issue.  Please cast my vote for a 
per-list option for the reasons outline in my message to JC.

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 12:15 AM 5/9/01 -0700, J C Lawrence wrote:
>There is a critical difference.  X does allow you and even makes it
>very easy to do damned near anything you want, encluding being
>incredibly stupid and making bad decisions.  In a general light,
>this is not a Bad Thing.  One critical aspect however is that should
>you do one of those stupid things you only break/damage yourself
>(person running the broken app).  A perfect example is X server
>grabs.

But, grabbing is so much fun!

> > Unfortunately, if you don't buy the "mechanism, not policy"
> > approach then you probably won't buy this argument either.
>
>Actually I buy and agree with both arguments, I just consider them
>misplaced in this case.  They work very well elsewhere.

I think they are appropriate here too.  It just seems to me that an adamant 
stance against configurability is actually more harmful to the stated goal 
of promoting wider acceptance of 2369 than allowing a per-list 
configuration would be.  Here's why I say that:

(a) Most mailman-owners will run with the defaults anyway, so all of their 
messages will still be 2369ized.

(b) Those of us that have problems in this area can 2369ize our lists one, 
or a few, at a time, where appropriate, and bring our users along at a rate 
that we can manage.  Since only we can determine what that rate is, only we 
can make that decision for ourselves.

So, bottom line, I agree that 2369 compliance is good for Mailman and a 
worthy goal for all mailman-owners.  A per-list configuration option would 
make it easier for me, and based on what I've read in the archive, others, 
to migrate towards full 2369 compliance, and therefore more likely that 
we'll do it.  That sounds like a good thing to me.

OTOH, a strident "hack it or take a hike" anti-configuration stance (some 
of the messages in the archive are downright hostile) actually makes it 
harder for me, and others, to migrate towards full 2369 compliance, which 
means it ain't gonna happen anytime soon.  I'll simply hack the 2369 
headers out by the roots and that will be the end of it as far as I'm 
concerned.  And that, I submit, undermines the goal of rapid widespread 
compliance.

Anyway, , that's how the picture looks from where I sit.

>Trade offs.  The high road.  Those that leave are typically
>(experience) better off gone, and (experience) their replacements
>are much more valuable and numerous.

I don't disagree with anything you said here about FAQs, user education, or 
customer/list member relations.  I think you are right on all counts.  The 
problem is, that at this particular moment in time, I simply cannot afford 
(in time or $$) to take the high road without just a little bit of help to 
make doing so a little bit easier.  If I have to deal with this issue on an 
all or nothing basis, it's going to be nothing.

In any case, Barry has said he'll consider the 2369 configuration issue for 
2.1, and that's good enough for me!  I ask for nothing more.

> > We now return you to your regularly scheduled program about how to
> > get Mailman to run on the Linux flavor-of-the-day...
>
>Yea gods save us.

Doesn't seem likely. ;-)

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 11:32 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>I disagree. Policy decisions should be made by people who can make them in
>an informed way, not out of ignorance. X windows lets its users do REALLY
>STUPID AND DESTRUCTIVE things, simply because they want to. "because they
>want to" isn't a good enough answer,

Sure it is.  It's what gives X the flexibility and power to do useful 
things which were not, or even could not, be anticipated by the developers 
in advance.  Really, I appreciate your concern but you don't have to 
protect me from myself.

>or else we ought to just give everyone
>root access on a computer, and if they want to "rm -rf /", well, we should
>let them.

Sure, why not?  What are you going to do, hide the rm man pages?  Disable 
"-rf" unless they get permission from you?  If it's their system, and 
they've decided they want to "rm -rf /", well then by golly I'll be happy 
to help.  I don't see why anyone should appoint themselves to be the rm 
police, or the List-* police.

>And in this specific case, there's a larger issue as well -- if sites turn 
>this stuff off widely, it discourages their adoption into the clients, 
>which screws over the overall adoption.

The problem with this argument, as I see it (and have expounded in more 
detail in my message to JC), is that your attitude will actually make it 
more likely for sites, like mine, to kill these headers site-wide until 
they are no longer a problem instead of doing it selectively and working 
towards compliance with 2369.


--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Thomas Hillson]

To help out those of you who like me think we should have the option of
removing the headers, here is my CookHeaders.py which removes all
headers that Mailman adds to outgoing mail. This is the crude way of
doing it, but my users are happier now and I have fewer complaints.
Myself and another gentleman had the same discussions you are having
with some people months ago and you will not change their minds.

If you use the code just copy the original CookHeaders.py to a new file
name to save it and replace it with the modified code.

This code is provided as is, it has not warranty that it will work or do what
you want. You use it at your own risk.

good luck,

Tom Hillson

--

#$base/Mailman/Handlers/CookHeaders.py
# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

"""Cook a message's Subject header.
"""

import string
import re
import urlparse
from Mailman import mm_cfg

def process(mlist, msg, msgdata):
# Mark the message as dirty so that its text will be forced to disk next
 # time it's queued.
 msgdata['_dirty'] = 1
 # Set the "X-Ack: no" header if noack flag is set.
 if msgdata.get('noack'):
 msg['X-Ack'] = 'no'
 # Because we're going to modify various important headers in the email
 # message, we want to save some of the information in the msgdata
 # dictionary for later. Specifically, the sender header will get waxed,
 # but we need it for the Acknowledge module later.
 msgdata['original_sender'] = msg.GetSender()
 subject = msg.getheader('subject')
 adminaddr = mlist.GetAdminEmail()
 fasttrack = msgdata.get('fasttrack')
 if not msgdata.get('isdigest') and not fasttrack:
 # Add the subject prefix unless the message is a digest or is being
 # fast tracked (e.g. internally crafted, delivered to a single user
 # such as the list admin). We assume all digests have an appropriate
 # subject header added by the ToDigest module.
 prefix = mlist.subject_prefix
 # we purposefully leave no space b/w prefix and subject!
 if not subject:
 msg['Subject'] = prefix + '(no subject)'
 elif prefix and not re.search(re.escape(prefix), subject, re.I):
 msg['Subject'] = prefix + subject
 #
 # get rid of duplicate headers
 del msg['sender']
 del msg['errors-to']
 msg['Sender'] = msgdata.get('errorsto', adminaddr)
 msg['Errors-To'] = msgdata.get('errorsto', adminaddr)
 #
 # Mark message so we know we've been here
 # msg.headers.append('X-BeenThere: %s\n' % mlist.GetListEmail())
 #
 # Add Precedence: and other useful headers. None of these are standard
 # and finding information on some of them are fairly difficult. Some are
 # just common practice, and we'll add more here as they become necessary
 #
 # http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html
 #
 # None of these headers are added if they already exist
 # if not msg.get('x-mailman-version'):
 # msg['X-Mailman-Version'] = mm_cfg.VERSION
 # Semi-controversial: some don't want this included at all, others
 # want the value to be ^List'.
 if not msg.get('precedence'):
 msg['Precedence'] = 'bulk'
 #
 # Reply-To: munging. Do not do this if the message is "fast tracked",
 # meaning it is internally crafted and delivered to a specific user.
 # Yuck, I hate this feature but enough people want it that we should
 # support it as an option.
 if not fasttrack:
 xreplyto = None
 # Set Reply-To: header to point back to this list
 if mlist.reply_goes_to_list == 1:
 xreplyto = msg.get('reply-to')
 msg['Reply-To'] = mlist.GetListEmail()
 # Set Reply-To: an explicit address
 elif mlist.reply_goes_to_list == 2:
 xreplyto = msg.get('reply-to')
 msg['Reply-To'] = mlist.reply_to_address
 # Give the recipient some ability to un-munge things.
 if xreplyto:
 msg['X-Reply-To'] = xreplyto
 #
 # Add list-specific headers as defined in RFC 2369, but only if the
 # message is being crafted for a specific li

Re: [Mailman-Users] Re: remove this?

[Mike Noyes]

At 2001-05-09 13:29 -0400, Barry A. Warsaw wrote:
>Mike, thanks for the Eudora suggestions.  I'm going to create a
>README.USERAGENT file that collects this wisdom, and I'm going to add
>a FAQ entry pointing people to this file.  If anybody else has
>suggestions on settings for other MUAs please send them along.

Barry,
Thanks, but I can't take credit for them. Someone else posted the Eudora 
instructions in a message on a similar thread. I used them to create a FAQ 
for my list users.

https://sourceforge.net/docman/display_doc.php?docid=1465&group_id=13751

>But, Mailman could do a better job of conforming to RFC 2369.  E.g. it
>could suppress List-Post: for read-only lists, and it could get rid of
>the obsolete List-Id: header.  I'll work on this for Mailman 2.1.
>
>I still believe that Mailman is doing The Right Thing by supporting
>RFC 2369.  When the MUA vendors catch up, end users will benefit.

I agree. :)

>That said, we may have to invoke the 9th Zen of Python: Practicality
>beats Purity[1].  Whether that means adding for Mailman 2.1 a
>list-specific configuration option (-1) or a site-wide configuration
>variable (-0), I'm not sure.  I just wanted to say that while I still
>agree with Chuq and JC that this RFC is important to support, I'm not
>totally deaf to the cries of dismay from those of you who have to
>expend real dollars to deal with users on non-conformant MUAs.

I'm sure whatever you decide to do will be fine.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Barry A. Warsaw]

Mike, thanks for the Eudora suggestions.  I'm going to create a
README.USERAGENT file that collects this wisdom, and I'm going to add
a FAQ entry pointing people to this file.  If anybody else has
suggestions on settings for other MUAs please send them along.

On the larger question of the List-* headers, there's no doubt that
the situation will not change for the 2.0.x maintenance branch.  If
you want to get rid of the headers, hack the source.

But, Mailman could do a better job of conforming to RFC 2369.  E.g. it
could suppress List-Post: for read-only lists, and it could get rid of
the obsolete List-Id: header.  I'll work on this for Mailman 2.1.

I still believe that Mailman is doing The Right Thing by supporting
RFC 2369.  When the MUA vendors catch up, end users will benefit.

That said, we may have to invoke the 9th Zen of Python: Practicality
beats Purity[1].  Whether that means adding for Mailman 2.1 a
list-specific configuration option (-1) or a site-wide configuration
variable (-0), I'm not sure.  I just wanted to say that while I still
agree with Chuq and JC that this RFC is important to support, I'm not
totally deaf to the cries of dismay from those of you who have to
expend real dollars to deal with users on non-conformant MUAs.

waffling-ly y'rs,
-Barry

[1] http://www.python.org/doc/Humor.html#zen

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

[Mailman-Users] Re: remove this?

[Harold Paulson]

>Same with hacking list-*. The general consensus among those of us who've put
>time into understanding this issue is that it's a very good thing for the
>long-term development of mail list technologies. Short term, it's at best a
>minor irritant, and that's only to people with cruddy mail clients (consider
>it an incentive to upgrade to soemthing decent).

For what it's worth, I use Eudora and rather like that it displays 
headers that it doesn't recognize.  Sure it scares the lusers, but I 
love that it tries to inform me when it sees something "weird".  They 
were simple enough to turn off in any case.  Of course it will be 
nicer when it supports the RFC...

- H

-- 

Harold Paulson  Sierra Web Design
[EMAIL PROTECTED]   http://www.sierraweb.com
VOICE: 775.833.9500 FAX:   810.314.1517

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Satya]

On May 9, 2001 at 09:51, Nigel Metheringham wrote:

>will not in general support them... and currently the only MUA I know 
>of that does use them is exmh (and that has a couple of wrinkles I 

Pine, at least since 4.21, supports List-*.

>We probably also ought to use the List-* headers as part of the loop 
>detection... and long term deprecate the X-beenthere - however judging 
>by the number of mailman 1.x installs around and the amount of people 
>with procmail filtering on that its likely to be a painful process.

I already procmailise -- I mean, filter -- on List-Id.

>this is not made easy - ie not a web config item, and if we do use 
>List-* as part of the loop detection remember that people using it may 
>screw themselves royally.  If its a configurable my tendancy would be 

Good!

>to put it in mm_cfg.py and ideally reset it on each upgrade.

That'd be nice.

-- 
Satya. http://satya.virtualave.net/>
US-bound grad students! For pre-apps, see http://quickapps.cjb.net/>
Reactor error -- core dumped.


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Nigel Metheringham]

[EMAIL PROTECTED] said:
> If and when MUAs make automated use of these headers as suggested by
> the  RFC, then it may be a good idea.  But until then, I simply can't
> afford the  added tech support burden to teach every user how to make
> this kind of  config change to their particular client.  It's hard
> enough to keep their  basic setting in order!  ;-) 

Chicken & Egg or Egg & Chicken.  Someone has to start.
Until there is evidence that list headers are being used, MUA authors 
will not in general support them... and currently the only MUA I know 
of that does use them is exmh (and that has a couple of wrinkles I 
could do without).

We probably also ought to use the List-* headers as part of the loop 
detection... and long term deprecate the X-beenthere - however judging 
by the number of mailman 1.x installs around and the amount of people 
with procmail filtering on that its likely to be a painful process.

We do need to document the use of the headers and potentially have a 
means for disabling them... however I would very strongly suggest that 
this is not made easy - ie not a web config item, and if we do use 
List-* as part of the loop detection remember that people using it may 
screw themselves royally.  If its a configurable my tendancy would be 
to put it in mm_cfg.py and ideally reset it on each upgrade.

BTW for people wishing to strip these then it may be better to do this 
in MTA filtering - exim can handle this easily.

I am strongly resisting the temptation to comment on the buns thread.

Nigel.

-- 
[ Nigel Metheringham   [EMAIL PROTECTED] ]
[ Phone: +44 1423 85 Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Wed, 09 May 2001 01:09:26 -0500 
Bill Warner <[EMAIL PROTECTED]> wrote:

> In the end, I think that any disagreement we may have over this
> issue is actually philosophical rather than technical.
> Personally, I am a firm believer in the guiding principle of the X
> Window System which always seeks to "provide mechanism, not
> policy."  If you apply that principle to this issue, then you
> conclude that Mailman should implement the mechanism for sending
> RFC2369 headers, but the policy decision of which, if any, of them
> should go out on a particular list should be left to the list
> owner.  It's obvious that many here disagree with that design
> philosophy.  So be it.

There is a critical difference.  X does allow you and even makes it
very easy to do damned near anything you want, encluding being
incredibly stupid and making bad decisions.  In a general light,
this is not a Bad Thing.  One critical aspect however is that should
you do one of those stupid things you only break/damage yourself
(person running the broken app).  A perfect example is X server
grabs.

With mail that's not the case.  One change affects hundreds if not
thousands or millions of people (we're getting lists of that size
now).  Yes, you can still do stupid things and write your own
policies, but the system instead of being geared to allowing that,
is instead geared to, "Make it easy for him to be a good netizen and
hard for him to cause us pain.".  There are too many other easy ways
to cause pain on the 'net to go around making it easy for there to
be more.

> It has also been said that because this is Open Source, I already
> have the ability to control this header behavior by hacking the
> source.  True enough, and I've already done that for my
> installation.  But I submit that deliberately making this kind of
> thing harder than it has to be, a kind of "Father Knows Best"
> attitude, is antithetical to the roots of todays Open Source
> movement.

If Father Really Knew Best, the source wouldn't be out there.  

> Unfortunately, if you don't buy the "mechanism, not policy"
> approach then you probably won't buy this argument either.

Actually I buy and agree with both arguments, I just consider them
misplaced in this case.  They work very well elsewhere.

>> and that's only to people with cruddy mail clients (consider it
>> an incentive to upgrade to soemthing decent).

> Unfortunately, the people I have to deal with don't see it that
> way.  They don't want anything to do with upgrades or
> reconfigurations.  

This sounds like your users need a FAQ.  It also sounds like they
may need some education -- often a Good Thing in any case (I
occassionally invent excuses for it with my list members).

There is a view that in the end the customer is always right and
that the provider therefore must (or will) always end up doing what
the customer wants.  This is the view that places the customer as
the 800lb gorilla and everyone/everything else as fleas sucking
their blood.  There is also a view that the provider vends the
service and the customer either accepts it or goes somewhere else.
Similarly, this is the vendor as the 800lb gorilla and everyone
else, and in particular the customers, as fleas (picking the host to
suck blood from).  The truth is somewhere in the middle.
Customer/vendor relationships are sympathetic not parasitic systems.

While arguably the September that Never Ended has, as promised,
Never Ended, in many ways it has actually begun to end.  The great
'net unwashed are not the uncontrollably 'net-cluefree barbarians
storming the castle they once were.  'Net life has improved, or, to
be excessively patronising, they have shown a capacity for learning
that was not at first obvious (the early days of Sept were bloody
and few bothered to observe the delicacies among the storming
hordes).  

I'm a believer in the relationship being balanced, and for that
balance to lean in my direction as regards use of my time and
effort.  I am not gentle with my list members, but I do respect them
and I will get their respect in turn or they will not post to my
lists.  I require them to follow my formatting rules, my quoting
styles, to attribute all quoted text, to not use HTML, to not
marketeer, to always be on topic, to always at least head towards
signal, etc etc etc just to have their posts considered bor
acceptance on my main list (other lists are more open).  And they
do.  They have changed and learned, and conformed.  And I've made
damned certain that I've returned value to them for their effort,
balancing the equation.

You've got to balance the books in their eyes.  The ROI must be very
clear.

> While the customer is not always right, you sometimes have to
> pretend that they are.

Sometimes you need to tell them they are wrong, why they re wrong,
and that you are more than willing to help them build and run
correct systems.

Trade offs.  The high road.  Those that leave are typically
(experience) better off gone, and (ex

Re: [Mailman-Users] Re: remove this?

[JC Dill]

On 11:32 PM 5/8/01, Chuq Von Rospach wrote:

 >It's like cough medicine. It tastes rotten going down, but long term, it
 >makes you feel better. Sometimes, you take a little pain now for the future.

This is similar to the pain mail server admins (and their associated 
support staff) went through when we (the Internet as a whole) had to go 
through the pains of closing open-relay mail servers following the spam 
deluge problems in the mid 90s.  Closing open relays was a PITA, but it was 
necessary to move on to a more secure and reliable mail delivery 
system.  Adapting to intelligent mailing list headers is a similar 
(although less urgent) problem.  Take the high road and be one of the 
leaders in making these changes that are "for the good of the Internet".

jc


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 11:09 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:

> Since upgrading my Mailman installation to
> 2.x these headers have been the direct cause of new tech support calls,
> everyone of which costs money.

So solve the real problem -- which is create a FAQ item telling people how
to fix mail clients, not to rip stuff out of the system that will, in the
long run, make it easier for users to use the system. It's a short term
investment for long-term gain, but if people refuse to adopt the headers,
the client writers won't feel the need to adopt them, and you'll spend your
time walking users through subscription issues instead of having them
automated in the client.

> policy decision of which, if any, of them
> should go out on a particular list should be left to the list owner.

I disagree. Policy decisions should be made by people who can make them in
an informed way, not out of ignorance. X windows lets its users do REALLY
STUPID AND DESTRUCTIVE things, simply because they want to. "because they
want to" isn't a good enough answer, or else we ought to just give everyone
root access on a computer, and if they want to "rm -rf /", well, we should
let them.

There are some actions and decisions you have to know what you're doing
before we should allow to happen. And in this specific case, there's a
larger issue as well -- if sites turn this stuff off widely, it discourages
their adoption into the clients, which screws over the overall adoption. So
you may want to turn it off, but that causes problems for the
internet-at-large in the future by discouraging adoption of these standards.

Now -- again, if you want to do it, be my guest. It's your system. But when
you start asking us to do it, or make it easy, or show you how, that's a
different matter -- because while you might think it's better for your site,
that's at odds with the overall goal, and there are bigger issues that take
precedence here (IMHO). Again, short term investment, minor pain. Long term
gain, long term advantage. But that gain happens only if we do everything we
can to encourage adoption, and the mail client authors adopt as well. That
won't happen if people can easily dump this stuff, because they're new,
different and people think they're therefore icky -- and don't do the
research or want to.

It's like cough medicine. It tastes rotten going down, but long term, it
makes you feel better. Sometimes, you take a little pain now for the future.

IMHO, this is one. I'm firmly against anything that makes it easy to remove
these lines, including ANY hints in any FAQs or documentation. I don't
believe Barry's quite that hard-ass about it, and it's his call, but at some
point, we have to say "this is worth having, and someone has to take the
first step".

> But I submit that
> deliberately making this kind of thing harder than it has to be, a kind of
> "Father Knows Best" attitude,

Sure. You know why? Because many times Father DOES.

> is antithetical to the roots of todays Open
> Source movement. 

Sorry, don't buy that at all. I don't see that as any part of open source.
You have the right to make any change you want to open source, but it's
generally the experts who write this stuff, and they should write it based
on their expertise -- and that means making philosophical decisions like
this. You have the right to change it personally, to argue with the experts,
or to throw it out and use someone else's software with a more compatible
philosophy, but the experts do the work, and they get final say on what is
and isn't right. 

> It has always seemed childish to me for
> someone to reply to a message only to say, in essence, "I know the answer
> to your question but I'm not going to tell you because you are either not
> worthy enough in some way, or I think you are going to do something silly
> with the information."  Why not just answer the question, or ignore it?

We did answer the question -- just not with the answer you wanted. If we
ignore it, it just gets asked again, louder, with a "why are you idiots
ignoring me?" whine attached...

> It's really not productive to try to guess some ones background based on
> one or two posts to a mailing list.  Just because I don't have the time to
> read mailman-users everyday, or hunt down every RFC that impacts it's

Just as it's not productive to try to guess how software like mailman
"ought" to work without doing the research needed to know why decisions were
made...

> I know, childish at best...

Yes, very. 



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

So, I lied about my previous post being my last, but on reflection perhaps 
some final comments are in order, or perhaps I just can't help myself...

At 04:54 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>This issue comes up again and again, and I apologize in advance if I sound
>(or sounded) grumpy about this

I, too, apologize, especially to Chuq and J C, for being grumpy, or rude, 
but on my side of the fence this particular issue is costing me real money, 
which tends to make me cranky.  Since upgrading my Mailman installation to 
2.x these headers have been the direct cause of new tech support calls, 
everyone of which costs money.

In the end, I think that any disagreement we may have over this issue is 
actually philosophical rather than technical.  Personally, I am a firm 
believer in the guiding principle of the X Window System which always seeks 
to "provide mechanism, not policy."  If you apply that principle to this 
issue, then you conclude that Mailman should implement the mechanism for 
sending RFC2369 headers, but the policy decision of which, if any, of them 
should go out on a particular list should be left to the list owner.  It's 
obvious that many here disagree with that design philosophy.  So be it.

It has also been said that because this is Open Source, I already have the 
ability to control this header behavior by hacking the source.  True 
enough, and I've already done that for my installation.  But I submit that 
deliberately making this kind of thing harder than it has to be, a kind of 
"Father Knows Best" attitude, is antithetical to the roots of todays Open 
Source movement.  Unfortunately, if you don't buy the "mechanism, not 
policy" approach then you probably won't buy this argument either.

Of course, through all of this the Mailman developers are free to develop 
as they see fit, and there is no requirement that I like the way they do 
it.  Conversely, there is no requirement that they, or anyone on this list, 
like the questions I ask about their product.

>But nobody is under any obligation to
>make that easy, to help you do it, or to give you instructions.

Of course not.  Neither are you under any obligation to reply to the 
question in the first place.  It has always seemed childish to me for 
someone to reply to a message only to say, in essence, "I know the answer 
to your question but I'm not going to tell you because you are either not 
worthy enough in some way, or I think you are going to do something silly 
with the information."  Why not just answer the question, or ignore it?

>Same with hacking list-*. The general consensus among those of us who've 
>put time into understanding this issue is that it's a very good thing for 
>the long-term development of mail list technologies.

I don't disagree with that.

>Short term, it's at best a minor irritant,

That, I strongly disagree with.  It may be a minor irritant to you, but it 
is much more than that here.

>and that's only to people with cruddy mail clients (consider
>it an incentive to upgrade to soemthing decent).

Unfortunately, the people I have to deal with don't see it that way.  They 
don't want anything to do with upgrades or reconfigurations.  As far as 
they are concerned this happened because of something that I did (upgrading 
Mailman), and they pay me $19.95/month, so I damn well better fix 
it.  While the customer is not always right, you sometimes have to pretend 
that they are.

>You're welcome to disagree -- but not demand that we help you do something

I apologize if you felt I was demanding anything.  That was not my intent.

>I get a little grumpy when people wander in telling me how things ought to 
>work when they've never been under the hood of a piece of email...

It's really not productive to try to guess some ones background based on 
one or two posts to a mailing list.  Just because I don't have the time to 
read mailman-users everyday, or hunt down every RFC that impacts it's 
development, or spend quite enough time to track down 
Mailman/Handlers/CookHeaders.py, doesn't mean that I have "never been under 
the hood of a piece of email..."  So, please, lets not get into a pissing 
contest.

[Oh dear me, I went and said the secret file name on the list, now everyone 
has the dangerous knowledge of how to get rid of the pesky RFC "mandated" 
List-* headers.  Whatever shall we do now?]  Ahem, sorry (sort of) about 
that, but I really couldn't resist.  I know, childish at best...

>Implementing list-* is investing in future technologies;
>footer data is managing today's users.

Exactly! My problem is that I have to manage today's users as cost 
effectively as possible, or I go out of business, and while I really do 
applaud the developers for investing in those future technologies by 
implementing RFC2369, I simply can't afford to have the cost of that 
investment coming directly out of my bank account.  So given that reality, 
what's so wrong with asking for an option that allows me to mo

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 22:07:42 -0700 
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:

> On 5/8/01 5:22 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

>>> I've decided the default footer isn't quite good enough.
>> Your complaint?

> Minor ones:

> ___ 
> sharks mailing list 
> [EMAIL PROTECTED]
> http://www.hockeyfanz.com/mailman/listinfo/sharks

> Neither of the URLs is defined. 

Fair call.

> That's still rough, but I find I have JUST enough people naïve
> enough to not know why those links are there that I want to add
> signposts. We're assuming they know what those items are for, and
> that's not really a safe assumption.

There are times I just feel blessed.  (Then I wake up)

>> Aside: I just ran some stats.  For my main list posting
>> percentage has now declined to between 17% - 23% of the total
>> subscriber base.  This down from an 80% poster rate for a list
>> that had 10% of the current subscriber base.
>> 
>> Not sure what to make of it.

> Those are still REALLY high compared to most lists.

Yeah, they surprised me.  I thought my percentages were down around
half that (8%) until I did some stats on the archives.  

>>> And the default mailman digest header is bad...

>> Agreed.  Then again I generally view digests as bad given the
>> current state of MUAs and digest support.

> Won't get into the politics of digests. 

Ptui.

I don't mind them as long as digest readers either never post, or
they properly manage their Subject, and In-Reply-To:/References:
headers in their replies.  Sadly few do.  Knowing the state of MUAs
out there I can't entirely blame them.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 5:22 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

>> I've decided the default footer isn't quite good enough.
> 
> Your complaint?

Minor ones:

___
sharks mailing list
[EMAIL PROTECTED]
http://www.hockeyfanz.com/mailman/listinfo/sharks


Neither of the URLs is defined. Better would be:

___
This message was sent to you through the [EMAIL PROTECTED] mailing list
Post to this list: [EMAIL PROTECTED]
Unsubscribe and get help: http://www.hockeyfanz.com/mailman/listinfo/sharks

That's still rough, but I find I have JUST enough people naïve enough to not
know why those links are there that I want to add signposts. We're assuming
they know what those items are for, and that's not really a safe assumption.

> Aside: I just ran some stats.  For my main list posting percentage
> has now declined to between 17% - 23% of the total subscriber base.
> This down from an 80% poster rate for a list that had 10% of the
> current subscriber base.
> 
> Not sure what to make of it.

Those are still REALLY high compared to most lists.

>> And the default mailman digest header is bad...
> 
> Agreed.  Then again I generally view digests as bad given the
> current state of MUAs and digest support.

Won't get into the politics of digests. People like them. But some parts of
the digest preamble ought to be in the footer, or simply gone. I couldn't
say offhand how I'll redo it -- haven't decided.



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 17:10:06 -0700 
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:

> On 5/8/01 5:01 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:
>> Good distinction.  I still use the default Mailman footer that
>> points to the list page.

> I've decided the default footer isn't quite good enough. 

Your complaint?

Aside: I just ran some stats.  For my main list posting percentage
has now declined to between 17% - 23% of the total subscriber base.
This down from an 80% poster rate for a list that had 10% of the
current subscriber base.

Not sure what to make of it.

> And the default mailman digest header is bad...

Agreed.  Then again I generally view digests as bad given the
current state of MUAs and digest support.

> I've gotten any number of complaints about how bloody long it is.

I get a couple complaints a year about MIME on the text digests and
that's about it.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 5:01 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

> Good distinction.  I still use the default Mailman footer that
> points to the list page.

I've decided the default footer isn't quite good enough. And the default
mailman digest header is bad -- I've gotten any number of complaints about
how bloody long it is.

Of course -- I haven't had time to change either, which is why I haven't
sent suggestions back in to improve these. Bt it's On The List...



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 5:02 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

>> Especially if they're MY buns. It'd scar some people for life...
> 
> I thought I mentioned that _MY_ universe was not capable of
> supporting such concepts.  Yeesh.

Heh. If you want to scare the children, you can go to www.chuqui.com, and
see me in a kilt. Why a kilt with a German name?

Do you really want to see me in lederhosen? I thought not...



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 16:55:49 -0700 
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:

> On 5/8/01 4:35 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:
>>> Chuq (official hard-ass of the 2002 summer olympics)
>> The concept of spandex covered buns at an athletic avent

> Especially if they're MY buns. It'd scar some people for life...

I thought I mentioned that _MY_ universe was not capable of
supporting such concepts.  Yeesh.  I'm not quite ready for
spontoaneous collapse of the firmament on the basis that probability
1.0 has suddenly been found to be equal to probability 0.0.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 16:54:59 -0700 
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:

> On 5/8/01 4:27 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:
>>> IMO, the List-* headers are excessive and should, at the very
>>> least, be configurable.
>> This has been a point of contention on the list and elsewhere.  I
>> disagree.

> I'll take a middle ground. If he really feels this is how the
> list-* headers ought to operate, he should write a patch to
> mailman and submit it to Barry via sourcefourge. Barry can then
> decide whether to include it, either as default behavior or as
> some configurable option or external hack/patch.

I believe this has been done already by the last guy to champion RFC
2369 configurability.

> But it's good go give them at least some hint in the message
> itself, since they (a) won't read instructions, (b) the list-* RFC
> isn't well implemented, and  the folks who most need that info
> are least likely to know to look in the headers. Implementing
> list-* is investing in future technologies; footer data is
> managing today's users.

Good distinction.  I still use the default Mailman footer that
points to the list page.  With a few thousand subscribers I get
about one message a month (little less actually) asking how to
unsubscribe, and the vast majority of those are due to some unusual
circumstance (mail forwarding etc) which they weren't sure how to
penetrate.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 4:35 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

>> Chuq (official hard-ass of the 2002 summer olympics)
> 
> The concept of spandex covered buns at an athletic avent

Especially if they're MY buns. It'd scar some people for life...



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 4:27 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:

>> IMO, the List-* headers are excessive and should, at the very
>> least, be configurable.
> 
> This has been a point of contention on the list and elsewhere.  I
> disagree.

I'll take a middle ground. If he really feels this is how the list-* headers
ought to operate, he should write a patch to mailman and submit it to Barry
via sourcefourge. Barry can then decide whether to include it, either as
default behavior or as some configurable option or external hack/patch.

Or if you really feel strongly about it, go find a more compatible MLM.

This issue comes up again and again, and I apologize in advance if I sound
(or sounded) grumpy about this -- but some of us have put a lot of time and
energy into studying these issues, and after a while, it gets tiring to hear
people come in who haven't HEARD of the RFCs, much less studied them, coming
in and telling us how we have to do things. And then complaining at us when
we disagree.

If you want to hack your copy of Mailman to send out headers identifying you
as the Queen of England, be my guest. But nobody is under any obligation to
make that easy, to help you do it, or to give you instructions.

Same with hacking list-*. The general consensus among those of us who've put
time into understanding this issue is that it's a very good thing for the
long-term development of mail list technologies. Short term, it's at best a
minor irritant, and that's only to people with cruddy mail clients (consider
it an incentive to upgrade to soemthing decent).

You're welcome to disagree -- but not demand that we help you do something
we think is wrong/stupid/shortsighted, and definitely not that we have to do
it your way, when you can't even tell us why it's done this way in the first
place... 

And I apologize (sort of) for ranting, but since I do this stuff for a
living, and I put a lot of time into trying to figure this stuff out, I get
a little grumpy when people wander in telling me how things ought to work
when they've never been under the hood of a piece of email...

>> If I want my list message to carry this info I can already put it
>> in the footers. 
> 
> Which is arguably quite offensive as it clutters the body of the
> message with repetitive noise rather than being safely and largely
> invisibly tucked away in the headers (invisibly until
> accessed/required)..

Actually, I'm in the camp of putting at least some of it in the footer TOO,
except in digests, where it needs to be in the preamble/header. I've got
some interesting (but unpublishable) research on location vs. usage vs.
message size... 

But it's good go give them at least some hint in the message itself, since
they (a) won't read instructions, (b) the list-* RFC isn't well implemented,
and  the folks who most need that info are least likely to know to look
in the headers. Implementing list-* is investing in future technologies;
footer data is managing today's users.




--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 8 May 2001 16:48:32 -0400 
Robert Clayton  wrote:

> Here is the address of the RFC list that pertains to structure and
> such.  Fair warning though. Have lots of coffee ready.

> www.imc.org/rfcs.html#rfc822

RFC 822 has been replaced by RFC 2822.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 15:13:57 -0500 
Bill Warner <[EMAIL PROTECTED]> wrote:

> The bottom line is, like the original poster of this thread, I
> want these headers to go away.  Unfortunately, I haven't been able
> to find where they are coming from.  If someone could simply tell
> me what I need to hack in order to get rid of these headers, I
> would be grateful.

I believe a patch was posted to the list a couple months ago.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 13:16:12 -0700 
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:

> Chuq (official hard-ass of the 2002 summer olympics)

The concept of spandex covered buns at an athletic avent for SysAdms
would appear to violate several basic tenets of the physical
universe -- well, at least in my universe...

Scary.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 15:21:27 -0500 
Bill Warner <[EMAIL PROTECTED]> wrote:

> At 12:47 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>> You should have made those comments to the standards
>> committee. The RFC is the RFC.

> What RFC?  If you have a cite for an RFC which says that Mailman
> must add 10 lines worth of headers to every message it sends I'd
> be delighted to read it.

RFC 2369:

  http://www.pasteur.fr/infosci/RFC/23xx/2369
 
>> (hint: any DECENT mail client can be configured to show or hide
>> header lines...)

> But that's not the point.  (Not mine anyway... :-) I can't see any
> valid reason why Mailman should force me to inflict these headers
> on my list readers.  

This is a choice.  In this case it is the choice of the Mailman
developers, and they've made this quite clear, that the ability to
turn off RFC 2369 headers is a generically Bad Thing and thus should
not be supported (see the list archives for details and discussion
on this).  Others, such as yourself, feel differently.  Thus, by the
wonder of Open Source you are free to edit your Mailman installation
to remove the headers, and to distribute and maintain the patches
that support that capability.

> If you want them going out on your lists that's just fine, but
> please give me the option to turn them off on mine.

You have the option and have always had it:  Hack the source.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Tue, 08 May 2001 14:12:52 -0500 
Bill Warner <[EMAIL PROTECTED]> wrote:

> At 12:01 PM 5/8/01 -0400, [EMAIL PROTECTED] wrote:
>> > How should I remove these (excessive headers) on each post?
>> makes my message long.
>> 
>> You would be generally ill advised to remove any of them.

> Why?  

The list headers are documented in RFC 2359 and are a generically
Good Idea.  The other headers you referenced with very rare
exception are required for correct mail system behaviour.

> IMO, the List-* headers are excessive and should, at the very
> least, be configurable.

This has been a point of contention on the list and elsewhere.  I
disagree.

> If I want my list message to carry this info I can already put it
> in the footers.  

Which is arguably quite offensive as it clutters the body of the
message with repetitive noise rather than being safely and largely
invisibly tucked away in the headers (invisibly until
accessed/required)..

> Why should I force everyone to scroll past a page long list of
> headers?!

You don't.  Only those with broken mail clients do.  The correct
target at this point is to pursue the authors of such broken mail
clients until they either catch a clue or their users abandon their
products as unusable (wish that would happen to Outlook).

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Mike Noyes]

At 2001-05-08 14:55 -0700, Chuq Von Rospach wrote:
>On 5/8/01 1:48 PM, "Clayton, Robert" <[EMAIL PROTECTED]> wrote:
>
> > Here is the address of the RFC list that pertains to structure and
> > such. Fair warning though. Have lots of coffee ready.
> >
> > www.imc.org/rfcs.html#rfc822
>
>Except that's not the RFC involing list-id and list* headers. And RFC822
>was recently superseded by an updated version...

Chuq & Clayton,
They are:

Simple Mail Transfer Protocol
ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

Internet Message Format
ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt

Apparently the numbers were reserved.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 01:33 PM 5/8/01 -0700, Mike Noyes wrote:
>Someone posted a hack to remove the headers a while ago. Search the list 
>if you're interested.

OK, I found a reference to this in the archive, and located the spot to 
hack the code.  On my first look I didn't grep deep enough into the 
distribution.  Mea Culpa.  So, this will be my last post on the subject and 
then I'll quietly go away, to the delight of the self-righteous among us, 
and hack my own installation.

>The Mailman developers are just following RFC2369.

Thanks for the cite, Mike.  I've read RFC2369, and while I applaud 
following the relevant RFCs, I'd like to make a few observations about 2369 
and it's application to Mailman:

1. Despite the protestations of some, there is nothing mandatory or 
required about these headers.  Quite the contrary.  From RFC2369: 
"Implementing these fields will be optional."

2. It seems clear, IMO, that the intent of RFC2369 is that you should be 
able to choose a subset of these headers on a per list basis: "Thus, some 
list managers or mail clients can choose to implement a subset of the 
fields based on the specific needs of their individual lists."  It makes 
absolutely no sense, for example, to send the List-Post header to a 
read-only list, or to send the List-Archive header to a list that isn't 
archived.

3. If the intent is really to be hard-assed about literal compliance with 
RFC2369 then

(a) why aren't the List- headers optionally configurable as implied by the 
RFC itself?

(b) why are List- (eg. List-Id) headers which are not defined in RFC2369 
implemented even though the RFC is already concerned about "avoiding the 
creation of too many fields"?

(c) why isn't the List-Owner field, which is defined in the RFC, implemented?

>All lists will eventually implement this, so I'd figure out a way to 
>educate your users.

If and when MUAs make automated use of these headers as suggested by the 
RFC, then it may be a good idea.  But until then, I simply can't afford the 
added tech support burden to teach every user how to make this kind of 
config change to their particular client.  It's hard enough to keep their 
basic setting in order!  ;-)

>  Just my opinion.

As the above is just mine...


--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 1:48 PM, "Clayton, Robert" <[EMAIL PROTECTED]> wrote:

> Here is the address of the RFC list that pertains to structure and such.
> Fair warning though. Have lots of coffee ready.
> 
> www.imc.org/rfcs.html#rfc822

Except that's not the RFC involing list-id and list* headers. And RFC822 was
recently superseded by an updated version...



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 1:21 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:

> At 12:47 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>> You should have made those comments to the standards committee. The RFC is
>> the RFC.
> 
> What RFC?  

2369. 

>> (hint: any DECENT mail client can be configured to show or hide header
>> lines...)
> 
> But that's not the point.  (Not mine anyway... :-)  I can't see any valid
> reason why Mailman should force me to inflict these headers on my list
> readers.  

That's because you haven't looked into the reason yet.

Those lines are there to help mail clients build automated interfaces to
list operations. It's a new, emerging standard. The only way you get mail
client authors to support it is if the mail server authors also support it.
If you just say "this does nothing" and hack it out, then you're right, it
never WILL do anything, because you'll have botched the reason for the
standards. 

At best, it's a minor short term irritation for a long-term improvement in
how mail lists operate.



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

RE: [Mailman-Users] Re: remove this?

[Ondercin Paul-O10322]

> > Yes, I know about the TabooHeaders settings for Eudora, but 
> most of my list
> > readers don't, and they are probably using some M$ junk to read mail
> > anyway, and they don't care about things like TabooHeaders 
> in any case.
> None of the MS Clients (at least that I've used) show these headers.

   Glossing over the fact that M$ usually ignores any standards they
feel like, Outlook likes to hide the headers from the user. Open the
letter from double-clicking on it, and in the View/Options menu option
you can find the missing headers listed as "Internet Headers". You can
also get to here by right-clicking on a message from the subjects pane
(pain?) and selecting "Options".

   Of course, there are NO headers listed here for any email sent
Exchange-to-Exchange. Which makes it a ball to try and trace a
message...


-Paul Ondercin
Motorola Postmaster

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[alex wetmore]

On Tue, 8 May 2001, Bill Warner wrote:
> Yes, I know about the TabooHeaders settings for Eudora, but most of my list
> readers don't, and they are probably using some M$ junk to read mail
> anyway, and they don't care about things like TabooHeaders in any case.

None of the MS Clients (at least that I've used) show these headers.

alex


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

RE: [Mailman-Users] Re: remove this?

[Clayton, Robert]

Here is the address of the RFC list that pertains to structure and such.
Fair warning though. Have lots of coffee ready.

www.imc.org/rfcs.html#rfc822

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Mike Noyes]

At 2001-05-08 15:13 -0500, Bill Warner wrote:
>At 12:42 PM 5/8/01 -0700, Mike Noyes wrote:
>>ref. Eudora .ini Settings TabooHeaders
>
>Yes, I know about the TabooHeaders settings for Eudora, but most of my 
>list readers don't, and they are probably using some M$ junk to read mail 
>anyway, and they don't care about things like TabooHeaders in any case.
>
>The point is, if I don't want those headers going out on *my* list, I 
>don't see any reason why Mailman, which is otherwise highly configurable, 
>should force me to do so.
>
>The bottom line is, like the original poster of this thread, I want these 
>headers to go away.  Unfortunately, I haven't been able to find where they 
>are coming from.  If someone could simply tell me what I need to hack in 
>order to get rid of these headers, I would be grateful.

Bill,
Someone posted a hack to remove the headers a while ago. Search the list if 
you're interested. The Mailman developers are just following RFC2369. All 
lists will eventually implement this, so I'd figure out a way to educate 
your users. Just my opinion.

>Thanks,

No problem.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

RE: [Mailman-Users] Re: remove this?

[Clayton, Robert]

Finally, logic prevails!

If I as a lay person can figure out how to remove them, then anyone should be able to. 
I am far from a programmer.

-Original Message-
From: Chuq Von Rospach [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 4:16 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Mailman-Users] Re: remove this?


On 5/8/01 12:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>> The List-headers are RFC-compliant. Footers are not.
> 
> What RFC says that footers are not allowed?

You know, we have this same argument every few weeks. Barry, can the
FAQ/INSTALL/README/etc be updated with a comment about this so we can simply
point them to the FAQ and quit having to re-argue this every time?

My bottom line is simple. Mailman is a standards-based system. These headers
are part of the standards. Taking them out is The Wrong Thing To Do. If you
want to do it anyway, on your server, BMG. But don't ask us to show you how,
or assume that because you want it that way that we have to help. And if you
don't know enough to fix the code on your own, you shouldn't be making
decisions like this on how things ought to be done.

Chuq (official hard-ass of the 2002 summer olympics)


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 12:47 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>You should have made those comments to the standards committee. The RFC is
>the RFC.

What RFC?  If you have a cite for an RFC which says that Mailman must add 
10 lines worth of headers to every message it sends I'd be delighted to 
read it.

>(hint: any DECENT mail client can be configured to show or hide header
>lines...)

But that's not the point.  (Not mine anyway... :-)  I can't see any valid 
reason why Mailman should force me to inflict these headers on my list 
readers.  If you want them going out on your lists that's just fine, but 
please give me the option to turn them off on mine.

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Bill Warner]

At 12:42 PM 5/8/01 -0700, Mike Noyes wrote:
>ref. Eudora .ini Settings TabooHeaders

Hello Mike,

Yes, I know about the TabooHeaders settings for Eudora, but most of my list 
readers don't, and they are probably using some M$ junk to read mail 
anyway, and they don't care about things like TabooHeaders in any case.

The point is, if I don't want those headers going out on *my* list, I don't 
see any reason why Mailman, which is otherwise highly configurable, should 
force me to do so.

The bottom line is, like the original poster of this thread, I want these 
headers to go away.  Unfortunately, I haven't been able to find where they 
are coming from.  If someone could simply tell me what I need to hack in 
order to get rid of these headers, I would be grateful.

Thanks,

--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 12:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>> The List-headers are RFC-compliant. Footers are not.
> 
> What RFC says that footers are not allowed?

You know, we have this same argument every few weeks. Barry, can the
FAQ/INSTALL/README/etc be updated with a comment about this so we can simply
point them to the FAQ and quit having to re-argue this every time?

My bottom line is simple. Mailman is a standards-based system. These headers
are part of the standards. Taking them out is The Wrong Thing To Do. If you
want to do it anyway, on your server, BMG. But don't ask us to show you how,
or assume that because you want it that way that we have to help. And if you
don't know enough to fix the code on your own, you shouldn't be making
decisions like this on how things ought to be done.

Chuq (official hard-ass of the 2002 summer olympics)


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

RE: [Mailman-Users] Re: remove this?

[Clayton, Robert]

I also don't see any extreme headers flowing through my system. I have an extensive 
list server that is looking fine. 

Which mail program are you using that shows a large header? 


-Original Message-
From: Satya [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 3:30 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mailman-Users] Re: remove this?


On May 8, 2001 at 14:12, Bill Warner wrote:

>Why?  IMO, the List-* headers are excessive and should, at the very least, 
>be configurable.  If I want my list message to carry this info I can 
>already put it in the footers.  Why should I force everyone to scroll past 
>a page long list of headers?!

What long list? They don't show in the default view of Pine.

The List-headers are RFC-compliant. Footers are not.

We've already had this discussion. Twice, I think.

-- 
Satya. http://satya.virtualave.net/>
US-bound grad students! For pre-apps, see http://quickapps.cjb.net/>
Reactor error -- core dumped.


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Satya]

On May 8, 2001 at 15:50, [EMAIL PROTECTED] wrote:

>On Wed, May 09, 2001 at 12:59:58AM +0530, Satya wrote:
>> The List-headers are RFC-compliant. Footers are not.
>
>What RFC says that footers are not allowed?

Too sleepy. Meant that footers are not recommended/mandated in the
same way as the List-* headers.

-- 
Satya. http://satya.virtualave.net/>
US-bound grad students! For pre-apps, see http://quickapps.cjb.net/>



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Ashley M. Kirchner]

[EMAIL PROTECTED] wrote:

> > The List-headers are RFC-compliant. Footers are not.
>
> What RFC says that footers are not allowed?

No one said footers are not allowed.  Read what was said.  Footers aren't RFC
compliant, that doesn't mean they're not allowed.  List-headers on the other hand
need to be compliant (and in this case, are).

AMK4

--
W |
  |  I haven't lost my mind; it's backed up on tape somewhere.
  |
  ~
  Ashley M. Kirchner    .   303.442.6410 x130
  SysAdmin / Websmith   . 800.441.3873 x130
  Photo Craft Laboratories, Inc. .eFax 248.671.0909
  http://www.pcraft.com  . 3550 Arapahoe Ave #6
  .. .  .  . .   Boulder, CO 80303, USA



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[jtrigg]

On Wed, May 09, 2001 at 12:59:58AM +0530, Satya wrote:
> On May 8, 2001 at 14:12, Bill Warner wrote:
> 
> >Why?  IMO, the List-* headers are excessive and should, at the very least, 
> >be configurable.  If I want my list message to carry this info I can 
> >already put it in the footers.  Why should I force everyone to scroll past 
> >a page long list of headers?!
> 
> What long list? They don't show in the default view of Pine.

They do, however, in the default views of mutt and Eudora.

> The List-headers are RFC-compliant. Footers are not.

What RFC says that footers are not allowed?

Jim Trigg
-- 
Jim Trigg  /"\
SKA Blaise de Cormeilles   \ / ASCII RIBBON CAMPAIGN
Hostmaster  X   HELP CURE HTML MAIL
Academy of S. Gabriel  / \

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Chuq Von Rospach]

On 5/8/01 12:12 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:

> 
> Why?  IMO, the List-* headers are excessive and should, at the very least,
> be configurable.  If I want my list message to carry this info I can
> already put it in the footers.  Why should I force everyone to scroll past
> a page long list of headers?!

You should have made those comments to the standards committee. The RFC is
the RFC. 

(hint: any DECENT mail client can be configured to show or hide header
lines...)



--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Mike Noyes]

At 2001-05-08 14:12 -0500, Bill Warner wrote:
>At 12:01 PM 5/8/01 -0400, [EMAIL PROTECTED] wrote:
>> > How should I remove these (excessive headers) on each post?  makes my
>> > message long.
>>
>>You would be generally ill advised to remove any of them.
>
>Why?  IMO, the List-* headers are excessive and should, at the very least, 
>be configurable.  If I want my list message to carry this info I can 
>already put it in the footers.  Why should I force everyone to scroll past 
>a page long list of headers?!

Bill,
This may help you.

List Headers - Eudora (Win) users

You can hide the new list headers. Edit your Eudora.ini file, and add this 
line under [settings].

TabooHeaders=List,X-UID,Received,Status,X-UIDL,Message,In-Reply, \
X-Priority,Mime-Version,Content,X-Persona,Resent-Message,References, \
Return,X400,X-400,Mail-System,Errors-To,X-List,Delivery,Disposition, \
X-Juno,Precedence,X-Attachments,X-MSMail,X-MimeOLE,X-Nav

note: everything other than "List" is the default

ref. Eudora .ini Settings TabooHeaders
http://www.eudora.com/techsupport/ini.html

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[Satya]

On May 8, 2001 at 14:12, Bill Warner wrote:

>Why?  IMO, the List-* headers are excessive and should, at the very least, 
>be configurable.  If I want my list message to carry this info I can 
>already put it in the footers.  Why should I force everyone to scroll past 
>a page long list of headers?!

What long list? They don't show in the default view of Pine.

The List-headers are RFC-compliant. Footers are not.

We've already had this discussion. Twice, I think.

-- 
Satya. http://satya.virtualave.net/>
US-bound grad students! For pre-apps, see http://quickapps.cjb.net/>
Reactor error -- core dumped.


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

[Mailman-Users] Re: remove this?

[Bill Warner]

At 12:01 PM 5/8/01 -0400, [EMAIL PROTECTED] wrote:
> > How should I remove these (excessive headers) on each post?  makes my 
> message long.
>
>You would be generally ill advised to remove any of them.

Why?  IMO, the List-* headers are excessive and should, at the very least, 
be configurable.  If I want my list message to carry this info I can 
already put it in the footers.  Why should I force everyone to scroll past 
a page long list of headers?!


--Bill


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

Re: [Mailman-Users] Re: remove this?

[J C Lawrence]

On Sat, 05 May 2001 03:52:55 +0800 
spades  <[EMAIL PROTECTED]> wrote:

> How should I remove these on each post?  makes my message long.

You would be generally ill advised to remove any of them.

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users

[Mailman-Users] Re: remove this?

[Spades]

How should I remove these on each post?
makes my message long.

X-Ack: no
X-BeenThere:
X-Mailman-Version: 2.0
Sender: 
Errors-To: 
X-BeenThere:
List-Help: 
List-Post: 
List-Subscribe:
List-Id: 
List-Unsubscribe:
List-Archive:


--
Mailman-Users maillist  -  [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users