Mailman 3 February 2000 - Mailman-Developers

RE: dont request passwords from web subscriber patch
by lee＠ufojoe.com 17 Feb '00

17 Feb '00

Fri, 7 Jan 2000 14:58:16 +0100 (MET) Fil fil(a)bok.net wrote: > >could the maintainers tell me if this patch is accepted or rejected ? >Patch name : dont request passwords from web subscriber I'm sorry to see no answer. I will be looking at adding it. However I seems to me to be only half an answer. The other half is allowing un-subscribe without password. If not you risk trapping silly buggers as if you were fly paper. An "only allow random password" mode would have the benifit of substiantially raising the bar for writting cgi to raid / spam a site, by making them parse email as well. ----------- ufojoe -------------------------------- 50 Canadian Folk Festivals http://www.interlog.com/~ufojoe/

2 1

sugg: disable notify when using remove_member
by Christopher Kolar 17 Feb '00

17 Feb '00

Hi everyone. Is there any chance that a toggle could be added to the remove_member program to make it function like add_member with respect to notification? We have a lot of lists that get cleared out periodically, and we have a lot of users who leave us every semester, and the notification either generates unnecessary helpdesk calls from the confused or generates bounces from people whose accounts are no longer active. I am not asking for it to be added to the web interface, because I know that it can be abused, but it would be nice at the command line for some of the more heavy-duty automated things that we are putting together. Cheers, --chris -- /////\\\\\/////\\\\\ Christopher G. Kolar Director of Instructional Technology Aurora University, Aurora, Illinois ckolar(a)admin.aurora.edu -- www.aurora.edu/~ckolar [PGP Public Key ID: 0xC6492C72]

2 1

Message.Message
by Ricardo 'admindb' Kustner 15 Feb '00

15 Feb '00

