Mailman 3 November 2000 - Mailman-Developers

Re: [Mailman-Users] Re: [Mailman-Developers] Reverting question
by J C Lawrence 15 Nov '00

15 Nov '00

On Tue, 14 Nov 2000 22:34:41 -0800 Marc MERLIN <marc_news(a)valinux.com> wrote: > Ok, more seriously, the only downside of group replies is that for > MUAs that don't support list-reply, like mutt does, the sender > gets two copies of the answer (which are easy to get rid off by > removing duplicate messages that contain the same message id) On *-ix platforms which have procmail/formail. Windows, MacOS, and BeOS users, to name but a few, have slightly more difficulty on this area. Sad, but true. >> http://www.metasystema.org/essays/reply-to-useful.mhtml > Yeah, except that the author is full of shit. Key points: This argument is a FAQ I've yet to see a single case where someone has been persuaded by the arguments of the other side once the argument has begun. Now, can we get on with some more productive discussions, like how vi users are scum-sucking brainless cretins and emacs users are the obviously intelligent few who can see and use true brilliance? > I do think that mailman should offer a reply-to option, but with a > very big disclaimer and maybe this discussion (or another one) so > that inexperienced listmasters realize what they're doing. I note that this is already done. > Microsoft is to operating systems & security Now, about them silly sendmail users... -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

3 3

Re: [Mailman-Users] Re: Reverting question
by J C Lawrence 15 Nov '00

15 Nov '00

On Tue, 14 Nov 2000 21:22:49 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > At 11:42 PM -0500 11/14/00, Tanner Lovelace wrote: >> There are arguments on both sides for this issue. I personally >> think it depends a lot on what the people on your list prefer. > But you need to be wary of making the mistake of "who's making > noise" being "what the people on the list prefer". Becaues I've > found, if I survey my lists, that the ones making the noise > *don't* represent the overall preferences of the list, but are > instead a noisy minority. Just because someone's complaining > doesn't mean they're right.... I've found the same statistics. That said, I've deliberately decided to comply with the noisy moinority view for the worst of reasons: I value the contributions of certain members of that minority highly (they occupy useful/divergent views or represent intellectually significant factions of the list topic), and, quite simply, the majority do not disagree enough to act on it (leave the list). An ugly trade-off, but one that (seems to) work. -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Problem archiving mail sent from pine (and other MUAs)
by Tanner Lovelace 15 Nov '00

15 Nov '00

I seem to have found an error where pipermail fails to process mail sent from pine (and possibly other mailers). The message gets added to the <listname>.mbox file but nothing else. In the logs/error file I get the following message: Nov 15 00:15:01 2000 qrunner(32366): Traceback (innermost last): Nov 15 00:15:01 2000 qrunner(32366): File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 221, in ArchiveMail Nov 15 00:15:01 2000 qrunner(32366): File "/usr/lib/mailman/Mailman/Archiver/pipermail.py", line 521, in processUnixMailbox Nov 15 00:15:01 2000 qrunner(32366): File "/usr/lib/mailman/Mailman/Archiver/HyperArch.py", line 224, in __init__ Nov 15 00:15:01 2000 qrunner(32366): TypeError: read-only character buffer, None Nov 15 00:15:01 2000 (32366) CORRUPT ARCHIVE FOR LIST: test Looking at the file HyperArch.py at line 224 I find the following: # Snag the content-* headers. RFC 1521 states that their values are # case insensitive. ctype = message.getheader('Content-Type') or "text/plain" cenc = message.getheader('Content-Transfer-Encoding') self.ctype = string.lower(ctype) self.cenc = string.lower(cenc) (line 224 is the last one.) So, apparently it is failing when it tries to lowercase the "Content-Transfer-Encoding" header string. So, I checked, and sure enough, pine (at least on the two systems I had access to) does not set this header. I then looked at RFC 1521 to see if this header is required. From the RFC (p.14) I quote: These values are not case sensitive. That is, Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body is already in a seven-bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present. So, the "Contenet-Transfer-Encoding" header is not mandatory and pipermail should not crash when it isn't there. Since I don't actually know python, :-) can anyone suggest an easy fix? It doesn't seem like it would be that hard to fix. I believe this is the same problem that Joshua Burley <jburley(a)kuci.org> first reported. Tanner Lovelace P.S. Should I submit this as a bug to sourceforge? -- Tanner Lovelace lovelace(a)wayfarer.org http://wtl.wayfarer.org/ Cthulu for President. Why settle for the lesser evil?

