Mailman 3 May 1998 - Mailman-Developers

More mailman locking issues
by Ken Manheimer June 12, 1998

June 12, 1998

Another issue with mailman locking - i think it's coarse grained, and needs to be refined. For example, this morning someone noticed that the umbrella listinfo page on python.org was hanging, because, it turns out, one of the lists was left in a locked state. (Not sure how that happened - it usually doesn't.) Well, the umbrella listinfo (and admin) pages open the lists only for the sake of determining which are public ones - no writing is actually required, so a lock isn't really required. It might be sufficient to offer a way to open a list "read-only", such that no locking is done. I think it would be better, however, to refine the locking system such that lists are not locked until they enter an operation that changes the list data in a way that will eventually need to be written. This would probably take a more effort than a "read-only" kluge, but may not be too bad. I guess this is one for the todo list. (Wish i had gobs of time to continue to hack on a these sorts of things - they're not very big or hard, but there is a bunch of them, and they need to be done right.) Ken

4 4

Pipermail
by John Viega June 5, 1998

June 5, 1998

Has anyone modified pipermail's hypermail emulation to work using only modules that are compiled in the default Python distribution? There's one dependency I have in mind: pipermail currently uses bsddb, which is not compiled into Python 1.5. I think gdbm is compiled in by default, but the two interfaces aren't compatible. My biggest goal w/ Mailman has always been to have everything people would ever want to do be easy to do. That's why I'm pretty reluctant to distribute without built-in archiving - one thing I hated about Majordomo was having to go out and download extras and then figure out how to integrate them to get useful functionality. I also believe that many people who will want to use Mailman will be using Python for the first time. The default Python installation is really easy to build. But as soon as you tell people, "Hey, now you have to recompile, and install crypt. Oh, and now you have to go download pipermail. And before you use that, you have to find bsddbm on the net somewhere, and install it", that's going to send people running back to the comfort of Perl and Majordomo, even though they'll be doing the same sorts of things. To that end, I've put in provisions for passwords to use md5 if crypt is not found. BTW, do you guys think md5 should be the default, and crypt an option for those who add it to their config? The only real advantage of crypt is that it is less space intensive. Also, the way I have things set up at the moment, if someone starts w/ the default distribution and later recompiles Python to include crypt, all the old passwords won't work, since they'll be in the md5 digest format. John

3 2

Some improvement suggestions
by Ken Manheimer June 5, 1998

June 5, 1998

Some of the other people here at cnri are using mailman, and they've hit up against one small change needed. I thought i'd mention it here, in case anyone gets the chance and inclination to address it. I also have one other item which i would really like to do, but the eventuality of actually doing it may be less near than i'd like (especially since i'm going away for a week, and there's all that catch-up time on return). The first item is the ability to edit the new-member welcome message. We offer list managers the ability to edit the html pages, and they get to see the way the magic refs (eg, <MM-List-Name>) are used on the template to see how they could use them for their own versions. Well, there is a number of standard mail messages, including particularly the welcome message, that they may want to edit. (IN FACT, two different groups, separately, came to me today with the need to edit the welcome message - for different reasons! A sure sign...) I think we would have to change the format substitutions, currently all the "%s" order dependent style, to be "%(real_name)s" dictionary substitutions, and otherwise do the same kind of thing we do for the html templates. (Ah, i see barry's done that in some recent checkins.) There is a bunch of messages, some which may benefit from this treatment, other might just clutter the list admins choices. Along these lines, there's something much more encompassing i'd like to do or see done. I'd like to extend the handling of list admin options and html templates so list-specific versions are only squirreled away in list-specific space if and when the list admin changes them from the default. This way, the central administrator could change the template or default values, and the new value would show for all the lists that haven't tailored their own versions. This would certainly be suitable for something like the html pages, where site style changes need propagation, and also for stuff like the forbidden posters. It may not be suitable for some others. This should be easy for the template files - just don't stash list-specific copies until an edit is made (and the edited copy differs), and use the default template if no list-specific one exists. It'd also be good to offer a way in the edit interface to revert to the default version, wiping out the list-specific copy. For the list admin options, we'd need a new field in the options data structure specifying the *name* of the default value, and likewise some way for the gui option for the list admin to explicitly revert to the default. Maybe there should be some way to have a locked-in list-specific setting, even if it doesn't differ from the _current_ site default. And then all the routines that use the list admin options will have to mediate through a routine (or options mediator object) that takes the name of the option and gets the default value when suitable... Well, i hope this is at least slightly understandable, if quick - i gotta run. C ya later! Ken

4 3

nasty admin Cookie bug (and fix)
by Scott May 31, 1998

May 31, 1998

there is a bug in the admin cgi changes that i posted. the block of code making general list changes fires from some brownsers when you log on and press enter to submit the data instead of clicking the submit button. the reason is that the code knows to process the login when the button is pressed because of it's name. that data is not submitted from some browsers when you submit the form by pressing enter instead of clicking on the button. since not much data is submitted, it wipes out a lot of the list information. bad bad bad! anyway, the fix is simple enough (against the previous patch and the substituted isAuthenticted function). scott chronis 3:01pm $ cvs diff -r1.4 admin Index: admin =================================================================== RCS file: /usr/local/cvsroot/mailman/cgi/admin,v retrieving revision 1.4 diff -r1.4 admin 689c690,692 < if category != 'members' and not cgi_info.has_key("request_login"): --- > if category != 'members' and \ > not cgi_info.has_key("request_login") and \ > len(cgi_info.keys()) > 1:

1 0

