Mailman 3 May 2005 - Mailman-Developers

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 15 May '05

15 May '05

Barry wrote: > I think I've stated my general philosophy in a previous message. > If WizzyMTA came with a new plug-in, documentation, and some promise > of support help (if only to answer questions on mailman-users), we'd > probably add the module in the next release. If we had a similar plug-in > architecture for multiple 3rd-party archivers, we'd facilitate the same > kind of thing for that service. I'd be all for that. Thanks for your feedback. I'll be happy to dig into the current archive system and work on a plug-in architecture to support multiple external archivers. I originally thought the Archive component of Mailman was something intended only to support the local pipermail archive, but using that API like you mention sounds like it would work well. I'm guessing it'd be a fair amount of work to make the internal pipermail work with the plug-in approach just like the external archivers. At the very least, it would need a lot of testing to make sure it doesn't break existing installations. I'll get back with MARC and possibly GMane so I can try to make things as general as is reasonable. I'll try to run a proposed approach in front of the list before coding it (unless it's easy enough to demonstrate the proposal via code). I think the only concern is that I think admins *would* find value in per-list control of external archives. This is speculation, though. Jeff

6 6

Mailman 2.1.6 release candidate 4
by Barry Warsaw 14 May '05

14 May '05

A few more last minute fixes and some language updates. Please let me know if you encounter any show stoppers. Barring any really critical bugs, this is going to be 2.1.6 final. -Barry https://sourceforge.net/project/shownotes.php?release_id=327367

1 0

subject_prefix multiplication
by Mark Sapiro 13 May '05

13 May '05

All of a sudden, within the last hour or so, subject_prefix on both mailman-users(a)python.org and mailman-developers(a)python.org is being added to replies even though it's already present resulting in doubling and tripling (so far not more) of the prefix. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 5

Patch for Mail Archive mirroring
by Jeff Marshall 13 May '05

13 May '05

I have submitted a patch to SourceForge for consideration. Feature: - New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive(a)mail-archive.com address from the subscriber list. The benefit to the list admin is to have a one-click setup option to provide them with mirroring and searchable archives. We (me and the other Jeff that admin The Mail Archive) have spoken with Lars at Gmane to see if we could make this work for Gmane as well, but he said their subscription process is manual and requires extra information, so Lars didn't think it would work for him. Patch was made against the latest CVS in branch Release_2_1-maint, which is currently 2.1.6rc3. Feedback? Thanks. Jeff Marshall marshman(a)frozenbear.com

13 36

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 12 May '05

12 May '05

I wrote: > I will check with Hank at MARC. One more followup. I emailed with Hank at MARC (marc.theaimsgroup.com). Hank really likes the idea and tried enhancing the patch to cover MARC as well. He ran into a few issues that caused him to abort the attempt ["...setting of the List-Archive: URL header. MARC (and I think Gmane too) sometimes takes liberty with list names, such as for a project foo, if they've a list "users" we add it as "foo-users" (as opposed to Mail Archive's equivalent "users(a)foo.org" which works to keep them unique). That also makes it difficult to make meaningful predictions for what the resulting URLs will be, or checking the subscription list, etc. "]. So for now Hank is passing on resolving those issues, although he's willing to put more effort into it if people want the MARC option. Jeff

1 0

Re: [Mailman-Developers] Patch for Mail Archive mirroring
by Jeff Marshall 06 May '05

06 May '05

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(a)frozenbear.com -----Original Message----- From: Brad Knowles Date: 5/3/05 1:56 am To: Stephen J. Turnbull Cc: mailman-developers(a)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(a)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(a)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%40frozze… Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http

3 2

XHTML Compliant Web UI - 2.1.6 Patch
by Bryan Carbonnell 05 May '05

05 May '05

I have just uploaded a patch that will make the web UI for MM 2.1.6rc1 XHTML 1 strict compliant. This patch allows for some CSS formatting as well. I have tried to make all the pages compliant, but I may have missed some combinations of pages and options, so if you find some that aren't compliant, please let me know which page isn't compliant and under which circumstances it's not. It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it,since this is my first attempt at something like this. -- Bryan Carbonnell - carbonnb(a)gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!"

3 2

Re: [Mailman-Developers] [ mailman-Bugs-871050 ] Uncought runner exception: Empty module name
by Steven G. Willis 02 May '05

02 May '05

It hath once been written: >UITB-Originating-Server: 194.109.24.25 (smtp-vbr5.xs4all.nl) The email (SMTP) server at 194.109.24.25 has been documented as: sending unsolicted email; on a network that sends unsolicited email; participated in a coordinated attack on our network (open bounce relay). You can view a direct report for the IP in question at: http://www.uitb.deepskytech.com/show_ip_report.php?ip=194.109.24.25 The bounces contain enough information for you to identify the general source of the problem. You should also have enough information to contact us directly for any details you may need in identifying the specific problem that exists in your email server(s)/network. Once you have corrected the problem(s) , please notify us of this. We can then confirm that the problem(s) has been corrected and remove the block that is in place for your email server(s)/network. ------------------------------------------------------------ NOTE: the issues on file from this location are simple enough to correct. Once these issues have been corrected, please contact us with the following information: IP Address(es) of SMTP Server(s) Managed: Host names of SMTP Server(s): Full Name/Role: Company Name (if any): Voice Phone Contact: Email Address: Full Snail Mail Address: We will use this information to create an "Allow record" for the IP addresses managed as SMTP servers by this individual/role. The information within an Allow record is kept private within the UITB.com system. And, once an Allow record has been created for particular IP address(es), then any future issues we see originating from there will result in a notification email being dispatched instead of immediate blocking; this allows for the situation noted to be corrected before any blocking is put into place that may possibly affect users. Let me know if you have any questions on this or if we can help in any way. Cheers! ================================================================ Steven G. Willis sgwillis(a)deepskytech.com 866.224.3058 Deep Sky Technologies, Inc. http://www.deepskytech.com/ http://www.badchickens.com/ http://www.store-secure.com/ AIM-iChat: dstisgwillis ================================================================ All words are plastic. Word images begin to distort in the instance of utterance. Ideas imbedded in a language require that particular language for expression. This is the very essence of the meaning within the word "exotic". ================================================================

1 1

max_days_to_hold
by Barry Warsaw 02 May '05

02 May '05

I just upgraded all the lists @python.org from 2.1.5 to 2.1.6rc3. I noticed that they all grew a max_days_to_hold = 3 value. I actually don't understand this since version.py has a add_only_if_missing('max_days_to_hold', 0) call. So shouldn't they all have gotten set to zero? I'd like to figure this out before we release 2.1.6 final. Also, I plan on changing DEFAULT_MAX_DAYS_TO_HOLD to 0 in Defaults.py.in because I don't think this should be enabled by default for new lists (it's a new feature in a maintenance release). -Barry

1 0