Mailman 3 October 1998 - Mailman-Users

management of lists
by Brent Harding Oct. 18, 1998

Oct. 18, 1998

Is it possible to manage lists via email with mailman?

1 0

(no subject)
by Brent Harding Oct. 18, 1998

Oct. 18, 1998

put list.header dog dog newconfig shutdown serve ban

1 0

Re: [Mailman-Users] Human orinted interface
by Harald Meland Oct. 16, 1998

Oct. 16, 1998

[Jean-Bernard ADDOR] > We have not finished the installation yet and I don't know what > happen if a message is crossposted on many lists, but I strongly > hope it will be send to a multiple subscriber only once. I doubt it. In order for that to work, Mailman would have to have: * a way of detecting when a message is posted to several Mailman lists. Today the "post" commands for the various lists are started by the MTA, and lead entirely separate lives. * a way of deciding _which_ of the MTA-started "post" commands should send the message to the multiple-subscribed address. A way of doing this would be to have a global database over what message-ids (a message-uniqe ID, not necessarily from the Message-Id: header. Determining this id is not necessarily trivial) that have been sent to what addresses. The first list to process a new message-id for anyt given address, enters the message-id/address pair into the database, thereby blocking any other "post" commands from sending that message to that address. Personally, I think this would be rather kludgy (to say the least). But, while we're on the subject of interprocess communication: I have some lists consisting of sublists, and I would like all of them to be moderated. Is there any (moderation-safe) way of saying "Once a message has been allowed onto the superlist, don't ask for confirmation from the sublists"? -- Harald

2 1

Mailman for use in large installation wishlist
by Harald Meland Oct. 16, 1998

Oct. 16, 1998

I am considering switching all our nearly 4000 mailing lists over to Mailman (eventually, there's no hurry for most of the lists (I'm only halfway through the Python tutorial yet :)), but with that many lists being involved, I'm having second thoughts due to some issues in the current Mailman implementation. First, some of our list administrators have admin rights for as many as 50 lists. That amounts to rather a lot of list passwords to keep track of for the poor admin, which is undesirable to say the least. Currently, our mailing list interface is a UNIX shell command, and determines whether to allow administration or not based upon the callers UID. That way, all the passwords any admin has to remember, is their standard UNIX password. Of course, it also means that only local UNIX users are able to administrate our lists (which means it is sometimes a bit of a pain to find new admins for old lists). Second, very many of our lists have several admins. Implementing multiple list admins by means of "share this one admin password between the lot of you" seems to me to be rather an ad hoc way of doing it. So, I was thinking: Would it be possible to have a Mailman-global database of administrators' (more-or-less canonical) email addresses and their passwords, and require both email address and password when authenticating for list administration? That way, each admin would only have to remember _one_ password (and their email address :), no matter how many lists she administrates, and multiple admins would authenticate using separate passwords. Mailman would still not have the restriction of allowing only local users to do administration. Any thoughts? Are anyone using Mailman for large lists/huge numbers of lists? PS: Is there any way of turning list archiving off entirely for any particular list? Archiving all of our nearly 4000 lists would need a lot of disk pretty fast... :) -- Harald

4 3

Changing admin address for "umbrella" list subscribers
by Ken Manheimer Oct. 15, 1998

Oct. 15, 1998

A while back i implemented a mailman feature to facilitate having "umbrella" lists to which other lists could be subscribed. I would like to change it slightly, and want to see if i'd be messing anybody up with the change. I'm not even sure if anybody but me uses the feature, so first i'll explain what it's about, and then i'll explain the problem. The idea is to enable maillists that are composed of only other maillists, as "subscribers". That way, announcements of interest to groups of lists could be sent to the encompassing list. This may sound peculiar, but it actually makes sense in the context of, for example, activities that have regional groups doing their regional thing, but also occasionally collecting together for, eg, national conclaves, or for discussions of common issues across the regions, etc. (In fact, i'm establishing a network of lists for people who do something i'm part of, contact improvisation, and this arrangement looks really pretty good for us.) The only special provision i had to make for this arrangment is an admin setting so that the members administrative stuff, like the monthly password reminders, are _not_ posted to the subscribed lists, but to their administrators. I created the 'reminders_to_admins' option, and set it so that the reminders would go to the 'list-admin(a)host.domain' account, rather than 'list(a)host.domain'. (I'm pretty sure this was pre 1.0b4, so it's been there for a while, probably unnoticed by most people.) The problem is that it may be that '-owner' is a more prevalent suffix for list administrator addresses than '-admin'. At least, that's what makelist.com seems to use, and from my probing they don't seem to support the '-admin' alias, while the policy for mailman is to support both. So i'm considering changing the option to go to '-owner' address instead of '-admin', but before i do that i wanted to find out whether (1) anyone already depends on the '-admin' option, and (2) whether anyone has objections to making the switch, in any case. (We could add *another* option to designate the suffix, but that doesn't strike me as a good solution - we'd be better off striving for some standard, than encouraging fragmentation here. What good would one choice or another be if some of the subscriber lists within the umbrella have one and some have the other?) Any clear feelings, one way or the other, from anyone? I plan on making the change within the next few days, but can still be dissuaded by solid arguments... Ken Manheimer klm(a)python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # <http://www.python.org/psa/>. #

