Mailman 3 July 1999 - Mailman-Developers

RE: [Mailman-Developers] Viewing anyone's options w/o a password
by Aahz 28 Jul '99

28 Jul '99

This is late, but I'd suggest something like this: Require both e-mail address and password on sign-in. If no match is made, the error page contains a link to the form for "mail me password". I could go either way on the error page stating that the e-mail address is valid. -----Original Message----- From: Harald Meland [mailto:Harald.Meland@usit.uio.no] Sent: Thursday, July 01, 1999 2:34 PM To: Rob Francis Cc: mailman-developers(a)python.org Subject: Re: [Mailman-Developers] Viewing anyone's options w/o a password [Rob Francis] > 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. I agree -- in principle this really is giving away more info than it should, e.g. if I suspect that someone is subscribed to a list, I can use this "feature" to verify my suspicion. However, if we make access to the user options page password restricted, we'd (obviously) have to put the "Email my password to me" button on some other page -- and I sort of think the listinfo page is crowded enough as it is. > Just wondering if this was a decision made on purpose, or perhaps an > oversight. I don't know for sure, but I suspect it was done like this because of the "Email my password to me" issue. Good suggestions on how this should best be solved are welcome. -- Harald _______________________________________________ Mailman-Developers maillist - Mailman-Developers(a)python.org http://www.python.org/mailman/listinfo/mailman-developers

1 0

Re: Mailman-Developers digest
by Helge Hielscher 26 Jul '99

26 Jul '99

Hello, Some days ago I joined the list and I wonder why the Mailman-Users list´s digest is in MIME but not the developer digest where the mails are only seperated with --__--__-- which makes it harder to read. Who can/may change that behavior? BTW are HTML Index Digests implemented in Mailman? Helge

4 4

Missing vnsprintf on Compaq Tru64 Unix
by Lance A. Brown 24 Jul '99

24 Jul '99

Greetings, I'm trying to install mailman 1.0rc3 on a Compaq Alpha 2100 running Tru64 V4.0D but am missing the vnsprintf call when linking the cgi-wrapper. I'm using gcc 2.8.1 to compile it. Is the code for this function available someplace? --[Lance]

2 1

subscribe problem. and search timescale.
by Martin Evans 23 Jul '99

23 Jul '99

Hello all, I may be wrong but I think I've managed st subscribe someone with an invalid email address to my test list. I subscribed 'asd(a)asd.qw.sd.' as a digest member. Mailman claims to send off a confirm message but then subscribes him to the list anyway. Im using version 1.00rc1. Is this a known bug, or has it been fixed in a later release? which brings me on to my second question... I see in the TODO list that an archive search engine is planned... is there any timescale for a release even a simple grep string type interface would be extremely useful? Cheers, martin. -- --- M.D.T.Evans - Computing Services - Queen Mary & Westfield College ---

1 0

Re: [Mailman-Developers] cookie problem ?
by Harald Meland 22 Jul '99

22 Jul '99

[Gergely Madarasz] > Btw I thought it should be enough to set the base url in the general > options section. Oops... you're right, the cookie's path should be based on the URL path[1] of self.web_page_url instead of the global default mm_cfg.DEFAULT_URL. Here's a quick patch to do this: Index: SecurityManager.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/SecurityManager.py,v retrieving revision 1.21 diff -u -r1.21 SecurityManager.py --- SecurityManager.py 1999/07/16 22:40:28 1.21 +++ SecurityManager.py 1999/07/22 07:27:15 @@ -95,7 +95,7 @@ c = Cookie.Cookie() c[key] = [client_ip, issued, expires, mac] # place in oven, - path = urlparse(mm_cfg.DEFAULT_URL)[2] # '/mailman' + path = urlparse(self.web_page_url)[2] # '/mailman' c[key]['path'] = path # and bake until golden brown c[key]['expires'] = mm_cfg.ADMIN_COOKIE_LIFE [1] I don't know what else to call the part of an URL with proto://hostname stripped off the front, and anything from "?" and to the end of the string removed as well. -- Harald

1 0

Re: [Mailman-Developers] cookie problem ?
by Harald Meland 21 Jul '99

21 Jul '99

