Mailman 3 - Mailman-Developers

Re: [Mailman-developers] wrappers: legal_caller()
by John Viega April 9, 1998

April 9, 1998

1 0

wrappers: legal_caller()
by Scott April 9, 1998

April 9, 1998

i have installed mailman as part of pilot project to test out new mailing list managers for work. i had to change the ./mailman/mail/wrapper program to check for multiple uids and gids to get the cron jobs to work properly (uid and gid were that of mailman when sending out results). has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a patch to ./src/mail-wrapper.c (the same change can be applied to the other legal_caller() functions in the wrappers): --- src/mail-wrapper.c … [View More]

2 2

suggestion
by Scott April 9, 1998

April 9, 1998

i would like to suggest two things about the confirmation step in subscriptions. first, that it be an option for email based subscriptions, and second, that just hitting reply and copying in the confirmation message (with or without regular email quotations) be made to work. if there's a consensus on this, i'd be willing to make the necessary changes. Scott Cotton IC Group, Inc.

2 1

BTW
by Scott April 9, 1998

April 9, 1998

nice work on the upcoming release, if that is indeed what's running at python.org. is there any work in progress on a mail interface to the adminstrative functions? Scott Cotton IC Group, Inc.

2 1

Pipermail issue...
by Stu Ekins April 8, 1998

April 8, 1998

Hi, Does anybody know of any issues with the pipermail module? It hasn't worked for me since I upped my python version to 1.5 (on Linux 2.x). I'm still learning the language and am not yet competent enough to debug it fully myself! Here's a traceback... Traceback (innermost last): File "./archive", line 31, in ? list.UpdateArchive() File "/home/mailman/mailman/modules/mm_archive.py", line 72, in UpdateArchive import pipermail File "/home/mailman/mailman/modules/pipermail.py", … [View More]

3 2

Next Release
by W T Hewitt March 28, 1998

March 28, 1998

On Tuesday, March 24, 1998 4:46 PM, Ken Manheimer [SMTP:klm@cnri.reston.va.us] wrote: > On Tue, 24 Mar 1998, W T Hewitt wrote: > > > I got the latest versions of mailman from ftp.python.org: > > > > klm.p1 > > mailman-1.0b1.tar.gz > > > > unpacked. When I tried to apply the patches I gave a significant number > > of rejects!! > > The patches should apply with no problems if you run the patch from the > same directory where you untarred … [View More]

3 2

Re: [Mailman-developers] Help please.
by Janne Sinkkonen March 24, 1998

March 24, 1998

Ken Manheimer <klm(a)cnri.reston.va.us> writes: > The patches should apply with no problems if you run the patch from the > same directory where you untarred the mailman package - ie, in the > directory where the single 'mailman' dir was created. The patches installed cleanly and I was even able to create a list. mm_cfg.py or some such however lacked a lot of DEFAULTs and I was never able to subscribe to a test list. I tracked it down to the cgi module returning an empty … [View More]

1 0

Help please.
by W T Hewitt March 24, 1998

March 24, 1998

I got the latest versions of mailman from ftp.python.org: klm.p1 mailman-1.0b1.tar.gz unpacked. When I tried to apply the patches I gave a significant number of rejects!! Would somebody please email me the latest version, or email where it is, or perhaps, let me know the trick to doing the patches.... -- Best wishes Terry W T Hewitt Telephone: +44 161 275 6095 Manchester Visualization Centre Fax: +44 161 275 6800 Manchester Computing Electronic … [View More]

2 1

Re: [Matrix-SIG] Testing transition to mailman list processor
by Ken Manheimer March 17, 1998

March 17, 1998

