Mailman 3 November 2000 - Mailman-Developers

Re: [Mailman-Developers] Towards 2.1
by Brian Edmonds Nov. 26, 2000

Nov. 26, 2000

Chuq Von Rospach <chuqui(a)plaidworks.com> writes: > if you're doing stuff to digests (like bursting), you should use MIME > digests any time tehy're available. Sure, in theory, but I can burst 1153 digests for reading purposes just fine. The full headers in the MIME digests can be nice on occasion, but for 99% of my needs, 1153 is just fine an is both smaller and faster for my client to parse. > >The announce has separate subscribers and also goes immediately to > >all regular and digest subscribers. Currently those lists are still > >running under Majordomo, as I have no idea how to make them do the > >same thing with Mailman. > The "easy" answer is to disable digests for announce lists. Since they > tend to be very low volume anyway, digest versions are generally pretty > useless. Um, no. Posts to the announce list go to the announce subscribers, the regular subscribers and directly to the digest subscribers. I could maintain a list of additional announce recipients which would be the regular and digest subscribers, but that would be an extra mechanism on top of Mailman, and prone to getting out of sync. Majordomo lets me set things up this way, which is pretty much the only thing keeping me from moving all my lists to Mailman. I'd also like to be able to do admin regexp matching on the body, but this may already be present in 2.0. I'm still running beta2. Likewise configurable holding or immediate rejection on a per regexp basis. Brian.

1 0

Re: [Mailman-Developers] Towards 2.1
by Brian Edmonds Nov. 26, 2000

Nov. 26, 2000

barry(a)digicool.com (Barry A. Warsaw) writes: > - Plain text digests should conform to RFC 1153. Yes please. Gnus supports 1153 digests, but doesn't recognize Mailman digests unless I switch to MIME format. > - Allow "urgent" postings to all members by the list admin which > bypasses normal digest delivery. I would like to be able to do this as more than just list admin. I've got at least three different lists on my system that have an announce, regular and digest options. The announce has separate subscribers and also goes immediately to all regular and digest subscribers. Currently those lists are still running under Majordomo, as I have no idea how to make them do the same thing with Mailman. And in the case of one of the lists it's not even an announce list, just a "regular" address that anyone can post to for topically urgent items. > - Allow the user to be excluded from postings if they're getting > them in the to: or cc: headers. Be smarter about filtering out > duplicate deliveries. This would be an interesting option, but I don't think I'd turn it on for most lists. > - Don't use the first public mailing list as the `originator' of > password reminders. Very much yes please. :) > - Provide an email interface to all administrative commands Ditto. > - For email subscribes, keep an audit of where requests are coming > from, and send the original request headers in the confirmation > message. Helps track down subscribe bombs. That sounds like a good idea. I've always liked mlms that do this. > - Support the `which' command. I had a user asking how to do this just yesterday. :) Brian.

2 1

Re: editing messages
by Tom Neff Nov. 25, 2000

Nov. 25, 2000

I patched 1.1 a year ago to allow editing a message before approval. I didn't bother with any pantywaist headers or disclaimers, although I suppose making one optionally available would be a joy-joy for the San Angeles Email Police. Mellow greetings and be well! *** admindb.py.orig Sun Jun 13 04:10:09 1999 --- admindb.py Mon Sep 18 14:27:48 2000 *************** *** 196,202 **** # We already handled this request. continue comment_key = 'comment-%d' % request_id ! if form.has_key(comment_key): list.HandleRequest(request, v, form[comment_key].value) else: list.HandleRequest(request, v) --- 196,207 ---- # We already handled this request. continue comment_key = 'comment-%d' % request_id ! contents_key = 'contents-%d' % request_id ! if form.has_key(contents_key) and form.has_key(comment_key): ! list.HandleRequest(request, v, form[comment_key].value, contents=form[contents_key].value) ! elif form.has_key(contents_key): ! list.HandleRequest(request, v, None, contents=form[contents_key].value) ! elif form.has_key(comment_key): list.HandleRequest(request, v, form[comment_key].value) else: list.HandleRequest(request, v) *************** *** 241,247 **** FontSize("+1", Bold('Contents:')) ]) form.AddItem(t) ! form.AddItem(Preformatted(val[2][1])) form.AddItem('<p>') --- 246,254 ---- FontSize("+1", Bold('Contents:')) ]) form.AddItem(t) ! # form.AddItem(Preformatted(val[2][1])) ! form.AddItem(TextArea("contents-%d" % val[0], rows=30, cols=85, ! text=val[2][1])) form.AddItem('<p>')

