Mailman 3 March 1999 - Mailman-Developers

Re: [Mailman-Developers] Does anyone else see these?
by J C Lawrence 05 Mar '99

05 Mar '99

On Fri, 5 Mar 1999 01:17:53 -0600 (CST) Christopher Lindsey<lindsey(a)ncsa.uiuc.edu> wrote: > Perhaps Mailman could add (yet another) header indicating the > targetted recepient to help with this type of situation? Maybe > X-Mailman-Recepient? Or it could be wrapped it into another header > like X-BeenThere... One technique I used for my own list software (now defunct) was that every N'th message to each subscriber was sent individually with custom headers giving the subscription address, list name etc. All the other sends (the rest of N) were sent as per normal with 100 RCPT TO's per message. Then, instead of attempting to parse bounce formats, instead I merely looked for these custom headers in the bouce returns and tracked that way. In this way, by rotating the N thru the subscriber base so that on any one particular posting only 1/N'th of the subscribers were sent individual messages I could minimise mail load on the system and have an guaranteed accurate tracking system for who was *really* bouncing when there forwards inbetween. -- J C Lawrence Internet: claw(a)kanga.nu ----------(*) Internet: coder(a)kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

1 0

Re: TOPICS
by Harald Meland 05 Mar '99

05 Mar '99