[Gergely Madarasz] > Hello, > > If I want to access the mailman pages thru a different url (like > http://somehost/cgi-bin/mailman/, the cgi-bin directory has a > symlink to mailman/cgi-bin) the cookie authentication is > problematic. Yup -- we wouldn't want browsers to send out Mailman cookies unless they actually are getting a Mailman page. Thus, the "path" setting of the Mailman-issued cookies are set to whatever the path part of mm_cfg.DEFAULT_URL is (i.e. normally "/mailman"). This means that Mailman cookies won't be sent to the server if you access the Mailman interface via some other CGI-script path. > It allows access for the first time but after that it wants > authentication again. Actually it is the password you send that gets you through the first time, and not any cookie. > Could this be fixed somehow ? I don't think we want to try being clever with any of the CGI environment variables for figuring out what URLs the cookies should be sent out for. > This way there wouldn't be need to configure the webserver to use > the /mailman/ alias. If you don't want to add the /mailman/ ScriptAlias (or whatever) to your web server configuration, Mailman's setting of mm_cfg.DEFAULT_URL should reflect this. This means that if you access all your Mailman CGI wrappers as e.g. <URL:http://mailman-host/cgi-bin/wrappername>, you should set DEFAULT_URL = "http://mailman-host/cgi-bin" in $prefix/Mailman/mm_cfg.py. Mailman cookies will then be sent out to any script in this cgi-bin directory. If you use both .../cgi-bin/wrappername and .../mailman/wrappername type URLs interchangeably, the cookies won't work for (at least) one of those -- so, you *shouldn't* use both types of URLs interchangeably. -- Harald

2 1

Re: [Mailman-Developers] Re: what is being checked?
by Harald Meland 21 Jul '99

21 Jul '99

[Phillip Porch] > > My suggestion is: these sort of things should require the "password=<>" on > > the same line as the request. If I am a legitimate subscriber, I can > > punch the HTML button to get my password mailed to me...it's not like I > > have to keep it on a post and would be an inconvenient imposition to > > require that parameter as part of the request. > > I think it is the way it is to accomidate the different privacy > settings. I'm not sure of the exact context here, but yes, different private_roster settings will give different results for the "who" mail command. * If "private_roster" is set to "List admin only", the "who" mail command will tell you "Private list: No one may see subscription list." * If set to "List members", it wil tell you "Private list: only members may see list of subscribers." unless the request sender address is a list member. This is the same algorithm that is used for deciding whether or not the "password" command with no arguments should mail back the member password or not -- so requiring a password to the "who" command in this case would just mean extra hassle, and not extra security. * If set to "Anyone", the roster will be mailed back without forther checking. In all cases only non-hidden member addresses are included in the roster. This all mimics the information available via the web interface closely. Does that answer the questions you have? -- Harald

2 1

Re: [Mailman-Developers] Fix for bug "incoming/64"--the prefix replication problem
by Harald Meland 21 Jul '99

21 Jul '99

[Dan Delaney] > Anyway, this would make the following subject line... > > Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) > > ...end up looking like this: > > Subject: [MyList] Re: Hello there So, if I send a mail with subject Subject: Administrivia: [foo] will be changed to [bar] Mailman should change it to Subject: [foo] Administrivia: will be changed to [bar] ? I don't think messing with the subject prefix to that extent is a good idea. Regarding stripping of consecutive "Re:" and "Fwd:" strings -- you'd still have problems with the nationalized versions of these ("SV:", "AD:", etc.) that some MUA vendors in their infinite wisdom have implemented, and besides this too have potential problems with stripping away substrings that really was meant to stay where they where. > The result is that your list messages always have readable, > comprehendable subjects that don't take 5 minutes to decode, AND > your list archives are much more functional and easier to browse > because messages which REALLY have the same subject won't be bogged > down with 'Re:'s and 'Fwd:'s. I think this "problem" should be solved in the user's MUA configuration (if the user wants the subjects mangled) and/or in the archiver thread generator. The archiver thread generator could be made to display sender address for all messages in the thread, but only display the subject at the top of the thread and every time the subject changes _substantially_. Non-substantial subject changes could e.g. be defined as changes which only include addition or removal of "Re:", "Fwd:" and instances of the subject prefix. The _real_ subjects, looking just the way they were sent (modulo subject prefix), would be available in the archive of each particular message. Example: Instead of having the archive thread view look like this: * [Mailman-Developers] foobar gazonk -- Harald Meland Re: [Mailman-Developers] foobar gazonk -- Barry A. Warsaw Re: [Mailman-Developers] florp -- Harald Meland it could look like this: * Harald Meland -- [Mailman-Developers] foobar gazonk Barry A. Warsaw Harald Meland -- [Mailman-Developers] florp (though I admit that it isn't entirely intuitive that "Barry A. Warsaw" is a link to an archived message and not a mailto: URL in this context.) -- Harald

1 0

Re: [Mailman-Developers] Various
by Harald Meland 21 Jul '99

21 Jul '99

[Per Starback] > * 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". [...] > 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? Yup, I agree that a three-state switch might be more intuitive -- but I'm hoping we'll find some even more general "posting access control" configuration setting -- i.e. one might want to restrict postings to members and addresses in the example.com domain, or everyone but addresses in badboys.net, or even only addresses with a localpart matching "\w+\.\w+". Either way, I don't see this changing before 1.0. > * 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. Noted. > * 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. I don't think this would be a smart move -- it could potentially cause _serious_ troubles when the list-specific files (e.g. old, installed by some previous site-admin which is now long gone) assumes interfaces that the Mailman distribution (which we'd like people to be able to upgrade from time to time without too much trouble) are trying to move away from. -- Harald

1 0

Mailman v 1.0rc1
by Marc Merlin 21 Jul '99

21 Jul '99

First off, I didn't install it, nor do I have access to it, so I can't really give more information than what's in this mail unfortunately. However if the bug hasn't been found and fixed yet, this report should be enough to find it. I had a user that was sending mail with the following in the "From: " field: Jason T. Collins <jcollins(a)valinux.com> Mailman would send mail back to jasont.collins(a)valinux.com and say the person wasn't subscribed. The problem went away when I had him remove the "." after the T in his name. My guess is that some regular expression in mailman is being fooled by the "." Marc -- Microsoft is to software what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f(a)merlins.org for PGP key and other contact information

1 0