Mailman 3 October 2001 - Mailman-Developers

DEFAULT_HOST_NAME -- Remark
by Oliver Egginger 27 Oct '01

27 Oct '01

The DEFAULT_HOST_NAME variable (option) should be renamed to DEFAULT_MAIL_DOMAIN (or something similar) Thats what it is. - oliver

2 1

<I>html tags in subject
by Phil Barnett 27 Oct '01

27 Oct '01

Barry, have you done something about people putting html tags in the subject? I have seen them really mess up the look of pipermail.

1 0

advice on external hooks and multi-list member sets
by Andy Heath 27 Oct '01

27 Oct '01

Hi, two areas I'd appreciate suggestions on how to *best* handle: They are specific but there are general issues hiding behind them. 1. Currently running 2.0.6. I need to plug external code into subscription/usubscription handling, for example so as to be able to call my own non-mailman code when a subscription happens. Where is the best place to do this ? I've been looking at ApprovedAddMembers but without detailed knowledge of the (soft) architecture I'm not completely certain that this is the best place. I need to pass to external code the approved id and password - how would I do this ? 2. Lists with shared member sets. People are going to wonder why I would want this. The reason is for interfacing with external software systems - I'm using my lists membership for access control in web applications (for example, only list members can access this part of the web). There are interesting things one might want to do such as having lists with mailouts disabled, just for membership control or using different lists (separate configurations but common or overlapping membership sets) for different purposes where web events are sent to lists and vice-versa. Easy question - is there an easy way to have two lists with *one* membership set (an obvious unix way to implement this would be a common file with links to it from two places - ok, its not relational database). Harder questions follow. Harder, more general questions. These considerations raise more general ones about external hooks and interoperability. I'm thoroughly in approval of the do-one-thing-well philosophy. Part of doing one thing well is about providing ways to interface that increase the number of contexts in which something can be used. Is there a need here for some general ways to interface with events within mailman ? Changing internal code may not be the best way because it will lock me in to that version. That suggests an API, which wouldn't quite solve my problem though. Is there a need to split out the membership system so as to allow other ways to handle membership (such as LDAP for example) or allow multiple ways to authenticate etc. ? andy

1 0

how to get the latest .po file to translate?
by Fil 27 Oct '01

27 Oct '01

how do you get the latests .po file? The french translation in version 2.1-alpha3 currently lacks quite a few sentences... -- Fil

4 3

Re: [Mailman-Users] Old Question, New Twist
by barry＠zope.com 27 Oct '01

27 Oct '01

[Cc: changed to mailman-developers -BAW] >>>>> "PC" == Paul Cox <paul(a)coxcentral.com> writes: PC> I'm that one that's done the last couple of Mandrake .rpm's PC> for Mandrake. Let me help you out. Maybe we should coordinate to make things easier (or more visible) for RPMs. I definitely don't have the time to support them, and am very glad that you do, but maybe we can make things easier. >> My problem is the age old: Failure to exec script. WANTED gid >> 99, GOT gid 12. (Reconfigure to take 12?) 554 5.3.0 unknown >> mailer error 2 PC> The reason for this is easy. Since Mandrake installs the PC> Postfix MTA by default (you have to go out of your way to use PC> sendmail instead), that's how the .rpm configures Mailman PC> during the build. Postfix delivers mail as gid nobody (99), PC> while sendmail delivers mail as gid 12 (mail). Unfortnately, PC> you can't build an .rpm for both ways. Since Postfix is the PC> default (and recommended) MTA, that's the one I went with. I've been thinking in the background about how to make the compiled in gid a run-time option. I've always considered it difficult and unsafe to do, but here's an idea: What if the mail and cgi wrappers took an optional argument (say -g) on the command line to specify the gid it looked for. No -g and it falls back to the compiled value. We'd have to #ifdef this feature though, and the default would be to disable it, because I believe it would allow untrusted users to defeat this test fairly easily. That might be too big a security hole. On second thought, maybe we allow ifdef'ing out the gid check altogether? On third thought, we could try to put the gid out of a config file, but it's such a pain to handle this in pure-C that I've avoided doing it. Maybe we need to bite the bullet? The other issue here is that by keeping the wrappers as small as possible, we can feel better about their security. The more complexity we introduce, the more exploits we potentially open up. Thoughts? -Barry

1 0

Using pre-existing passwords along with mailman passwords?
by Jerry Stratton 27 Oct '01

27 Oct '01