[Paulo Eduardo Neves] > Harald Meland wrote: > > Anyhow, I guess that implementing this would be a lot easier (and > > cleaner) if every list member had some "user objects" -- and that is > > planned for after 1.0. So I guess we'll think about it all until we > > have the infrastructure to implement it on top of in place. > > I've read in the TO-DO list about User profiles, is it the same of user > object? Not quite, but they're not unrelated, either. > Could you explain the idea behind it? Well, the motivation I have for implementing "user objects", is that I don't want one particular user that is subscribed to several Mailman mailing lists (on the same Mailman installation) to have to remember one password per list. If Mailman had an installation-wide database of all members subscribed to any of the lists, and each list had "pointers" pointing to specific user objects in this database (meaning that the users corresponding to the pointed-to objects are members of the pointing-from list), the user password could be kept in the user object instead of with each list. You'd also get a lot of other benefits from this, of course: * User objects could know about the different mail aliases belonging to one user (meaning that Mailman would know that `hmeland(a)usit.uio.no' and `harald.meland(a)usit.uio.no' were really the same user, which is very handy for "restrict posting privilege to list members") * Admins are users as well -- thus their _single_ admin password, which would work for all the lists they admin, could be stored in a (special) user object. Lists with multiple admins wouldn't need their admins to share the single list password anymore. * If some person changes email address, update the person's user object -- and all the mailing lists the person is a member of automatically goes to the new address. Ditto for disabling delivery when going on vacation etc. Having separate settings for different lists should of course remain possible. ... just to mention a few things. None of this is set in stone, of course -- these are just some ideas I have, nothing has actually been implemented. "Member profiles", I think, means that you each user can organize their subscriptions into hierarchies (within their user object) -- thus, any changes made to the root node in the hierarchy gets inherited by all your subscriptions. Example: * Root node | * Python mailing lists | * "Mailman-users" subscription options * "Mailman-developers" subscription options * Work-related mailing lists | * "postmaster" subscription options * "hostmaster" subscription options * "webmaster" subscription options Your local mail system has recently been upgraded to support addresses of the form `username+suffix(a)example.com', signifying that mail to this address goes directly into your IMAP folder called `suffix'. You want to use separate mail addresses for the python lists and the work-related lists -- so you enter each of these "member profiles" and update them, and the changes propagate down the tree to the different lists. Voila :) > I believe it would solve well a problem I have. I have an announcement > list where I send messages about a lot of topics. Not all topics are of > interest of all subscribers (i.e. Joe doesn't want to know about events > in other state). > > It looks like user profiles (or Topics) would solve this problem. Topics are not the same as member profiles. The (hypothetic) user "Topics" setting are meant to signify what subset of messages you want to receive from a topic-enabled Mailman list, while member profiles are for specifying defaults for subsets of your list subscriptions (regardless of whether the subscribed-to lists are topic-enabled or not). I was merely stating that for implementing topics, one needs to keep so much user-specific information (on what topics are deemed interesting) in Mailman, that keeping off implementing it until _after_ the introduction of user objects (which will provide a handy mechanism for storing user-specific information) would seem like a smart move. -- Harald

1 0

Does anyone else see these?
by paz 05 Mar '99

05 Mar '99

I've gotten two admin messages to mailman-owner from a mailman list I run on apriori.net (Hummers - a humor list). (begin included text) =================================== Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29989 for <jokes-in(a)apriori.net>; Thu, 4 Mar 1999 02:08:34 -0500 (EST) (envelope-from mailman-owner(a)apriori.net) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29979 for <hummers-admin(a)apriori.net>; Thu, 4 Mar 1999 02:08:30 -0500 (EST) (envelope-from mailman-owner(a)apriori.net) Date: Thu, 4 Mar 1999 02:08:30 -0500 (EST) Message-Id: <199903040708.CAA29979(a)apriori.net> From: mailman-owner(a)apriori.net Subject: Hummers member redscares(a)spamcom.net bouncing - NOT disabled To: hummers-admin(a)apriori.net Errors-To: mailman-owner(a)apriori.net MIME-version: 1.0 Content-type: multipart/mixed; boundary="192.168.51.99.1.29976.920531310.496.13704" X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. <hummers.apriori.net> Parts/attachments: 1 Shown 16 lines Text 2 Shown 61 lines Text ---------------------------------------- Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: Hummers Member: redscares(a)spamcom.net Action: Subscription not disabled. Reason: Excessive or fatal bounces. BUT: User not found. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner(a)apriori.net. [ Part 2: "Attached Text" ] This is a MIME-encapsulated message --CAA24772.920531258/camel8.mindspring.com The original message was received at Thu, 4 Mar 1999 02:07:37 -0500 (EST) from mx10.mindspring.com [207.69.200.126] ----- The following addresses had permanent fatal errors ----- <redscares(a)spamcom.net> ----- Transcript of session follows ----- 550 <redscares(a)spamcom.net>... Host unknown (Name server: spamcom.net: host not found) --CAA24772.920531258/camel8.mindspring.com Content-Type: message/delivery-status Reporting-MTA: dns; camel8.mindspring.com Received-From-MTA: DNS; mx10.mindspring.com Arrival-Date: Thu, 4 Mar 1999 02:07:37 -0500 (EST) Final-Recipient: RFC822; redscares(a)spamcom.net Action: failed Status: 5.1.2 Remote-MTA: DNS; spamcom.net Last-Attempt-Date: Thu, 4 Mar 1999 02:07:38 -0500 (EST) --CAA24772.920531258/camel8.mindspring.com Content-Type: text/rfc822-headers Return-Path: <hummers-admin(a)apriori.net> Received: from mx10.mindspring.com (mx10.mindspring.com [207.69.200.126]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id CAA01606 for <redscares(a)spamcom.net>; Thu, 4 Mar 1999 02:07:37 -0500 (EST) From: hummers-admin(a)apriori.net X-MindSpring-Loop: t-eaton(a)mindspring.com Received: from apriori.net ([209.192.153.107]) by mx10.mindspring.com (Mindspring Mail Service) with ESMTP id rdsc9m.i37.37kbi3u for <t-eaton(a)mindspring.com>; Thu, 4 Mar 1999 02:07:34 -0500 (EST) Received: from gw.apriori.net (localhost.apriori.net [127.0.0.1]) by apriori.net (8.8.8/8.8.8) with ESMTP id CAA29959; Thu, 4 Mar 1999 02:08:03 -0500 (EST) (envelope-from hummers-admin(a)apriori.net) Received: from localhost (jokes-in@localhost) by apriori.net (8.8.8/8.8.8) with SMTP id CAA29933 for <hummers(a)apriori.net>; Thu, 4 Mar 1999 02:07:52 -0500 (EST) (envelope-from jokes-in(a)apriori.net) Date: Thu, 4 Mar 1999 02:07:51 -0500 (EST) To: hummers(a)apriori.net Subject: [Hummers] The Short List Message-ID: <Pine.BSF.3.96.990304020500.29669C-100000(a)gw.apriori.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hummers-admin(a)apriori.net Errors-To: hummers-admin(a)apriori.net X-Mailman-Version: 1.0b8 Precedence: bulk List-Id: Humor email list. <hummers.apriori.net> X-BeenThere: hummers(a)apriori.net --CAA24772.920531258/camel8.mindspring.com-- ========================================== (end included text) redscares(a)spamcom.net (obviously) is not a subscriber of list Hummers, yet the message seems to think he is. Therefore I can't delete from the subscriber list one who isn't subscribed... In the line: X-MindSpring-Loop: t-eaton(a)mindspring.com user t-eaton(a)mindspring.com IS a subscriber, however. Does anyone know what's going on with this? cheers - -- Philip. philip zimmermann paz(a)apriori.net www.apriori.net ayer, ma usa

2 1

Re: [Mailman-Developers] TOPICS (was bounce processing question and idea for future enhancements...)
by Harald Meland 05 Mar '99

05 Mar '99

[Jeff Hahn] > Listserv topics work like this: > > Messages sent to the list include one or more keywords (topics) in the > subject. There is a defined set of topics for the list. Subscribers can > choose to receive messages for individual topics. > > When the MLM receives a message, it extracts the topics from the subject. > To deliver a message, the MLM intersects the set of topics in the message > with the set of topics that a given subscriber has chosen (to use set > terminology). If the intersection is non-empty, that subscriber gets the > message, otherwise not. > > there is usually an "ADMIN" topic that is sent to ALL listmember and has > restricted posting. Subscribers can choose whether or not to "subscribe to > New topics automatically", so that when topics are added, the member list > can be updated. > > Messages without a valid topic are optionally rejected. My feelings on this are rather mixed: While I can see the use something like this would have when your users are inexperienced, I'm still not sure that I would be able to tell it apart from some featuritis-infected hack :) Anyhow, I guess that implementing this would be a lot easier (and cleaner) if every list member had some "user objects" -- and that is planned for after 1.0. So I guess we'll think about it all until we have the infrastructure to implement it on top of in place. -- Harald

2 1

Re: [Mailman-Developers] Install clarification
by Harald Meland 04 Mar '99

04 Mar '99

[Christian Tismer] > Can it be that the chmod should better read like > "chmod a+rx,g+ws ." ? It can, indeed. Fixed and checked in. > newlist has been changed somewhere between 1.0b7 and 1.0b9 > in the wrong way, and the change has obviously not been > tested! [...] > The "import paths" must go *before* the try..except True -- fixed and checked in. Thanks a lot for the feedback! -- Harald

1 0

Re: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url)
by Harald Meland 04 Mar '99