Hi, It seems like nobody looked at the changes i've posted for admindb.py cause i just found out that I made it more difficult than necessary to seperate the message body from the header :) This funcinality is already possible using MM/python libs : fp = open(os.path.join(mm_cfg.DATA_DIR, filename)) fullmsg = Message.Message(fp) msg_header = string.join(fullmsg.headers, '') msg_body = fullmsg.body fp.close() ...on the bright side, I learned a bit more about python and the MM code :) oh i just realized, that this way the ADMINDB_PAGE_TEXT_LIMIT isn't taken into account... :( Ricardo.

1 0

Re: [Mailman-Developers] Mailman limitations
by Harald Meland 15 Feb '00

15 Feb '00

[Gerrit Holl] > Harald Meland wrote on 950465938: > > > > I don't want to give anyone the idea that the direction of Mailman > > development is not properly influenced by the input from the members > > on this list -- after all, discussing Mailman development is what this > > list is for. > > I've already sent some patches to this list, but none were > implemented. For example, my latest patch, it added docstrings to > many methods of MailList. Sorry, I haven't gotten around to that -- and, as I've tried to indicate, my local tree is regrettably quite a bit out of sync with CVS right now :( I'm trying to use whatever time I can find to backport the parts of my local tree that can/should go into CVS _now_ -- and get up to date with this list. However, I have put your messages in the "look at this when I have time" category -- I'll try to become better at notifying people whenever I put stuff into that category. > Who have access to the CVS tree? The five people mentoined in the > acknowledgements file? AFAIK: Yes, only the "core developers" have CVS write access. I think there have been some attempts to make that situation better whenever it got clear that all the core developers were to busy with other stuff, but I don't think anything has come of these attempts yet. Hmmm, would SourceForge solve any of this? -- Harald

1 0

list admin guide v0.2 now online
by Christopher Kolar 14 Feb '00

14 Feb '00

Hello everyone. It has been a while since I last updated the information, but I have finally gotten around to making revisions to my first attempt at MailMan documentation. The second versions of the list administrator's guide and quick reference are now online at: www.aurora.edu/~ckolar/mailman This document has been prepared for list owners: people who are not necessarily technical but who own a MailMan list. For various reasons I am locked into doing them in HTML for the time being, but will someday take it all and put it into TexInfo format. Please feel free to send me feedback. --chris -- /////\\\\\/////\\\\\ Christopher G. Kolar Director of Instructional Technology Aurora University, Aurora, Illinois ckolar(a)admin.aurora.edu -- www.aurora.edu/~ckolar [PGP Public Key ID: 0xC6492C72]

1 0

Re: [Mailman-Developers] Mailman limitations
by Harald Meland 14 Feb '00

14 Feb '00

[Thomas Wouters] > But Mailman is, in my opinion, nowhere near complicated enough to > make it easy to misconfigure it. Yet. With a few exceptions (read: weird special cases), I agree. > > Ideally, we'd like to support as big a set of (good :) features as any > > other mailing list administration package, but without alienating > > first-time Mailman list administrators through a veritable maze of > > list settings, all of them interconnected... Good documentation might > > solve part of this, but if there are (overly) complex features the > > corresponding documentation will probably have to be complex as well, > > meaning that the Mailman learning curve gets steeper. > > Exactly. And let me tell you that good documentation is not enough if the > first look the fresh administrator gets of his new list is as complicated as > the bridge of the USS Enterprise. That's what the "might solve _part of_ this" stuff was meant to imply... ;) > However, I dont think redesigning the adminpages to make it all fit AND > appear sane, is impossible. But, are "sane" and "user understandable" interchangeable? (Sorry, the bofh part of me took control there for a minute :). > I think it can be done with just a little bit of thought ;) > Currently, the admin page is, to be frank, overwhelming. Yup -- that's the reason I'm somewhat sceptical to accept patches for new "special case" features. > The moment you open the page, you get a large list of options to > select from. Some of these are useful and clear. Others, most, are > more-or-less obvious, but not of interest. And some are plain > weird. You do your best to browse them and edit them to your need, > and then you look up, and you see that you have *seven*more*pages* > to do ! AND three more pages, which may contain more links, of other > administrativia ! I guess this is a bit like what kind of stereo systems people prefer -- some people want the one with the most buttons (and flashing lights), while other people just want something that *works*. :-D Some time back, someone asked whether it would be possible to have different "styles" on the list admin pages -- i.e., the more techish admins would get the full (overwhelming) set of admin settings, while newbie admins would get a (much less confusing and) smaller set of the most commonly used list settings (possibly with the option of getting access to the full set of settings if they e.g. followed some "for expert list admins" link). Which set of options to present to the admin could either be settable per list or per admin (when we get the user database in place). There have also been a little talk of even more generic solutions to this -- e.g. implementing list configurations as inheritance hierarchies, so that a change to the "base" configuration would automatically affect all the lists that inherit the attributes that were changed but don't override them. <rant> However, it seems to me that every time we start discussing advanced web interface stuff, someone mentions integrating Mailman with Zope -- which it is said would buy us a lot of neat features practically for free -- and people go "Yeah" and "Cool" and "Sounds like a perfect match"... and then nobody actually _do_ anything about it all. :) Should Mailman be integrated with Zope? Would such a change mean that Mailman has to _rely_ on Zope being installed, or would it be feasible (and resonably easy) for Mailman to take advantage of Zope only if it's available (at run time? Or at install time?)? What advantages would such a change buy us? Are there things we want to do anyway, and which would _have_ to be changed to integrate with Zope, and thus could be started work on right away? Should all of this wait until after the next Mailman release is completed? ;) Is my ranting about this at all called for? ;) </rant> > What needs to be done mostly is just creating more but smaller pages, > especially for the current 'general options' and 'privacy options' pages, > plus for whatever options are added. To me, having a tangle with lots of different pages with few options on them isn't really much better than a tangle with lots of options on a few pages. The _real_ problem is to avoid the tangle. I agree that the structure of the current admin pages aren't optimal, though -- but restructuring the pages will only take us so far if we start adding specialcase code left and right. > (While I was writing this and thinking it up (in that order ;) I thought how > incredibly cool it would be to have some kind of rule-based message > acception (/refusal/holding/discarding/temp-fail/...) system, where each > rule could be header-match, number of postings to the list so far, load of > the machine matched against a priority for the list or user, time of day or > whatever. And where each rule would have it's own default reject/accept > messages, of course. Not very hard to implement in Python and the current > 'pipe' architecture, if I may be so kind. But for the life of me I can't > figure out how to make such a scheme configurable through an HTML page ;P) That's *exactly* the way I feel about that stuff. :) Of course, you could just let the admin edit the rules as pure text -- and then have the CGI script do the appropriate syntax checks and other sanity checks/rule validation before actually changing the list's configuration. Of course, that would mean we're _very_ close to significantly affecting the slope of Mailman's learning curve. > > > I can't say for certain what parts are currently being developped, > > > though, I'm relatively new on this list, and a lot of development > > > seems to happen behind the scenes. > > > I'm not quite sure what you mean by that, but just to clarify: I try > > to keep/redirect whatever discussions on Mailman development I get > > involved in to this list. However, I've "been away" for some time, > > busy doing Real Work -- part of which was to implement new Mailman > > features that we here at uio.no were in pressing need of. > > > I don't want to give anyone the idea that the direction of Mailman > > development is not properly influenced by the input from the members > > on this list -- after all, discussing Mailman development is what this > > list is for. > > I'm sorry, I didn't mean to imply that this list was defunct, or that > mailman development is dead, or that people are wasting their time waiting > for the developers, or any of that. Good -- and I tried to phrase the above in a way as not to suggest that I thought you did -- it was meant purely as an clarification, not as some kind of an accusation. > It's just that I dont see the lively discussions I'm used to I can relate with that -- but I can't really figure out why that's how things are here at mailman-developers... > Or maybe I hadn't realized how busy the cabal is -- having a fun > project (Mailman) highish on my priority list for once makes me > slightly impatient. You want us to believe that normally you're _not_ impatient? Yeah, right... ;-D > I shouldn't complain, anyway. Most of my patches have received good > commentary, and one even got applied ! Well, neither should we... just keep'em coming. Cheers, -- Harald

