Mailman 3 - Mailman-Developers

wrappers: legal_caller()
by Scott 09 Apr '98

09 Apr '98

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 Tue Jun 10 12:31:16 1997 +++ src/mail-wrappernew.c Thu Apr 9 03:41:32 1998 @@ -37,9 +37,18 @@ NULL /* Sentinal, don't remove */ }; -/* Should make these arrays too... */ -const int LEGAL_PARENT_UID = 8; /* mail's UID */ -const int LEGAL_PARENT_GID = 12; /* mail's GID */ + +const int LEGAL_PARENT_UIDS[] = { + 1, /* mail's uid */ + 537, /* mailman's uid */ + -1 /* Sentinel, don't remove */ +}; + +const int LEGAL_PARENT_GIDS[] = { + 1, /* mail's gid */ + 100, /* mailman's gid */ + -1 /* Sentinel, don't remove */ +}; /* @@ -77,20 +86,45 @@ ** is the parent process allowed to call us? */ int legal_caller() { - /* compare to our parent's uid */ - if(LEGAL_PARENT_UID != getuid()) + int uid, gid, isok, idi; + isok = 0; + idi = 0; + uid = getuid(); + while (LEGAL_PARENT_UIDS[idi] != -1) + { + if(LEGAL_PARENT_UIDS[idi] == uid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) { - fprintf(f,"GOT UID %d.\n", getuid()); - return 0; + fprintf(f,"GOT UID %d.\n", uid); + return 0; } - if(LEGAL_PARENT_GID != getgid()) + isok = 0; + idi = 0; + gid = getgid(); + while (LEGAL_PARENT_GIDS[idi] != -1) { - fprintf(f,"GOT GID %d.\n", getgid()); - return 0; + if(LEGAL_PARENT_GIDS[idi] == gid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) + { + fprintf(f,"GOT GID %d.\n", gid); + return 0; } return 1; } + int valid_command(char *command){ int i = 0; @@ -119,7 +153,7 @@ i = strlen(argv[1]) + strlen(COMMAND_LOCATION) + 2; command = (char *)malloc(sizeof(char) * i); sprintf(command, "%s/%s", COMMAND_LOCATION, argv[1]); - + fprintf(f, "command is %s\n", command); if(!valid_command(argv[1])){ fprintf(f,"Illegal command.\n"); } Scott Cotton IC Group, Inc

2 2

suggestion
by Scott 09 Apr '98

09 Apr '98

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 09 Apr '98

09 Apr '98

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 08 Apr '98

08 Apr '98

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", line 424, in ? words = string.split(datestr) TypeError: argument 1: expected read-only buffer, None found Cheers, Stu.

3 2

Next Release
by W T Hewitt 28 Mar '98

28 Mar '98

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 the mailman package - ie, in the > directory where the single 'mailman' dir was created. I finally figured out the problem. I'd ftp'ed the file to a PC then to an SGI O2, and the klm.p1 had extraneous <CR>s in it! I've been using mailman on an SGI, and my problems/suggestions/fixes for the next release. I'm willing to do some of them if somebody will tell me which ones to do: 1) in mailman/src/*.c put UID and GID in a .h file so I Only need to edit one file 2) Make /home/mailman a configuration variable 3) Make the logging files /tmp* world writeable (when debugging I had problems running as nobody and mailman) and make the names consistent 4) Use HTMLgen for creating HTML 5) On SGI you can't add aliases to programs in /etc/aliases You do it through a .forward file for /home/mailman All names in /etc/aliases are therefore aliased to mailman, and I have a mailwrapper script that does what aliases used to do. 6) Add archive more frequently (e.g., daily, hourly, now) to mm_archive volume_frequency I have a fix for this 7) crontab on SGI complains about blank lines in crontab.in 8) Put all the files associated with a list in one subdirectory, that is independent of mailman code. Best wishes Terry W T Hewitt Manchester Visualization Centre Telephone: +44 161 275 6095 Manchester Computing Fax: +44 161 275 6800 University of Manchester Email: w.t.hewtt(a)mcc.ac.uk Manchester M13 9PL URL: http://info.mcc.ac.uk/MVC United Kingdom (Formerly Computer Graphics Unit)

3 2

Re: [Mailman-developers] Help please.
by Janne Sinkkonen 24 Mar '98

24 Mar '98

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 FieldStorage to cgi/subscribe and the gave up. There was no signs of problems in server (apache) logs, and I did change the UIDs and GIDs in wrapper code. Also, the scripts in cgi/ have their suid bit set, although I guess that's not necessary, at least not in Linux where suid scripts do not suid at all. Just FYI. -- Janne Sinkkonen <janne(a)iki.fi> <URL: http://www.iki.fi/~janne/ >

1 0

Help please.
by W T Hewitt 24 Mar '98

24 Mar '98

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 mail: w.t.hewitt(a)mcc.ac.uk University of Manchester http://www.man.ac.uk/MVC Manchester M13 9PL United Kingdom (formerly the Computer Graphics Unit)

2 1

Re: [Matrix-SIG] Testing transition to mailman list processor
by Ken Manheimer 17 Mar '98

17 Mar '98

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.... :-) 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

1 0

State of mailman (was: Re: list entry indexing)
by John Viega 27 Feb '98

27 Feb '98

> 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 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 | ----------------------------------------------------------------------------

1 0

List entry indexing
by Robin Friedrich 27 Feb '98

27 Feb '98

In a prior round of email, Ken mentioned that we would need to key the mail list entries to something other than the person's actual email address in order to implement the flexible user information editing capability of the web (changing one's sendto address, etc.). I agree that this is needed, sooner or later. Since I haven't seen the code yet, how difficult is it to just make a unique key for each subscriber and key the database off that with address as just one value? I hope I'm not using this list too soon. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich(a)pythonpros.com http://www.pythonpros.com

4 8