1 0

Minor flaw in archive date handling
by Christian Tismer Nov. 25, 2000

Nov. 25, 2000

Hi folks, I had some trouble getting the stackless mailing list repaired, after one message was repeated thousands of times. This was a message from October, but interestingly, the thousands of messages appeared in both the October and the November archives. Looking forther at one instance of the thousands of copies, I recognized that the message had no "Date:" entry, just a Resent-Date, for some unknown reason. After clearing the whole pipermail archive and recreating it with the bin/arch command, the message again appeared in the November archive. I took one of the fields with valid date enties and added it as "Date:" field by hand. Then the archiving worked as expected. My question: When a message happens to have no date, messages appear to be archived into the wrong archive file. There are a couple of other date fields available, like the usual "from" - line on top of the message, fields like Resent-Date or dates from the message passing through other servers. Wouldn't it make sense to do a more exhaustive search for a proper date, instead of accepting a missing date? cheers - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com

1 1

Re: [Mailman-Developers] Editing of messages at the admin page
by J C Lawrence Nov. 25, 2000

Nov. 25, 2000

On 24 Nov 2000 23:55:20 CET Ricardo Kustner <ricardo(a)rixhq.nu> wrote: > Although I like this idea, I personally think it would be more > friendly to add an extra comment field that will be added to the > top or bottom of the message... something like "[ Administrators > note: blah blah blah ]"... If you edit the content of a persons > message nobody will know what exactly you editted which can lead > to questionable situations... While I have a minor history of editing user's submissions to the list, in each case I've prefaced the resultant message with something akin to: EdNote: The following lightly edited for <insert reason> eg: http://www.kanga.nu/archives/MUD-Dev-L/2000Q4/msg00205.php I like this practice for the reasons you state. It is for similar reasons that I preface messages posted via my archives with text indicating both the source and invalidity of the From: address: http://www.kanga.nu/archives/IRead-L/2000Q4/msg00000.php The problem with doing this automatically upon edits is handling MIME in an end-user friendly fashion. The intent of the added header etc is partially substitute for an editorial note, and to make up for those occassions where the moderator edits and then fogets to annotate his changes. I don't want to embed diffs of the changes (which would remove the value of the edit in the case of flammage or inappropriate content), but I feel the system should at least flag the fact of the edit in some automatic fashion. This all said, the possibility of abuse is always present. Mailman can't prevent it, and I don't believe should be in the busines of controlling content at that level (tehre are applications where its unwelcome and unecessary). -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

1 0

Editing of messages at the admin page
by J C Lawrence Nov. 24, 2000

Nov. 24, 2000

I'm toying with the idea of adding raw message editing capabilities to the web moderation interface. The interface design would be as follows: ADMINDB_PAGE_TEXT_LIMIT would accept a special value of "0" meaning "entire message". This would have the side effect of also displaying all headers. If the config is set to display entire messages and the moderator edits the message in the relevant TEXTAREA, then the following will happen: A custom header will be inserteted in the message headers: X-Moderator: This message was edited by the list moderator A similar comment will be prepended at the top of the message. (I'm still argueing with myself on this one as I'd like it but some wouldn't) The edited form of the message will be broadcast. -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

2 1

Re: [Mailman-Developers] Re: Future of pipermail?
by J C Lawrence Nov. 24, 2000

Nov. 24, 2000

On Thu, 23 Nov 2000 23:54:23 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > At 11:45 PM -0800 11/23/00, J C Lawrence wrote: >> True. As happens I'm more tempted by LDAP. > I tend to think that the mailman <-> authentication interface is > going to be gnarly enough that it'll be a custom API. But I also > think that having PAM and LDAP access to the data will also > important to have for access in other ways -- PAM solves my > problem for archive access in apache wonderfully, and either PAM > or LDAP would make it easier to evolve my web forums into using a > sitewide account/password setup, which is something I really want > down the road. I don't see them as exclusive: http://www.padl.com/pam_ldap.html --<cut>-- The pam_ldap module provides the means for Solaris and Linux workstations to authenticate against LDAP directories, and to change their passwords in the directory. --<cut>-- -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: [Mailman-Developers] Re: Future of pipermail?
by J C Lawrence Nov. 24, 2000