3 2

Re: [Mailman-Developers] Mailman limitations
by Harald Meland 14 Feb '00

14 Feb '00

[Thomas Wouters] > On Sat, Feb 12, 2000 at 12:23:47PM -0800, Edward Elhauge wrote: > > > What I don't like is that I can't run the lists on autopilot mode. > > I'm not sure what would constitute autopilot mode. I concur that some things > in Mailman could be made more selfreliant, like bluntly refusing some > messages, but making it work right all the time is pretty hard. Ummm, yes -- if by "working right" you mean "reject the messages the admin _wants_ to have rejected, regardless of how list is actually configured" :) What I think is needed (as a start), are variants of the various "blocks" we have in place now, which would discard (into the big bit bucket, with no message to the sender) or reject (send the message back to the sender) incoming messages, as opposed to just "holding" them. There are some issues to be resolved with this, of course. For one, it shouldn't be too easy for Mailman list administrators to misconfigure their lists in a fashion that discards (or, possibly, rejects) incoming messages -- as that might lead to Mailman seeming reckless with incoming messages. Deciding upon exactly what "too easy" means in terms of implementation is, of course, the hard part. Next, there's the issue of not over-complicating the admin pages. Ideally, we'd like to support as big a set of (good :) features as any other mailing list administration package, but without alienating first-time Mailman list administrators through a veritable maze of list settings, all of them interconnected... Good documentation might solve part of this, but if there are (overly) complex features the corresponding documentation will probably have to be complex as well, meaning that the Mailman learning curve gets steeper. > I can't say for certain what parts are currently being developped, > though, I'm relatively new on this list, and a lot of development > seems to happen behind the scenes. I'm not quite sure what you mean by that, but just to clarify: I try to keep/redirect whatever discussions on Mailman development I get involved in to this list. However, I've "been away" for some time, busy doing Real Work -- part of which was to implement new Mailman features that we here at uio.no were in pressing need of. I don't want to give anyone the idea that the direction of Mailman development is not properly influenced by the input from the members on this list -- after all, discussing Mailman development is what this list is for. Cheers, -- Harald

3 2

admindb.py heldmsg template
by Ricardo Kustner 14 Feb '00

14 Feb '00