1 0

Re: [Mailman-Users] Configuration under EXIM and Debian v2.0
by Harald Meland Oct. 15, 1998

Oct. 15, 1998

[Tomas Fasth] > From: Harald Meland <Harald.Meland(a)usit.uio.no> > > >test: |"/var/lib/mailman/scripts/post test" > > AFAIK, sendmail applies standard RFC822 syntactical rules on > aliases. Hence the quotation to deal with white spaces. OK, but does test: "|/var/lib/mailman/scripts/post test" do the same thing as the above alias? Or does sendmail rely on the first non-whitespace character to be `|' in the value of a pipe alias (thereby making use of `"' as the first character inappropriate for Mailman)? > Another thing; There is no wrapper involved in your example. Like this: Well, it wasn't really my example -- I just snipped the alias described by Peter Gervai to explain the Exim/sendmail problem. In my Exim setup, I have set up things to use the wrapper: Alias file entry: ----------------- test: "|/local/Mailman/mail/wrapper post test" test-admin: "|/local/Mailman/mail/wrapper mailowner test" test-request: "|/local/Mailman/mail/wrapper mailcmd test" owner-test: test-admin test-owner: test-admin Relevant parts of my Exim configuration: ---------------------------------------- # My Mailman transport config: mailman_list_pipe: driver = pipe allow_commands = /local/Mailman/mail/wrapper user = mailman return_output # ... and the corresponding director config: local_lists: driver = aliasfile search_type = lsearch # This is not in production use yet, so don't mind the odd placement # of my alias file :) file = /local/Mailman/data/MTA_aliases pipe_transport = mailman_list_pipe > According to my understanding the wrapper is needed to set user id / > group id accordingly, among other things. On my system the wrapper is only setgid, not setuid. As you can see from the transport configuration above, I set the uid to run the pipe as explicitly in the "user = mailman" line. > How does exim handle the if not through a wrapper? I guess that if all the wrapper does is to change UID and GID, Exim should be able to do without it entirely (by setting them in the transport config). I haven't bothered to find out yet, though. > Does this mean you're running mailman as root? I don't know for sure, but I wouldn't think so. > >, I propose changing the current "newlist" output. > > Better up, if the current output isn't portable, make the newlist > output configurable at installation time (by setting type of MTA). Maybe this will be needed eventually. However, if there is any chance of making the output portable between MTAs, that would be less of a hassle (to the installing admin) than having to specify which type of alias to use. -- Harald

1 0

Re: [Mailman-Users] Configuration under EXIM and Debian v2.0
by Tomas Fasth Oct. 15, 1998

Oct. 15, 1998

From: Harald Meland <Harald.Meland(a)usit.uio.no> To: Mailman users <mailman-users(a)python.org> Date: den 15 oktober 1998 06:32 Subject: Re: [Mailman-Users] Configuration under EXIM and Debian v2.0 >This one stung me, too. Is the sendmail aliases syntax different from >the Exim syntax here? Exim interprets the alias > >test: |"/var/lib/mailman/scripts/post test" AFAIK, sendmail applies standard RFC822 syntactical rules on aliases. Hence the quotation to deal with white spaces. Another thing; There is no wrapper involved in your example. Like this: test: |"/home/mailman/scripts/wrapper post test" According to my understanding the wrapper is needed to set user id / group id accordingly, among other things. At least when using sendmail as MTA. How does exim handle the if not through a wrapper? On the other hand, I notice the path to be /var/lib/mailman. Does this mean you're running mailman as root? Isn't that kind of dangerous? >, I propose changing the current "newlist" output. Better up, if the current output isn't portable, make the newlist output configurable at installation time (by setting type of MTA). -- Tomas

1 0

Re: [Mailman-Users] Configuration under EXIM and Debian v2.0
by Harald Meland Oct. 14, 1998

Oct. 14, 1998

[Peter Gervai] > - Create a list as usual. 'su - www-data' before creating... > When creating, newlist tells you what to insert. > Twist it a little, such as: > test: "|/var/lib/mailman/scripts/post test" > test-admin: "|/var/lib/mailman/scripts/mailowner test" > test-request: "|/var/lib/mailman/scripts/mailcmd test" This one stung me, too. Is the sendmail aliases syntax different from the Exim syntax here? Exim interprets the alias test: |"/var/lib/mailman/scripts/post test" as "when mail resolved via the alias key "test" arrives, try piping it to the space-containing command name '/var/lib/mailman/scripts/post test' with no arguments" If both sendmail and Exim are happy with the following syntax: test: |/var/lib/mailman/scripts/post test , I propose changing the current "newlist" output. -- Harald

