[Mailman-Developers] unsubscribe
On Tue, 1 Jan 2002, Barry A. Warsaw wrote:
> Date: Tue, 01 Jan 2002 22:48:51 -0500
> From: "Barry A. Warsaw" <[EMAIL PROTECTED]>
> To: Dan Mick <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Mailman-Developers] New Bounce system
>
>
> > "DM" == Dan Mick <[EMAIL PROTECTED]> writes:
>
> >> so I need more information. Exactly how did you do the
> >> upgrade?
>
> DM> The standard way; config (as me) and "make install" (as root).
>
> Did you install over an existing Mailman 2.0.x installation, or did
> you do a fresh MM2.1 install and copy list directories over?
>
> >> Which version of Python are you using?
>
> DM> 2.1.1
>
> Cool.
>
> >> Do you see any errors in logs/error that might be relevant?
>
> DM> Nothing easily findable, no.
>
> Okay.
>
> >> Try using bin/dumpdb on both the (old) config.db value and the
> >> (new) config.pck value and check attributes like
> >> `data_version', and `delivery_status'.
>
> DM> Where do I find the old and new files?...the new ones are
> DM> obviously there, but the old ones aren't saved by upgrade, are
> DM> they?...it'd be nice if they were somewhere I'm missing,
> DM> because then I could manually fix the problem. (No, I don't
> DM> have backups.)
>
> All the files should be in lists//config.{db,pck}{,.last}
>
> The upgrade procedure doesn't get rid of the .db files.
>
> DM> A small string under the "nomail" box, if checked, would do
> DM> it; I'm not sure it would add a lot to the size (but might;
> DM> haven't futzed with the layout). Given that we're already two
> DM> vertical spaces because of the "realname" box, it might fit
> DM> without changing the size.
>
> I'll check out your patch momentarily. Thanks!
> -Barry
>
> ___
> Mailman-Developers mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/mailman-developers
>
Kathy Baron
Computing Services
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
>Another wish... probation. I had a system with Majordomo, daily >cron rotation of subscriber files, that I liked, hackish as it >was. New subscribers were unable to send mail to a particular large >and active list for a period of time (five days in my case) after >subscribing. This was to force new subscribers to read the list traffic >and figure out, as much as they could in five days, list culture and >what is acceptable. That list has lots of "juvenile" subscribers, >and the probation period is (was) useful to temper their behavior. A probation period would be a nice spam-deterrent also; I'm pretty sure we've had at least one person subscribe first, then send advertising immediately, to one of our lists. Jerry -- [EMAIL PROTECTED] http://www.sandiego.edu/~jerry/ Serra 188B/x8773 -- 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 ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] Yet another wish?
I must apologize in advance, since I haven't been paying that close attention to recent developments here, and this may already be included. I'd like it to be easy to set up mailman to run with greatly reduced functionality (to run a single announcement (not discussion) list for a site), which shouldn't take any modification, except that I'd like to be able to turn off the password requirements for it--I want people to be able to subscribe/unsubscribe just by sticking their email address in a field and hitting a button. Other fanciness (digest/ack/etc.) should also be hidden, as this is really meant to be a bare-bones way to use mailman. I've hacked earlier mailman installs to remove some of the security, but not in a clean enough way to submit as a patch. -Dale ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Marc Perkel's Feature Wish List
>> I've got a patch to do that against 2.0.8 which works for new >> lists. If someone could tell me what the right way is to add >> an entry into an existing database I'd have a complete patch. > "DM" == Dan Mick <[EMAIL PROTECTED]> writes: DM> I think Mailman/versions.py::NewVars() is the one that does DM> all that sort of stuff. It's invoked when the version change DM> is detected in MailList.py::CheckVersion(), though, and that DM> version number is owned by Barry/the official distro. DM> I think it's probably difficult to do in a patch so that it DM> doesn't interfere with future releases. True. Each list has an integer attribute called `data_version' and this is compared against Mailman/Versions.py::DATA_FILE_VERSION. If the latter is greater, then we run the schema updates in versions.py, which currently is a morass of every change in schema or data format since the early early 1.0 days. It's getting very close to unmaintainable. As Dan rightly points out though, I increment DATA_FILE_VERSION whenever I add or change a MailList attribute, so for you to increment it in your patch means eventually we'll conflict and some lists may not update. But I don't think you'll need to do that. Remember that you can always add an arbitrary attribute to a MailList object, e.g. with bin/withlist and as long as the attribute name doesn't collide with some existing attr name, and as long as it doesn't start with an underscore, Mailman's persistence mechanism will happily save and load that attribute as if it were one of its own. So my suggestion would be to include a bin/withlist script that adds the attribute you need and then saves the list. Don't muck around with versions.py and Version.py. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
> "LW" == Lawrence Weeks <[EMAIL PROTECTED]> writes: LW> Another wish... probation. I had a system with Majordomo, LW> daily cron rotation of subscriber files, that I liked, hackish LW> as it was. New subscribers were unable to send mail to a LW> particular large and active list for a period of time (five LW> days in my case) after subscribing. This was to force new LW> subscribers to read the list traffic and figure out, as much LW> as they could in five days, list culture and what is LW> acceptable. That list has lots of "juvenile" subscribers, and LW> the probation period is (was) useful to temper their behavior. Although it isn't time-based, MM2.1 will let you set a default `moderate' flag on a per-user basis. As long as that flag is set, member postings will be held for moderator approval. At the same time a moderator approves of a member's held posting, s/he can clear the moderate bit, thus taking the member off probation. (This latter feature is only in cvs). I think a time-based auto-de-probation feature will have to wait until after MM2.1. LW> And how about the oft-requested rotating footers? I looked in LW> an alpha release of 2.1 and didn't see it in Decorate.py. LW> I'd like this functionality, so I'll make these changes myself LW> if necessary. I'll happily contribute patches, but I'm not an LW> experienced Python coder nor am I too familiar with the MM LW> structure, so it'll likely be an ugly hack. :-) I'm not quite sure what "rotating footers" mean... -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Marc Perkel's Feature Wish List
Neat! Note that in MM2.1 Mailman/Bouncer.py has a method BounceMessage() that performs all the basic logic for bouncing (rejecting) a message. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] my top 3 wishlist for mailman cvs
> "MM" == Marc MERLIN <[EMAIL PROTECTED]> writes: MM> First, of all, I'd like to say that I really like many of the MM> changes in improvements in mailman cvs, some of them will same MM> me a lot of time with not having to deal with confused users MM> anymore :-) Yay! MM> I however, have 3 items left on my wishlist :-) MM> #1 Very big feature request: MM> The main list admin's cookie should be valid for all the MM> lists. Having to retype the list password over and over again MM> as I hop from list to list is very tiring. Would the site admin password suffice or are you really looking for a different password. The site list's password could serve this role, but I sofrt of see it as a hack. Note that until now I've avoided cookie-fying the site password token when authenticating using the site password, but that's mainly based on some vague fear that if there's a hole in Mailman's security mechanism, accepting a site password cookie token would leave the whole list vulnerable. I'm not aware of such an exploit of course. If this is really something you want, I think you could add it pretty easily to SecurityManager.py. MM> #2 Is there any way to have mailman still understand admin MM> password in crypt/md5 format? It could read them and only MM> generate the new kind. Resetting 16,000+ list admin passwords MM> on sourceforge.net is going to be a major showstopper (I know, MM> you can regenerate all of them and Email them automatically, MM> but still...) Have you tested this? I think this is already in there. MM2.1 should, failing the sha comparison, do an md5 and then a crypt compare. If any of them hit, it re-stores the list admin password using the sha hash (it /knows/ the cleartext password because it was sent over the wire in the form data, so it knows what to sha hash and re-store). I anticipated your pain (benefits of joyriding in Guido's time machine), so if this doesn't work, it's a bug. MM> #3 I'd really like to see a nomail field and a disabled field MM> (one settable by the user, one set by mailman when it disables MM> a member) Hmm, can you describe a use case for why you'd want to split these, presumably in the membership summary page? Did you see the idea in cvs based on Dan's suggestion (that an abbreviation of the reason is shown next to the nomail checkbox). -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Marc Perkel's Feature Wish List
>> The bounce message should be able to be customized giving the >> user information to join the list - or just go to hell. JCL> 2.1 is much better in this regard, but I'll have to see JCL> if it went that far. It doesn't. Anybody want to contribute some code? -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Marc Perkel's Feature Wish List
> "MP" == Marc Perkel <[EMAIL PROTECTED]> writes: MP> I have set up the system and I've been running it for a few MP> weeks and I really like it. But there's a few little missing MP> features - many of which should be easy to add, that I hope MP> you developers will consider. I'm the systems admin for the MP> Electronic Frontier Foundation. Ah, an excellent organization! MP> I'd like to be able to enter (and/or allow the user to enter) MP> other email addresses that if they sens email from the other MP> address they have the same membership privileges as the MP> original member email address. Thus if [EMAIL PROTECTED] is in the MP> list but the email comes from [EMAIL PROTECTED] then it is treated MP> the same. Ideally - the user could make these aliases and it MP> would apply to all lists the user is a member of. This will be added after MM2.1 when I consolidate the user database. For now, I've added a FAQ entry describing the workaround: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.001.htp MP> Right now the url http://domain.com/mailman/admin goes to a MP> page that just shows public lists. I'd like to see a link MP> there that goes to a master admin page - where you first have MP> to enter the master password - and then you get several master MP> admin options - including: An excellent idea. The way to do this is to have a `site' cgi script which provides the functionality. I think it's too late to add this to MM2.1, unless someone contributes the code. I'm offline right now, but I would suggest you add these ideas to the Mailman wiki: http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage perhaps to the MM3 notes section? Or better yet, add them to the Feature Request tracker on the SourceForge project. MP> 2) Menu to create a new list - avoiding the need to go to the MP>command MP> line. Please note that MM2.1 will let you create new lists thru-the-web. The link is on the admin overview page. MP> Mailman allows a list of people (nonmembers) who are allowed MP> to post to the list. The list normally contains additional MP> email addresses. I would like to see the ability to refer to MP> the entire membership of other lists for membership/or posting MP> privileges. For example "@otherlistname" could mean to include MP> all the members of another list as being allowed to post to MP> this list. Thus you could create an umbrella list - containing MP> 3 other lists - and make the list postable by the members of MP> any of the three lists (and thier personal aliases) and no one MP> else. MP> Additionally - I'd like to enter a flat file reference MP> "/usr/lists/viplist" to include as people who can also MP> post. So if I have 50 lists and we get a new board member - I MP> don't have to add them as a privileged person to 50 lists. You will be able to do both these things in MM2.1, but you'll have to hack a little Python. MM2.1 has an extension mechanism which would let you a small Python module to get this behavior. I agree that both are worthwhile and I'd like to see a more integrated approach for a future version. MP> If I set my password - that should be my password for all MP> lists. This also applies to my real name - for whenever you MP> add that - and other info about me as a user that I chose to MP> set - such as my email aliases - my home page - my favorite MP> links - or whatever. Maybe the ability to have a checkbox on MP> some "per list" setting that allow me to apply the changes to MP> all lists. This checkbox exists in MM2.1. You can change your RealName, email address, or password globally, i.e. on all lists in that (virtual) domain. It's a bit of a hack internally, but a more principled approach will be added when the consolidated user database is implemented. MP> Some people play by the rules - some don't. It would be nice MP> to have global blacklist and global whitelist features to MP> control spammers and those who otherwise misbehave. See Mailman/Handlers/SpamDetect.py for the current approach. Requires shell access to the Mailman installation. MP> I'd like a setting so that if non-members post to the list MP> that their messages are automatically dropped (bounced) MP> without list owner intervention. The bounce message should be MP> able to be customized giving the user information to join the MP> list - or just go to hell. Hmm, except for the customizable bounce information, this exists in MM2.1. You can also auto-discard certain addresses, and do address matching on explicit address or regular expression. MP> Anyhow --- many of these features could be easilly added - MP> many might take some serious work - but - I thought I'd add MP> this to the wanted list in case no one else thought of these MP> thin
Re: [Mailman-Developers] Couple more small bugs in current CVS
> "DM" == Dan Mick <[EMAIL PROTECTED]> writes: DM> Mailed these to Barry too, but again, just in case anyone else DM> is running into them before Barry gets to them: These are (or will be when I travel in my time machine and get back online) fixed in CVS. Thanks! -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
On Thu, 3 Jan 2002 14:17:40 -0500 Barry A Warsaw <[EMAIL PROTECTED]> wrote: > I think a time-based auto-de-probation feature will have to wait > until after MM2.1. At which time both based, # of posts based rule support would be useful, along with the ability to take an existent member and apply an individual rule set to them (moderate for next N time/posts). > I'm not quite sure what "rotating footers" mean... The ability to have the list sig (as appended to posts) be rotated thru a range of possible values. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
Once upon a time (Thu Jan 03), J C Lawrence wrote: > On Thu, 3 Jan 2002 14:17:40 -0500 Barry A Warsaw <[EMAIL PROTECTED]> wrote: >> I think a time-based auto-de-probation feature will have to wait >> until after MM2.1. > At which time both based, # of posts based rule support would be > useful, along with the ability to take an existent member and apply > an individual rule set to them (moderate for next N time/posts). Yes, both/either option per-user would be useful. >> I'm not quite sure what "rotating footers" mean... > The ability to have the list sig (as appended to posts) be rotated > thru a range of possible values. Yes... I have a Perl script that did that for me when I used Majordomo. It was in the MTA aliases processing, inserted as a filter just before the message was sent out to subscribers. Majordomo used separate aliases for archiving and for delivering to reflective and digest subscribers, so that worked well. That script can no longer be used because all of those processing streams are internal to Mailman, and the filter would wind up putting those sigs into the digests and the archives. I was considering a hack in Decorate.py which would just call that Perl script, or rather, a script specified in the footer configuration variable, and use the result as the sig. That would make it work again, but something more 'elegant' would nice. Larry -- Lawrence Weeks "Audaces fortuna juvat." [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
Once upon a time (Thu Jan 03), Jerry Stratton wrote: > A probation period would be a nice spam-deterrent also; I'm > pretty sure we've had at least one person subscribe first, then > send advertising immediately, to one of our lists. Indeed, that was also a motivation for implementing the probation period, we also had a spammer or two do that in years past. Larry -- Lawrence Weeks "Audaces fortuna juvat." [EMAIL PROTECTED] ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] simple feature
Will 2.1 have the ability to just completey *drop* posts matching a pattern, instead of holding them for moderation? I've got a couple of lists where Re: posts (replies back to the list) arent allowed; only initial problem messages and then a summary/solution posting. It would be nice if I could have Mailman just *drop* the Re: posts instead of holding them for moderation; I'd like to avoid having to use Procmail for this... Bill -- Bill Bradford [EMAIL PROTECTED] Austin, TX ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] One more wish
> "LW" == Lawrence Weeks <[EMAIL PROTECTED]> writes: >> The ability to have the list sig (as appended to posts) be >> rotated thru a range of possible values. LW> Yes... I have a Perl script that did that for me when I used LW> Majordomo. It was in the MTA aliases processing, inserted as a LW> filter just before the message was sent out to LW> subscribers. Majordomo used separate aliases for archiving and LW> for delivering to reflective and digest subscribers, so that LW> worked well. That script can no longer be used because all of LW> those processing streams are internal to Mailman, and the LW> filter would wind up putting those sigs into the digests and LW> the archives. LW> I was considering a hack in Decorate.py which would just call LW> that Perl script, or rather, a script specified in the footer LW> configuration variable, and use the result as the sig. That LW> would make it work again, but something more 'elegant' would LW> nice. Don't hack Decorate.py. Instead create a new pipeline module, called something like FooterRoulette.py and stick that in the GLOBAL_PIPELINE anywhere between ToUsenet.py and ToOutgoing.py. Then turn off standard footers for the lists you want to rotate, and add whatever logic you want in FooterRoulette.py to get the footer templates, sticking whatever you want in them. Could all be done with not a lot of lines of Python, and it ought to integrate well with the current architecture. The hard part would be integrating that with thru-the-web customization, but I'd punt on that to start out with. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] simple feature
> "BB" == Bill Bradford <[EMAIL PROTECTED]> writes: BB> Will 2.1 have the ability to just completey *drop* posts BB> matching a pattern, instead of holding them for moderation? BB> I've got a couple of lists where Re: posts (replies back to BB> the list) arent allowed; only initial problem messages and BB> then a summary/solution posting. General matching against headers with auto-discards probably will not be supported out of the box in MM2.1. BB> It would be nice if I could have Mailman just *drop* the Re: BB> posts instead of holding them for moderation; I'd like to BB> avoid having to use Procmail for this... No need to use Procmail to add this feature though! Simply add a pipeline module that checks the listname, and for those lists that you want to discard Re: messages, simply search Subject: headers for Re:. Here's some untested code that might get you close. Note that you'll have to add this module to the GLOBAL_PIPELINE, probably just before Hold.py. -Barry --- snip snip Mailman/Handlers/DiscardRe.py import re from Mailman.Errors import DiscardMessage # If a list is not mentioned here, we don't even search its Subject: LISTNAMES = [ 'norelist1', 'norelist2', # ... ] # Compiled regular expression that searches for a literal string "Re:" # matching case insensitively. cre = re.compile(r're:', re.IGNORECASE) def process(mlist, msg, msgdata): if mlist.internal_name() not in LISTNAMES: return subject = msg['subject'] if subject and cre.search(subject): raise DiscardMessage snip snip ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] my top 3 wishlist for mailman cvs
On Thu, Jan 03, 2002 at 02:14:11PM -0500, Barry A. Warsaw wrote: > MM> The main list admin's cookie should be valid for all the > MM> lists. Having to retype the list password over and over again > MM> as I hop from list to list is very tiring. > > Would the site admin password suffice or are you really looking for > a different password. The site list's password could serve this role, > but I sofrt of see it as a hack. Sorry if i wasn't clear. Yes, the site admin password entered once and working on all the lists would be great. Now, if I admin 10 lists with the same list password, and that works too, even better, but I don't need this as bad. > Note that until now I've avoided cookie-fying the site password > token when authenticating using the site password, but that's mainly > based on some vague fear that if there's a hole in Mailman's security > mechanism, accepting a site password cookie token would leave the > whole list vulnerable. I'm not aware of such an exploit of course. > > If this is really something you want, I think you could add it pretty > easily to SecurityManager.py. I'll have to look. > MM> #2 Is there any way to have mailman still understand admin > MM> password in crypt/md5 format? It could read them and only > MM> generate the new kind. Resetting 16,000+ list admin passwords > MM> on sourceforge.net is going to be a major showstopper (I know, > MM> you can regenerate all of them and Email them automatically, > MM> but still...) > > Have you tested this? I think this is already in there. MM2.1 No, I just took your docs for granted (they say you need to regen everything after the upgrade). If it works, great :-) > I anticipated your pain (benefits of joyriding in Guido's time > machine), so if this doesn't work, it's a bug. Cool. > MM> #3 I'd really like to see a nomail field and a disabled field > MM> (one settable by the user, one set by mailman when it disables > MM> a member) > > Hmm, can you describe a use case for why you'd want to split these, > presumably in the membership summary page? Did you see the idea in > cvs based on Dan's suggestion (that an abbreviation of the reason is > shown next to the nomail checkbox). I saw the changelog in 2.1a4 and it looked like what I was looking for, but I wasn't able to see the reason why a user was disabled in admin/listname/members/list The idea is to be able to script remove or re-add everyone who disabled themselves (only) or who got disabled due to bounces (only). It seems that you've implemented this now, I'm just not sure where the info is yet. Marc -- Microsoft is to operating systems & security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger [EMAIL PROTECTED] for PGP key ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
