Mailman 3 June 1999 - Mailman-Developers

Cookie security hole in admin interface
by John Morton 14 Jun '99

14 Jun '99

[Didn't see this problem discussed in the recent archive messages, so...] I was looking at the code for the admin cgi in search of a good cookie authentication system, and found out that it was doing this, c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name + "-admin"): if c[list_name + "-admin"].value == `hash(list_name)`: return 1 ...to authenticate based on a cookie. This code is from 1.0b8, but it only took a couple of minutes to set the appropriate wafer in my junkbuster configuration, and point netscape at the admin page for mailman-developers. I'll leave the replication of this exploit as an exercise for the readers. Possible solutions: Lock down that url with whatever security features your web server has. This sucks as a long term solution, but it should protect from disgruntled script kiddies that you just chucked off your lists. Make the value based on a hash of some slow changing system variable. Something that changes with the frequency of your desired expire time, for example. Maybe a cron job to set a key based on some fast changing system stats every hour or so. Use SSL for the admin interface and save the name and password in the cookie. Any better suggestions? John.

3 4

Envelope from, sender, from, etc.
by Per Starback 14 Jun '99

14 Jun '99

In 1.0rc1 USE_ENVELOPE_SENDER = 0 by default, but still it didn't work for me. After investigating it turned out that the documentation misled me. I think the documentation or the function should be changed, preferrably the latter. According to the section in NEWS where USE_ENVELOPE_SENDER is added: # With this variable set to true, the envelope sender (e.g. Unix # "From_" header) is used to match addresses, otherwise the From: # header is used. The FAQ also speaks about the difference being between using envelope from and From:. The comments in Defaults.py indicate that this is perhaps not the whole truth as they say # The envelope sender is set by the SMTP delivery and is thus less easily # spoofed than the sender, which is typically just taken from the From: header "Typically" is the key word here. The actual code uses GetSender which prefers to use Sender: but uses From: if there is no Sender:. So my messages which said From: starback(a)ling.uu.se Sender: starback(a)objekt.ling.uu.se where rejected when only "starback(a)ling.uu.se" was a subscriber. Am I missing something here? It seems to me that the point of USE_ENVELOPE_SENDER=0 is that we are willing to accept the lesser security we get when we just accept who the sender says they are and don't insist that the "technical stuff" (envelope from) has to match. Why then refuse because of a Sender: header that probably echoes what was in envelope from? -- Per Starback <starback(a)ling.uu.se> <http://stp.ling.uu.se/~starback/me.html> "Life is but a gamble! Let flipism chart your ramble!"

2 1

Re: Mailman feature request
by Harald Meland 13 Jun '99

13 Jun '99

I'm Cc:ing mailman-developers, as either that or the Jitterbug database is where feature requests belong. [Dave Cinege] > I'd like an unsubscribe (or mass unsubscribe) field added to the > memebership management section. The pages with check boxes are cute > and everything, but cut&paste is much faster. I tend to agree -- and would additionally like to have a "Unsubscribe all" button (with some added safety pins to avoid blasting away your entire list by mistake). > Also I'd like to see a nice big 'unsubscribe' title at the bottom of > the list info page. I've already had 5 mentally challenged people > mail me that I had to point that out. Here's a patch that makes > things more obvious: I guess that the listinfo page could mention how to unsubscribe in larger writing -- but I don't want to scare users from changing their (other) subscription options, either. I think I'll have to ponder on how this best could be done a little while. > --- listinfo.html.orig Sun Jun 13 11:42:01 1999 > +++ listinfo.html Sun Jun 13 11:48:33 1999 > @@ -103,18 +103,18 @@ > <TR> > <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> > <a name="subscribers"> > - <MM-List-Name> Subscribers</a> > + <MM-List-Name> Subscribers (Unsubscribe)</a> > </TD> > </TR> > <tr> > <TD COLSPAN="2" WIDTH="100%"> > + <MM-Subscribe-Form-Start> > + <MM-Editing-Options> > + <MM-Form-End> > + > <MM-Roster-Form-Start> > <MM-Roster-Option> > <MM-Form-End> > - > - <MM-Subscribe-Form-Start> > - <MM-Editing-Options> > - <MM-Form-End> > </td> > </tr> > </table> -- Harald

1 0

Various
by Per Starback 12 Jun '99

12 Jun '99

Various things I, as a new Mailman user, have wished was different. These are not bug reports, but rather design issues. * Privacy Options I don't like the combined meanings of the fields A = "Restrict posting privilege to list members?" and B = "Addresses of members accepted for posting to this list without implicit approval requirement". The current functionality is: If A is No, and B isn't set, then anyone is allowed to post. If A is No, and B is set, then *only* users listed in B are allowed to post. If A is Yes, then members *and* users listed in B are allowed to post. My usual setting is the last one. Only members and some special addresses are allowed to post to the list. But sometimes when I go away for some time I would like to open up the list a little to make it work more seamlessly while I can't be there to administrate it. Now I can't just turn switch A to do that, but instead I have to remove all addresses from B as well. Of course that's not very much problematic to do, but nevertheless it seems illogical. Perhaps it would be better if A had three possible values: Noone, Members only, Anyone. And then B always is a list of *additional* addresses besides what option A states? * Digest-member options "Header added to every digest" is empty as the default value. I would prefer if the whole Send xxx maillist submissions to [...] When replying, please [...] "Re: Contents of xxx digest...") blurb was there instead, so all of that could be edited. (By the way, that blurb ends with an unmatched ")". That's an error in Digester.py.) * List-specific programs Something I'm missing from Smartlist which I have been using since before is the possibility there of adjusting everything for a particular list by making a special version of the list programs for that list. In this way it would great if I could just put a changed Digester.pyc (for example) in the directory for a particular list to have that list use that one instead of the default one. This wouldn't be needed for most lists, or course, but still such a minor(?) change would make it *possible* to do almost anything, including stuff that there probably will be support for in the future but that someone could need to fix "by hand" for one particular list right now, and specialized stuff for which there never will be generalized support.