Cookies
by John Viega May 30, 1998

May 30, 1998

I installed Scott's patches for confirmation and admin logins (thank god for ediff-buffers). I have a couple of questions mainly for Scott, but I think other people might be interested in discussing them. First, I don't know what the expiration time for cookies is, but the cookie didn't go away when I shut down my browser. Do you think that's good behavior? I'd like to not be implicitly logged in if someone else starts up my browser. Also, I've seen some sites that log people off automatically after 15 mins of inactivity on that site. Do you think that's a good idea? Second, if you don't have cookies on, changes don't get made. You get sent back to the login screen, and when you log back in, everything is the same. Should cookies really be required? Something that could be done to offer similar functionality yet not require cookies would be to have an "enter your password" box after the initial login, and put the password in the proper field as default text. While that may not be incredibly secure, it's not much worse than sending a plaintext password via httpd the first time only (although the password will be in the page source). Also, perhaps there should be a way to explicitly log out? I can't get logged out, even by turning off cookies! John

2 5

Smtp delivery.
by The Dragon De Monsyne May 29, 1998

May 29, 1998

I noticed the message about direct smtp delivery being needed for virtual hosting.... As I mentioned before, I have a version on mailman 1.0b1 that I am running that already does this. I am going to give a good shot at integrating that feature into the current (1.0b3?) source this weekend. (I want to anyway, as I want to upgrade my server. ) BTW, I also mentioned some user database changes in my variant of mailman... I'm dropping those, as I don't like the way I implemented them. I'll just try to incorporate the other features I added to 1.0b1 (smtp delivery being the biggie) into the current tree, and go from there. -The Dragon De Monsyne

4 4

Re: [Mailman-Developers] Re: your mail
by Roy Smith May 29, 1998

May 29, 1998

"John Viega" <viega(a)list.org> wrote: > It's more efficient than Majordomo, especially when doing bulk mailing. This may be a naive question, but how can that be? Majordomo doesn't actually get involved in mail delivery (at least the versions I've used). It just maintains an address file which is read by sendmail (or whatever MTA you're using) to do the actual delivery. So what does it mean to say that majordomo isn't efficient at bulk mailing?

2 1

Re: your mail
by John Viega May 29, 1998

May 29, 1998

On Thu, May 28, 1998 at 10:29:17PM -0400, Corbett Klempay wrote: > Does anyone have any quantitative (or maybe even non-quantitative) idea of > Mailman's performance, especially compared to direct competitors such as > Majordomo? It's more efficient than Majordomo, especially when doing bulk mailing. > Do we know of any very high volume lists being run on Mailman How high volume? I know of some lists with 5000+ users, they don't seem to have any problems. The biggest one I run has been over 2000 strong. > (or is this even a good idea?). I imagine that something like ezmlm would > probably obliterate both Majordomo as well as Mailman as far as > performance, but I don't see the average list needing the kind of fiendish > performance ezmlm provides (don't me wrong; ezmlm has a lot to recommend > it); most people could (and would) trade ezmlm's speed for Mailman's slick > web interface. But what I'm wondering is do we know how big this > performance tradeoff is? You'd do a lot better performance wise trading sendmail for qmail than Mailman for ezmlm. Also, within a few months we're going to have an option to keep mailman as a persistant server, to avoid the costs involved of always starting up. > Also, I saw that there was a mention on the TODO list about adding support > for other MTAs (such as qmail). Has anyone implemented this on their own > yet? Would providing support for qmail affect (enhance) performance much? I'm working on this feature as we speak. Like I said, the underlying mail transport is more important than the MLM software in terms of how many messages you can push through a machine. > I'm trying to (seeing how smooth Mailman is) see what kind of potential > user base there will be; I'm wondering at what point the list becomes too > speed-critical to allow use of Mailman. Any comments? Well, I think that the current way the locking is done might cause some problems on lists that have large, large numbers of users AND get tons of users. I don't know how large those numbers are yet, but the big list I run has gotten 100 posts in an hour before, without problem. The locking is going to eventually become more fine-grained, so even for the largest lists, I don't think it'll be a problem. John

2 2

oh yeah, one more teeny tiny needed change
by Ken Manheimer May 29, 1998

May 29, 1998

One more small suggestion i got today - list managers should be able to override the monthly password reminder for their list members. Some lists are infrequent, announcement only lists, and there can be enough info in the header/footer about where to find the place to get their passwords that the password reminder is gratuitous. At least, that's the opinion of someone who's running such a list... briefly, ken

1 0

Re: Alternate hosts and sendmail
by Ken Manheimer May 28, 1998

May 28, 1998

It looks like having mailman do smtp directly is going to resolve the problem i was having getting mailman to do "virtual hosting". And that increases the priority of getting the direct smtp connection in - i have some people here at cnri who need the capability, not urgently, but it'd be nice sooner rather than later... The problem i'm referring to is that mailman does the right thing sending out messages as if they come from the domain for which the maillist is configured, but sendmail by default rewrites the addresses so the maillist address looks like the primary domain for which sendmail is configured. The consensus was that reconfiguring sendmail to avoid that would be dirty - it entails rewriting one of the rulesets, which is fairly-to-very intrusive. Well, it turns out that this problem does not apply to mail relayed by direct smtp connections, hooray. That means no special instructions will be necessary for sendmail (or other mda) configuration, hooray. Oh, and incidentally, i'm going to be away for the next week and a day - no new releases, though barry and john may have some nice stuff to spring on you in the interim. I'm gone! (Hooray.) Ken

1 0