I posted this to the users group, and they suggested I post it here; I've looked into what might need to be done, and it looks like it will be a lot easier for list members than for list administrators; since list members have 'usernames' (their e-mail address), but list administrators just have their password? Is there a best place to apply such a patch? At our University, we use a special username/password (called a "UNet" account) for all web-related items. We can match the UNet username directly to the user's University e-mail address. I would like to use this username/password for all list members and list owners who have a UNet account, but fall through to the mailman-generated password for those who do not. We do not have access to the actual password--it is stored only as a Unix hash so we can't simply insert it into the mailman password database (and we wouldn't want to send it out via e-mail on a monthly basis in any case). Has anyone else implemented something like this? What I'm looking at as a possibility is setting up an Apache .htaccess file so that all of the mailman directories are password protected, but allow guest access (Apache has a special module that will do this). If a user logs in using their UNet account, map it to their e-mail address and bypass mailman's login process. If the user logs in as a guest, do not bypass mailman's login process. Has anyone already done this? If so, are there already any instructions somewhere for how to do this? Any foreseeable problems with this method? Jerry -- jerry(a)sandiego.edu http://www.sandiego.edu/~jerry/ -- The more restrictions there are, the poorer the people become. The greater the government¹s power, the more chaotic the nation would become. The more the ruler imposes laws and prohibitions on his people, the more frequently evil deeds would occur. --The Silence of the Wise: The Sayings of Lao Zi

2 1

another patch
by Tokio Kikuchi 27 Oct '01

27 Oct '01

Hi, handle_opts.html no longer exists, I guess. Barry, I hope you can care other patches I have posted before; http://mail.python.org/pipermail/mailman-developers/2001-October/009832.html http://mail.python.org/pipermail/mailman-developers/2001-October/009655.html Tokio -------- Original Message -------- Date: Fri, 26 Oct 2001 16:52:36 +0900 (JST) From: Mailman Admin <mailman(a)seppyo.org> To: tkikuchi(a)is.kochi-u.ac.jp --- edithtml.py.orig Wed Jul 11 23:45:09 2001 +++ edithtml.py Fri Oct 26 16:51:45 2001 @@ -42,7 +42,6 @@ ('listinfo.html', _('General list information page')), ('subscribe.html', _('Subscribe results page')), ('options.html', _('User specific options page')), - ('handle_opts.html', _('Changing user options results page')), ) _ = i18n._

2 1

regexp on body checks
by Bob Puff＠NLE 27 Oct '01

27 Oct '01

I'm searching through the admin area of 2.1a3, and I can't seem to find where the body checks are done. I remember a recent discussion that 2.1 could look for a string in the body of a message (like the footer of a quoted digest), and reject the message if it matched. Bob

2 1

Lots of dup Rcv: headers?
by Bob Puff＠NLE 27 Oct '01

27 Oct '01

Ok, here's another oddity. In a 2.1a3 list, it looks like the Received: headers are being duplicated: Received: by main.nlenet.net (mbox bob) (with Cubic Circle's cucipop (v1.31 1998/05/13) Thu Oct 25 22:58:50 2001) X-From_: csc-admin(a)lists.churchsoundcheck.com Thu Oct 25 22:57:57 2001 Return-Path: <csc-admin(a)lists.churchsoundcheck.com> Delivered-To: bob(a)nlenet.net Received: from main.nlenet.net (localhost.localdomain [127.0.0.1]) by main.nlenet.net (Postfix) with ESMTP id 2FE1413D126 for <bob(a)nleaudio.com>; Thu, 25 Oct 2001 22:57:57 -0400 (EDT) Delivered-To: csc(a)nlenet.net Received: from ns.nlenet.net (ns.nlenet.net [208.178.159.66]) by main.nlenet.net (Postfix) with ESMTP id C8DEE13D126 Received: from ns.nlenet.net (ns.nlenet.net [208.178.159.66]) by main.nlenet.net (Postfix) with ESMTP id C8DEE13D126 for <csc(a)lists.churchsoundcheck.com>; Thu, 25 Oct 2001 22:57:55 -0400 (EDT) Received: from nleaudio.com (nle-m0.nlenet.net [192.168.2.9]) by ns.nlenet.net (Postfix) with ESMTP id 97B72770C Received: from nleaudio.com (nle-m0.nlenet.net [192.168.2.9]) by ns.nlenet.net (Postfix) with ESMTP id 97B72770C for <csc(a)lists.churchsoundcheck.com>; Thu, 25 Oct 2001 22:58:17 -0400 (EDT) Message-ID: <3BD8D39D.CA5D4360(a)nleaudio.com> Date: Thu, 25 Oct 2001 23:08:13 -0400 From: "Bob Puff@NLE" <bob(a)nleaudio.com> X-Mailer: Mozilla 4.08 [en] (Win95; I) MIME-Version: 1.0 To: csc(a)lists.churchsoundcheck.com Subject: Re: [Csc] test message #1 References: <3BD8CD75.DABB8C8C(a)nleaudio.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: csc-admin(a)lists.churchsoundcheck.com Errors-To: csc-admin(a)lists.churchsoundcheck.com X-BeenThere: csc(a)lists.churchsoundcheck.com X-Mailman-Version: 2.1a3 Precedence: bulk ...etc, etc, etc.. Note that the proper order should be: ns.nlenet.net -> main.nlenet.net. Once. Bob