1 0

Configuration under EXIM and Debian v2.0
by Peter Gervai Oct. 14, 1998

Oct. 14, 1998

Hello, Browsing the list revealed that no real how-to is present on using mailman with exim and/or debian. There is actually a deb package for sendmail, but it won't work for exim. I tried to install it and it works, more-or-less. I'd like to share that what I've done and raise some still not resolved questions. I'd like to comment that trying beta4 made python process to start allocating all available virtual memory (and beyond), rendering the machine unusable... I'm sure it was because some mistakes on my part but maybe it's possible to stop wild allocations caused by bad permissions, illegal mail headers, etc. Reinstalled beta5 from scratch and now it works. Either the bug got fixed, or I made config right this time, or most probably pure magic. My most important question: please anyone tell me which files, directories must have different permissions from chown mailman.mailman and 0775 (dir) or 664 (file)! I suspect log/ and files inside, and list/ maybe with its full content, but I don't know all possible files, and maybe missed some, and I have to KNOW it and not to guess, which gets used (needs to be written) as "mailman", which as "www-data", and which as both (probably requires some common groups then). This is my most important problem. The other is some actual minor one: mailman web interface cannot unlock a list, when a user want to enter her options webpage: Error at Cgi/subscribe.py line 65 - Unlock... Probably permission problem but I can't figure it out. Remember, I don't speak Python AT ALL. TIA. Okay, thats about questions. Here's the "debian+exim install manual" v0.01 -----------------------------8<------------------------------- Installing MailMan (1.0b5) on Debian GNU/Linux v2.0 + Exim by gervai 'grin' peter <grin(a)tolna.net>, v0.01 98/10/14 Install python-base, python-net. Install mailman user and group. I advise you to use 'lists' user and group id. (You can play and compile the whole stuff to lists.lists, probably not a big speciality, but I'm in kind of hurry. And a bit easier for me...) Compile very carefully to use correct mailman uid for the mail, and www-data uid for the cgi programs. (I have put stuff into /var/lib/mailman, but hardcore Debian file system standard gods may tell me otherwise. YMMW.) ./configure --prefix=/var/lib/mailman --with-mail-gid='mailman' \ --with-cgi-gid='www-data' Compile. Install. After installed, the following modifications were installed: - Fix up directory permissions, enable logging (even after that I ain't sure whether all logging will be allright...) chgrp lists /var/lib/mailman/* chmod 775 /var/lib/mailman/* chmod 3777 /var/lib/mailman/{logs,locks} - Enable web configuration interface chown www-data /var/lib/mailman/lists -R - Enable scripts for running them from the pipe transport later chmod +x /var/lib/mailman/scripts/{post,mail}* - Base Exim setup for lists. We create a separate alias file for the lists in /etc/mailman/aliases, and we insert lists there. We run everything uid,gid=mailman. Insert into /etc/exim.conf: into TRANSPORTS (place isn't important) mailman_pipe: driver = pipe; current_directory = /var/lib/mailman into DIRECTORS (immediately after system_aliases: section) mailman_list: driver = aliasfile; file = /etc/mailman/aliases search_type = lsearch user = mailman group = mailman pipe_transport = mailman_pipe - Create a list as usual. 'su - www-data' before creating... When creating, newlist tells you what to insert. Twist it a little, such as: test: "|/var/lib/mailman/scripts/post test" test-admin: "|/var/lib/mailman/scripts/mailowner test" test-request: "|/var/lib/mailman/scripts/mailcmd test" the other two alias is just okay. Insert this stuff into /etc/mailman/aliases, then press ENTER to get the administrative mail about the new list. - Several file gets created uid.gid I don't like, and had to fix afterwards. I can't python, so anyone see the light can help me... or us. - /var/lib/mailman/logs/* (esp: error and subscribe) chown them to www-data or touch/chown them beforehand. ------------------------------->8---------------------------- All comments are welcome, of course. If I made a mistake by list netiquette, just correct me. MOst of the time I'm in hurry so writing's first, thinking's afterwards. :-)) regards, grin (grin(a)tolna.net)

1 0

Mail Precidence
by Michael Ghens Oct. 12, 1998

Oct. 12, 1998

Neet list! Anyway. I noticed that mail is sent out as normal mail instead of Precidence bulk or list. Also, is there a switch for just queueing the mail. On large systems, this is at times, desireable. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Michael Ghens Small Planet Connections Internet: michael(a)spconnect.com Santa Barbara, CA http://www.spconnect.com/~michael ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Unix is user friendly. It's just selective about who its friends are.

1 0