[Mailman-Developers] Patch for Mail Archive mirroring
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.
marshman at frozenbear.com
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
> 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/
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http
More information about the Mailman-Developers