Mailman 3 February 1999 - Mailman-Developers

Possible bug in 1.0b8
by Liam Kirsher 10 Feb '99

10 Feb '99

Hi, I don't know Python, so it's a little hard to tell what's going on. I think this is an undocumented feature, however. We changed the cgi name from mailman to newsletter, and so the url was incorrect. This caused the login process to fail because the url was incorrect. I found the problelm in Cgi/admindb.py, line 116 the reference to /mailman/admindb/ was a problem. I think the "mailman" part should be gotten from the DEFAULT_URL, perhaps? I just inserted what it needed to be ("newsletter"), but you might want to fix it for the future releases. Liam -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam(a)numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt

1 0

forwarded message from RFC Editor
by Fred L. Drake 10 Feb '99

10 Feb '99

I don't know if this would be interesting to you guys... -Fred

1 0

make update
by Greg Stein 10 Feb '99

10 Feb '99

I updated a 1.0b6 install to 1.0b8. Seems to have worked fine (great job!). The upgrade script issued some "errors" though, which it really shouldn't have. Specifically, here is a snapshot: Updating mailing list: p2c-dev - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me I never used a CVS snapshot. Looking at the code, I believe it doesn't recognize the fact that this came from 1.0b6 (i.e. recent versions) and just assumed it was a CVS version. Anyhow: it could throw somebody off if they weren't expecting it, so I'd recommend some kind of change -- alter the text, suppress it, etc. thx -g -- Greg Stein, http://www.lyra.org/

1 0

Re: [Mailman-Developers] What happened?
by Harald Meland 10 Feb '99

10 Feb '99

