I'm sorry if this issue was already addressed in later versions of mailman. I'm running debian etch and the mailman deb: dpkg -l | grep mailman ii mailman 2.1.9-7 Powerful, web-based mailing list manager
I wrote a majordomo like interface for mailman which allows users to perform some backwards compatible functions via email, and access some information, like subscribed lists and owned lists via a web interface.
When I released the interface to users, one of the first things a user did was to use all caps in the list they were attempting to create. My script verifies that the list doesn't already exist: if Utils.list_exists(listName):
which it didn't and then passes it into the mailman Create function.
mlist.Create(listName, listOwner, listPasswordHash )
There were no errors in the create process. The problem was that the list was actually a duplicate of an existing list which obviously wasn't in all caps. Since the process by which mailman gets the list configuration seems to be case insensitive, both lists would access the old config, so functionally I had two references to the same list.
The solution to the problem was to just .lower() the listName string at the top of the list create function, but it might make sense to lower the string in the Create function as mailman is not case sensitive after that point.
Let me know if you'd like me to open a bug for this issue...
Thanks, -Lawren Quigley-Jones lawrenqj@gmail.com
Lawren Quigley-Jones wrote:
I wrote a majordomo like interface for mailman which allows users to perform some backwards compatible functions via email, and access some information, like subscribed lists and owned lists via a web interface.
When I released the interface to users, one of the first things a user did was to use all caps in the list they were attempting to create. My script verifies that the list doesn't already exist: if Utils.list_exists(listName):
So does mlist.Create()
which it didn't and then passes it into the mailman Create function.
mlist.Create(listName, listOwner, listPasswordHash )
There were no errors in the create process. The problem was that the list was actually a duplicate of an existing list which obviously wasn't in all caps. Since the process by which mailman gets the list configuration seems to be case insensitive, both lists would access the old config, so functionally I had two references to the same list.
I don't think this is quite correct in an OS with case sensitive path names. I think you should have ended up with the original lists/listname/ directory with it's original contents and a new lists/LISTNAME/ directory with the new list's config.pck and other files.
The real problems arise because the web CGIs lower case the list name, and the MTA might not distinguish local parts that differ only in case. Thus, the LISTNAME list is effectively unusable.
The solution to the problem was to just .lower() the listName string at the top of the list create function, but it might make sense to lower the string in the Create function as mailman is not case sensitive after that point.
Lower casing the listname before calling Create() is what bin/newlist and Mailman/Cgi/create.py do, so I could say that not doing that is a misuse of the Create() method, but I agree that since upper and mixed case names don't really work, the Create() method or possibly Utils.list_exists() should do this.
Let me know if you'd like me to open a bug for this issue...
Thanks for the report. I don't think it's necessary to open a bug. I'll fix it without a bug in the tracker, but I would like some feedback if anyone has any opinion on the best place to do it, i.e., the Create() method, Utils.list_exists(), both or somewhere else.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
Thanks for the report. I don't think it's necessary to open a bug. I'll fix it without a bug in the tracker,
Up to you, but it is useful to people with lower versions to be able to see that the bug has been reported, and what progress is being made, in the tracker.
but I would like some feedback if anyone has any opinion on the best place to do it, i.e., the Create() method, Utils.list_exists(), both or somewhere else.
IMO, fix it in Utils.list_exists() and call that from the Create() method.
Stephen J. Turnbull wrote:
Mark Sapiro writes:
Thanks for the report. I don't think it's necessary to open a bug. I'll fix it without a bug in the tracker,
Up to you, but it is useful to people with lower versions to be able to see that the bug has been reported, and what progress is being made, in the tracker.
Good point.
but I would like some feedback if anyone has any opinion on the best place to do it, i.e., the Create() method, Utils.list_exists(), both or somewhere else.
IMO, fix it in Utils.list_exists() and call that from the Create() method.
I realized that only fixes the problem of creating a list with an upper/mixed case name where the lower case name already exists.
We still need to make sure that we only create lists with lower case names in the first place. The API which is the Create() method needs to enforce this. So, I'm inclined to lower-case the name provided to Create(), but also lower-case the name provided to Utils.list_exists().
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 5, 2007, at 3:51 PM, Mark Sapiro wrote:
We still need to make sure that we only create lists with lower case names in the first place. The API which is the Create() method needs to enforce this. So, I'm inclined to lower-case the name provided to Create(), but also lower-case the name provided to Utils.list_exists ().
I'm actually not convinced this is a bug, but a problem with the
client of Create() and list_exists(). The problem is that once you
lowercase the list name in those two methods, you might have to start
lowercasing them in an API that might get called via script, web, or
email. I really don't think we need viral .lower() calls all over
the place.
It's tempting to lowercase in Create() but I think it's better to
lowercase the list names at the edges of the system, in much the same
way that we should be converting strings to unicode at the edges of
the system. This means that Lawren's email and web extensions should
be doing the lowercasing there.
Another problem of course is that the constraints for internal API
functions like Create and list_exists() isn't really documented
anywhere. I'm trying to improve that situation for Mailman 3.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRwapjnEjvBPtnXfVAQJZ4QP/RrFuMZ3FcwzCWFdDdq1xdBVvV6ZUcllB +J/nHS5vqY8Fw36JcbJ+BlmzDbwNcWk6FivcjQehktt2owkYJjEZPfvTXytpjgvr Um7UjX4Vbc+p9u2e3l2J3rQuwTt8HNZmU8yTgX7x/lzgLnvHOGujuqXbAkSv5ILv 3gpbHGaOqbM= =A+Ef -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
I'm actually not convinced this is a bug, but a problem with the client of Create() and list_exists().
I did say in my original reply in this thread: | Lower casing the listname before calling Create() is what bin/newlist | and Mailman/Cgi/create.py do, so I could say that not doing that is a | misuse of the Create() method ...
The problem is that once you lowercase the list name in those two methods, you might have to start lowercasing them in an API that might get called via script, web, or email. I really don't think we need viral .lower() calls all over the place.
It's tempting to lowercase in Create() but I think it's better to lowercase the list names at the edges of the system, in much the same way that we should be converting strings to unicode at the edges of the system. This means that Lawren's email and web extensions should be doing the lowercasing there.
I agree, but the problem remains that upper and mixed case internal names don't work because of the many user interfaces that lower case the name before accessing the list. So, what does Create() do when asked to create a list with a non-lower case name?
- Go ahead and create it.
- Lower case the name and create that.
- Raise raise Errors.BadListNameError.
Presently it does 1), but I think 2) is better and perhaps 3) is best.
Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFHCVreVVuXXpU7hpMRAjWcAJ0YYudg4Tl6zg6sPrOt9/Lc4/wdzQCeMbq8 ChiA4GBUrkacAIFaG909BN8= =Yw4C -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 7, 2007, at 6:17 PM, Mark Sapiro wrote:
I agree, but the problem remains that upper and mixed case internal names don't work because of the many user interfaces that lower
case the name before accessing the list. So, what does Create() do when
asked to create a list with a non-lower case name?
- Go ahead and create it.
- Lower case the name and create that.
- Raise raise Errors.BadListNameError.
Presently it does 1), but I think 2) is better and perhaps 3) is best.
Let's do #3, or alternatively, we could add an assert since this is a
constraint of Create(). E.g. something like this before the
Utils.list_exists() call:
assert name == name.lower(), 'List name must be all lower case.'Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHC3wP2YZpQepbvXERAtToAJ9t1NToyQCtohVl3ZV0PWv2r5OodwCbBn7G BRRVrLmbFfcGb72HlUxpkT8= =OKYE -----END PGP SIGNATURE-----
participants (5)
-
Barry Warsaw -
Barry Warsaw -
Lawren Quigley-Jones -
Mark Sapiro -
Stephen J. Turnbull