2 1

Re: [Mailman-Developers] [NEWBIE] ... Help! File permission error
by Harald Meland 11 Jun '99

11 Jun '99

[Feisal Umar] > Harald, > > if u don't mind, please go to > http://listserv.mysmac.com/pipermail/demo-users/ > > On the "Downloadable Version" column: > archive 19990604 is the problem I'm having now > (and still do), > archive 19990602 is what I will get if I run > ~prefix/bin/arch <list name> whatever whatever I got a chance to observe that the problem was there some time ago, but now I'm no longer allowed to view the URL mentioned above. However, I can only find one place in the Mailman code where a gzipped file is being created -- and that's the one I fixed by my first patch to solve this problem (line 889 of current CVS HyperArch.py). Neither can I find no likely chmod() calls to cause the problems you're seeing. So, unless anyone else speaks up and tells me they have similar problems, I'm going to have to assume that the problem is specific to your system (in some way -- without having a closer look at the system from within, I'm unable to pinpoint the problem further). Sorry, -- Harald

1 0

listinfo.html
by Per Starback 11 Jun '99

11 Jun '99

There are some html errors in the default listinfo.html, including some none-nesting tags. In this mail is a version that fixes most of them. As can be seen I have edited revision 1.19 (which is in 1.0rc1). (While fixing the errors I changed the indentation to be more consistent, so if you want to check exactly what is changed you might want to use diff -b or -w.) If you add <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> at the start of this there are still two errors left than a validator finds. That's the HEIGHT attribute to TABLE which is a netscapism, and the COLS attribute which is an explorerism. (Maybe they should be eliminated too.) -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-  <HTML> <HEAD> <TITLE><MM-List-Name> Info Page</TITLE> </HEAD> <BODY BGCOLOR="#ffffff"> <TABLE COLS="1" BORDER="0" CELLSPACING="4" CELLPADDING="5"> <TR> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#99CCFF" ALIGN="CENTER"> <MM-List-Name> -- <MM-List-Description> </TD> </TR> <tr> <td colspan="2"> </td> </tr> <tr> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> About <MM-List-Name> </TD> </TR> <tr> <td colspan="2"><MM-List-Info> To see the collection of prior postings to the list, visit the <MM-Archive><MM-List-Name> Archives</MM-Archive>. <MM-Restricted-List-Message> </TD> </TR> <TR> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> Using <MM-List-Name> </TD> </TR> <tr> <td colspan="2"> To post a message to all the list members, send email to <A HREF="mailto:<MM-Posting-Addr>"><MM-Posting-Addr></A>. You can subscribe to the list, or change your existing subscription, in the sections below. </td> </tr> <TR> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> Subscribing to <MM-List-Name> </TD> </TR> <tr> <td colspan="2"> Subscribe to <MM-List-Name> by filling out the following form. <MM-Subscribe-Form-Start> <MM-List-Subscription-Msg> <blockquote> <TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" WIDTH="70%" HEIGHT="112"> <TR> <TD BGCOLOR="#dddddd" WIDTH="55%">Your email address:</TD> <TD WIDTH="33%"><MM-Subscribe-Box> </TD> <TD WIDTH="12%"> </TD></TR> <TR> <TD COLSPAN="3">You must enter a privacy password. This provides only mild security, but should prevent others from messing with your subscription. Do not use valuable passwords! <MM-Reminder> </TD> </TR> <TR> <TD BGCOLOR="#dddddd">Pick a password:</TD> <TD><MM-New-Password-Box></TD> <TD> </TD></TR> <TR> <TD BGCOLOR="#dddddd">Reenter password to confirm:</TD> <TD><MM-Confirm-Password></TD> <TD>  </TD></TR> <tr> <td>Would you like to receive list mail batched in a daily digest? </td> <td><MM-Undigest-Radio-Button> No <MM-Digest-Radio-Button> Yes </TD> </tr> <tr> <td colspan="3"> <center><MM-Subscribe-Button></center> </TABLE> </blockquote> <MM-Form-End> </td> </tr> <TR> <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#FFF0D0"> <a name="subscribers"> <MM-List-Name> Subscribers</a> </TD> </TR> <tr> <TD COLSPAN="2" WIDTH="100%"> <MM-Roster-Form-Start> <MM-Roster-Option> <MM-Form-End> <MM-Subscribe-Form-Start> <MM-Editing-Options> <MM-Form-End> </td> </tr> </table> <MM-Mailman-Footer> </BODY> </HTML>

1 0

performance again...
by Ricardo Kustner 09 Jun '99

09 Jun '99

Hi, well, it happened again last night that the system load jumped to abnormal levels on our server when some messages where being approved in admindb so I had to try to telnet to it again and issue a shutdown to the machine... It's getting really unworkable like this... :( recently, one of the people who use the moderating page told me that she often moderates by selecting several messages to approve on 1 page and then press the submit button (to be honest i didnt even know that was possible myself) -- i guess that's what can cause things going wrong: too many messages are being send at the same time and mailman goes bezerk... does anybody have idea how i can fix this? or is this a bug in mailman? i really need to fix it soon... there are other things running on that server too and it needs to be up 24h a day... if i happen to be online i usually fix it in 30-60 mins (telnetting to a server with 60+ systemload can take a while) but if i'm not around it can be down all night :( Thanks, Ricardo. --

1 0

Archiving Automatically
by Feisal Umar 05 Jun '99

05 Jun '99

Earlier I had a problem where whenever I tried to access the "Downloadable version" version of my list's archive. (The xxx.txt.gz has permission 600) I managed to fix it via manually running $prefix/bin/arch <listname> archives/private/<list-name>.mbox/<list-name>.mbox Shouldn't the bin/arch function be run automatically for each of my list? My list works fine in all other aspect (fingers crossed) except for 'downloadable archive'. Did I miss a step elsewhere? Thanks in advance -- Feisal Umar, Project Manager Huge, Friendly and Entertaining http://altavista.skali.com Skali Multimedia Applications Centre http://www.altek.com.my/smac

1 0

Re: [Mailman-Developers] Monthly reminder sent by mailman-owner considered harmful
by Harald Meland 05 Jun '99

05 Jun '99

[Bart Schaefer] > On 4 Jun 1999, Harald Meland wrote: > > > [Bart Schaefer] > > > > > Consider the possibility that I, unaware that this is going to take > > > place, subscribe an address that represents a local exploder. At > > > some later time everyone on that local list is going to be given my > > > password > > > > If you're adding other people's addresses, then how would they be able > > to unsubscribe later > > Because my "local exploder" is a news gateway and they simply use their > newsreader to subscribe/unsubscribe the newsgroup. Or because my exploder > is another mailing list manager so they can subscribe/unsubscribe from the > local list. Neither of these is an uncommon situation. I have no problem seeing the usefulness of adding non-personal addresses to mailing lists. I was merely stating that you shouldn't be using a very "private" password when doing so (i.e. don't use passwords that are used for other subscriptions as well). [ Even if the automatic reminders are turned off, people can still go to the list's member page (if it is open), click on some member address, and click on the "Send me my password now" button to have Mailman distribute the password to the member (which could be an exploder). ] In cases like these, there _will be_ loopholes in Mailman's "security mechanisms", unless you introduce some new concepts -- e.g. a "member owner address" that receives all administrative requests regarding it's associated member. The umbrella list feature of Mailman solves these things for lists where _all_ the member are exploders, but not for lists with both user and list members. I have been thinking about implementing a more general solution after 1.0 is out, but the list of post-1.0 things to do is getting pretty long... :) -- Harald

3 2

[NEWBIE] ... Help! File permission error
by Feisal Umar 05 Jun '99

05 Jun '99

Harald, if u don't mind, please go to http://listserv.mysmac.com/pipermail/demo-users/ On the "Downloadable Version" column: archive 19990604 is the problem I'm having now (and still do), archive 19990602 is what I will get if I run ~prefix/bin/arch <list name> whatever whatever I don't see anyone else having this problem ... so far. >From your previous analysis, archive 19990602 "downloadable version" is what I should get everytime a post is sent to the list .... why isn't it happening here? Thank you for your efforts so far :) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0