Mailman 3 February 2000 - Mailman-Developers

Validating passwords
by Gerrit Holl Feb. 10, 2000

Feb. 10, 2000

Hello, I have an idea for a feature: The password the user supplies may not be too similar to the email adres. A minimal check could be (pseudo-code): if string.find(string.lower(email_adres), string.lower(password)): raise InvalidPassword("adress may not contain password") this could be an option set by the list owner. What do you think? regards, Gerrit. -- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth

1 0

Re: [Mailman-Developers] When will mailman 1.2 be released?
by J C Lawrence Feb. 9, 2000

Feb. 9, 2000

> I mean, is Mailman likely to be released every month like many > other projects, or far less often, like Python? The last version > was released in November last year, so it's not really "Release > early, release often". Hardly -- as all the sources are publicly available via CVS, every change is "released". In that context the "release process" really is just a labelling game, and nothing to really do with the function or development of the product itself. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

When will mailman 1.2 be released?
by Gerrit Holl Feb. 9, 2000

Feb. 9, 2000

Hello, when do you think mailman 1.2 will be released? How stable is the current CVS tree, and how heavily is it tested? In what order of magnitude is the release frequency? regards, Gerrit. -- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth

3 3

Bug#57597: mailman: Different gate_news problems this time. (fwd)
by Gergely Madarasz Feb. 9, 2000

Feb. 9, 2000

And a locking problem... is this serious ? ---------- Forwarded message ---------- Date: Wed, 09 Feb 2000 03:57:40 +0000 (UTC) From: Lazarus Long <lazarus(a)overdue.dhis.net> To: submit(a)bugs.debian.org Subject: Bug#57597: mailman: Different gate_news problems this time. Resent-Date: Wed, 09 Feb 2000 04:03:05 +0000 (GMT) Resent-From: Lazarus Long <lazarus(a)overdue.dhis.net> Resent-To: debian-bugs-dist(a)lists.debian.org Resent-cc: Gergely Madarasz <gorgo(a)sztaki.hu> Package: mailman Version: 1.1-2 Severity: important Subject: Cron <list@phoenix> [ -x /usr/bin/python -a -f /usr/lib/mailman/cron/gate_news ] && /usr/bin/python /usr/lib/mailman/cron/gate_news X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/var/list> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=list> Date: Wed, 9 Feb 2000 03:50:15 +0000 (UTC) Exception Mailman.LockFile.NotLockedError: <Mailman.LockFile.NotLockedError instance at 812bb50> in <method LockFile.__del__ of LockFile instance at 8135e88> ignored

2 1

Re: [Mailman-Developers] unsubscriptions requiring approval
by Harald Meland Feb. 9, 2000

Feb. 9, 2000

[Thomas Wouters] > Another minor patch adding what I need to mailman ;) I also noticed > this on the jitterbug list, so I guess more people had wished or at > least wondered for it ;P Yup, that's correct. > I'm posting it mostly to see if it generates comments, and for me to > find a good excuse to sleep. :-) I've had a go at integrating your patch into my locally hacked Mailman (BTW, could anyone provide me with a clue as to how I can tell patch(1) to understand a multiple-directory CVS diff?) -- and noticed that you seemingly have forgotten to add a DEFAULT_UNSUBSCRIBE_POLICY to Defaults.py.in, and that the comments in some places bore clear signs of a bit hasty cut-and-paste work :) > is there a good word for 'unsubscription request' ? I'm probably not the best person to answer questions on English wording, but to me "unsubscription request" is OK. However, saying Your authorization is required for a mailing list unsubscription request approval: (quickly, three times in a row :) is quite a mouthful, so one might consider rephrasing that sentence somewhat ;) > Adding this has been mostly an exercise to learn a bit about the Mailman > insides, and to see how easily it can be done; fairly easily ;) Comments are > welcome, including "d'oh, dont write that, i already wrote it !" My immediate comment would be: How fast can we get this guy to sign the appropriate papers? :-D I'll try to get your stuff tested a bit here, too, and hopefully we can get around to committing it later. Thanks, -- Harald

2 1

new feature request for anon lists
by Roberto Ullfig Feb. 9, 2000

Feb. 9, 2000

Here are the relevant lines from MailList.py # if self.anonymous_list: # del msg['reply-to'] # del msg['sender'] # msg.SetHeader('From', self.GetAdminEmail()) # msg.SetHeader('Reply-to', self.GetListEmail()) if self.anonymous_list: del msg['sender'] msg.SetHeader('From', self.GetAdminEmail()) if self.reply_goes_to_list: del msg['reply-to'] msg.SetHeader('Reply-to', self.GetListEmail()) What I've done is use the reply_goes_to_list flag to control whether or not the Reply-To is munged instead of munging indiscriminately. It make a lot of sense to me that this is how it should work. Anyone see any problems with this? -- Roberto Ullfig : rullfig(a)uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago

