Mailman 3 April 2000 - Mailman-Developers

Re: feature reminder: no unsubscribe (Christopher Kolar)
by Ken Manheimer 21 Apr '00

21 Apr '00

On Fri, 21 Apr 2000 Christopher Kolar <ckolar(a)admin.aurora.edu> wrote: > I am setting up some more course mail lists and I remembered to check on > our testbed box for a feature that a bunch of people requested in the past: > that a mail list have a setting that subscribers cannot remove themselves > without admin approval. This was sought for situations (like a class) > where you don't want people to be able to opt out. > > I did not find this in 2b1, is it implemented? Maybe just as something to > drop into the config file instead of through the web? If not, is there a > chance that it can get into the 2.0 code? Thanks much. My apologies if this has already been hashed out to everyone's satisfaction, but i would be nervous about how this particular feature would be subject to abuse. I suppose, on the one hand, that spammers and the like could just use something else - bare mailling list aliases, for that matter - to get their captive audiences. On the other hand, i wouldn't want mailman to be the tool of choice for capturing audiences. Might notifications of deenlistment, with the ease of forcing reenlistment, be sufficient? Not adamant, but wary, Ken Manheimer klm(a)digicool.com

2 1

feature reminder: no unsubscribe
by Christopher Kolar 21 Apr '00

21 Apr '00

I am setting up some more course mail lists and I remembered to check on our testbed box for a feature that a bunch of people requested in the past: that a mail list have a setting that subscribers cannot remove themselves without admin approval. This was sought for situations (like a class) where you don't want people to be able to opt out. I did not find this in 2b1, is it implemented? Maybe just as something to drop into the config file instead of through the web? If not, is there a chance that it can get into the 2.0 code? Thanks much. --chris -- /////\\\\\/////\\\\\ Christopher G. Kolar Director, Department of Instructional Technology Aurora University, Aurora, Illinois ckolar(a)admin.aurora.edu -- www.aurora.edu/~ckolar [PGP Public Key ID: 0xC6492C72]

4 4

Re: [Mailman-Developers] Messages in a time warp
by J C Lawrence 20 Apr '00

20 Apr '00

On Thu, 20 Apr 2000 09:46:51 +0100 Nigel Metheringham <Nigel.Metheringham(a)VData.co.uk> wrote: > Should mailman have a check for misdated messages - ie ones where > the date is more than a couple of days off the receive date? > These could then be moderated like other errors. I would like this. -- J C Lawrence Internet: claw(a)kanga.nu ----------(*) Internet: coder(a)kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

1 0

Messages in a time warp
by Nigel Metheringham 20 Apr '00

20 Apr '00

Having been a little fooled by the top and bottom few entries in the mailman-users archives:- http://www.python.org/pipermail/mailman-users/ Should mailman have a check for misdated messages - ie ones where the date is more than a couple of days off the receive date? These could then be moderated like other errors. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Re: [Mailman-Developers] idea
by Dan Mick 19 Apr '00

19 Apr '00

> On Wed, Apr 19, 2000 at 01:45:37PM -0700, Dan Mick wrote: > > > > admindb.py for approved posts : > > > > When a post is held for approval, convert the email-address > > > > of the poster to a hyperlink to the options page for that > > > > user ("/mailman/options/listname/email--at--host.com") > > > Mailman/Cgi/admindb.py line #215 > > > t.AddRow([Bold('From:'), '<A HREF="%s/%s">%s</A>' % (mlist.GetRelativeScriptURL('options'), Utils.ObscureEmail(sender), sender)]) > > > there should be a cleaner way to code this, but for now it makes my daily work with the > > > posts on our moderated list a lot easier... > > What do you use this for? Punitive unsubscription? > > i actually had to look up the word 'punitive' in an English-Dutch dicitionary :) oops, sorry!.. > anyway, no I don't use it for punitive unsubscription... but often people post message > like "please unsubscribe me" or "how come I don't receive any more mail from the list?" > (the latter happens when they had a full mailbox and mailman automatically disabled > their account).... though it's possible to write a message with explanation, in most > cases (especially considering the lack of computer knowledge of most of the > subscribers) this only confuses them more... so I usually want to fix it myself. Oh, okay, that makes perfect sense. (most of my admin tasks are rejecting HTML, attachments, and messages Cc'ed to 1000 AOLers...I get very few sub/unsub requests. Mostly those are email to the listmaster directly.)

1 0

idea
by Ricardo Kustner 19 Apr '00

19 Apr '00

Hi, I was just thinking what could be a usefull feature in admindb.py for approved posts : When a post is held for approval, convert the email-address of the poster to a hyperlink to the options page for that user ("/mailman/options/listname/email--at--host.com") so if you see a message with "please remove me from this list" or "why haven't i been getting any more mail lately?" you can just click on the address and immediately edit the options for that user... ps: i'm still voting for having the message headers seperated from the body on the approval page... i keep having to put back my own hacks after upgrading to a new beta ;) Ricardo. --