[Hermann Benedek] > The list received a lot of messages like this: [...] > Received: from MAILQUEUE by UZEM_1 (Mercury 1.21); 9 Feb 99 10:20:35 GMT+1 > From: "Cseh Miklos" <CSEHMI(a)uzem.radio.hu> As I couldn't find any hints in the original message that should have spurred any DSN (Delivery Status Notification), are you sure it's not the guys sending the replies that are at fault? I have on occasion encountered mail setups/clients that send me "delivery status notification" _regardless_ of whether I want it or not (and I don't :). Sometimes this is something that users have turned on themselves, and sometimes it's turned on for all users by the local admin (presumably because "it sounded neat"). What suprises me, though, is that the notifications are sent to the _list_ address, which only appeared in the "To:" header of the original message. Granted, I would not at all be surprised if such broken setups _also_ didn't care whether or not Reply-To: was set (which it apparently doesn't)... but sending delivery notification to the To: address? That's a new one to me. BTW, I thought DSN was something that was propagated through optional flags to certain SMTP commands, and not in the message (body or headers) itself -- cf RFC1891. Thus Mailman would essentially strip any DSN requests from a message before delivering a copy of it to the list members (because the envelope of the Mailman-originating message is _completely_ new, and not influenced by the original envelope in any way). > What is this? I'm filtering the "RCPT:" e-mails now.... If I'm guessing right, you'll either have to do some pretty aggressive filtering, or convince those of your members who send "I have now read your mail" messages to *stop* doing so (or at least don't send them to the To: header address). If none of these "solutions" work, there is one final (and very tempting, if I may say so :) option: Simply unsubscribe the offending members until they learn to behave. Good luck, -- Harald

2 1

[Fwd: Re: [Mailman-Users] Messages silently disappearing]
by Greg Stein 10 Feb '99

10 Feb '99

Screwed up privs seems to happen a lot. Sure, maybe the person installed improperly. But if it is simply permissions, then it should be easily rectifiable. Wasn't there a script or something to check the permissions? I couldn't find it. Would be nice to have one. Regardless, I might recommend a web page or other document that has a detailed listing of owner/group/privs for the relevant directories and files. thx -g Wes Morriston wrote: > > I did as you suggested. All the directories in /home/mailman are now > owned by mailman and all have the g+s setting. I took the +s off of > /usr/bin/python. The result? Messages silently disappear as before. > Put the +s back on python, and they don't disappear. > > Something clearly has the wrong ownership and/or permissions, but I just > don't know what! > > Frustrated, > > Wes > > Christopher Lindsey wrote: > > > > > drwxrwsr-x 2 root mailman 512 Feb 9 17:37 data > > > > > > That is exactly how mailman installed itself. (I was root when I did > > > the install.) > > > > Yes, I had the same problem. > > > > > I then did a > > > > > > chown -R mailman . > > > > > > in /home/mailman. > > > > This will probably unset the g+s setting on all directories. You > > need to set it back: > > > > cd ~mailman > > chown -R mailman.mailman . > > find . -type d -exec chmod g+s {} \; > > > > > The following, I discovered, does cause the messages to be delivered. > > > > > > chmod +s /usr/bin/python > > > > > > I hope it is not too dangerous to run python as root. > > > > Ummm, I would undo that. > > > > Chris > > > > ------------------------------------------------------ > > Mailman-Users maillist - Mailman-Users(a)python.org > > http://www.python.org/mailman/listinfo/mailman-users > > ------------------------------------------------------ > Mailman-Users maillist - Mailman-Users(a)python.org > http://www.python.org/mailman/listinfo/mailman-users -- Greg Stein, http://www.lyra.org/

1 0

Re: [Mailman-Developers] subscribers being ignored
by Harald Meland 09 Feb '99

09 Feb '99

[Jerry Adlersfluegel] > Harald Meland wrote: > > Just under the "conn = ..." line, insert > > > > conn.set_debuglevel(1) > > > > to enable debugging. Save the file, and send a message to the > > problematic list. Debugging output (i.e. a transcript of the entire > > SMTP dialogue) should now be in ~mailman/logs/error. Remember to > > remove the debugging line again afterwards. > > Ok, I put that in there, and debugging shows up in other places, but not > in that error log. OK, so I might have guessed wrong about the location of the resulting log file :) > Anyway, I had changed one of the user's settings to digest, so he would > at least get the list messages. Then when I was going to do the above > test, I changed him back to regular to see what happened, when he showed > up in the recipient list. I did the same for another user that was being > ignored, (change to digest and back to regular) and now he is getting > mail too. I don't know what was going on there, but it appeared to be > reproducible. Earlier, I had removed and re-added them to the list, but > that did nothing. Odd -- Internally, changing to digest only moves the address from the `members' dict to the `digest_members' dict, and reversing the change reverses the move. > Thanks for the help, Harald. I don't think that was a solution, but > I appreciate your efforts. If this really is unrelated to your MTA, then the output of the following commands might prove helpful in debugging (should you encounter the problem again): $ cd ~mailman $ python Python 1.5.1 (#1, Oct 9 1998, 15:23:54) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Mailman import MailList >>> import pprint >>> list = MailList.MailList("PROBLEM_LIST_NAME", lock=0) >>> pprint.pprint(list.__dict__) Substitute the name of the problematic list name for PROBLEM_LIST_NAME. -- Harald

1 0

What happened?
by Hermann Benedek 09 Feb '99

09 Feb '99

The list received a lot of messages like this: (sorry about the big header, but perhaps it contains some useful information) **************************************************************************** ***8

1 0

Re: [Mailman-Developers] Moderation comment interface change
by J C Lawrence 09 Feb '99

09 Feb '99

On Mon, 8 Feb 1999 19:49:09 -0500 Christopher G Petrilli<petrilli(a)amber.org> wrote: > On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote: >> On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G >> Petrilli <petrilli(a)amber.org> wrote: >>> Actually, it's not a bad format, probably better than all the >>> others, and well "documented" in elisp. >> >> True, and that'a a major strength. > > Yup, and I've never had a problem with it not finding the message > start/end correctly. I suspect it's about as bulletproof as any > non-database/singel-file solution can be! Quite. FWLIW FIDO used a not-dissimilar format. >> This is why you have options, such as the _option_ to save MH >> folders. > Ok, this I can see... that would be helpful, and shouldn't be that > hard to arrange, honestly... we've talked several times about > having an "archive filter" that does something in a black box, but > it's important to the main mailing list manager. Aye. I'm tempted to hack it in myself but I don't really have a feel for the flow of the base design of MailMan right now (and my Python skills are a little rusty). >>>> Need a MHonArc analogue that will run against MySQL. >>> >>> You mean a user interface? :-) Of course... >> >> I see two main approaches: >> >> A patch to MHonArc to read from MySQL > > Ick, but that's just me... I have allergic reactions to all things > related to Perl.. but that's just me. Ditto. > I just took a look at MHonArc, and it's not bad, > honestly... thoguh the interface needs a lot of work. It works and it works well. It delivers well proven and well known results for hundreds of thousands of messages a day. While I may quibble about the design and implementation of the product (it has great big hoary wary fugly bits), there's not a whole lot I can argue with the job it does (I use it here across a half dozen lists and a couple hundred thousand archives posts). >> A MHonArc analogue that will dynamically generate pages at >> request time from a MySQL database. > This is more what I have in mind... Its also a significant engineering effort with a _long_ test and burn in period behind it. This is human-sourced data with Microsoft seasoning: Expect to spend 90% of your time figuring out how to handle 3% of the weird exceptions. It is also of course the "One True Way". I just don't think its really worth the effort right now. > I have the following goals, personally, when I'm thining through > this. > * NO static HTML pages, everything is dynamically generated > (Zpublisher?) * Full-text query of messages * Intellegent MIME > handling (MHonArc gets this almost right) * Moderator "commenting" > of messages (more on this later) * Intellegent queries based on > header information I'm currently playing about with having MHonArc generate pages which contain a PHP3 blob referencing a DB entry which contains web-browser annotations and list-owner comments (cf PHP's own annotated manual). It looks like a workable idea that could actually be fairly useful. >> The first is the easiest and has all the prior art behind it. >> The second is the nominally "better" approach but is a >> significant engineering efffort. > Well, I'm not sure how much it is... MHonArc has taken a whole lot of time to get where it is today, and that's not for lack of effort or much due to bad design principles in the early efforts. Its mostly due to the fact that its a nasty nut to crack. >> Yup. Need something that will index the DB contents and derive >> appropriate URLs for the data found, rather than running thru the >> presentation_interface/web server to access the data and bind >> them to URLs. > THere's the rub... one of the problems i've had doing threading of > archives has been the fact that a few mail systems don't insert > Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-) Quite. I approve of MHonArc's approach: silently ignore duplicate and missing MessageID's. A slightly better approach would be to pseudo-generate MessageID's for messages which miss them (say a simple hash function of the message body), and then only ignore duplicate hashes, but its a very small gain for a very small impact problem. -- J C Lawrence Internet: claw(a)kanga.nu (Contractor) Internet: coder(a)kanga.nu ---------(*) Internet: claw(a)under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

2 1

Re: [Mailman-Developers] Moderation comment interface change
by J C Lawrence 09 Feb '99

09 Feb '99

On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G Petrilli<petrilli(a)amber.org> wrote: > On Mon, Feb 08, 1999 at 11:24:18AM -0800, J C Lawrence wrote: >>> Well, the other option is PMDF style (4 0x001 characters at the >>> beginning of the line). >> >> True, tho its been quite a while since I've run into that one. > Oh you'd be amazed how often I run into it... MMDF/PMDF live :-) I'll make no comment on elisp based MUA's. > Actually, it's not a bad format, probably better than all the > others, and well "documented" in elisp. True, and that'a a major strength. >>> THe big problem with using MH-style is that it can become a >>> HUGE HUGE HUGE disk hog... >> >> I have a little over a million and a half messages in MH folders >> right now, and yes, they chew disk space. Disk however is cheap. > Cheap yes, but still, I don't know that I want to waste it like > this unless there's no other solution. This is why you have options, such as the _option_ to save MH folders. >> Need a MHonArc analogue that will run against MySQL. > You mean a user interface? :-) Of course... There are multiple possible definitions of UI in that sentence. I see two main approaches: A patch to MHonArc to read from MySQL A MHonArc analogue that will dynamically generate pages at request time from a MySQL database. The first is the easiest and has all the prior art behind it. The second is the nominally "better" approach but is a significant engineering efffort. >> Need a decent search tool (I use WebGlimpse, but HT://Dig isn't >> too bad) that will run against the results. > THis is the second problem... I've been thinking about it... I > don't know of any text-indexer (ie inverted indeces) that is > designed to be programatically driven, rather than > stand-alone... Agreed. > I want something that can do all it's indexing, but be driven from > the unified interface, not from some secondary interface... know > what I mean? Yup. Need something that will index the DB contents and derive appropriate URLs for the data found, rather than running thru the presentation_interface/web server to access the data and bind them to URLs. Its a genericy vs effort issue. Good search tools are not trivial. -- J C Lawrence Internet: claw(a)kanga.nu (Contractor) Internet: coder(a)kanga.nu ---------(*) Internet: claw(a)under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

2 1

Re: [Mailman-Developers] subscribers being ignored
by Harald Meland 08 Feb '99

08 Feb '99

[Jerry Adlersfluegel] > How can I see exactly who a message is being (or was) sent to by > mailman? Sendmail should be logging this, I think. Have a look in your syslog. Barring that, I guess you could instrument Mailman like this: Open ~mailman/Mailman/Utils.py in your favorite editor. Look for this piece of code, in the TrySMTPDelivery() function: try: conn = smtplib.SMTP(mm_cfg.SMTPHOST) # Do the EHLO/HELO manually so we can check for DSN support Just under the "conn = ..." line, insert conn.set_debuglevel(1) to enable debugging. Save the file, and send a message to the problematic list. Debugging output (i.e. a transcript of the entire SMTP dialogue) should now be in ~mailman/logs/error. Remember to remove the debugging line again afterwards. -- Harald

2 1