Hi, well... I've made some more changes in admindb.py in my local copy of MM (cvs version) ... I've replaced the part that generates the html for messages that are held for approval with a template (using the neat mlist.ParseTags() function)... so this way it's much easier (IMHO) to make changes in the functionality and gives the admin more freedom in designing the admin pages. I've seen a lot of place in the MM code where html is being generated by python code... I personally think that the html should be left outside the code as much as possible ... would also make it a lot easier to translate the output to other languages, doesn't it? Maybe it seems a bit silly that i focus so much on such a small part of MM, but the admindb pages are important for the way i handle our mailinglist plus I have some ideas i'd like to implement. In case anyone is interested, below is my updated patch, and I'll attach a sample heldmsg.html template (oh look a html attachment! :) ) Ricardo. *** admindb.py Mon Feb 14 16:25:43 2000 --- /usr/local/cvs/mailman/Mailman/Cgi/admindb.py Mon Nov 15 23:29:46 1999 *************** *** 195,211 **** form.AddItem(Center(Header(2, msg))) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename)) ! msg_header = "" ! msg_body = "" ! for line in fp.readlines(mm_cfg.ADMINDB_PAGE_TEXT_LIMIT): ! if msg_body == "": ! if line != "\n": ! msg_header = msg_header + line ! else: ! msg_body = line ! else: ! msg_body = msg_body + line ! fp.close() except IOError, (code, msg): if code == ENOENT: --- 195,201 ---- form.AddItem(Center(Header(2, msg))) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename)) ! text = fp.read(mm_cfg.ADMINDB_PAGE_TEXT_LIMIT) fp.close() except IOError, (code, msg): if code == ENOENT: *************** *** 219,242 **** pass return raise ! ! replacements = mlist.GetStandardReplacements() ! ! replacements['<mm-heldmsg-from>'] = sender ! replacements['<mm-heldmsg-reason>'] = reason ! replacements['<mm-heldmsg-subject>'] = subject ! replacements['<mm-heldmsg-id>'] = `id` ! replacements['<mm-heldmsg-comment>'] = ("Please do *not* post administrative requests" " to the mailing list! If you wish to subscribe," " visit %s or send a 'help' message to the" " the request address, %s , for instructions" % (mlist.GetAbsoluteScriptURL('listinfo'), ! mlist.GetRequestEmail())) ! replacements['<mm-heldmsg-header>'] = msg_header ! replacements['<mm-heldmsg-excerpt>'] = msg_body ! ! form.AddItem(mlist.ParseTags('heldmsg.html', replacements)) ! form.AddItem('<p>') --- 209,239 ---- pass return raise ! t = Table(cellspacing=0, cellpadding=0) ! t.AddRow([Bold('From:'), sender]) ! t.AddRow([Bold('Reason:'), reason]) ! t.AddRow([Bold('Subject:'), subject]) ! t.AddRow([ ! Bold('Action:'), ! RadioButtonArray(id, ("Approve", "Reject", "Discard (eg, spam)")) ! ]) ! t.AddRow([ ! Bold('If you reject this post, explain (optional):'), ! TextArea('comment-%d' % id, rows=4, cols=60, ! text=("Please do *not* post administrative requests" " to the mailing list! If you wish to subscribe," " visit %s or send a 'help' message to the" " the request address, %s , for instructions" % (mlist.GetAbsoluteScriptURL('listinfo'), ! mlist.GetRequestEmail()))) ! ]) ! row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ! t.AddCellInfo(row, col, colspan=3) ! t.AddRow([Bold('Message Excerpt:'), ! TextArea('fulltext-%d' % id, text, rows=10, cols=60)]) ! row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ! t.AddCellInfo(row, col, colspan=3) ! form.AddItem(t) form.AddItem('<p>')

1 0

Re: [Mailman-Developers] cron/gate_news watermark == 0
by Harald Meland 14 Feb '00

14 Feb '00

[Jim Tittsler] > On Sun, Feb 13, 2000 at 08:57:20PM +0100, Harald Meland wrote: > > Or, even better, move the per-list watermark info from gate_watermarks > > into the list's config.db, replacing any 0 values in gate_watermarks > > with None values in config.db. This has the advantage of reducing the > > number of different files that would have to be changed when > > cloning/renaming a list. > > This seems logical to me, since I think the administrator really wants to do > the "catch up" any time gateway_to_mail transitions from No to Yes (implying > that it needs to be able to update the watermark, either in config.db or by > locking(?) and updating gate_watermarks). I agree completely. > With the present behavior, watermarks don't appear to be deleted if you stop > gatewaying a newsgroup for a while. Correct. And yes, that could be considered a bad thing... > (You could del the watermark entries any time gate_news was run and > the list wasn't marked as gatewaying... that seems unclean, but a > smaller patch. :-) "Small is beautiful" isn't _always_ the best of strategies :) Do you feel up to making a new, slightly more complex patch implementing this change, or should I (or someone else) start looking into it? -- Harald

1 0

Re: [Mailman-Developers] When will mailman 1.2 be released?
by Harald Meland 13 Feb '00

13 Feb '00

[Ricardo Kustner] > does python has something simular like Perl's DBI module ? I can find no particular python module corresponding to the perl DBI module, but there does exist an API specification to which the various database modules should conform. See <URL: http://www.python.org/sigs/db-sig/>. -- Harald

2 1