2 3

Re: [Mailman-Developers] Change to acceptable_aliases
by Harald Meland 19 Apr '00

19 Apr '00

[Barry Warsaw] > My proposal is to change the semantics of acceptable_aliases, so that > matching is done against the entire recipient address, not just the > localpart. To support backwards compatibility, I'm willing to use the > following rules for 2.0: > > 1) if the regexp does not contain an `@', then match only against the > localpart as before. > > 2) if the regexp contains an `@', match against the entire recip > address. > > 3) deprecate #1 so that a future release will only match against the > entire address. > > Thoughts? As we're talking (possibly incomprehensible) regexps here, I think I would go a little bit further: 1) If the regexp does not contain an '@', first try matching it against the localpart (i.e. the way things work now). 2) If 1) was skipped *or* if it didn't produce a match, try matching against entire recip address (i.e. try this even if the regexp does not contain any '@' signs). 3) Deprecate '@'-less regexps so that a future release will only match against the entire address. Warn the site admin if any '@'-less regexps are found when upgrading to such a (future) version. 4) Possibly provide a small script that iterates through all/specified lists, adding '@.*' to any lines in acceptable_aliases not containing an '@'. Such a change _could_ break some (strange) regexps, and thus should not be done automatically. > Is anybody using acceptable_aliases? Yes, they're used pretty much around here. Due to the nature of our previous mailing list system, all old lists now converted to Mailman have quite a lot of alternative posting addresses; this led to quite a few messages being held because of "implicit destination" right after the conversion. -- Harald

3 2

Fix for bug 170, is it any good?
by David Caldwell 18 Apr '00

18 Apr '00

Hello, Is this the right list to send this to? In ListAdmin.py this line (line 167 in 1.1, line 200 in 2.0beta2): self.LogMsg("vette", note) seems to be causing Mailman trouble. Above that you create 'note' and use strquote to remove percents from variables you catenate to it. But you don't use strquote on everything. In 2.0beta2 you added strquote to the subject line, but the sender still doesn't have it (unless I missed something). Instead of trying to catch all the percents in the strings you catenate, could you just change the line to this: self.LogMsg("vette", '%s', note) and get rid of the whole problem in one fell swoop? It seems more straight forward to me. But then I don't know python that well. I picked up enough to try to fix this problem I'm having where a % in the senders address on a moderated list bombs the list software. My change seems to work, but I'm not sure if there are any ramifications. Take care, David

2 1

probing list names, and subscribers
by britt 15 Apr '00

15 Apr '00

I noticed there were a message or two about the ability to probe for list membership, and list existance, even when privacy features have been turned on. I didn't see anything about this in the To-Do list. Has anyone made any noise about working on this problem? I see it as two fold, one list names can be probed for existance. The same thing for membership simply by guessing names to go after http://host/mailman/admin and http://host/mailman/options/ This defeats the purpose of having private lists, which is an absolute necessity for my system. I think both of these can be easily fixed, and I'm more than willing to do the coding (i needed an excuse to learn yet another language) For lists, if the list doesn't exist, don't give a failure page, but give the password page, and then always fail, giving no clue if the list name or the password is the problem. For users, just ALWAYS produce the user options page, and then do a password fail if they try to submit anything. This can produce more work for the mailman admin, as the legit users are less sure about why an action is not working. Comments? Suggestions? Pointers to python docs ;) thanks, Britt Head Admin, Harvard Computer Society, and majordomo flunkie ----------------------------------------------------------------------- Britt Bolen britt(a)bolen.com britt.bolen.com

1 0

Re: [Mailman-Developers] Change to acceptable_aliases
by Harald Meland 14 Apr '00

14 Apr '00

[Barry A. Warsaw] > Except that I think `@'-less regexps still have useful semantics, so > I don't want to prohibit them. I just want the matching to > (eventually) always be done against the entire recip address, not > just the localpart. Then wouldn't it make more sense to already now try matching the regexp against the entire address, even if the regexp does not contain any '@'? Your change will cause the (not too far-fetched, IMO) regexp .*\.uio\.no$ to _only_ be matched against the localpart (and thus very likely _not_ produce a match) for now, although you're saying that you eventually want it to match against the entire address (and that likely _will_ produce a match). So, I still say: 1) If the regexp does not contain an '@', first try matching it against the localpart (i.e. the way things work now). 2) If 1) was skipped *or* if it didn't produce a match, try matching against entire recip address (i.e. try this even if the regexp does not contain any '@' signs). Or am I misunderstanding something? -- Harald

4 4