04 Mar '99

[Christian Tismer] > Hi Barry et al, > > I found it - Mailman 1.0b9 has a bug in admin.py . Which was fixed _days_ ago in CVS :-) > defaulturi = 'mailman/admin%s/%s' % (mm_cfg.CGIEXT, [...] > "path" : os.environ.get("REQUEST_URI", defaulturi), [...] > defaulturi is *wrong*, it needs a slash in front. > > How comes that nobody complained yet? If your web server provides CGI scripts with an REQUEST_URI environment variable, the fallback value of `defaulturi' won't be used. This has been further refined in the current CVS version -- first try REQUEST_URI (which isn't part of the CGI/1.1 spec), then try concatenation of SCRIPT_NAME and PATH_INFO (both of which _are_ part of CGI/1.1), then fall back on the (corrected) defaulturi. -- Harald

2 1

Re: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9)
by Harald Meland 04 Mar '99

04 Mar '99

[Greg Stein] > Harald Meland wrote: > > ... > > For users it is always good to make _all_ the bells and whistles > > configurable. However, Mailman has to find a balance between user > > configurability and how efficient list delivery should be. > > I strongly disagree with the blanket statement that it is "always good". Sorry, I phrased that rather badly -- what I meant to propagate, was that there's always _some_ user that wants more configurability. If Mailman should cater to any and all of these wishes, it would be a) inefficient and b) (as you point out) a terrible mess. Sorry about the confusion. > You really should not keep dropping knobs onto Mailman. ... unless there is a real need for them, I presume? > Look at the problem with the settings for "who can post to this > list". LOTS of people have problems with getting that set up > right. The problem? Too many knobs. Well, the "too many knobs" issue of "who can post" is (at least in part) caused by the "rather finegrained control" many list admins want over who can post. So, the problem is not merely to reduce the number of buttons, but to do so while _keeping needed functionality_. -- Harald

1 0

Setup prob: abs/rel CGI url
by Christian Tismer 04 Mar '99

04 Mar '99

Hi Mailman developers, I've set up Mailman 1.0b9 for starship.skyport.net exactly as the INSTALL file said. It is working so far, with one exception: When I try to use the admin page for my test list, I first get the password dialog, as usual. After entering the password, Mailman complains that the list "mailman" is nonexistent. Reason: The CGI of the password dialog contains a relative CGI URL: <html> <head> <title>test Administrative Authentication</title> </head> <body bgcolor="#ffffff"> <FORM METHOD=POST ACTION="mailman/admin/test"> which causes the URL to pile up to http://starship.skyport.net/mailman/admin/mailman/admin/test and leads to the message that a list "mailman" indeed does not exist. :-) I think I have checked everything against the 1.0b7 installation on python.net and couldnot find any difference whcih mght cause this. The only real difference is that skyport.net still runs an early Python 1.5 version. Please help, I cannot find the bug. Can it be due to Python 1.5 ? cheers - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home

1 1

Re: [Mailman-Developers] bounce processing question and idea for future enhancements...
by Harald Meland 04 Mar '99

04 Mar '99

[Jeff Hahn] > Bounce processing question... > > Since some of the big email domains (hotmail, aol, etc.) are known to > "burp" and deny existence of perfectly valid users, I'd like to handle all > returns as bounces and not remove people automatically on the first "user > unknown" message. I assume the way to handle it is to change "REMOVE" to > "BOUNCE" in the lines like the following in bouncer.py > > (regex.compile('.*%s: User unknown.*' % email_regexp), REMOVE), > > Any comments? Any better way to do it? Nope, none apart from the obvious "This is a very sad situation" :( If you're happy with Mailman "disabling" failed addresses (as opposed to removing them), you can tweak the `automatic_bounce_action' list config option accordingly from "Bounce Options". > Idea for future enhancements... > > This is the big one. Does anyone besides me have a desire to see Mailman > support Listserv style "topics"? Where topics are extracted from the > message subject and list messages are sent to a subset of the list that > "subscribes" to that particular topic? I don't know ListServ -- what is the motivation for implementing something like this? Wouldn't a separate mailing list for each "topic" and appropriate crossposting do the same? Should there be topic-specific archives, or should the archive be topic-insensitive? To be frank, this whole idea seems rather hackish to me, though I might feel better about it if you explain _why_ you have a need for it. Of course, if this, for some reason that eludes me at the moment, is a nice feature to have in an MLM, we'd like to have it in Mailman :) -- Harald

3 2

Re: [Mailman-Developers] Configurability (was Re: [ANNOUNCE] Mailman 1.0b9)
by J C Lawrence 04 Mar '99

04 Mar '99

On Wed, 3 Mar 1999 11:42:24 -0800 John Viega<John(a)list.org> wrote: > Well, my philosophy on the matter is to keep the common tasks easy > and the expert tasks possible. So I think there should be a basic > section, and an advanced section, where there'd be some overlap. > For example, in the basic section, you could just say, "give me a > moderated list", but the fine grained control is available at the > expert level. I don't really mind catering to everyone as long as > we focus on catering to the novice, since that's most people who > will be administrating or using a list... Specifically: VA Research has a need for a list server that presents only the following options upon list creation (web preferred): Name of list. Reply-To option. Open/closed subscription option. Subscribers only from specified domain text field. Bounces go to MailMan owner or list owner option. Support digests option. The actual need is for someone in HR, a computer illiterate someone who just understands typewriters, to be able to create a list on demand which central IS can then do the background management for (bounces etc) but is otherwise default configured and obvious. They *really* like MailMan. They just need a severely dumbed down interface to list creation for it. -- J C Lawrence Internet: claw(a)kanga.nu ----------(*) Internet: coder(a)kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

1 0