I figured I would attempt a brief summary of major points brought up by the discussion.

Concerns

• proper documentation describing the feature and possibly Mailman's position on archiver tie-ins
• make sure it defaults to off (it currently does)
• we should look for opportunities to add safeguards
• one possible safeguard - an option for admins to add the "X-No-Archive: yes" header - has pros and cons (cons: does it conflict with local pipermail archiving? possible conflict with user's X-No-Archive intentions?)

Is it an endorsement?

• people ranged from "seems like an endorsement" to "no more than mailman endorses the other software it works with"
• I'm happy to do the work to make this feature work with other archiving services as well. Gmane looks like it is out. I will check with Hank at MARC.

Overall

• seems like most people think it is a positive patch (with the caveat that it defaults to "off") because it makes things easy for admins that choose to use it
• in the end, it's up to Barry and Tokio. Hopefully one of them can jump in briefly and make the call, or ask me for some rework on the patch.

Corrections or clarifications are welcome.

Thanks to everyone for their consideration and response; people seemed to put a lot of energy into this. Much appreciated.

Jeff Marshall marshman@frozenbear.com

-----Original Message----- From: Brad Knowles Date: 5/3/05 1:56 am To: Stephen J. Turnbull Cc: mailman-developers@python.org, Chuq Von Rospach , Chuq Von Rospach Subj: Re: [Mailman-Developers] Patch for Mail Archive mirroring

At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote:

Sure, they _are_ different, in a relevant way---they exist to broaden distribution, including archiving. But I think that in the great majority of cases where random users can just sign up, that is a service to be encouraged. It's not a good idea to put the burden of proof on them, when either the list-owner can be more selective about membership, or they can use X-No-Archive.

The problem here is that Mailman should not be adding an 

"X-No-Archive:" header to messages that it is processing. This is something that should be controlled from the perspective of the user, and Mailman should not be stepping on their toes.

Moreover, if Mailman did add such a header, what would happen to 

the internal archiving system? Would Mailman ignore the header that it has added while honoring the same header that might have been put on the message by the user?

As a list admin, I can see a strong desire to keep your own 

archive, but to want to prevent anyone else from maintaining an archive, at least not without your express approval. Unless, that is, you gateway to USENET news, in which case Google and others have news archives that you could not control and could not even be aware of in most cases. But then if you gateway to USENET news, you should be aware of this issue, and be prepared for what might happen.

Again, I'm not really arguing against the patch. It's the people who might be doing extra releases (Barry and Tokio, right?) or answering the FAQs (Brad and Mark, primus inter pares) who should decide if it belongs in the Mailman distribution.

IMO, the ultimate decision is up to Barry -- it's his project, 

and he gets to decide how things go. However, he is currently focusing on Mailman3 right now, and Tokio is the release engineer for Mailman2, and in the past Barry has been open to comments and suggestions from others. So, I imagine he might make his feelings known, but then leave the ultimate decision to Tokio, who would hopefully also take input from others.

However, I don't see that Mark or I would necessarily have any 

more weight given to our comments during that discussion as a result of our work with the FAQ and answering the questions. I would hope that we would be heard along with the others commenting on the subject, and appropriate weight would be given to them by Barry and Tokio, but more based on their merits than on the work we do with the FAQ.

There are plenty of other knowledgeable people on mailman-users 

and mailman-developers who don't (or haven't recently) done much of anything with the FAQ, and I would hope that their voices would be given as much weight relative to their experience as would ours.

I do advocate some kind of public statement about the policy toward adding new facilities of this kind. One easy one would be "you write the patch, and show that you conform to certain rules such as 'patch defaults off' and 'service respects X-No-Archive as well as conforming to relevant RFCs', and we'll put it in to the next regular release that isn't already in feature freeze."

I'm not so sure this is a good idea.  At least, not so far as 

guaranteeing that it would be put in the next regular release. IMO, if the patch defaults to off, and the service conforms to the relevant RFCs and BCPs, then I think we should give it serious consideration, but I wouldn't want to guarantee anything more than serious consideration.

Or maybe it's worth encouraging such services, and being more helpful about it.

I would encourage more people to make patches, and to try to be 

more helpful about this process in general. But I wouldn't want to make any guarantees as to what would/would not get included -- everything should get the appropriate level of consideration, but no guarantees beyond that.

-- Brad Knowles, brad@stop.mail-abuse.org

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

SAGE member since 1995. See http://www.sage.org/ for more info.

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/marshman%40frozzen...

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http