[Mailman-Developers] Patch for Mail Archive mirroring

Jeff Marshall marshman at frozenbear.com
Fri May 6 04:14:40 CEST 2005

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

- 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.

- 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 at frozenbear.com

-----Original Message-----
From:  Brad Knowles 
Date:  5/3/05 1:56 am
To:  Stephen J. Turnbull
Cc:  mailman-developers at 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 

	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 at 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 at python.org
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%40frozzenbear.com

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

More information about the Mailman-Developers mailing list