>>>>> "Brad" == Brad Knowles <[EMAIL PROTECTED]> writes:
Brad> At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote:
>> 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.
Brad> The problem here is that Mailman should not be adding
Brad> an "X-No-Archive:" header to messages that it is processing.
Brad> This is something that should be controlled from the
Brad> perspective of the user, and Mailman should not be stepping
Brad> on their toes.
OK. I can't find a spec for the X-No-Archive header that looks
"official", but the USEFOR draft for the "Archive" header does say
"for use by the poster".
Brad> Moreover, if Mailman did add such a header, what would
Brad> happen to the internal archiving system? Would Mailman
Brad> ignore the header that it has added while honoring the same
Brad> header that might have been put on the message by the user?
Exactly. You'd just put the "Add X-No-Archive header" handler in the
pipeline after Mailman's archiver. The list admin already has control
of Mailman's internal archiver.
Brad> As a list admin, I can see a strong desire to keep
Brad> your own archive, but to want to prevent anyone else from
Brad> maintaining an archive, at least not without your express
Brad> approval.
I think the semantics are arguably OK here as long as Mailman passes
through any existing X-No-Archive header (or Archive, when that gets
out of draft status). The user has no right to expect to be archived
elsewhere if the list master's policy is "we do our own archiving."
But yes, Mailman should respect the RFCs (including drafts, for
optional facilities it wants to use). Too bad.
Maybe you could make it part of the user's configuration. Then the
list master could default it to X-No-Archive: yes; individual users
could turn it to no if they want to, including on a message by message
basis. A stretch, I know, but it would be really horrible to have to
have separate archiving control headers for the user and the list, and
to have to establish a precedence, etc.
>> 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."
Brad> I'm not so sure this is a good idea. At least, not so
Brad> far as guaranteeing that it would be put in the next regular
Brad> release.
I'm happy with your phrasing of "serious consideration." Nothing's
guaranteed in a volunteer maintained project, of course.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
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/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
