[Mailman-Developers] Patch for Mail Archive mirroring

Bob Puff bob at nleaudio.com
Fri May 6 08:28:59 CEST 2005 

Personally, I'd much rather see the HT/Dig patch implemented before this one.
 That is IMHO more useful to the average mailman admin than this.

Bob


---------- Original Message -----------
From: Jeff Marshall <marshman at frozenbear.com>
To: brad at stop.mail-abuse.org, stephen at xemacs.org
Cc: mailman-developers at python.org, chuqui at plaidworks.com
Sent: 05 May 2005 19:14:40 -0700 
Subject: Re: [Mailman-Developers] Patch for Mail Archive mirroring

> 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 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 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 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
> 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%40frozzenbear.com
> 
> Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.http
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/bob%40nleaudio.com
> 
> Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp
------- End of Original Message -------

More information about the Mailman-Developers mailing list