Mailman 3 June 1999 - Mailman-Developers

Re: [Mailman-Developers] config.db
by Christopher Lindsey June 23, 1999

June 23, 1999

> How interesting... I did the exact same thing. Someone sent a 1MB message > to the list (picture attached) and I wanted to extract the picture, shrink > it, and then let it go through (the reduced picture was 50k, and we allow > attachments up to 100k on the list). It would have been nice if there had > been a "forward to:" option on the managment page that would send the > message to me. (I know, I know, that's not generally what the listadmin > would want to do, but I thought I'd put in my $0.02). As it was, I copied > config.db to another file, hacked it into my mailbox, and was able to get > at it that way, but it was kind of annoying :). Rupa Schomaker posted a patch to forward held messages to the listowner on May 30, 1999. I plan on adding an option (either personally or virtually through a co-worker :) to forward to another address entered via textbox -- this is useful when you've got multiple admins and don't want to spam them all with a held message. Anyhow, Rupa's patch should be in the mailman-users archive for May, 1999. Chris

1 0

Setting Reply-To
by J C Lawrence June 23, 1999

June 23, 1999

A peculiar need: I need to set Reply-To on a list to something OTHER than the list address. Specifically I need to set Reply-To to the address of another list. Can do? -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Linux/IA64 - Work: claw(a)varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ...

1 0

Re: [Mailman-Developers] config.db
by Ricardo Kustner June 23, 1999

June 23, 1999

Hi, On 22-Jun-99 Troy Morrison wrote: > How interesting... I did the exact same thing. Someone sent a 1MB message > to the list (picture attached) and I wanted to extract the picture, shrink > it, and then let it go through (the reduced picture was 50k, and we allow > attachments up to 100k on the list). It would have been nice if there had > been a "forward to:" option on the managment page that would send the > message to me. (I know, I know, that's not generally what the listadmin > would want to do, but I thought I'd put in my $0.02). Very interesting indeed :) i had the same thing yesterday so i'll add $0.02 to that. > As it was, I copied > config.db to another file, hacked it into my mailbox, and was able to get > at it that way, but it was kind of annoying :). I could find hacks for getting it out there too but that's quite a hassle and some of my moderators are windows users and they can't do neat things like us :) actually one weird thing with one of our moderators is that if she approves a lot of mail on the list in the admindb interface, it often happens that some of the fastcgi scripts on our erver crash (well, we all the the system load tends to go sky high with the current version of mailman :( ) and at the same time the windows PC of the moderator totally freezes up... the only connection i think of is that the mail is being delivered to the moderator's mailbox at the same time as Netscape Mail tries to check POP mail from there... but it's still kinda weird to me... oh well let's just blame it on windows ;) Ricardo. --

1 0

Cooki e problem with current CVS tree
by J C Lawrence June 23, 1999

June 23, 1999

I just revved a 1.0rc1 installation to the current CVS tree. Cookies no longer track properly -- you are asked to re-authenticate on every page and nothing gets done. Known fix? -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Linux/IA64 - Work: claw(a)varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ...

1 0

Viewing anyone's options w/o a password
by Rob Francis June 23, 1999

June 23, 1999

It seems kind of odd to me that if I know someone's email address on a list that I can go to the Info page and enter their email address, and then w/o a password see what options they have set. Granted, I can't change the options, but why even let someone get to see the options a person has selected? Just wondering if this was a decision made on purpose, or perhaps an oversight. -rob rfrancis(a)dti.net

1 0

config.db
by Ricardo Kustner June 22, 1999

June 22, 1999

Hi, Yesterday i was looking where mailman stores the pending-for-moderation messages ... it took a while before I found out... cause i'd never suspect it to be inside config.db ? what's the philosophy on that... it seems kinda weird to keep it in the configuration database... Ricardo. --

2 1

Mailman internationalization. Report from the trenches. VERY LONG
by Juan Carlos Rey Anaya June 22, 1999

June 22, 1999