On Tue, 17 Mar 1998, Charles G Waldman wrote: > Ken Manheimer writes: > > The Matrix-SIG mailing list has just been migrated to mailman, a > > python-based maillist management system. > > Hi Ken - this is off-topic for the Matrix-SIG - more of a "mailman" > question. I've been meaning to mention this to someone, I'm not sure > who the maintainer is of the Mailman package - is it you? Anyway, > your message provides me with the excuse to write you.... :-) … [View More]At the moment i'm carrying the ball, basically in order to get mailman in full gear at python.org. As you may know, we're using a version that's the most recent one recovered after loss of the server where john viega was developing and running mailman, and basically several months of work were lost. John is around and interested in continuing to work w/mailman, but deep in a grad school thesis, so it'll a little while before he gets to concentrate on it again. However, his intention is to come back to it, especially now that several people have also expressed interest. Towards the end of collaborating on mailman, we've set up a mailman-developers(a)python.org maillist - see http://www.python.org/mailman/listinfo/mailman-developers . I recommend joining that list, right off - it's not yet particularly active (i, for one, am too busy scrambling just to get the system shipshape and in production at this moment to do planning), but i expect we will be using it in earnest as time goes by. In addition, barry warsaw and i are setting up a mechanism (which barry devised) which should enable cvs sharing of the mailman sources across the internet, so we can do widely distributed coordinated development - at least have a convenient way to share modifications. We'll be pursuing this eventually, as time allows. > I recently set up "mailman" at my company, for our internal use. I > grabbed the distribution from python.org as well as the klm patches. > It basically works fine, but I noticed one oddness. > > If there is a line in a mail message that starts with "From ", > preceded by a blank line, the message is truncated in the message > archives. For instance: > > >From where I'm sitting, it looks like a very simple bug to fix. > > (This part of the message won't be archived) > > Has anybody fixed this yet? I don't want to waste time on this if > it has already been fixed. My work on the version here has diverged from the adapted version of pipermail that john was shipping with mailman - andrew kuchling is working here (handily enough!), so we're using a newer version of pipermail. We should be packaging up the whole shebang, pipermail and mailman, for use by others within the next few/several weeks, but in the meanwhile you're sorta on your own re the internal pipermail. That said, i do have an idea about what is needed. I am pretty sure that the line starting with "From " is being treated as the start of a new message, which probably is unarchivable and dropped on the floor, or perhaps getting put at some random place in the archive. The easy thing to do would be to preprocess the messages before they're put in the archive file so lines in the body starting with "From ", and following a blank line, have ">" prepended. I think the place to do this is in mailman/modules/mm_archive.py, Archiver.ArchiveMail(), but you'd have to scope it out a bit. Phew! This may be a bit more than you bargained for. I hope you don't mind that i'm cc'ing this to mailman developers - the info may well be useful for someone else. Ken Manheimer klm(a)python.org [View Less]

1 0

State of mailman (was: Re: list entry indexing)
by John Viega Feb. 27, 1998

Feb. 27, 1998

> I would definitely like to see a user-centric view of the world, as > opposed to a list-centric view, especially when we're talking about > users managing their presence via the Web. I want to be able to pull > up one Web page that gives me a form by which I can change my email > address in one fell swoop, perhaps have different email addresses per > list, change my visibility per list, etc. If I had to visit a > list-centric page for every list I'm a member of, that … [View More]would be a huge > pain. (But list-centric Web pages still have their uses, so the same > database could drive both views). > > Maybe the code isn't set up for this now, but it should be a goal of > future development. In that case, while I agree with Ken that the > email account is critical as the user's identity, having some other > unique key to identify the user is helpful when email addresses > change, as is inevitable. Requiring or using a public key system > seems excessive, but I don't see how to keep the user id from being > given to the user. I might not remember what address I'm subscribed > with on which list (I see this happen a lot with Majordomo users > actually). Okay, sorry I'm late in jumping into these discussions, but I've been away. A little bit of background for anyone who doesn't know: I had been developing mailman off and on, until I lost several months worth of changes in a disk crash (blame Greg Stein for not doing backups :). I'm slightly uncomfortable seeing people use the version that is now getting passed around, but I am certainly happy people are using it. The above problem was once changed. I kept a centralized user database. The way you could change your email address was with your password... there was no need for any sort of public key, etc. Some other stuff that was lost (some of this might actually be there, but I don't think so): - going to the listinfo CGI script w/o an argument should give a list of lists, except for the ones that are configured to be "hidden". - If a user appears in the TO or CC lines, and we can determine that he is on our mailing list, don't send him mail, because he already got it. Don't count such addresses towards the "this is probably spam" threshhold. - If a list admin gets lazy, and doesn't handle approvals for a long time, automatically send back rejections. - A site config page, including a password for the site manager, which works on any list. - A change to the way prefixes are handled, which it looks like Ken reimplemented already. - Talk to port 25 instead of calling sendmail, to make portability to other MTAs easier. There might have been a few more things. Those are the important things I can remember. However, Mailman was never 100% of the way to where I'd like it to be. One of the big problems is that I started out with a lot of majordomo experience, so a lot of the model is the same. What I'd most like to change, is to make mailman a daemon process that is always running, and use threads effectively. This would reduce the overhead of always having to start up a python interpreter and init mailman whenever a request comes in. It could also improve the grainularity of the locking mechanism, which is something that I feel really needs to be done. Anyway, my situation is that I don't have too much spare time to be coding until I finish the thesis I'm writing (though maybe a little bit). That shouldn't be any later than June 1. However, I'd be more than happy to accept changes from other people, and go back to actually releasing this software, if there is an interested development community this time around. All of the things mentioned above, I'd like to see happen, but anything that improves mailman, I'd like to incorporate. John ---------------------------------------------------------------------------- |John Viega "The public at large tends to confuse the | |viega(a)list.org composing of a symphony with the writing of | |http://list.org/~viega/ its score." | |University of Virginia -- Edsger Dijkstra | ---------------------------------------------------------------------------- [View Less]

1 0