Nov. 24, 2000

On Fri, 24 Nov 2000 00:01:29 -0500 (EST) Bill Bumgarner <bbum(a)codefab.com> wrote: > How about PAM-- pluggable authentication modules? It seems to > have become relatively standard on LInux and BSD and provides a > flexible and portable API that provides for versatile plug-n-play > authentication across platforms. Authentication data in the sense of identification (you know the UID and the password) is the simplest problem, and is probably so small as to be ignorable. The problem is not just UID/PW combos, but access rights, settings, configurations, meta data, etc. > Even if the implementation is not appropriate, the architecture is > certainly interesting and will likely contain ideas that are > pertinent to building such an authentication system as Chuq > described. True. As happens I'm more tempted by LDAP. -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

2 1

Interface to Archivers
by Jeffrey C. Ollie Nov. 24, 2000

Nov. 24, 2000

It would seem to me that the discussion so far regarding the "future of pipermail" is going too far in the direction of discussing "what would the most keenest archiver look like" rather than discussing "what should the interface between the Mailman and an archiver look like" and "what should the default archiver look like". So to try and steer the discussion in this direction, here I go sticking my foot in my mouth: What Should the Interface Between Mailman and an Archiver Look Like: def submit(mlist, msg) archiver = __import__('Mailman.Archivers.' + mm_cfg.ARCHIVE_MODULE) submit = getattr(getattr(getattr(mod, 'Archivers'), mm_cfg.ARCHIVE_MODULE), 'submit') urls = submit(mlist, msg) return urls The 'urls' returned from the archive module will be a data structure that includes a URL that points to the archived message as a whole and optionally URLs that point to individual MIME-decoded individual parts. If the archiver includes URLs for individual parts Mailman could optionally reformat the message to remove attachments and replace them with a pointer to the archive. So then we write any number of modules that interface to popular archivers, plus we include a simple default archiver (IMHO, in the same tarball as the Mailman). This way, the details of the archiver are completely hidden from Mailman and adding support for new archivers is very simple. I suppose that one could even add support for different archivers for every list. What Should the Default Archiver Look Like: It'll look a lot like pipermail, in that it stores archived messages in files on a filesystem. Indexes and tables of contents will be rebuilt as needed and saved in static files. It'll look different from pipermail in that MIME message parts will be decoded and be accessible as individual files. The reason for going with files stored on a filesystem is that it's very simple. No database to deploy and no fancy web server is required. More complex schemes are of course possible by writing the appropriate plug-in. Jeff

1 0

Re: [Mailman-Developers] Re: Future of pipermail?
by J C Lawrence Nov. 24, 2000

Nov. 24, 2000

On Tue, 21 Nov 2000 23:59:47 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > At 2:26 AM -0500 11/22/00, Bill Bumgarner wrote: >> Anything that is *using* Mailman as >> just-another-moving-part-among-many faces the memebership >> management problem and it is nasty,nasty,nasty. > If we end up doing the authentication widget, I want it to ship > with a set of modules and/or interfaces. That would include one > that does personal home pages, surveys, an interface to mailman, > an interface to a web forum, an LDAP interface of some sort for > external directory lookup and authentication purposes, and a few > other toys. I have slight allergic reactions here. Yes, I agree that a generic modular authentication model would be extremely useful (and I'd kill for a sufficiently flexible one), and it would be good if Mailman were able to plug into such a thing were it to be available on the local system, I don't see this as a Mailman specific problem, or one that should really be considered part of or rolled into the Mailman design process outside of "we should be able to integrate with one of those if its available, otherwise we punt to our LCD implementation". > With it and a few key tools, you can easily do 90% of Yahoo, minus > the big muther sets of data, but when it's done, you're very close > to a yahoo portal with clubs, IRC, egroups and some other tools > all rolled into a single cohesive beast -- and it'll scale, and it > will be extensible through a standard interface. Which, while a nice problem, is not the problem I belive Mailman is trying to solve. Mailman should of course play nicely with such solutions (yes, plural), but I see considerable loss to be realised if we tie it to a specific implementation or model (eg Zope), and abstracting at just the API level (as versus at the process level) is going to tend to lead you in that direction. > (and what I find scary is I don't see *anything* that is > technically a huge stretch. it's all engineering, not magic... Too true (written as one who has just re-engineered his own auth models). There's no rocket science here, just the normal stack of security model and privacy concerns. -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

3 2