1 0

Re: [Mailman-Users] Re: [Mailman-Developers] Reverting question
by Dan Mick 15 Nov '00

15 Nov '00

> At 5:50 PM -0800 11/14/00, Marc MERLIN wrote: > >2) If you don't want to take that advise, you certainly shouldn't overwrite > > a users' reply to with the list's > > I'll disagree. If you feel you must coerce reply-to, coerce it > unconditionally. You've already decided the list's needs outweigh the > individual's needs, or you woudln't be coercing in the first place > Once you make that decision, whether or not the user ALSO uses a > reply-to is meaningless, and trying to take that into consideration > only confuses things, because then the list has its reply-to coerced > -- sometimes, and you have to know how to read mail headers ot figure > out when. Not good for the typical user, who may never figure out why > something isn't working randomly. I have to agree with Chuq; all or nothing seems to be the only sane policy. (and I'm a big Reply-To hater.)

1 0

Default path for archives wrong in rc2
by Phil Barnett 15 Nov '00

15 Nov '00

I know that we got caught up in the replyto munging issue, but did anyone see that when I switched to rc2, my archives went offline and I can't add a new user because the archive is not where it's expected to be now because of a /bin/ in the message? I can post the problems specifically again if necessary, but the path problem was posted a couple of days ago. Since my rc2 upgrade from b6, I can't create new lists and my archives are offline. http://www.matrixlist.com/mailman/listinfo is broken and the data didnt' move. -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net

1 0

Re: Mailman-Users digest, Vol 1 #870 - 2 msgs
by Ray Frush 14 Nov '00

14 Nov '00

> I've slept on this one and I'm prepared to change things for 2.0 final > so that if Reply-To munging is turned on, it'll override any existing > Reply-To field in the original message. The deciding factor for me > was realizing how difficult it was to send private replies with > munging turned on, so it might as well be equally difficult for every > poster. If Reply-to munging is enabled, I would expect that it would really munge. That is, if you turn on the feature, it will ALWAYS exhibit the behaviour. In the current version, Reply-To: munging appears broken because it appears to work part of the time. Count this as a vote to enable the much debated Reply-to munging that will override any client (MUA) Reply-to settings. -- Ray Frush "Either you are part of the solution, T:970.288.6223 or part of the precipitate." -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Agilent Technologies IT | Technical Computing | Fort Collins Site

1 0

Re: Searchable Archives
by John Block 14 Nov '00

14 Nov '00

Hello Bob Fortunatly I'm skilled enough to beable to cut and paste addresses so you will get this publically. > #2. Is there any, ANY way to make the archives searchable? (Under Linux) My plan is to have pipermail which is included in the tarball create html pages. I'm then plannning to get the http://www.thunderstone.com search engine installed to search the html Thunderstone seems to offer alternative search terms based on relationships in the data. A feature which has has got me excited) John

1 0

Re: [Mailman-Users] Re: [Mailman-Developers] Announcing Mailman 2.0 release candidate 2
by Phil Barnett 14 Nov '00

14 Nov '00

On 14 Nov 2000, at 0:16, Barry A. Warsaw wrote: > > >>>>> "PB" == Phil Barnett <midnight(a)the-oasis.net> writes: > > PB> I upgraded from 2.0b6 from 2.0rc2 Friday night. A person wrote > PB> me and said the replyto: is no longer pointed to the list. I > PB> checked several messages and they were, but some were not. Any > PB> message I send to the list has a replyto of myself instead of > PB> to the list. > > Please remember that if the original message has a Reply-To: already, > Mailman will not overwrite that, even if "explicit reply-to" is set. > So, did the original mesasge have a Reply-To already? > > I just tested this using rc2. With reply_goes_to_list set to > "explicit address" and reply_to_address set to some non-blank value, > any message without a Reply-To: gets one set to that value. Any > message that already has a Reply-To: set is unchanged. That's > expected behavior (i.e. works for me!) Expected behavour for whom? For all the users on my lists, it has them screaming. They want to know why Mailman is broken after the upgrade. 2.0b6 did not exhibit this behaviour. How can I make 2.0rc2 work like b6 did? I think it's rather impossible to get all list users on the planet to remove their replyto so they can reply to the list on a list that replyto list is set. Expecially so since setting replyto is generally a global setting in most MUA's. Why was this changed? Is there a way to make Mailman to have this be selectable behaviour for it to work both ways? Not being able to force replyto to the list is broken behaviour in my users eyes, and, they are the ones who really count. My open source developers list is ready to switch back to egroups over this. That can't be good news. -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net

1 0

Announcing Mailman 2.0 release candidate 2
by barry＠digicool.com 14 Nov '00

14 Nov '00

This is it. Mailman 2.0 release candidate 2 is now available from SourceForge at http://sourceforge.net/project/showfiles.php?group_id=103 www.list.org and www.gnu.org should be updated soon. Excerpts from the NEWS file are given below. Of primary importance in this release is the fix of the last known mail duplication bug, and updated on-line documentation. You can view the documentation at http://mailman.sourceforge.net Please let me know if you find any errors in the docs. Unless something's royally screwed, those are the only changes I'll make before 2.0 final. Plan for that one week from today: Friday November 17th. Enjoy, -Barry -------------------- snip snip -------------------- 2.0 release candidate 2 (10-Nov-2000) - Documentation updates: start at admin/www/index.html - bin/withlist accepts additional command line arguments when used with the --run flag; bin/mmsitepass and bin/newlist accept -h/--help flags - bin/newlist has a -o/--output flag to append /etc/aliases suggestions to a specified file - SourceForge bugs fixed: 116615 (README.BSD update), 117015 (duplicate messages on moderated posts), 117548 (exception in HyperArch.py), 117682 (typos), 121185 (vsnprintf signature), 121591 and 122017 (bogus link after web unsubscribe), 121811 (`subscribe' in Subject: doesn't get archived) - SourceForge patches applied: 101812 (securelinux_fix.py contrib), 102097 (fix for bug 117548), 102211 (additional args for withlist), 102268 (case insensitive Content-Transfer-Encoding:)

4 6

Re: [Mailman-Developers] Announcing Mailman 2.0 release candidate 2
by Gunnar Evermann 14 Nov '00

14 Nov '00

barry(a)digicool.com (Barry A. Warsaw) writes: > This is it. Mailman 2.0 release candidate 2 is now available from > SourceForge at ok, I've just installed this from scratch. > - SourceForge patches applied: > 102268 (case insensitive Content-Transfer-Encoding:) This fix is wrong AFAICT. If an article doesn't contain a C-T-E header then I get the following from running the archiver list@casablanca:/var/lib/mailman$ bin/arch mailman-test-list-a Traceback (innermost last): File "bin/arch", line 129, in ? main() File "bin/arch", line 118, in main archiver.processUnixMailbox(fp, Article) File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 521, in processUnixMailbox a = articleClass(m, self.sequence) File "/var/lib/mailman/Mailman/Archiver/HyperArch.py", line 224, in __init__ self.cenc = string.lower(cenc) TypeError: read-only character buffer, None I just started learning Python, so I'll leave the (trivial) fix to you, Barry. Just wanted to let you know before you release this :-) Gunnar

2 1