2 1

MIME-encoding headers/body for Mailman-generated mails
by Ben Gertzfield 26 Oct '01

26 Oct '01

To finish up the Japanese support for Mailman, I'm going to dive in and start by adding support for MIME-encoding and decoding (either quoted-printable or base64, whichever is appropriate) header lines. Right now, no matter what language is enabled, the localized emails sent out through the virgin queue are sent verbatim. We need to: 1) Encode the message (headers and body) with the encoding that locale uses for email. Needed for EUC-JP to iso-2022-jp. Can be used for Big5 and CN to iso-2022-cn (see http://www.imc.org/rfc1922) but I don't know if any Chinese mail readers actually support iso-2022-cn. 2) MIME-encode the Subject field, specifying the character set appropriate for the list's locale. Use quoted-printable for ASCII-like charsets, base64 for non-ASCII-like charsets. 3) Set the charset in the Content-Type: of the mail, again appropriate for the list's locale. 4) (sometimes) MIME-encode the body with base64, for 8-bit character sets. In a perfect world, all email would be 7-bit, but going by the Taiwanese spam I receive, people don't seem to send Chinese mail in iso-2022-cn. Instead, the common thing to do seems to be sending 8-bit Big5 mail that's base64 encoded (or not! I get 8-bit email directly in Big5 from time to time in my spam folder.) I looked at the email and mimify modules, and neither of them expose a proper interface for MIME-encoding headers. Well, mimify *tries*, really it does, but it forces quoted-printable, which makes no sense for Asian languages, and does line-wrapping incorrectly, a HUGELY important issue with double-byte encodings that will become corrupt if they're line-wrapped in between two bytes of a double-byte character. I think the proper place for this is in the email module, but I don't want to re-invent the wheel. (Though I do understand the issue very well, and have written up code to do this by-hand before, including supporting double-byte charsets properly). Can we get the code from somewhere else, or should I write up encode_header and decode_header methods for the email.Message class? Next, we need to come up with a table mapping languages to the encodings they use for email. Right now, these are the encodings used for our supported languages (from Defaults.py): def add_language(code, description, charset): LC_DESCRIPTIONS[code] = (description, charset) add_language('big5', _('Traditional Chinese'), 'big5') add_language('de', _('German'), 'iso-8859-1') add_language('en', _('English (USA)'), 'us-ascii') add_language('es', _('Spanish (Spain)'), 'iso-8859-1') add_language('fr', _('French'), 'iso-8859-1') add_language('gb', _('Simplified Chinese'), 'gb2312') add_language('hu', _('Hungarian'), 'iso-8859-1') add_language('it', _('Italian'), 'iso-8859-1') add_language('ja', _('Japanese'), 'euc-jp') add_language('no', _('Norwegian'), 'iso-8859-1') add_language('ru', _('Russian'), 'koi8-r') We need another mapping, from 'code' to 'email charset conversion', 'header mime method', and 'body mime method'. (The last one may not be necessary, if we are converting to a 7-bit encoding.) This is what I understand is actually supported by email clients people around the world use, but I could be very wrong. email_charsets = { # code mail conv header enc body enc 'big5': [None, 'base64', 'base64'], 'de': [None, 'qp', 'qp'], 'en': [None, None, None], 'es': [None, 'qp', 'qp'], 'fr': [None, 'qp', 'qp'], 'gb': [None, 'base64', 'base64'], # just a guess! use iso-2022-cn? 'hu': [None, 'qp', 'qp'], # I thought Hungarian was iso-8859-2? 'it': [None, 'qp', 'qp'], 'ja': ['iso-2022-jp', 'base64', None], 'no': [None, 'qp', 'qp'], 'ru': [None, 'base64', None], # I assume koi8-r is 7-bit.. } I was surprised to see that we specify iso-8859-1 for Hungarian; I'm pretty sure sure it uses accented vowels that are only in iso-8859-2. Also, I don't know if people actually use iso-2022-cn in the Real World. The RFCs suggest to use it, but I get the feeling it's not actually supported by Chinese email clients. Anyone know? If we can use it, then we should for both big5 and gb. In any case, there's a wonderful Python 2.0 codec module which I'm testing now, that makes it possible to convert to/from Japanese. I am VERY unhappy with the historically used kconv.py module, which has thrown tracebacks at me whenever it sees encodings it doesn't understand. It should be good for our purposes; we could just ship it in 'misc' for folks who need Japanese. http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/ Ben -- Brought to you by the letters R and Y and the number 9. "Hoosh is a kind of soup." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/

2 2