"Brad" == Brad Knowles brad@stop.mail-abuse.org 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.