Features requested...
Hi Everyone,
I have a several ideas for features that may be of interest. Theirimplementation would certainly be to my benefit. I've listed them below.
FYI, I'm testing out Mailman as a replacement for my campus' existingMajordomo setup. If I can just get a few issued resolved, I think the transition will go easily.
Please add an option so subscribers can elect to show only the username part of their e-mail address in the subscriber list instead of the whole thing (regardless of the @->" at " conversion).
In the section of the listinfo page where a user can subscribe to the list in question, please add another radio-button option for "Conceal yourself from subscriber list?" if the list's subscriber list can be seen by the list members or the public. I'm somewhat of an anti-spam nut so I don't like having my e-mail address publically visible in any form.
Allow the system-wide admin to disable the mail->news and news->mail gatewaying for the whole system and/or for selected lists. (I've got some list admins that want to use this, but I *really* don't want to see that kind of traffic on my server. Not to mention the liability issues...)
On the membership management admin page, please setup a mechanism for large lists to limit the display of user options to X number of users per page. It's a killer to try to admin large lists from slow machines with limited memory. (ex, took me a long time and a lot of swapping to load the page for a 3000 member list)
Please setup a means by which a user can specify what additional addresses he/she posts from other than their subscription address. (For example, my campus has a mail aliasing system so that all public addresses have the form "firstname.lastname@usm.edu" or similar. But the address they post from may be "username@host.usm.edu" or similar. This becomes a problem for lists that have member_posting_only turned on.)
Please setup a mechanism for a pre-made set of options to be used as defaults when creating new lists. For instance, on our campus, we have a form that prospective list owners fill out to request a new list. On this form, we have the following options for them to "check" that determine how their list is initially setup.:
Archived list (Duh) Closed list (Subscriptions requests must be approved list list owner. Otherwise list is "Open" and anyone may subscribe.) Secured list (Only list members may post to the list) Moderated list (list owner must approve all posts to the list) Announcement (List will be used for outgoing announcements only. Implies moderated and secured.)
I don't mind creating files with all of the configuration options and their default config values. I just need a snippet of code to read the values in and use those as defaults when creating the list. And then, perhaps if I combined that with #7 below, I could get it to automatically import the configuration of a previous majordomo list... (I don't know how either of these would work with the idea to create lists from a site admin page, tho. Perhaps the site admin could choose from a pull-down menu of option pre-sets or pre-existing majordomo lists when creating a mailman list?)
If anyone has written a withlist module that can read in the values in an existing Majordomo 1.94 config file and update the corrosponding values in a Mailman list's config db, I'd be ever so greatful to get a copy. This would make transitioning to mailman *so* much easier than having to do each list by hand through the web interface.
The <body> tag is not currently setup right for error pages.
Please build-in the option for individual list owners to filter binary attachments. (I think something like this is already in the works, but I'd like it to be a per-list option settable by the list owner.)
In the pipermail archives, please do the following:
move the archives to http://host/mailman/archives/listname or provide a redirect from there to http://host/pipermail/listname.
implelement a link for users to reply to posts in an archive by using a mailto: URL to open up a mailer window from their browser. Or perhaps make this optional on a per-list basis. (Note: this might break threading if a specific "In-Reply-to" header can't be added)
in threaded view: (a) add links at the bottom of each post to go back to the previous thread and forward to the next. (b) perhaps setup a mode where a user could see all the threads expanded on one page (as it is now) or see all the thread titles on one page and clicking them expands the thread into a new page.
Lastly, I'd like to note that, while I understand most of what's going on in the code, I don't have time ATM to sit down and really learn Python. Hence, I don't have the expertise to go about making most of these modifications myself. I do, however, plan to sit down and learn Python as well as possible over the holiday break. So perhaps I can pitch in directly during the new year.
Thank-you for your attention. I look forward to hearing from anyone who can help! ;-)
~ Rick Niess ~-- .oooO "Man with closed Oooo. Rick C. Niess ( ) mouth gathers ( ) University of Southern Miss. \ ( no foot!" ) / guardian@bark.cc.usm.edu --\_)------------------(_/-------------------------------
On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote:
- On the membership management admin page, please setup a mechanism for large lists to limit the display of user options to X number of users per page. It's a killer to try to admin large lists from slow machines with
Hmm, it already does that. When you select membership, it displays them in chunks of 10 or something. I've upped mine to 30, and would actually prefer 100.
I do note that with my 1.0 install, if I log in with the site-admin password, I can't select the broken-out lists (it asks for the password again, then takes me back to the first chunk, even though it says "chunk=3" or whatever in the URL.
- Please setup a means by which a user can specify what additional addresses he/she posts from other than their subscription address. (For example, my campus has a mail aliasing system so that all public addresses
The current way we're doing this is that if users have multiple addresses they want to post from, they have to subscribe once for each of those addresses, and then only enable delivery on ONE of them.
For you, it sounds like you may want to limit it to members only, but then allow posting from anyone who's e-mail address is "*@usm.edu" or "*@*.usm.edu"... Not ideal, but it sounds like your environment doesn't really keep users from having a new address every week, and that's hard to predict.
- move the archives to http://host/mailman/archives/listname or provide a redirect from there to http://host/pipermail/listname.
Correct me if I'm wrong, but can't you do that in Apache with a slightly modified version of the lines you already have in there to get the "/mailman/" and "/pipermail/" URLs to work?
Lastly, I'd like to note that, while I understand most of what'sgoing on in the code, I don't have time ATM to sit down and really learn
^^^^^^^^^^^^^^^^^^^Yeah, that seems to be the common problem these days. Too much demand, too few geeks.
Sean
"Where are we going?" "Planet Ten!" "When?" "Real soon!" -- _Buckaroo_Banzai_ Sean Reifschneider, Inimitably Superfluous jafo@tummy.com URL: http://www.tummy.com/xvscan HP-UX/Linux/FreeBSD/BSDOS scanning software.
Hi All,
On Mon, 15 Nov 1999, Sean Reifschneider wrote:
- On the membership management admin page, please setup a mechanism for large lists to limit the display of user options to X number of users per page. It's a killer to try to admin large lists from slow machines with Hmm, it already does that. When you select membership, it displays them in chunks of 10 or something. I've upped mine to 30, and would actually
On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote: prefer 100.
I must have broken this somehow. Checking into it...
- Please setup a means by which a user can specify what additional addresses he/she posts from other than their subscription address. (For <snip> For you, it sounds like you may want to limit it to members only, but then allow posting from anyone who's e-mail address is "*@usm.edu" or "*@*.usm.edu"... Not ideal, but it sounds like your environment doesn't really keep users from having a new address every week, and that's hard to predict.
Ahh. Very good points. The latter isn't exactly feasable in a fewcases, but it's a start.
- move the archives to http://host/mailman/archives/listname or provide a redirect from there to http://host/pipermail/listname. Correct me if I'm wrong, but can't you do that in Apache with a slightly modified version of the lines you already have in there to get the "/mailman/" and "/pipermail/" URLs to work?
I hadn't thought of that. Yes, it should work. I've added a third"Alias" line to Apache's srm.conf:
Alias /icons/ /home/httpd/icons/ Alias /pipermail/ /home/mailman/archives/public/ Alias /mailman/archives/ /home/mailman/archives/public/
I left the old one in in case the change broke something. As a sidenote, I'll say that I was more concerned with URL uniformity than the actual location of the archiver and data.
Lastly, I'd like to note that, while I understand most of what'sgoing on in the code, I don't have time ATM to sit down and really learn
^^^^^^^^^^^^^^^^^^^Yeah, that seems to be the common problem these days. Too much demand, too few geeks.
Perhaps, but that's also why some of us are paid well. ;-)
~ Rick ~-- .oooO "Man with closed Oooo. Rick C. Niess ( ) mouth gathers ( ) University of Southern Miss. \ ( no foot!" ) / resnet@usm.edu --\ )------------------(_/-------------------------------
Sean responded to a bunch of Rick's points, and I'll just add a few more thoughts.
"RN" == Rick Niess rniess@netserver3.otr.usm.edu writes:
RN> 1) Please add an option so subscribers can elect to show only
RN> the username part of their e-mail address in the subscriber
RN> list instead of the whole thing (regardless of the @->" at "
RN> conversion).The problem here is that we don't actually keep that information around in the database. This is bogus, and is something that I hope will get fixed when we have a real User database (don't ask when ;)
RN> 2) In the section of the listinfo page where a user can
RN> subscribe to the list in question, please add another
RN> radio-button option for "Conceal yourself from subscriber
RN> list?"I'd actually like to see more options at the subscription page, if not all the options a user can change later (that might be too cluttered and daunting though).
RN> 3) Allow the system-wide admin to disable the mail->news and
RN> news->mail gatewaying for the whole system and/or for selected
RN> lists.You can disable news->mail easily by shutting off the cron entry for gate_news. Shutting off mail->news will actually be much easier to accomplish with the current CVS snapshot, since you can just edit out the ToUsenet module from the message delivery pipeline.
There's a meta-issue about providing more site configuration options via the Web, and that's definitely something I'd like to improve in the future.
RN> 5) Please setup a means by which a user can specify what
RN> additional addresses he/she posts from other than their
RN> subscription address. (For example, my campus has a mail
RN> aliasing system so that all public addresses have the form
RN> "firstname.lastname@usm.edu" or similar. But the address they
RN> post from may be "username@host.usm.edu" or similar. This
RN> becomes a problem for lists that have member_posting_only
RN> turned on.)Again, with a real User database, we could easily allow users to subscribe multiple addresses, enabling delivery to some or all of those addresses, and allowing postings from any of a User's known addresses. Very difficult to do right now unfortunately.
RN> 6) Please setup a mechanism for a pre-made set of options to
RN> be used as defaults when creating new lists.I've thought about this, but haven't had time to work on it. It actually would be easy to do (contributions?? :). Remember that bin/newlist isn't magic -- it's really quite simple. What you could do is hack this script to include various common list "personalities", which really just means certain list option settings, and then just make those settings after the call to newlist.Create().
A simple hack would be to just have a bunch of classes in the newlist script which implement these defaults, and add a command line switch to invoke one of those classes on the newly created list. If you want to get fancy, you could publish an API and let folks add their own list personalities. newlist would try to import a module, dig a class out, call the API method on the list object, and then Save it.
RN> 7) If anyone has written a withlist module that can read in
RN> the values in an existing Majordomo 1.94 config file and
RN> update the corrosponding values in a Mailman list's config db,
RN> I'd be ever so greatful to get a copy.And if you do, please let me know, 'cause I'd love to add something like this to the distribution!
RN> 8) The <body> tag is not currently setup right for error
RN> pages.I don't understand; I guess you mean the driver script is broken? Can you give me more details?
RN> 9) Please build-in the option for individual list owners to
RN> filter binary attachments. (I think something like this is
RN> already in the works, but I'd like it to be a per-list option
RN> settable by the list owner.)Again, while this functionality doesn't exist yet, the new message delivery architecture could accomodate this much more easily.
RN> 10) In the pipermail archives, please do the following:I'd love it if someone became the Pipermail champion. I just don't have the wherewithal to do much development on this code.
RN> Lastly, I'd like to note that, while I understand most of
RN> what's going on in the code, I don't have time ATM to sit down
RN> and really learn Python. Hence, I don't have the expertise to
RN> go about making most of these modifications myself. I do,
RN> however, plan to sit down and learn Python as well as possible
RN> over the holiday break. So perhaps I can pitch in directly
RN> during the new year.Well Rick, it'll probably take you about a day to learn all the Python you need to become a prolific Mailman hacker! Just be sure to try it /before/ you eat the turkey dinner and get all "stuffed". :)
-Barry
The problem here is that we don't actually keep that information around in the database. This is bogus, and is something that I hope will get fixed when we have a real User database (don't ask when ;)
What are the current plans for this? I'd like to help. I should have some time over the coming holidays.
-S
"SH" == Steven Hazel cherub@azrael.dyn.cheapnet.net writes:
Me> The problem here is that we don't actually keep that
Me> information around in the database. This is bogus, and is
Me> something that I hope will get fixed when we have a real User
Me> database (don't ask when ;)
SH> What are the current plans for this? I'd like to help. I
SH> should have some time over the coming holidays.Well, there are a number of questions (if it was an easy hack it'd already be done :).
First, do we want to use a real OODB underneath (such as ZODB), or do we cook our own? If we cook our own, do we modify Mailman to run as a long-running process to make things efficient? How do we handle safely modifying the user database (e.g. a user adding email addresses to their profiles)? There are also UI issues for making all this convenient for users. Finally, a user database should be robust enough to handle specifying various other roles. IOW, users can also be list admins, list moderators, and site admins.
Too sleepy to write more tonight.
-Barry
[Barry A. Warsaw]
"SH" == Steven Hazel cherub@azrael.dyn.cheapnet.net writes:
Me> The problem here is that we don't actually keep that Me> information around in the database. This is bogus, and is Me> something that I hope will get fixed when we have a real User Me> database (don't ask when ;) SH> What are the current plans for this? I'd like to help. I SH> should have some time over the coming holidays.Well, there are a number of questions (if it was an easy hack it'd already be done :).
This is my cue, I guess ;)
First, do we want to use a real OODB underneath (such as ZODB), or do we cook our own?
I tried using ZODB at first, but found that my try at that scaled very poorly (The FileStorage file was ~160MB even before there were 2000 entries in my database, and the time needed to open the database seemed to scale with the size of it...). Dunno if this was due to me being boneheaded when implementing stuff, or to actual problems with ZODB, but I kinda lost my spirit for it anyway :-\
So, I surfed to Parnassos, searched the vault there, and came up with a copy of bplustree.py. Implemented purely in Python, as opposed to ZODB, which relies on some C Zope modules. The disk space used per record seems very reasonable. Open time appears to be pretty much unrelated to file size. Record access time seems fast enough. One problem, though -- this module does not handle multiple simultanous writes, so we have to be careful with locking -- which *could* make the user db into a bottleneck.
[ As we put Mailman into production with the ~3.500 lists we have here at uio.no, we discovered that the current locking code didn't work very well on a system that got so busy it started swapping -- so I rewrote the entire file locking module to be more robust, and added some code to have the "post" mail injection script exit with temporary error codes if it couldn't get a lock on the list within a reasonable amount of time -- leaving it to the MTA to try injecting the mail again later. Things have been running smooth ever since. ]
A fresh entry (created to be added as member of LIST-A) in the resulting user db have these attributes:
{'admin_for': {}, 'admin_pwd': None, 'aliases': {'ADDRESS@DOMAIN': 1}, 'member_of': {'LIST-A': 1}, 'member_pwd': 'PASSWORD', 'preferred_address': 'ADDRESS@DOMAIN'}
Currently 'aliases' and 'preferred_address' isn't used, but the intention is to use them for associating several mail addresses with the same user account (probably by some means of email confirmation).
'member_pwd' is stored in cleartext, while 'admin_pwd' (when set) is stored as a MD5 digest.
An "username" field has been added to all login pages -- currently we're running with this as a text entry field, but I'll probably install some changes to use a <SELECT> menu of the list's admins instead (mainly to reduce the amount of typing an admin has to do when logging in, but also partly due to the fact that it's common for a browser to SUBMIT on pressing Enter in a text field iff it's the only one in the form).
Logins are still done per list (but with your own admin password), as the cookie secret business has been a bit complicated by all this -- I'm planning to have a cron job generating random list- and admin-independent secrets ever so often, and use these when issuing new cookies -- thus removing the complications and making cross-list single login viable.
It is all rather non-generalized (and part of the code is... uhmmm... not quite as clean as could be wished for), but it has been working fine for over a month now (modulo the various bugfixes I've made along the way, of course). I agree with those wanting a generalized API to use whatever database backend appropriate -- but with all these local changes I'm feeling rather removed from the rest of Mailman development already, so I don't think I'm likely to start working on that soonish.
I'm not sure how it's best to proceed with all this from here -- I think the stuff I've made could prove usable for others beside me, and I'd sure love to get my CVS tree closer to being in sync with the rest of you. However, if I just go ahead and check stuff in, that might mean pushing 1.2 a fair bit away.
So, for now, I've made my current development tree (which, Right Now,
isn't quite the code we have in production here; I've been holding off
installing changes since I started implementing the login-with-menu
stuff mentioned above. As some list admins might not want to be
listed as list admins this openly, I've asked for opinions before
installing that change) available at
I'll try explaining all this in a more structured fashion later, but please don't hesitate to ask any specific questions you might have.
[ Apart from the user database stuff, the tree has a fair bit of other new stuff in it as well.
Perhaps most notable is "meta-members", i.e. special list members which are dynamically expanded to real mail addresses at list post time. Currently there is only one type of meta-member, MailmanList, which expands to the appropriate set of members (digest or regular members, based on whether what kind of post this is) on the given list. Other types are planned.
Other nice stuff is the ability to name lists with full email addresses internally (useful when housing lists in several mail domains), the use of a cache for building the list overview pages, and (useful when having lots of lists, to avoid loading _all_ of them to build the overview), the "this list is busy, return incoming mail to MTA" hack, and bin/move_to has been extended so it can create a copy of list X with another name Y -- to help renaming lists internally. ]
-- Harald
Hi All,
Whew! Sorry for the delay in response. Been busybusybusy. Andsick. <snifflesniffle> Getting better tho. Anyway...
On Mon, 15 Nov 1999, Barry A. Warsaw wrote:
RN> subscribe to the list in question, please add another RN> radio-button option for "Conceal yourself from subscriberI'd actually like to see more options at the subscription page, if not all the options a user can change later (that might be too cluttered and daunting though).
<nod> I'd thought about asking for all of them but didn't want topush my luck. ;-) Having "as many as is tactful and/or sensible in the context" would be a good idea, IMHO.
RN> 3) Allow the system-wide admin to disable the mail->news and RN> news->mail gatewaying for the whole system and/or for selectedYou can disable news->mail easily by shutting off the cron entry for gate_news. Shutting off mail->news will actually be much easier to accomplish with the current CVS snapshot, since you can just edit out the ToUsenet module from the message delivery pipeline.
<nod> I've already done this. However, it doesn't remove theconfiguration option from each list's admin pages. But I think you knew what I meant. ;-)
BTW, from the sound of it, the new modular pipline structure Barrydescribed sounds like a winner! *lots* more flexibility. Even room for on-the-fly user modules, etc. One question, tho. What was "CVS" mean?
RN> 5) Please setup a means by which a user can specify what RN> additional addresses he/she posts from other than their RN> subscription address. (For example, my campus has a mailAgain, with a real User database, we could easily allow users to subscribe multiple addresses, enabling delivery to some or all of those addresses, and allowing postings from any of a User's known addresses. Very difficult to do right now unfortunately.
Yup. Although I will note that Mailman's current means of dealingwith it (multiple subscriptions, only one actually delivering) is more elegant than Majordomo's (just multiple subscriptions or a separate list that doesn't actually handle posts)
RN> 6) Please setup a mechanism for a pre-made set of options to RN> be used as defaults when creating new lists.
<snip> > which really just means certain list option settings, and then just > make those settings after the call to newlist.Create(). <snip> > A simple hack would be to just have a bunch of classes in the newlist > script which implement these defaults, and add a command line switch > to invoke one of those classes on the newly created list. If you want > to get fancy, you could publish an API and let folks add their own <snip>
Oy. OOP has never been my strong suit. Okay, sticking with the KISSprinciple, how about the desired initial "personalities" each be stored in separate files all stored in a single subdirectory somewhere (ex, "$prefix/personalities"). The format can be a simple "maiman_db_variable_name='desired value'" on each line allowing for hashed comment lines. Look familiar to some Majordomo users? <g> (Note: We'll have to figure out a way to weed out erroneous input from here.) Then the site admin can specify that personality with a command-line switch to newlist. And this could be handled right after newlist.Create(), as you said.
*And*, we could implement a separate switch to import aMajordomo-style config file and map to the appropriate values, etc. Not hard, just tedious. I'll be happy to sit down and write up a map of what Majordomo values go to what Mailman values if someone can use this in the short term...
RN> 8) The <body> tag is not currently setup right for error RN> pages.I don't understand; I guess you mean the driver script is broken? Can you give me more details?
Sure. All the normal admin and default user pages have a BODY taglike '<BODY BGCOLOR="#ffffff">'. But most of the erorr pages (ex, from the archives and options CGI's) only have '<body>'. Not terrible, just cosmetic. Then again, some of the error messages themselves could use a little elaboration. And uniformity. (Yes I know it's an opensource project and, no, I'm not berating anyone. Just pointing out the obvious so it can be fixed at some point.)
RN> Lastly, I'd like to note that, while I understand most of RN> what's going on in the code, I don't have time ATM to sit down RN> and really learn Python. Hence, I don't have the expertise toWell Rick, it'll probably take you about a day to learn all the Python you need to become a prolific Mailman hacker! Just be sure to try it /before/ you eat the turkey dinner and get all "stuffed". :)
<giggle> We shall see... ;-) BTW, I should note that I have notreally dealt with OOP before. (That's one of the reasons Python seems so daunting to me.) So if I've made some statments that don't make sense for Python, now you know why. Anyway, thanx for listening.
~ Rick ~-- .oooO "Man with closed Oooo. Rick C. Niess ( ) mouth gathers ( ) University of Southern Miss. \ ( no foot!" ) / resnet@usm.edu --\ )------------------(_/-------------------------------
participants (5)
-
Barry A. Warsaw -
Harald Meland -
Rick Niess -
Sean Reifschneider -
Steven Hazel