By the time being, we have made important progress for internationalizing mailman. Juan Carlos Rey has prepared a functional demo version of our proposed way to do it. This demos has the new ideas, with messages in english and spanish for the pages. All proposed ideas in our message dated Fri, 21 May 1999 14:57:39 +0200 with the subject: Re: [Mailman-Developers] features suggestion: languages have been implemented and work as described there. We have not translated, yet, the hardcoded message strings, but the code need to change their values depending on language is ready to be used. Now we are trying to reconciliate our chages with a CVS tree we have downloaded this morning. (Yes, we didn't know how to use CVS when we started). You can test the web interface at: http://joker.sci.uma.es/mailman/listinfo/test The list main language is spanish (español) The admin password is "ejemplo" (be gentle, please :) We have concentrated on function, not on aspect, so it is a bit crude. The use of a message catalog in different languages will have a big impact on main Mailman development, so we would need your input on such an issue. We have found two ways for doing this: Using GNU gettext (which does not work completely in python and has some other implications, see attached conversation) our KISS approach: python modules with the messages in them. Like this: --- BEGIN es.py --- ErrorInvalidPasswd = 'Error: clave incorrecta' ListNotFound = 'la lista no se encuentra: %s' DEFAULT_MSG_FOOTER = """_______________________________________________ lista de distribucion %(real_name)s - %(real_name)s@%(host_name)s %(web_page_url)slistinfo/%(_internal_name)s """ --- END es.py --- To use the message catalog: import Catalog Msg = Catalog.MsgLang('es') print Msg.get('ErrorInvalidPasswd') Attached conversation with Dan Ohnesorg, who is interested in working in the project. ------ START -------- > > Acording with the article, there are many parts to consider: > - Character Sets > - Message Output > - Locales > - Character Input and display > - Documentation > > I think the areas we should consider are: > - Messages output to end user > - Character set Sure. I agree. > GNU gettext: > * advantages > - Easy to mantain, once parsed with 'xgettext', and compiled to .mo > file, with 'tupdate' is easy to update the catalog - new version of software can run with old catalogs and only some part of meesages is not translated - for developper of software is gettext clean to undestand a simple to include > * disadvantages > - A little complicated to generate. It must be, parsed, and > installed. It also > must be updated 'at hand' if catalog changes. > - At the moment, it is not fully operational for python It is the biggest problem. > - Take into account locales, mailman will be executed on the server, > language s a parameter in a form. Your software can switch locales indepently of server. For example in midnight commander are locales switched before parsing any output of sub processes > Catalog in lang.py > * disadvantages > - More difficult to mantain up to date. - More works for mailman developers > * advantages > - It's very easy to create messages we need (multilines) > - No need to be generated, once modified source files, it is ready > for use. Changes are in effect once saved the file. > - We can abstract inside lang.py operations we need for some > languages, whenever it gives the apropiate value to messages. > > I have given a glimpse to 'wstring' and 'intl' modules. I really don't > know how to use 'wstring' for our purpose. Please, if you know how to > use it, let me know too. I dont know how to use unicode in mail. I think it is not that what we now need. Unicode is fine in databses, printing etc, but mail with unicode charset is probably unredable by any client. intl module is probaly good. I will look on it and i will say more later. Your modules are working, but I am not sure, If they are acceptable for mailman developers. ---END--- -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey(a)uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------# # Solo se que cada vez se menos :-| # #----------------------------------------------#

1 0

Unsubscribed users still getting monthly reminders
by J C Lawrence June 15, 1999

June 15, 1999

I have Mailman v 1.0b8 running at Kanga.Nu (yes, I know its old, I'll upgrade tonight), and have two list members complaining that they are no longer subscribed to a list and yet receive monthly password reminders. When I check the web interfaces, they are in fact unsubscribed. Ideas? -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Linux/IA64 - Work: claw(a)varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ...

1 0

Re: [Mailman-Developers] Cookie security hole in admin interface
by Harald Meland June 14, 1999

June 14, 1999

[John Morton] > Harald Meland writes: > > As the extra complexity added by having to save session state on the > > server side (i.e. have Mailman keep track of session IDs) is rather > > large, and as Mailman isn't safe from package sniffing anyway (unless > > you're running things on a SSL server, in which case cookie sniffing > > shouldn't be of any trouble anyway), I settled for slightly less. > > True. Though stealing a cookie via packet sniffing will still require > the thief to be on the same IP as the original cookie owner, or it > will require them to fake their IP as well. I wasn't really thinking of cookie stealing, but rather on plain text password sniffing... and to remove that vulnerability, one would have to use SSL or somesuch. > [Note, I'm not a python hacker, so bear with me :-) ] > > Do add the domain that this mailman for this list is supposed to be > under (or the browser will send this cookie to every site you connect > to!) RFC 2109 has this to say: 4.3 User Agent Role 4.3.1 Interpreting Set-Cookie The user agent keeps separate track of state information that arrives via Set-Cookie response headers from each origin server (as distinguished by name or IP address and port). The user agent applies these defaults for optional attributes that are missing: [...] Domain Defaults to the request-host. (Note that there is no dot at the beginning of request-host.) ... so I think that the current behaviour of not specifying the cookie's domain at all is correct. > and restrict the scripts that it is sent to to /mailman/ at worst, > /mailman/admin and /mailman/admindb separately at best (allowing > separate passwords for those two scripts is a needed feature for a > proper distinction between list admins and moderators, anyway). Current behaviour is to restrict to /mailman (well, the code is really using path part of mm_cfg.DEFAULT_URL) -- to allow the same cookie to authenticate against both admin and admindb pages. If a separate admindb password is implemented, it won't be a problem to issue a cookie with a different name for authentication with that password (e.g. use the 'listname:admin' cookie for access to both admin and admindb, and also test for 'listname:admindb' if the first fails on admindb access). > I'd prefer to grab the secret from a file that's refreshed via a > cronjob every 24hrs or so. Uhm, then anyone getting their cookie just before the secret is refreshed will have to re-enter their password before their cookie should have expired. Do we really want that? > > mac = hash(secret + client_ip + `issued` + `expires`) > > Is the hash() function one way? Yup, at least for now (and I believe it wouldn't be of much use as a hashing function if it wasn't). > The FAQ talks about doing a second round of MD5 hashing to '...avoid > an attack in which additional data is appended to the end of the > cookie and a new hash recalculated by the attacker.', but I don't > really understand why that's necessary. Neither did I -- but I believe the FAQ answer made the assumption that the server stores more session state than Mailman does. > Should we check that expires - issued = mm_cfg.ADMIN_COOKIE_LIFE ? Depends on whether you want cookies issued directly before the site admin changes ADMIN_COOKIE_LIFE to go dead immediately or not until after they were set to expire on creation. > The combination of a cryptographic hashing function and a secret key > that's regenerated on a 24hour cycle makes an attack by constructing > a cookie infeasible (at least, within the useful lifetime of > whatever hashing function we're using). I'm hoping that using the list's encrypted admin password as secret, in combination with a relatively short expire time, is sufficient -- but I'm no cryptography expert. I _am_ trying to keep the applied security mechanisms within reason, though -- if you want a completely bullet-proof Mailman, use an SSL-enabled server. > Remaining sources of attacks are: > > Packet sniffing: They could steal the cookie this way. But they'd > just steal the password, anyway, so it's a moot point. Use SSL if > you're that paranoid. Exactly. > Stealing the cookie: Presumably by some method other than packet > sniffing or direct access to your terminal; maybe a broken browser > could be distributing the cookie to every site it meets. The > attacker will need to fake your IP to the web server _and_ get the > response back, which is rather hard. Hmmmm... how do proxies (e.g. web cache servers) enter into this picture? > Getting access to your terminal: The short expiry time is supposed > to help defeat this problem. I was wondering whether Mailman should re-issue a new cookie on each successful cookie authentication, but decided against it -- partly due to this possible problem, partly because it would annoy people who have their web browser warn them before accepting new cookies, and partly because anyone struggling with Mailman's web admin interface to a single list for more than (the default) three hours probably is such a humble person that having to enter the admin password once more won't be a big problem :) > The price to pay for the convenience of not having to type the > password in every time. Indeed. > Perhaps having an option to turn off the use of cookies will keep > the paranoid happy and allow admins to use their servers native > authentication methods. Perhaps modules to interface between mailman > and the various different web servers is a direction someone would > like to go in? An option to disable cookie authentication altogether is easily implemented (have a look at SecurityManager.WebAuthenticate()) -- but I don't know anything about "native authentication methods", so I think I'll put it off until I understand the issues better. -- Harald

1 0

Re: [Mailman-Developers] Cookie security hole in admin interface
by Harald Meland June 14, 1999

June 14, 1999

[Gerhard Gonter] > Harald Meland writes: > > As the extra complexity added by having to save session state on the > > server side (i.e. have Mailman keep track of session IDs) is rather > > large, and [...] > > In a local CGI application, we are storing cookies in an LDAP server > which would be an excellent supplement for Mailman anyway. True -- I was only saying that for fixing the hole, such a major job would take too much time. For post-1.0 LDAP support might at some time be nice (although it would have to be a purely optional thing, of course). > User database and some other things might be stored there. I toyed > around with that idea in conjunction with our old Listprocessor but > gave up on that because the Listprocessor is such a mess. Maybe generalizing the interface for storing state in Mailman is something to think about. If we had such a thing, we could have a "marshal-dump to/from local file" subclass, an "LDAP-query" subclass, and so on... I think many of the other things we have put off until after 1.0 will have priority, though. -- Harald

1 0