1 0

Re: [Mailman-Developers] Reply goes to list error
by Harald Meland Feb. 9, 2000

Feb. 9, 2000

[Barry A. Warsaw] > >>>>> "HM" == Harald Meland <Harald.Meland(a)usit.uio.no> writes: > > HM> Ooops, sorry -- my version did, but I hadn't checked that in. > HM> Checked in now. > > Actually, there's a bug in your version. When using the setitem > interface (e.g. msg['reply-to'] = '...'), you don't want to set the > value to include the key or the newline. I'm about to check in a fix. That's what I get for changing from the msg.headers.append() to the msg[header] style of doing these things just prior to checking it all in (because I realized I found the latter style to be "cleaner" in this context). I guess I'm now cured for the check-in-untested-code disease for a few more months... Sorry, -- Harald

1 0

Archiver.py bug ?
by Thomas Wouters Feb. 9, 2000

Feb. 9, 2000

I ran across this in my errors log: Traceback (innermost last): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 212, in ArchiveMail self.__archive_to_mbox(msg) File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 168, in __archive_to_mbox post.SetHeader('Date', time.ctime(time.time())) post is a Mailman.Message.Message instance, which is a subclass of rfc822.Message... But neither of those objects define a SetHeader method, and the two calls to SetHeader in Archiver.py are the only calls in Mailman to that particular method. An old leftover, perhaps ? The attached patch should fix it. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

I18N concerns for Japanese
by Brian Takashi Hooper Feb. 9, 2000

Feb. 9, 2000

Hi there - I just checked out the latest version of Mailman from CVS and am taking a look at it with an eye to making it work better with our environment here, which is Japanese. I think that Mailman would be very popular in Japan too with a localized interface and a few tweaks to ensure that mail goes out in the proper format. I haven't been on Mailman-dev for a long time yet, so forgive me if I'm rehashing an old topic (I checked through the archives as best I could, so I apologize in advance for redundancy): 1. Headers: To, Subject: The To: and Subject: lines in Japanese messages often contain Japanese; the proper encoding for this seems to be base-64 encoded ISO-2022 (JIS). Mail received from list members is of course no problem, but mail which the system sends out, if it contains Japanese, needs to be able to do this conversion. Looking at an example implementation (Mew, an emacs module which does Japanese mail), it looks like only those parts of the header which contain JIS escape sequences are encoded, that is, ASCII parts of the To: and Subject: lines are not encoded. I think this makes sense, since encoding the entirety of To: would obscure the recipient address, which might not be good for some mailers. I assume there are other standards out there for various languages to insert non-ascii characters in the To: and Subject: lines, probably which do similar tricks; are there any folks out there who have similar requirements or experiences? I think that my difficulty would be solved if it was possible to specify a filter which should be applied to outgoing message headers; this could by default be None, or a filter which just returns its string argument unchanged. This also should be linked to the specification of charset for the message. Content-type, Mime-Version: Typically, Japanese mail sets the Content-type and Mime headers like so: Content-type: text/plain; charset=ISO-2022-JP Mime-Version: 1.0 Looking at the Mailman source, it looked like charset=us-ascii is hardcoded for a few types of messages (ToDigest, bounce); as far as I can tell it's not set for outgoing admin messages (someone please catch me if I'm wrong on this). The message body of Japanese messages normally sent in ISO-2022 without bin-hex translation, but I don't think this has any implications vis-a-vis Mailman's current behavior. So, I guess what I'm suggesting is adding the ability to add custom filters to do special header processing based on locale... Opinions, additions, flames anyone? 2. Templates We have already done some localization of templates here, and will continue to do so until we've finished... in this case, maybe it would be nice to offer downloads of drop-in-replacement template folders for different languages somewhere. I volunteer our templates when they are done. Obviously there are other inline text messages which also require some mechanism for localization; maybe gettext? Are there any other localization issues which people have come across for other locales? --Brian Hooper Tokyo, Japan

1 0

Re: [Mailman-Developers] Reply goes to list error
by Harald Meland Feb. 8, 2000

Feb. 8, 2000

[Balazs Nagy] > On 7 Feb 2000, Harald Meland wrote: > > > > On Tue, 18 Jan 2000, Balazs Nagy wrote: > > > > > > I just cannot understand why nobody from thosw who have write access > > > did anything about the subject. > > > > Because Reply-To: munging is already part of CookHeaders.py, I guess. > > And that takes appropriate note of the "fastrack" attribute of the > > message object, too. > > CookHeaders doesn't do anything about the subject. Ooops, sorry -- my version did, but I hadn't checked that in. Checked in now. -- Harald

2 1