From stu@ekins.net Wed Apr 8 11:21:09 1998 From: stu@ekins.net (Stu Ekins) Date: Wed, 8 Apr 1998 11:21:09 +0100 Subject: [Mailman-developers] Pipermail issue... Message-ID: <199804081022.LAA06752@super.m2.com> Hi, Does anybody know of any issues with the pipermail module? It hasn't worked for me since I upped my python version to 1.5 (on Linux 2.x). I'm still learning the language and am not yet competent enough to debug it fully myself! Here's a traceback... Traceback (innermost last): File "./archive", line 31, in ? list.UpdateArchive() File "/home/mailman/mailman/modules/mm_archive.py", line 72, in UpdateArchive import pipermail File "/home/mailman/mailman/modules/pipermail.py", line 424, in ? words = string.split(datestr) TypeError: argument 1: expected read-only buffer, None found Cheers, Stu. From akuchlin@cnri.reston.va.us Wed Apr 8 15:35:58 1998 From: akuchlin@cnri.reston.va.us (Andrew Kuchling) Date: Wed, 8 Apr 1998 10:35:58 -0400 (EDT) Subject: [Mailman-developers] Pipermail issue... In-Reply-To: <199804081022.LAA06752@super.m2.com> References: <199804081022.LAA06752@super.m2.com> Message-ID: <13611.35248.129856.570523@newcnri.cnri.reston.va.us> Stu Ekins writes: >Does anybody know of any issues with the pipermail module? It hasn't worked >for me since I upped my python version to 1.5 (on Linux 2.x). I'm still >learning the language and am not yet competent enough to debug it fully >myself! I'm Pipermail's developer, and yes, there have been several issues with it. The version included with Mailman is 0.02, which is really out of date; I rewrote it almost completely for 0.04. I'm now going to try to make a new distribution of 0.05 available in the next day or two. >Here's a traceback... >Traceback (innermost last): > File "./archive", line 31, in ? > list.UpdateArchive() > File "/home/mailman/mailman/modules/mm_archive.py", line 72, in >UpdateArchive > import pipermail > File "/home/mailman/mailman/modules/pipermail.py", line 424, in ? > words = string.split(datestr) >TypeError: argument 1: expected read-only buffer, None found That looks like datestr is None, where it's being expected to be a string; this probably means that there's a message with no 'Date:' line in its headers, or, alternatively, there's an unescaped 'From' at the beginning of a line, and the program is thinking that it marks the start of a new message. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ The clerisy are those who read for pleasure, but not for idleness; who read for pastime but not to kill time; who love books, but do not live by books. -- Robertson Davies, _A Voice from the Attic_ From klm@python.org Wed Apr 8 15:47:22 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 8 Apr 1998 10:47:22 -0400 (EDT) Subject: [Mailman-developers] Pipermail issue... In-Reply-To: <13611.35248.129856.570523@newcnri.cnri.reston.va.us> Message-ID: On Wed, 8 Apr 1998, Andrew Kuchling wrote: > Stu Ekins writes: > >Does anybody know of any issues with the pipermail module? It hasn't worked > >for me since I upped my python version to 1.5 (on Linux 2.x). I'm still > >learning the language and am not yet competent enough to debug it fully > >myself! > > I'm Pipermail's developer, and yes, there have been several > issues with it. The version included with Mailman is 0.02, which is > really out of date; I rewrote it almost completely for 0.04. I'm now > going to try to make a new distribution of 0.05 available in the next > day or two. And i've continued to work on mailman, among other things disengaging the internal, old version of pipermail and tailoring it to work with an external archiver (specifically) like andrew's new version of pipermail. If you can wait, i'm going to make a new release available over the weekend, in conjunction with andrew's release of the new pipermail. (I may make a preview available on friday, in order to give some time for people to identify any major showstoppers in my release, since i'll be away for most of the subsequent week...) Ken From scott@chronis.icgroup.com Thu Apr 9 08:45:38 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 03:45:38 -0400 Subject: [Mailman-developers] wrappers: legal_caller() Message-ID: <19980409034538.10528@chronis.icgroup.com> i have installed mailman as part of pilot project to test out new mailing list managers for work. i had to change the ./mailman/mail/wrapper program to check for multiple uids and gids to get the cron jobs to work properly (uid and gid were that of mailman when sending out results). has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a patch to ./src/mail-wrapper.c (the same change can be applied to the other legal_caller() functions in the wrappers): --- src/mail-wrapper.c Tue Jun 10 12:31:16 1997 +++ src/mail-wrappernew.c Thu Apr 9 03:41:32 1998 @@ -37,9 +37,18 @@ NULL /* Sentinal, don't remove */ }; -/* Should make these arrays too... */ -const int LEGAL_PARENT_UID = 8; /* mail's UID */ -const int LEGAL_PARENT_GID = 12; /* mail's GID */ + +const int LEGAL_PARENT_UIDS[] = { + 1, /* mail's uid */ + 537, /* mailman's uid */ + -1 /* Sentinel, don't remove */ +}; + +const int LEGAL_PARENT_GIDS[] = { + 1, /* mail's gid */ + 100, /* mailman's gid */ + -1 /* Sentinel, don't remove */ +}; /* @@ -77,20 +86,45 @@ ** is the parent process allowed to call us? */ int legal_caller() { - /* compare to our parent's uid */ - if(LEGAL_PARENT_UID != getuid()) + int uid, gid, isok, idi; + isok = 0; + idi = 0; + uid = getuid(); + while (LEGAL_PARENT_UIDS[idi] != -1) + { + if(LEGAL_PARENT_UIDS[idi] == uid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) { - fprintf(f,"GOT UID %d.\n", getuid()); - return 0; + fprintf(f,"GOT UID %d.\n", uid); + return 0; } - if(LEGAL_PARENT_GID != getgid()) + isok = 0; + idi = 0; + gid = getgid(); + while (LEGAL_PARENT_GIDS[idi] != -1) { - fprintf(f,"GOT GID %d.\n", getgid()); - return 0; + if(LEGAL_PARENT_GIDS[idi] == gid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) + { + fprintf(f,"GOT GID %d.\n", gid); + return 0; } return 1; } + int valid_command(char *command){ int i = 0; @@ -119,7 +153,7 @@ i = strlen(argv[1]) + strlen(COMMAND_LOCATION) + 2; command = (char *)malloc(sizeof(char) * i); sprintf(command, "%s/%s", COMMAND_LOCATION, argv[1]); - + fprintf(f, "command is %s\n", command); if(!valid_command(argv[1])){ fprintf(f,"Illegal command.\n"); } Scott Cotton IC Group, Inc From scott@chronis.icgroup.com Thu Apr 9 08:51:27 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 03:51:27 -0400 Subject: [Mailman-developers] BTW Message-ID: <19980409035127.37117@chronis.icgroup.com> nice work on the upcoming release, if that is indeed what's running at python.org. is there any work in progress on a mail interface to the adminstrative functions? Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Thu Apr 9 09:06:37 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 04:06:37 -0400 Subject: [Mailman-developers] suggestion Message-ID: <19980409040637.04722@chronis.icgroup.com> i would like to suggest two things about the confirmation step in subscriptions. first, that it be an option for email based subscriptions, and second, that just hitting reply and copying in the confirmation message (with or without regular email quotations) be made to work. if there's a consensus on this, i'd be willing to make the necessary changes. Scott Cotton IC Group, Inc. From scott@blackbox.pobox.com Thu Apr 9 09:04:22 1998 From: scott@blackbox.pobox.com (scott) Date: Thu, 9 Apr 1998 04:04:22 -0400 (EDT) Subject: No subject Message-ID: <199804090804.EAA01236@blackbox.pobox.com> lists From klm@python.org Thu Apr 9 16:44:31 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 11:44:31 -0400 (EDT) Subject: [Mailman-developers] BTW In-Reply-To: <19980409035127.37117@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > nice work on the upcoming release, if that is indeed what's running at > python.org. Thanks - yes. > is there any work in progress on a mail interface to the adminstrative > functions? Not currently. It's a good idea, and wouldn't be hard to implement. However, i've identified many such things pending - i'll put it on my list, which i'll be including in the package when i release. Ken From klm@python.org Thu Apr 9 16:47:45 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 11:47:45 -0400 (EDT) Subject: [Mailman-developers] wrappers: legal_caller() In-Reply-To: <19980409034538.10528@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > i have installed mailman as part of pilot project to test out new > mailing list managers for work. > > i had to change the ./mailman/mail/wrapper program to check for > multiple uids and gids to get the cron jobs to work properly (uid and > gid were that of mailman when sending out results). > > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a > patch to ./src/mail-wrapper.c (the same change can be applied to the > other legal_caller() functions in the wrappers): This sounds fine. Note that the next release will have a somewhat simpler wrapper situation - john has consolidated all the cgi wrappers into a single source file, so there now is a total of three wrappers - the generic cgi wrapper (which is parameterized to create an executable for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. Ken From klm@python.org Thu Apr 9 17:03:15 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 12:03:15 -0400 (EDT) Subject: [Mailman-developers] suggestion In-Reply-To: <19980409040637.04722@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > i would like to suggest two things about the confirmation step in > subscriptions. first, that it be an option for email based > subscriptions, and second, that just hitting reply and copying in the > confirmation message (with or without regular email quotations) be > made to work. Both sound good to me, with one reservation. It's all too common for people to lazily cite an entire message when they're responding to it, so their response may be, "No don't subscribe me", followed by a citation of the entire subscription-confirmation request. That sort of thing would have to be recognized, particularly since we want to strenuously avoid having a subscription refusal lead to subscription... > if there's a consensus on this, i'd be willing to make the necessary > changes. Cool. Ken From scott@chronis.icgroup.com Thu Apr 9 17:59:01 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 12:59:01 -0400 Subject: [Mailman-developers] wrappers: legal_caller() In-Reply-To: ; from Ken Manheimer on Thu, Apr 09, 1998 at 11:47:45AM -0400 References: <19980409034538.10528@chronis.icgroup.com> Message-ID: <19980409125901.07425@chronis.icgroup.com> On Thu, Apr 09, 1998 at 11:47:45AM -0400, Ken Manheimer wrote: | On Thu, 9 Apr 1998, Scott wrote: | | > i have installed mailman as part of pilot project to test out new | > mailing list managers for work. | > | > i had to change the ./mailman/mail/wrapper program to check for | > multiple uids and gids to get the cron jobs to work properly (uid and | > gid were that of mailman when sending out results). | > | > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a | > patch to ./src/mail-wrapper.c (the same change can be applied to the | > other legal_caller() functions in the wrappers): | | This sounds fine. Note that the next release will have a somewhat | simpler wrapper situation - john has consolidated all the cgi wrappers | into a single source file, so there now is a total of three wrappers - | the generic cgi wrapper (which is parameterized to create an executable | for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. One more thing that may make the installation easier would be to have a single header file that is #included in each c source file with something like /* legal parent uid's of the wrapper ./mailman/mail/wrapper */ const int LEGAL_MAIL_PUIDS[] = { 0, /* root */ 1, /* bin */ 537, /*mailman */ -1, /* Sentinel, do not remove */ } or if there's a worry of defining unused variables: #ifdef MAIL_WRAPPER [declaration] #endif along with a '#define MAIL_WRAPPER 1' in mail-wrapper.c this way, while whoever is installing the program, they would only have to edit one file to play with the calling uid and gid. Scott Cotton IC Group, Inc. From jtv2j@cs.virginia.edu Thu Apr 9 19:09:08 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 9 Apr 1998 14:09:08 -0400 (EDT) Subject: [Mailman-developers] wrappers: legal_caller() Message-ID: <199804091809.OAA09086@cobra.cs.Virginia.EDU> > On Thu, Apr 09, 1998 at 11:47:45AM -0400, Ken Manheimer wrote: > | On Thu, 9 Apr 1998, Scott wrote: > | > | > i have installed mailman as part of pilot project to test out new > | > mailing list managers for work. > | > > | > i had to change the ./mailman/mail/wrapper program to check for > | > multiple uids and gids to get the cron jobs to work properly (uid and > | > gid were that of mailman when sending out results). > | > > | > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a > | > patch to ./src/mail-wrapper.c (the same change can be applied to the > | > other legal_caller() functions in the wrappers): > | > | This sounds fine. Note that the next release will have a somewhat > | simpler wrapper situation - john has consolidated all the cgi wrappers > | into a single source file, so there now is a total of three wrappers - > | the generic cgi wrapper (which is parameterized to create an executable > | for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. > > One more thing that may make the installation easier would be to have > a single header file that is #included in each c source file with > something like > > /* legal parent uid's of the wrapper ./mailman/mail/wrapper */ > const int LEGAL_MAIL_PUIDS[] = > { > 0, /* root */ > 1, /* bin */ > 537, /*mailman */ > -1, /* Sentinel, do not remove */ > } > > or if there's a worry of defining unused variables: > > #ifdef MAIL_WRAPPER > > [declaration] > > #endif > > along with a '#define MAIL_WRAPPER 1' in mail-wrapper.c > > this way, while whoever is installing the program, they would only > have to edit one file to play with the calling uid and gid. > > Scott Cotton > IC Group, Inc. > > > ------------------------------------------------------ > Mailman-developers maillist - Mailman-developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers Actually, the ultimate goal is to have as much configuraiton as possible picked out automatically, and the rest of it maintained by a single file, or perhaps a web page. For example, most of the uids we could do a good job of guessing based on the passwd file, and then keep it open for people to change if they have special considerations. John From klm@python.org Fri Apr 10 02:21:04 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 21:21:04 -0400 (EDT) Subject: [Mailman-developers] Pre-release of new mailman version Message-ID: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> I've packaged an a prerelease of my new version of mailman - the one currently running on python.org. I plan to do a real (beta) release by the end of the weekend, but would like to have people do some poking and prodding before then, to shake out any overt problems in my packaging methods... (Also, some people are doing their own work on particular pieces, and need to work w.r.t. the current version instead of the substantially different prior one.) Since there are some substantial changes, particularly in the way default site values are configured and in the maillist data structures, you should not overwrite anything you're using for production. (In particular, i haven't implemented the routine that migrates the datastructures from older list versions to the current one, so things *will* break) This relase is more for reference - yours and mine. Please let me know if you do play with it and have anything interesting to report. Thanks! ken manheimer klm@python.org From akuchlin@cnri.reston.va.us Fri Apr 10 15:39:34 1998 From: akuchlin@cnri.reston.va.us (Andrew Kuchling) Date: Fri, 10 Apr 1998 10:39:34 -0400 (EDT) Subject: [Mailman-developers] Pre-release of new Pipermail version In-Reply-To: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> References: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> Message-ID: <13614.11768.37106.671049@newcnri.cnri.reston.va.us> Following up on Ken's announcement of a Mailman prerelease, I've made a prerelease snapshot of Pipermail 0.05. Hopefully I can do some cleanups and actually write some documentation before finalizing 0.05. You can get the code from . This is the first new release since June '97. It's very, very different from 0.02; here's an except from the README: ====== This is a snapshot of the current code for Pipermail 0.05. It is almost completely different from 0.02. Version 0.02 was simply a script that imitated Hypermail quite closely. The Python SIG archives, however, steered further development, since I wanted to customize the SIG lists in various complicated ways. Pipermail has therefore mutated into an abstract base class (pipermail.T) that provides the skeleton for indexing; you use it by creating a subclass which defines methods to write indexes and format articles. The "hypermail.py" script is intended to be a Hypermail clone with most of Hypermail's features, and it also provides an example of creating a usable subclass of pipermail.T . You could further subclass HypermailFormatter, if desired; I've done this for the Python SIG mailing list archives. In other words, Pipermail isn't a list archiver, though it comes with a useful sample archiver in the form of hypermail.py . Pipermail is, instead, a framework for building your own customized message archivers. ====== -- A.M. Kuchling http://starship.skyport.net/crew/amk/ But the really great eccentrics are all inimitable; they are not possessed by a single oddity; they are, in their deepest selves, unlike the generality of mankind. -- Robertson Davies, "Lewis Carroll in the Theatre" From scott@chronis.icgroup.com Sat Apr 11 17:48:35 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 12:48:35 -0400 Subject: [Mailman-developers] prerelease feedback Message-ID: <19980411124835.50476@chronis.icgroup.com> some notes on the prerelease: atleast one of the wrappers (cgi-wrapper) was seg faulting on my machine (linux2.0.29 on a pentum). i haven't completely traced and fixed the problem yet, all i've done is commented out the check_caller() function call to make it work in the meant time. i'll track this one down more thoroughly early next week. the integration with the archiving is still using pipermail v.02. it's unclear to me whether archiving is going to be done separately (with it's own cron jobs) or called via Archiver.UpdateArchives. i am also unsure by what mechanism private archives are going to be hidden (via cgi password authentication, .htaccess or what). overall, i'd like to say yet again that mailman seems to be developing very quickly and extend thanks to ken and john and andrew. Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Sat Apr 11 17:56:49 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 12:56:49 -0400 Subject: [Mailman-developers] administrative unsubscribing Message-ID: <19980411125649.52233@chronis.icgroup.com> it seems to me like list admins need a more efficient way to (mass-)unsubscribe members than going through them one at a time the same way that a list member would unsubscribe them. some ideas for the interface are: have the mass subscibe box simply full of a list of all subscribers and be able to edit it directly. under member management administrative interface, list all the members with a checkbox allowing the adminstrator to unsubcribe people one click at a time. are there any other ideas for how to do this? if there is a consensus on whether this feature should be added and what the interface should look like, i'll add it to my list of things to implement and get startted next week. scott From klm@python.org Sat Apr 11 18:48:00 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 13:48:00 -0400 (EDT) Subject: [Mailman-developers] administrative unsubscribing In-Reply-To: <19980411125649.52233@chronis.icgroup.com> Message-ID: On Sat, 11 Apr 1998, Scott wrote: > it seems to me like list admins need a more efficient way to > (mass-)unsubscribe members than going through them one at a time the > same way that a list member would unsubscribe them. This is something i've also had in mind. > some ideas for the interface are: > > have the mass subscibe box simply full of a list of all subscribers > and be able to edit it directly. And do some kind of differencing approach, where members that you deleted from the list are deleted, and members that you added are added? My thoughts have been tending to the next option... (I should note that there's another mechanism for doing mass subscriptions which i came to rely on for transferring over my existing lists - mailman/bin/populate_new_list turns out to work better for me. In either case, you have to be careful to clean out extra stuff from the entries - you can't add "klm@python.org (ken manheimer)", for instance.) > under member management administrative interface, list all the members > with a checkbox allowing the adminstrator to unsubcribe people one > click at a time. I would have a table with an entry for each member, including their address and some check buttons, one to disable delivery, one to hide/unhide them, and one to unsubscribe them completely. There's one nuance that i think should be accounted for as well, which makes the setup slightly more elaborate than just that. I think this interface *should* include the members that have set the concealment option for their subscription. However, that means that this interface, itself, should be accessed indirectly from the membership management page, via something that requires the administrator password. Otherwise, non-administrators could visit the admin pages and get to see the concealed folks... This reminds me of a somewhat related area that really needs work - the subscription mechanisms are too basic, at the moment. There are two missing features - actual confirmation of subscription requests (currently that's finagled around), and subscription of forwarding addresses. Let me explain... I've had several requests from subscribers to be able to change their subscription address. Makes sense to me, but it so happens that the current mechanisms for preventing mischievous third-party subscriptions are not up to this. New web-based subscriptions addresses are "confirmed" by prompting an email subscription sent from the subscription address. Well, that's not really confirmation - the web-based subscription attempt isn't recorded or anything, it just prompts the helpful message desribing how to subscribe, basically. Well, i don't think we can use the same trick for subscription address changes, because the old address needs to be removed, as well as adding the new one. And we can't rely on the password for the old address because that doesn't vouch for the authority over creation of the new address - ie, someone could subscribe at their real address in order to get a password that would allow them to subscribe an arbitrary address of their choice. No good. In particular, there is no confirmation tracking done - no database of requests to be resolved against confirmations. We would need something like that to do the subscription transfers, i think. Or at least, i think that would be the right way to do it, particularly since such a mechanism would enable the other big, lacking subscription feature - the ability to subscribe a forwarding address. Ie, some people have a forwarding address at acm.org, but no actual logins there. They would like to be able to subscribe that address, but the current mechanism doesn't allow it - it is constrained to the sender/from fields, because there is no actual confirmation going on, just identification. Anyway, these are some issues i'm hoping to tackle and or yield to others... > are there any other ideas for how to do this? if there is a consensus > on whether this feature should be added and what the interface should > look like, i'll add it to my list of things to implement and get > startted next week. Cool - the membership management stuff is one of the things i had on my list! Ken From scott@chronis.icgroup.com Sat Apr 11 19:01:44 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 14:01:44 -0400 Subject: [Mailman-developers] administrative unsubscribing In-Reply-To: ; from Ken Manheimer on Sat, Apr 11, 1998 at 01:48:00PM -0400 References: <19980411125649.52233@chronis.icgroup.com> Message-ID: <19980411140144.10696@chronis.icgroup.com> OK, i'll get started on this stuff next week. confirmation of subscription requests (allowing forwarding addresses) and an administrator-only accessed list of subscribers in a table with check buttons to change their options/unsubscribe them. Scott On Sat, Apr 11, 1998 at 01:48:00PM -0400, Ken Manheimer wrote: | On Sat, 11 Apr 1998, Scott wrote: | | > it seems to me like list admins need a more efficient way to | > (mass-)unsubscribe members than going through them one at a time the | > same way that a list member would unsubscribe them. | | This is something i've also had in mind. | | > some ideas for the interface are: | > | > have the mass subscibe box simply full of a list of all subscribers | > and be able to edit it directly. | | And do some kind of differencing approach, where members that you | deleted from the list are deleted, and members that you added are added? | My thoughts have been tending to the next option... | | (I should note that there's another mechanism for doing mass | subscriptions which i came to rely on for transferring over my existing | lists - mailman/bin/populate_new_list turns out to work better for me. | In either case, you have to be careful to clean out extra stuff from the | entries - you can't add "klm@python.org (ken manheimer)", for instance.) | | > under member management administrative interface, list all the members | > with a checkbox allowing the adminstrator to unsubcribe people one | > click at a time. | | I would have a table with an entry for each member, including their | address and some check buttons, one to disable delivery, one to | hide/unhide them, and one to unsubscribe them completely. | | There's one nuance that i think should be accounted for as well, which | makes the setup slightly more elaborate than just that. I think this | interface *should* include the members that have set the concealment | option for their subscription. However, that means that this interface, | itself, should be accessed indirectly from the membership management | page, via something that requires the administrator password. | Otherwise, non-administrators could visit the admin pages and get to see | the concealed folks... | | This reminds me of a somewhat related area that really needs work - the | subscription mechanisms are too basic, at the moment. There are two | missing features - actual confirmation of subscription requests | (currently that's finagled around), and subscription of forwarding | addresses. Let me explain... | | I've had several requests from subscribers to be able to change their | subscription address. Makes sense to me, but it so happens that the | current mechanisms for preventing mischievous third-party subscriptions | are not up to this. | | New web-based subscriptions addresses are "confirmed" by prompting an | email subscription sent from the subscription address. Well, that's not | really confirmation - the web-based subscription attempt isn't recorded | or anything, it just prompts the helpful message desribing how to | subscribe, basically. Well, i don't think we can use the same trick for | subscription address changes, because the old address needs to be | removed, as well as adding the new one. And we can't rely on the | password for the old address because that doesn't vouch for the | authority over creation of the new address - ie, someone could subscribe | at their real address in order to get a password that would allow them | to subscribe an arbitrary address of their choice. No good. | | In particular, there is no confirmation tracking done - no database of | requests to be resolved against confirmations. We would need something | like that to do the subscription transfers, i think. Or at least, i | think that would be the right way to do it, particularly since such a | mechanism would enable the other big, lacking subscription feature - the | ability to subscribe a forwarding address. Ie, some people have a | forwarding address at acm.org, but no actual logins there. They would | like to be able to subscribe that address, but the current mechanism | doesn't allow it - it is constrained to the sender/from fields, because | there is no actual confirmation going on, just identification. | | Anyway, these are some issues i'm hoping to tackle and or yield to | others... | | > are there any other ideas for how to do this? if there is a consensus | > on whether this feature should be added and what the interface should | > look like, i'll add it to my list of things to implement and get | > startted next week. | | Cool - the membership management stuff is one of the things i had on my | list! | | Ken | From klm@python.org Sat Apr 11 19:08:32 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 14:08:32 -0400 (EDT) Subject: [Mailman-developers] prerelease feedback In-Reply-To: <19980411124835.50476@chronis.icgroup.com> Message-ID: On Sat, 11 Apr 1998, Scott wrote: > atleast one of the wrappers (cgi-wrapper) was seg faulting on my > machine (linux2.0.29 on a pentum). i haven't completely traced and > fixed the problem yet, all i've done is commented out the > check_caller() function call to make it work in the meant time. i'll > track this one down more thoroughly early next week. Ok. > the integration with the archiving is still using pipermail v.02. > it's unclear to me whether archiving is going to be done separately > (with it's own cron jobs) or called via Archiver.UpdateArchives. i am > also unsure by what mechanism private archives are going to be hidden > (via cgi password authentication, .htaccess or what). I'm not clear exactly what you're saying. My intention was to deprecate but not yet remove all the stuff that implemented the internal pipermail processing. That amounted to commenting out some stuff in mm_archive.py, removing the archive-job entries from the crontab template, and so forth. The actual messages are deposited, using some remaining mm_archive.py methods, in files in either the public or private dirs, according to the configuration settings. Pipermail is supposed to be pointed at the directories, with the private stuff hidden behind a password wrapper, which i'll be including in my final package. (I also added another setgid cgi executable wrapper in the src dir makefile, etc - all of got finally working yesterday, so it's not in the package i sent out thursday eve.) > overall, i'd like to say yet again that mailman seems to be developing > very quickly and extend thanks to ken and john and andrew. Thanks! I'm looking forward to the kind of growth we can get with more contributors. Though that also has me a bit daunted, and had me a bit compulsive trying to polish up one thing or another, so people didn't build on, and lock in, shaky foundations. (Turns out there's never enough you can do about that - there's always going to be some wrong turns taken...) Ken From klm@python.org Sat Apr 11 19:57:54 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 14:57:54 -0400 (EDT) Subject: [Mailman-developers] Treating you shoddily Message-ID: <199804111857.OAA17347@glyph.CNRI.Reston.Va.US> I'm test a delivery to a list with more than a few addresses (not much more), to see whether a slightly drastic measure to deal with a subtle bug scales up. In case you're interested, the problem was with addresses that contain a quote - there's only one instance on all my lists, someone with the last name "O'hara". The single quotes were being lost in the forked sendmail (and/or before that, in the forked deliver script command line). The solution appears to be to apply repr to the addresses before exposing them to the shell. It works on the problematic addresses, and the few addresses i played with on some trial lists, but this is the first try with a middling sized list. And incidentally, one of the near changes is to switch over to direct SMTP acces to the mail delivery agent on the current machine, rather than forking sendmail and exposing the addresses to the command line. John has already provided me with an SMTP class that he's been playing with, but i was shy about diving into that so near to releasing the new version. Ken From klm@python.org Sat Apr 11 20:00:58 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 15:00:58 -0400 (EDT) Subject: [Mailman-developers] Treating you shoddily In-Reply-To: <199804111857.OAA17347@glyph.CNRI.Reston.Va.US> Message-ID: On Sat, 11 Apr 1998, Ken Manheimer wrote: > I'm test a delivery to a list with more than a few addresses (not much > more), to see whether a slightly drastic measure to deal with a subtle > bug scales up. It seems to be fine - i got a copy of the message, and received no bounces notices... Ken From klm@python.org Mon Apr 13 15:49:02 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 10:49:02 -0400 (EDT) Subject: [Mailman-developers] late on new mailman release - soon Message-ID: <199804131449.KAA23491@glyph.CNRI.Reston.Va.US> Well, i've failed on my promise of a full-fledged release of 1.0b2 this weekend - i was within minutes of it (early this morning) when our systems folks had to shutdown the systems for emergency reasons. When i get things recovered here i'll finish it up and make it available - almost certainly later today, at the latest. Ken From klm@python.org Mon Apr 13 21:42:31 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 16:42:31 -0400 (EDT) Subject: [Mailman-developers] Mailman 1.0b2 available Message-ID: <199804132042.QAA25502@glyph.CNRI.Reston.Va.US> Finally, i've got a complete package of mailman 1.0b2 ready for consumption. This has some substantial features beyond friday(?)'s prerelease, particularly support for private archives and fix of a bug handling addresses containing quotes. It also has lots of niggles polished in preparing the release, so i'd strongly suggest using getting this version even if you got the prerelease. Here's the encompassing README. I (in the grand Python tradition - didn't mean to do it, but i can see now how this happens) will be away the rest of this week, for the most part, but may be able to field some immediate problems or whatever tomorrow. Below is the encompassing README - cheers! Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # Distribution README for mailman 1.0b2. This is mailman v1.0b2.0 - probably the first real, full-function beta-level release of V1. In case you don't know, mailman is a maillist management system with full web-based administration and membership interfaces. It is written almost wholly in Python, and nicely extensible. See the README in the mailman directory for more details. To use it, unpack the tar file and move the mailman directory to within ~mailman on your system. See the README in the mailman directory for more details. Mailman was devised by John Viega, who developed it pretty far but lost later versions in a system crash. The current version is based on an early release (1.0b1) that john did which i (ken manheimer) picked up and stashed away, until such time that i could pay attention to it. Turns out i had one of the most recent surviving copies, so it became the basis of the current system. However, that version was in some ways still at the prototype stage, so i've spent some time polishing it up, enough at first to get it running for use with the maillists here at python.org, and perhaps a bit more to get it looking better, easier to use, and a bit more solid. I'd say this release, if not ready for prime time, is ready for general use and development. Below is a list of the major new features added since the original release (1.0b1.1), bugs stomped and still pending, and thoughts about further develpment necessary and/or desirable. For anyone interested in joining in on the development crowd, or just tracking the progress, there's a maillist for you to join (we're considering using mailman to run it - kidding!), mailman-developers@python.org. Visit http://www.python.org/mailman/listinfo/mailman-developers for more info. New Features Web pages much more polished - Better organized, text more finely crafted - Easier, more refined layout - List info and admin interface overviews, enumerate all public lists (via, e.g., http://www.python.org/mailman/listinfo - sans the specific list) - Admin interface broken into sections, with help elaboration for complicated configuration options Maillist Archives - Integrated with a newer, *much* improved, external pipermail - to be found at http://starship.skyport.net/crew/amk/maintained/pipermail.html - Private archives protected with maillist members passwords, cookie-fied. Spam prevention - New spam prevention measures catch most if not all spam without operator intervention or general constraints on who can post to list: require_explicit_destination option imposes hold of any postings that do not have the list name in any of the to or cc header destination addresses. This catches the vast majority of random spam. Other options (forbidden_posters, bounce_matching_headers) provide for filtering of known transgressors. - Option obscure_addresses (default on) causes maillist subscriber lists on the web to be slightly mangled so they're not directly recognizable as email address by web spiders, which might be seeking targets for spammers. Site configuration arrangement organized - in mailman/mailman/modules: - When installing, create a mailman/modules/mm_cfg.py (if there's not one already there), using mm_cfg.py.dist as a template. mm_default.py contains the distributed defaults, including descriptions of the values. mm_cfg.py does a 'from mm_defaults.py import *' to get the distributed defaults. Include settings in mm_cfg.py for any values in mm_defaults.py that need to be customized for your site, after the 'from .. import *'. See mm_cfg.py.dist for more details. Logging - Major operations (subscription, admin approval, bounce, digestification, cgi script failure tracebacks) logged in files using a reliable mechanism - Wrapper executables log authentication complaints via syslog Wrappers - All cgi-script wrapper executables combined in a single source, easier to configure. (Mail and aliases wrappers separate.) List structure version migration - Provision for automatic update of list structures when moving to a new version of the system. See modules/versions.py. Code cleaning - Many more module docstrings, __version__ settings, more function docstrings. - Most unqualified exception catches have been replaced with more finely targeted catches, to avoid concealing bugs. - Lotsa long lines wrapped (pet peeve:). Many Bugs Stomped ----------------- Many bugs stomped. Some memorable ones: - Subscriber addresses containing quotes (eg, Ken_O'Manheimer@python.org) were not properly escaped to survive transmission through shell to sendmail - Specifying a non-existent user for editing user options now complains immediately, rather than presenting a form. - Ad-hoc /tmp log files (which could bollix things if unwritable) gone - User changing from digest to non-digest and vice versa doesn't escape sort order. - Users are not sorted by address, internally - only on presentation - htmlformat.py no longer silently hides bugs in format operations. Instead, unexpected objects show as repr() would - easier to debug, without making htmlformat fragile. - File creation bracketed by proper umask setting to ensure specified file permissions. - Notices are sent for rejections of moderated postings (but not for discarded ones). - Web pages now all have titles. - Duplicate approvals of subscription requests do not lead to duplicate memberships. Pending bugs ------------ - Mime digests a bit feeble - postings containing mime attachments not properly handled - Bounce processing - Turning off bounce processing doesn't? - Turning on non-member-post exclusion doesn't - More generally mm_utils.AddressesMatch() needs to be really thought out. For instance, klm@python.org vs klm@acm.org should be seen as different, but klm@parrot.python.org and klm@larch.python.org and klm@python.org should probably be seen as the same. There may be more criteria... - Bounces of the confirmation notices sent to people attempting web-based subscriptions are, necessarily, directed (via reply-to header) to maillist-request addr, and get mishandled there as unrecognized requests. Not sure how to solve this one short of recognizing bad subscriber addrs before sending out the notice. Pending Developments and Issues ------------------------------- Some modest Pending Refinements: - Use re module everywhere instead of regexp and regsub. - Implement a reasonable administrivia filter for lists (but less likely to misfire than majordomo's) (administrivia is, eg, unsubscribe request mistakenly sent to list posting addr) - Refine any unqualified exception guards to specify target exceptions. - Turn standard mailman exceptions into class exceptions. - Implement cookies (with moderate lifetimes) for user and admin passwords. - Unravel edit-options functionality from cgi/subscribe script - give edit-options a script of its own. (Not imperative, maybe when the bigger project of implementing member profiles is done.) - Relax constraint that everything be installed in /home/mailman. (I'll probably do this for the next release. We can probably use relative paths for most things, particularly the routine sys.path setting in all the python code, and possibly for the wrappers.) - Foolproof list deletion (bin/rmlist) a bit by asking for password (and have list admin or site password work). - Should member deletion be confirmed with email? - Submission of edited user options should return to edit-options page, like admin options pages do. - People mass subscribed on admin form should not require approval, even for closed-subscribe lists. Some bigger Pending Projects - User and Admin Guides - HOWTOs - Developers guide - documentation - Implement email interface to admin commands. - Implement a 'which' mailcmd. (Probably not hard! May be good intro project for someone wading into mailman development.) - Put the admin interface and other things like private subscriber rosters *behind* passwords, like the private archives are. Eg, instead of putting the password box on the listinfo form, have it always be just a regular link to the roster, but then the roster page would be a password page if the roster is private and there's no cookie for it. - Generalize and refine admindb so that pending bounces, subscriptions, etc are stored in the filesystem, nicely catalogued, and the interfaces for handling them (eg, admindb) shows succinct summaries, with links to see the entire things. (I may work on this.) - Develop subscription mechanisms so real confirmation happens, and use that as basis for option to change existing subscription delivery address. (Scott cotton is working on this.) - Deliver by connect to SMTP 25 instead of sendmail. (I'm checking in modules/smtplib.py module john's played with some.) - Robustify aliases handling to not just append entries if they already exist, and ideally, edit existing ones if they need to change. - Implement a real admin/membership-management section, that includes includes hidden subscribers, provides easy perusal and changing of all members (including concealed members) status, including disabling or removal from list. - Implement some automated validation of installation - check for obvious problems with options settings, file access permissions, sendmail hookup, etc. ? Have an implicit list-managers list for every site, which includes all the list managers? - Make listinfo page static, regenerated every time admin options are changed. This will speed up and reduce load for listinfo page loading. More Fundamental, or just more bigger:), Pending Projects - Refine locking to only necessary sections, so there's less room for unnecessary contention. - Implement the system as a persistent server. (John's planning to do this.) - Implement member profiles, using a class. For name, organization, description, etc, and defaults options settings. The lists, themselves, could still have copies of the specific passwords and the compact bitmaps (for the sake of efficiency) for list-specific options like digest/nondigest, but the user could set their default choices - delivery address, password, delivery mode - in their profile. From klm@python.org Mon Apr 13 21:46:52 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 16:46:52 -0400 (EDT) Subject: [Mailman-developers] Release location Message-ID: <199804132046.QAA25554@glyph.CNRI.Reston.Va.US> Daggone it, neglected to say where to find it: ftp://ftp.python.org/pub/python/contrib/Network/mailman.tar.gz Ken From klm@python.org Tue Apr 14 23:10:28 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Apr 1998 18:10:28 -0400 (EDT) Subject: [Mailman-developers] First patch - Message-ID: <199804142210.SAA00520@glyph.CNRI.Reston.Va.US> Here's the first mailman 1.0b2 patch. For messages going to the maillist, a blank line between the message headers and the body was lacking, so if the first line of the body looked like a header (eg, 'http://www.python.org/'!), it would be included among the headers. Here's the checkin message and the patch. You need to apply the patch from the modules directory, if you use 'patch'. Ken .DeliverToList(): Was missing a newline between message headers and body, so initial body lines that looked like header would be incorporated in header. *** mm_deliver.py.1.18 Tue Apr 14 18:01:34 1998 --- mm_deliver.py Tue Apr 14 18:01:34 1998 *************** *** 122,138 **** msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') ! tmp_file.write(string.join(msg.headers,'')) ! # If replys don't go to the list, then they should go to the ! # real sender ! if self.reply_goes_to_list: ! tmp_file.write('Reply-To: %s\n\n' % self.GetListEmail()) ! if header: tmp_file.write(header + '\n') tmp_file.write(self.QuotePeriods(msg.body)) if footer: --- 122,136 ---- msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' + if self.reply_goes_to_list: + msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') + tmp_file.write(string.join(msg.headers,'') + '\n') ! if header: # The *body* header: tmp_file.write(header + '\n') tmp_file.write(self.QuotePeriods(msg.body)) if footer: From scott@chronis.icgroup.com Wed Apr 15 11:31:42 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 06:31:42 -0400 Subject: [Mailman-developers] confirmation of subscriptions Message-ID: <19980415063142.57641@chronis.icgroup.com> i have developed a working confirmation step in the subscription process for mailman. there are some things that should be presented for discussion and or polished up before this addition (hopefully) makes it to the distribution. below i've attached a patch to be applied to files in the mailman/modules directory, and an extra module (mm_pending.py). in addtion, i'll put a distribution of the changed modules/*.py files at ftp://chronis.icgroup.com/pub/mmconfirm.tgz all comments and feedback on the following are most welcome. CHANGE ROSTER: new mm_defaults variable DEFAULT_CONFIRM_SUBSCRIBE the admin/listname/privacy page no longer presents the web_subscribe_requires_confirmation, instead it present a new confirm_subscribe option. the subscribe command now uses the following syntax (backwards compatible): subscribe [arg [arg [arg]]] where can be one of: password, digest|nodigest or address=. anytime the address= is specified, the confirmation step is triggered regardless of list preference. As an administrator of a high volume mailing site, i strongly encourage us to keep it this way. this will also allow users to subscribe with forwarding addresses. there is a new mail command: confirm if the confirmation number represents an outstanding subscribe request that is pending confirmation, then the subscription will take place. TODO: make email interface to unsubscribe address= get totally rid of web_subscribe_requires_confirmation in the code because it is no longer visible check to make sure the address= address is being checked as a valid email address. clean up mm_pending.py with __version__ and stuff. NOTE: i'm getting buggy output of the mm_deliver.SUBSCRIBEACKTEXT, and am not sure if it is the result of any of my changes, though it looks like a bug unrelated to these changes at a glance. Scott ----------------------------------------------------------------------------- PATCH ----------------------------------------------------------------------------- diff -c -r /tmp/mailman/modules/maillist.py ./maillist.py *** /tmp/mailman/modules/maillist.py Sun Apr 12 00:34:01 1998 --- ./maillist.py Wed Apr 15 05:19:56 1998 *************** *** 139,144 **** --- 139,145 ---- self.welcome_msg = '' self.goodbye_msg = '' self.open_subscribe = mm_cfg.DEFAULT_OPEN_SUBSCRIBE + self.confirm_subscribe = mm_cfg.DEFAULT_CONFIRM_SUBSCRIBE self.private_roster = mm_cfg.DEFAULT_PRIVATE_ROSTER self.obscure_addresses = mm_cfg.DEFAULT_OBSCURE_ADDRESSES self.member_posting_only = mm_cfg.DEFAULT_MEMBER_POSTING_ONLY *************** *** 282,297 **** " members are admitted only at the discretion of the list" " administrator."), ! ('web_subscribe_requires_confirmation', mm_cfg.Radio, ! ('None', 'Requestor confirms via email', 'Admin approves'), 0, ! 'What confirmation is required for on-the-web subscribes?', ! ! "This option determines whether web-initiated subscribes" ! " require further confirmation, either from the subscribed" ! " address or from the list administrator. Absence of" ! " any confirmation makes web-based subscription a" ! " tempting opportunity for mischievous subscriptions by third" ! " parties."), "Membership exposure", --- 283,296 ---- " members are admitted only at the discretion of the list" " administrator."), ! ('confirm_subscribe', mm_cfg.Radio, ('No', 'Yes'), 1, ! 'Should subscriptions require confirmation step?', ! ! "This option forces all subscription requests to prompt a verification" ! " message to be sent to the subscribing address, and a response from that" ! " address before subscription takes place. This prevents malicious" ! " folk from (mass) subscribing unconsenting owners of email addresses to" ! " mailing lists."), "Membership exposure", diff -c -r /tmp/mailman/modules/mm_defaults.py ./mm_defaults.py *** /tmp/mailman/modules/mm_defaults.py Mon Apr 13 14:09:27 1998 --- ./mm_defaults.py Wed Apr 15 05:30:58 1998 *************** *** 81,86 **** --- 81,88 ---- DEFAULT_REPLY_GOES_TO_LIST = 0 # Admin approval unnecessary for subscribes? DEFAULT_OPEN_SUBSCRIBE = 1 + # confirm neccesary for subscribes? + DEFAULT_CONFIRM_SUBSCRIBE = 1 # Private_roster == 0: anyone can see, 1: members only, 2: admin only. DEFAULT_PRIVATE_ROSTER = 0 # When exposing members, make them unrecognizable as email addrs. To *************** *** 88,96 **** DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. DEFAULT_MEMBER_POSTING_ONLY = 0 - # 1 for email subscription verification, 2 for admin confirmation: - DEFAULT_WEB_SUBSCRIBE_REQUIRES_CONFIRMATION = 1 - # Digestification Defaults # # Will list be available in non-digested form? --- 90,95 ---- diff -c -r /tmp/mailman/modules/mm_mailcmd.py ./mm_mailcmd.py *** /tmp/mailman/modules/mm_mailcmd.py Thu Apr 9 19:48:30 1998 --- ./mm_mailcmd.py Wed Apr 15 05:28:59 1998 *************** *** 6,12 **** # Not implemented: get / index / which. import string, os, sys ! import mm_message, mm_err, mm_cfg, mm_utils option_descs = { 'digest' : 'receive mail from the list bundled together instead of ' --- 6,12 ---- # Not implemented: get / index / which. import string, os, sys ! import mm_message, mm_err, mm_cfg, mm_utils, mm_pending option_descs = { 'digest' : 'receive mail from the list bundled together instead of ' *************** *** 47,53 **** --- 47,55 ---- 'set' : self.ProcessSetCmd, 'options' : self.ProcessOptionsCmd, 'password' : self.ProcessPasswordCmd, + 'confirm': self.ProcessConfirmCmd } + self.__noMailCmdResponse = 0 def AddToResponse(self, text): self._response_buffer = self._response_buffer + text + "\n" *************** *** 84,90 **** self.AddError("%s: Command UNKNOWN." % cmd) else: self._cmd_dispatch[cmd](args, line, mail) ! self.SendMailCmdResponse(mail) def SendMailCmdResponse(self, mail): self.SendTextToUser(subject = 'Mailman results for %s' % --- 86,93 ---- self.AddError("%s: Command UNKNOWN." % cmd) else: self._cmd_dispatch[cmd](args, line, mail) ! if not self.__noMailCmdResponse: ! self.SendMailCmdResponse(mail) def SendMailCmdResponse(self, mail): self.SendTextToUser(subject = 'Mailman results for %s' % *************** *** 338,386 **** self.AddError("%s %s" % (sys.exc_type, sys.exc_value)) self.AddError("%s" % sys.exc_traceback) def ProcessSubscribeCmd(self, args, cmd, mail): digest = self.digest_is_default if not len(args): password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! elif len(args) == 1: ! if string.lower(args[0]) == 'digest': ! digest = 1 ! password = "%s%s" % (mm_utils.GetRandomSeed(), ! mm_utils.GetRandomSeed()) ! elif string.lower(args[0]) == 'nodigest': ! digest = 0 ! password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! else: ! password = args[0] ! ! elif len(args) == 2: ! if string.lower(args[1]) == 'nodigest': ! digest = 0 ! password = args[0] ! elif string.lower(args[1]) == 'digest': ! digest = 1 ! password = args[0] ! elif string.lower(args[0]) == 'nodigest': ! digest = 0 ! password = args[1] ! elif string.lower(args[0]) == 'digest': ! digest = 1 ! password = args[1] ! else: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return ! elif len(args) > 2: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return try: ! self.AddMember(mail.GetSender(), password, digest) self.AddToResponse("Succeeded.") except mm_err.MMBadEmailError: self.AddError("Email address '%s' not accepted by Mailman." % ! mail.GetSender()) except mm_err.MMMustDigestError: self.AddError("List only accepts digest members.") except mm_err.MMCantDigestError: --- 341,410 ---- self.AddError("%s %s" % (sys.exc_type, sys.exc_value)) self.AddError("%s" % sys.exc_traceback) + + + def ProcessSubscribeCmd(self, args, cmd, mail): digest = self.digest_is_default + password = "" + address = "" + done_digest = 0 if not len(args): password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! elif len(args) > 3: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return ! else: ! for arg in args: ! if string.lower(arg) == 'digest' and not done_digest: ! digest = 1 ! done_digest = 1 ! elif string.lower(arg) == 'nodigest' and not done_digest: ! digest = 0 ! done_digest = 1 ! elif string.lower(arg)[:8] == 'address=' and not address: ! address = string.lower(arg)[8:] ! elif not password: ! password = arg ! else: ! self.AddError("Usage: subscribe [arg [arg [arg]]] where can be\n" ! "\t[password]\n\t[digest|nodigest]\nor" ! "\t[address=]") ! return ! if not password: ! password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! # we don't want people subscribing addresses other than the sender address ! # without an extra confirmation step ! if address or self.confirm_subscribe: ! if not address: ! pending_addr = mail.GetSender() ! else: ! pending_addr = address ! ! cookie = mm_pending.gencookie() ! mm_pending.add2pending(pending_addr, password, digest, cookie) ! self.SendTextToUser(subject = "%s -- confirmation of subscription req. %d" % \ ! (self.real_name, cookie), ! recipient = pending_addr, ! sender = self.GetRequestEmail(), ! text = mm_pending.VERIFY_FMT % ({"email": pending_addr, ! "listaddress": self.GetListEmail(), ! "listname": self.real_name, ! "cookie": cookie, ! "requestor": mail.GetSender()})) ! self.__noMailCmdResponse = 1 ! return ! self.FinishSubscribe(mail.GetSender(), password, digest) + def FinishSubscribe(self, addr, password, digest): try: ! self.AddMember(addr, password, digest) self.AddToResponse("Succeeded.") except mm_err.MMBadEmailError: self.AddError("Email address '%s' not accepted by Mailman." % ! addr) except mm_err.MMMustDigestError: self.AddError("List only accepts digest members.") except mm_err.MMCantDigestError: *************** *** 391,406 **** self.AddApprovalMsg(cmd) except mm_err.MMHostileAddress: self.AddError("Email address '%s' not accepted by Mailman " ! "(insecure address)" % mail.GetSender()) except mm_err.MMAlreadyAMember: ! self.AddError("%s is already a list member." % mail.GetSender()) except: # TODO: Should log the error we got if we got here. self.AddError("An unknown Mailman error occured.") self.AddError("Please forward on your request to %s" % self.GetAdminEmail()) self.AddError("%s" % sys.exc_type) ! def AddApprovalMsg(self, cmd): self.AddError('''Your request to %s: --- 415,451 ---- self.AddApprovalMsg(cmd) except mm_err.MMHostileAddress: self.AddError("Email address '%s' not accepted by Mailman " ! "(insecure address)" % addr) except mm_err.MMAlreadyAMember: ! self.AddError("%s is already a list member." % addr) except: # TODO: Should log the error we got if we got here. self.AddError("An unknown Mailman error occured.") self.AddError("Please forward on your request to %s" % self.GetAdminEmail()) self.AddError("%s" % sys.exc_type) ! ! ! def ProcessConfirmCmd(self, args, cmd, mail): ! if len(args) != 1: ! self.AddError("Usage: confirm \n") ! return ! try: ! cookie = string.atoi(args[0]) ! except: ! self.AddError("Usage: confirm \n") ! return ! pending = mm_pending.get_pending() ! if not pending.has_key(cookie): ! self.AddError("Invalid confirmation number!\n" ! "Please recheck the confirmation number and try again.") ! return ! (email_addr, password, digest, ts) = pending[cookie] ! self.FinishSubscribe(email_addr, password, digest) ! del pending[cookie] ! mm_pending.set_pending(pending) ! ! def AddApprovalMsg(self, cmd): self.AddError('''Your request to %s: ---------------------------------------------------------------------- mm_pending.py ---------------------------------------------------------------------- """ module for handling pending subscriptions """ import os import sys import posixfile import marshal import time import rand import mm_cfg DB_PATH = mm_cfg.MAILMAN_DIR + "/misc/pending_subscriptions.db" LOCK_PATH = mm_cfg.LOCK_DIR + "/pending_subscriptions.lock" VERIFY_FMT = """\ You or someone (%(requestor)s) has requested that your email address (%(email)s) be subscribed to the %(listname)s mailling list at %(listaddress)s. If you wish to fulfill this request, please reply to this message, with the following line, and only the following line in the message body: confirm %(cookie)s If you do not wish to subscribe to this list, please simply ignore or delete this message. """ # ' icky emacs font lock thing def get_pending(): " returns a dict containing pending information" try: fp = open(DB_PATH,"r" ) except IOError: return {} dict = marshal.load(fp) return dict def gencookie(p=None): if p is None: p = get_pending() while 1: newcookie = rand.rand() if p.has_key(newcookie): continue return newcookie def set_pending(p): ou = os.umask(0) try: lock_file = posixfile.open(LOCK_PATH,'a+') finally: os.umask(ou) lock_file.lock('w|', 1) fp = open(DB_PATH, "w") marshal.dump(p, fp) fp.close() lock_file.lock("u") lock_file.close() def add2pending(email_addr, password, digest, cookie): ts = int(time.time()) processed = 0 p = get_pending() p[cookie] = (email_addr, password, digest, ts) set_pending(p) def set_processed(cookie, value): p = get_pending() if p.has_key(cookie): (email_addr, listname, password, digest, processed, ts) = p[cookie] processed = value p[cookie] = (email_addr, listname, password, digest, processed, ts) set_pending(p) else: raise ValueError, "attempt to set processed field in pending to non existent cookie (%d)" % (cookie) From dima@bog.msu.su Wed Apr 15 17:33:45 1998 From: dima@bog.msu.su (Dmitry Khrustalev) Date: Wed, 15 Apr 1998 20:33:45 +0400 (MSD) Subject: [Mailman-developers] Mailman results for Thread-SIG (fwd) Message-ID: I'm getting the following error from mailman: Date: Sat, 4 Apr 1998 12:12:38 -0500 (EST) From: thread-sig-request@python.org To: dima@bog.msu.su Subject: Mailman results for Thread-SIG >>>> subscribe **** Email address 'dima@bog.msu.su' not accepted by Mailman. When trying to use web interface i get: Mailman won't accept the given email address as a valid address. (Does it have an @ in it???) ( address is dima@bog.msu.su ). Can someone look at this problem? -Dima From scott@chronis.icgroup.com Wed Apr 15 23:59:39 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 18:59:39 -0400 Subject: [Mailman-developers] confirmation of subscriptions In-Reply-To: <19980415063142.57641@chronis.icgroup.com>; from Scott on Wed, Apr 15, 1998 at 06:31:42AM -0400 References: <19980415063142.57641@chronis.icgroup.com> Message-ID: <19980415185939.30501@chronis.icgroup.com> some further developments have taken place: the subscribe cgi now uses the confirmation step instead of the old web-confirmation step when confirmations are required for subscription. i'll post more patches and a distribution later tonight. scott On Wed, Apr 15, 1998 at 06:31:42AM -0400, Scott wrote: | | i have developed a working confirmation step in the subscription | process for mailman. From janne@avocado.pc.helsinki.fi Thu Apr 16 00:38:37 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 02:38:37 +0300 Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives Message-ID: I have several minor things: First, when the "reply to the list" option of a list is set, it seems that a potential existing Reply-To: is not (always) stripped off. Instead there will be two Reply-To: headers, one for the list, one from the original sender. I guess this is a bug? Second, here's a working answer_majordomo_mail script. The script in 1.0b12 didn't work for me (the patch would be larger than the script itself, hence I include this here): #!/usr/local/bin/python # This is another script that's really just for my use, but # feel free to use it if you know how... import sys f = open('/dev/null', 'w') sys.stderr = f sys.path.append('/home/mailman/mailman/modules') import mm_message, mm_utils msg = mm_message.IncomingMessage() text = open('/home/mailman/mailman/misc/majordomo.answer.txt', 'r').read() mm_utils.SendTextToUser('Your mail to Majordomo...', text, msg.GetSender(), 'mailman-owner') I would also like to ask about the archives. The README says 'integrated with [...] external pipermail'. :) Besides the links and authorization service provided, what does this mean in practice? Should I run piper-hypermail from a crontab or is there something better around somewhere? -- Janne From scott@chronis.icgroup.com Thu Apr 16 04:09:36 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 23:09:36 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions Message-ID: <19980415230936.53080@chronis.icgroup.com> proposal concerning web based subscriptions: *allways* use confirmation, even if the list doesn't require them via email. If you don't, it's a security hole for any mailing list that doesn't implement it, and for out of service-attacks against the system mailman on which mailman is running. Even if a list is not advertised, it is still vulnerable to this, as an "attacker" could well find out the name of list by other means. it seems that as mailman becomes more widely used, more and more lists will have a problem with this. comments? Scott Cotton IC Group Inc From janne@avocado.pc.helsinki.fi Thu Apr 16 16:46:43 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 18:46:43 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Janne Sinkkonen's message of "16 Apr 1998 02:38:37 +0300" Message-ID: Here's a patch to get rid of extra Re:'s around the beginning of the subject line. I don't know whether this replaces too aggressively or not (I'm testing it on a largish mailing list). Probably not. Another question is that should we have Re: PREFIX .* or PREFIX Re: .* in replies. I'd maybe favor the latter (this is also what the patch implements). *** maillist.py Thu Apr 16 18:38:02 1998 --- maillist.py~ Sun Apr 12 07:34:01 1998 *************** *** 747,763 **** prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! else: ! if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): ! # The subject prefix is there already, possibly with some Re:'s. ! # Take the extra Re:'s away, put one behind prefix. ! prefix_mess_rx=re.compile('^(re:? *)*' + ! re.escape(prefix) + '(re:? *)*', re.I) ! subj=re.sub(prefix_mess_rx, prefix + 'Re: ', subj) ! else: ! # No prefix yet. ! subj=prefix+subj ! msg.SetHeader('Subject', subj) if self.digestable: self.SaveForDigest(msg) --- 747,755 ---- prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), ! subj, re.I): ! msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.digestable: self.SaveForDigest(msg) -- Janne Sinkkonen From janne@avocado.pc.helsinki.fi Thu Apr 16 17:29:57 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 19:29:57 +0300 Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages In-Reply-To: Scott's message of "Wed, 15 Apr 1998 18:59:39 -0400" Message-ID: If the 'reply to list' option is set, mailman seems to put an erroneous 'Reply-To:' header into administrative messages as well, for example to reminders to administrators about pending messages. (Then the administrators discuss what to do, and the discussion goes to the list.) -- Janne Sinkkonen From janne@avocado.pc.helsinki.fi Thu Apr 16 20:57:10 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 22:57:10 +0300 Subject: [Mailman-developers] More polishing... Message-ID: Below is a set of patches to take care of a few bugs. My earlier patch to get rid of extra Re:'s is included in a modified form. Changes: 1. No double Reply-To:'s to list mail. Reply-To:'s in some admin mail still remain. 2. Get rid of extra Re:'s on the subject line. However, leave "Re: PREFIX" instead of "PREFIX Re:" - the latter does not work with some mail readers which use Re: for threading (and there was some strange problems with answering the mail as well). 3. Some people wanted to have Reply-To: in every attachment of a MIME digest (for lists with reply_to_list true). 4. A bug in digest topic section (wrong argument order to ""%(...)) corrected. Some polishing of the header (to make it more useful to the most helpless non-WWW-subscribers). 5. crontab: the right name of the script is senddigests. *** modules/mm_deliver.dist.py Wed Apr 15 20:43:04 1998 --- modules/mm_deliver.py Thu Apr 16 22:16:38 1998 *************** *** 123,128 **** --- 123,131 ---- else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: + # Get rid of old Reply-To: + for item in msg.headers: + if item[0:9] == 'Reply-To:': msg.headers.remove(item) msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) *** modules/maillist.dist.py Sun Apr 12 07:34:01 1998 --- modules/maillist.py Thu Apr 16 21:07:18 1998 *************** *** 747,755 **** prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), ! subj, re.I): ! msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.digestable: self.SaveForDigest(msg) --- 747,763 ---- prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! else: ! if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): ! # The subject prefix is there already, possibly with some Re:'s. ! # Take the extra Re:'s away, put one behind prefix. ! prefix_mess_rx=re.compile('^(re:? *)*' + ! re.escape(prefix) + '(re:? *)*', re.I) ! subj=re.sub(prefix_mess_rx, 'Re: ' + prefix, subj) ! else: ! # No prefix yet. ! subj=prefix+subj ! msg.SetHeader('Subject', subj) if self.digestable: self.SaveForDigest(msg) *** modules/mm_digest.dist.py Thu Apr 16 20:57:13 1998 --- modules/mm_digest.py Thu Apr 16 22:03:10 1998 *************** *** 97,106 **** body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n\n%s" % (self._mime_separator, self.next_post_number, ! fromline, date, subject, body)) self.next_post_number = self.next_post_number + 1 topics_file.close() --- 97,116 ---- body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) + try: + if self.reply_goes_to_list: + maybe_replyto='Reply-To: %s\n' % ( + self.QuoteMime(self.GetListEmail()),) + else: + maybe_replyto='' + except: + self.LogMsg("error", + "mm_digest: tried to include reply-to - not quite") + digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n%s\n%s" % (self._mime_separator, self.next_post_number, ! fromline, date, subject, maybe_replyto, body)) self.next_post_number = self.next_post_number + 1 topics_file.close() *************** *** 185,198 **** Subject: Contents of %s digest, Volume %d #%d Date: %s ! When replying, please edit your Subject line so it is more specific than "Re: Contents of %s digest..." Send %s maillist submissions to %s To subscribe or unsubscribe via the web, visit %s ! or send email to %s Topics for this digest: %s --- 195,210 ---- Subject: Contents of %s digest, Volume %d #%d Date: %s ! When replying, please edit your Subject line to be more specific than just "Re: Contents of %s digest..." Send %s maillist submissions to %s To subscribe or unsubscribe via the web, visit %s ! or send email to ! %s ! A message saying just 'help' (without the quotes) will give you a guide. Topics for this digest: %s *************** *** 200,207 **** msg.GetSender(), self.real_name, self.volume, self.next_digest_number, time.ctime(time.time()), ! self.real_name, self.GetListEmail(), ! self.real_name, self.GetScriptURL('listinfo'), self.GetRequestEmail(), topics_text) --- 212,219 ---- msg.GetSender(), self.real_name, self.volume, self.next_digest_number, time.ctime(time.time()), ! self.real_name, self.real_name, ! self.GetListEmail(), self.GetScriptURL('listinfo'), self.GetRequestEmail(), topics_text) *** cron/crontab.in~ Fri Apr 3 03:16:29 1998 --- cron/crontab.in Thu Apr 16 20:52:38 1998 *************** *** 2,8 **** 0 17 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdbs # # Noon, mail digests for lists that do periodic as well as threshhold delivery. ! 0 12 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdigests # # 5 AM on the first of each month, mail out password reminders. 0 5 1 * * /usr/local/bin/python /home/mailman/mailman/cron/mailpasswds --- 2,8 ---- 0 17 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdbs # # Noon, mail digests for lists that do periodic as well as threshhold delivery. ! 0 12 * * * /usr/local/bin/python /home/mailman/mailman/cron/senddigests # # 5 AM on the first of each month, mail out password reminders. 0 5 1 * * /usr/local/bin/python /home/mailman/mailman/cron/mailpasswds From scott@chronis.icgroup.com Mon Apr 20 00:08:02 1998 From: scott@chronis.icgroup.com (Scott) Date: Sun, 19 Apr 1998 19:08:02 -0400 Subject: [Mailman-developers] small bug with roster (and patch) Message-ID: <19980419190802.25426@chronis.icgroup.com> It seems like cgi/roster was treating lists whose roster subscribers are viewable by members of the list as only viewable by the admin. looks like an indentation error. here's a patch: *** roster Sun Apr 19 19:04:17 1998 --- roster.dist Sun Apr 19 19:05:24 1998 *************** *** 56,66 **** mm_err.MMBadPasswordError): bad = ("%s subscriber authentication failed." % list.real_name) ! else: ! # Anonymous list - admin-only visible ! # - and we already tried admin password, above. ! bad = ("%s admin authentication failed." ! % list.real_name) if bad: doc = error_page_doc(bad) doc.AddItem(list.GetMailmanFooter()) --- 56,66 ---- mm_err.MMBadPasswordError): bad = ("%s subscriber authentication failed." % list.real_name) ! else: ! # Anonymous list - admin-only visible ! # - and we already tried admin password, above. ! bad = ("%s admin authentication failed." ! % list.real_name) if bad: doc = error_page_doc(bad) doc.AddItem(list.GetMailmanFooter()) scott From scott@chronis.icgroup.com Mon Apr 20 12:37:40 1998 From: scott@chronis.icgroup.com (Scott) Date: Mon, 20 Apr 1998 07:37:40 -0400 Subject: [Mailman-developers] membership management developments Message-ID: <19980420073740.52669@chronis.icgroup.com> I have made of number of changes to membership management in my copy of mailman. First, the mass subscribe function now checks the emails, reports any errors found, and reports successfull subscriptions. i changed the error check for emails to demand a host name part, as it seemed to make sense that way. Second, there is a much more succint interface to unsubscribing members and/or changing their options. This section is hidden behind password authentication, but is still part of the "members" category in the admin cgi. to see what these changes look like, please feel free to see http://chronis.icgroup.com/mailman/admin/postal/members (password postal). i think a little more explanation of the member options is in order on the page, but appreciate any and all feedback. Since these changes have taken place after applying a few patches posted here, and i've become a bit confused as to which version is which at this point in time, i'm simply making a tarball snapshot of the modules in the mailman/modules directory and the scripts in the mailman/cgi available at ftp://chronis.icgroup.com/pub/mm_mod+cgi.tgz Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Mon Apr 20 22:06:33 1998 From: scott@chronis.icgroup.com (Scott) Date: Mon, 20 Apr 1998 17:06:33 -0400 Subject: [Mailman-developers] membership management developments In-Reply-To: ; from Janne Sinkkonen on Mon, Apr 20, 1998 at 06:53:50PM +0300 References: <19980420073740.52669@chronis.icgroup.com> Message-ID: <19980420170633.30680@chronis.icgroup.com> On Mon, Apr 20, 1998 at 06:53:50PM +0300, Janne Sinkkonen wrote: | Scott writes: | | > to see what these changes look like, please feel free to see | > http://chronis.icgroup.com/mailman/admin/postal/members (password | > postal). i think a little more explanation of the member options is | > in order on the page, but appreciate any and all feedback. | | Seems great. | | A couple of problems though. I get this when trying to get to the 'privacy | options' page: woops. thanks. lets see, each mailling needs to have an attribute defined (confirm_subscribe). (1= on, 0=off). try this: import mm_utils, maillist for listname in mm_utils.list_names(): list = maillist.MailList(listname) list.confirm_subscribe = 0 # or 1 list.Save() | | Traceback (innermost last): | File "/home/mailman/mailman/cgi/admin", line 682, in ? | main() | File "/home/mailman/mailman/cgi/admin", line 124, in main | FormatConfiguration(doc, list, category, category_suffix, cgi_data) | File "/home/mailman/mailman/cgi/admin", line 256, in FormatConfiguration | form.AddItem(FormatOptionsSection(category, list, cgi_data)) | File "/home/mailman/mailman/cgi/admin", line 305, in FormatOptionsSection | big_table.AddRow(GetGuiItem(item, category, list)) | File "/home/mailman/mailman/cgi/admin", line 372, in GetGuiItem | gui_part = RadioButtonArray(varname, params, getattr(list, varname)) | AttributeError: confirm_subscribe | | | Another problem is that with a large mailing list, Netscape draws the | members page with all the options switch very very slowly (making the | page useless, actually). i anticipated as much, and will be working on making it separate the list mmebers table into chunks if the list is large enough over the next few days. One problem that will need to be solved in this respect is authentication. Is it too annoying to require the password for viewing each chunk? is it acceptable to use cookies for authentication of this section? what should the cutoff size of the list be for chunkifying the section? thanks for your feedback Scott From scott@chronis.icgroup.com Thu Apr 16 03:20:37 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 22:20:37 -0400 Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: ; from Janne Sinkkonen on Thu, Apr 16, 1998 at 02:38:37AM +0300 References: Message-ID: <19980415222037.22717@chronis.icgroup.com> On Thu, Apr 16, 1998 at 02:38:37AM +0300, Janne Sinkkonen wrote: | | I have several minor things: [...] | I would also like to ask about the archives. The README says | 'integrated with [...] external pipermail'. :) Besides the links and | authorization service provided, what does this mean in practice? | Should I run piper-hypermail from a crontab or is there something | better around somewhere? Not that i know of. It's honestly taken me about as long to get private archiving working on a list on my system as it did to develop the confirmation step in subscribing. I don't doubt that mailman and pipermail should be separate packages, but it sure would be nice to have drop-in archiving available with the new pipermail. From what i understand, this would probably involve writing a custom archiving class from the pipermail.T class, that deals with archive volume incrementing and can present a cgi interface to the list admin. any takers? Scott From klm@python.org Mon Apr 20 23:43:24 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 20 Apr 1998 18:43:24 -0400 (EDT) Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: <19980415222037.22717@chronis.icgroup.com> Message-ID: (I probably should have first posted a note mentioning that i was approving a posting of scott's that was held due to not explicitly mentioning the mailman-developer's list name among the recipients - that's why his 5 day old posting just showed... Ken.) From janne@avocado.pc.helsinki.fi Tue Apr 21 12:28:48 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 21 Apr 1998 14:28:48 +0300 Subject: [Mailman-developers] Mailer daemons on the list Message-ID: I found two mailer daemons from my mailing list. Not good. :) Here's a theory of how they ended up there: somebody has sent a 'help' to the list-request address. Mailman has replied, but for some reason the reply address has been dysfunctional. The mailer daemon then sends a bounce to the list-request address with the help message in an attachment. mailman processes the message, finds 'subscribe' in there, and subscribes. Would it be possible to include some kind of tag or cookie (maybe an X header) in the outgoing messages? We could then search every incoming request message for the tag, and if we find one, we would then know the history of the message. -- Janne From scott@chronis.icgroup.com Tue Apr 21 16:59:27 1998 From: scott@chronis.icgroup.com (Scott) Date: Tue, 21 Apr 1998 11:59:27 -0400 Subject: [Mailman-developers] membership management developments: chunkifying Message-ID: <19980421115927.08362@chronis.icgroup.com> i have somehow managed to get the membership management section chunkified, with proper authentication. there is a new variable in mm_defaults called DEFAULT_CHUNK_SIZE, which as commented sets the size of the chunk of members presented at a time to admins editing their options/ unsubscribing them. this section of membership management uses cookie authentication. As Authentication is getting particulary messy in the program cgi/admin, i wouldn't suggest (m)any futher develops that involve special authentication without rewriting the script from the bottom up. anyway, here is a patch, as applied against the distribution version that i posted about the other day that does an improved job of membership management stuff. scott Index: cgi/admin =================================================================== RCS file: /usr/local/cvsroot/mailman/cgi/admin,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 admin *** admin 1998/04/21 03:27:57 1.1.1.1 --- admin 1998/04/21 15:45:15 *************** *** 9,17 **** --- 9,20 ---- import sys sys.path.append('/home/mailman/mailman/modules') + # XXX need to fix this, this directory should be configurable. + sys.path.append('/home/mailman/cgi-bin') import os, cgi, string, crypt, types import mm_utils, maillist, mm_cfg, mm_err from htmlformat import * + import Cookie try: sys.stderr = mm_utils.StampedLogger("error", label = 'admin', *************** *** 27,32 **** --- 30,38 ---- ('bounce', "Bounce Options"), ('archive', "Archival Options")] + # + # XXX this this data is also in mm_mailcmd (i think), it should become shared + # option_info = { 'digest' : 0, 'nomail' : mm_cfg.DisableDelivery, 'norcv' : mm_cfg.DontReceiveOwnPosts, *************** *** 36,42 **** } - def main(): """Process and produce list options form. --- 42,47 ---- *************** *** 80,86 **** FormatOptionHelp(doc, cgi_data['VARHELP'].value, list) print doc.Format(bgcolor="#ffffff") return ! if not cgi_data.has_key('adminpw'): AddErrorMessage(doc, 'Error: You must supply the admin password to' ' change options.') --- 85,125 ---- FormatOptionHelp(doc, cgi_data['VARHELP'].value, list) print doc.Format(bgcolor="#ffffff") return ! if cgi_data.has_key('adminpw') and cgi_data.has_key('edit_members'): ! adminpw = cgi_data["adminpw"] ! if type(adminpw) is type([]): ! adminpw = adminpw[0].value # use the first one, i guess -scott cotton ! else: ! adminpw = adminpw.value ! try: ! list.ConfirmAdminPassword(adminpw) ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! c = Cookie.Cookie() ! c[list.real_name] = hash(list.real_name) ! print c ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 1) ! print doc.Format(bgcolor="#ffffff") ! return ! elif cgi_data.has_key('chunk'): ! if os.environ.has_key("HTTP_COOKIE"): ! cookie = Cookie.Cookie(os.environ["HTTP_COOKIE"]) ! if cookie.has_key(list.real_name): ! if cookie[list.real_name].value == hash(list.real_name): ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! print doc.Format(bgcolor="#ffffff") ! return ! else: ! AddErrorMessage(doc, "Error: Invalid Cookie value") ! else: ! AddErrorMessage(doc, "Error, no cookie for list!") ! else: ! AddErrorMessage(doc, "no cookie!") ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) ! print doc.Format(bgcolor="#ffffff") ! return ! elif not cgi_data.has_key('adminpw') : AddErrorMessage(doc, 'Error: You must supply the admin password to' ' change options.') *************** *** 90,103 **** adminpw = adminpw[0].value # use the first one, i guess -scott cotton else: adminpw = adminpw.value ! try: list.ConfirmAdminPassword(adminpw) ! ChangeOptions(list, category, cgi_data, doc) # Yuck. This shouldn't need to be here. WTF?!? ! if not list.digestable and not list.nondigestable: list.nondigestable = 1 ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') if not list.digestable and len(list.digest_members): AddErrorMessage(doc, --- 129,142 ---- adminpw = adminpw[0].value # use the first one, i guess -scott cotton else: adminpw = adminpw.value ! try: list.ConfirmAdminPassword(adminpw) ! ChangeOptions(list, category, cgi_data, doc) # Yuck. This shouldn't need to be here. WTF?!? ! if not list.digestable and not list.nondigestable: list.nondigestable = 1 ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') if not list.digestable and len(list.digest_members): AddErrorMessage(doc, *************** *** 121,127 **** ' (does it have the colon?)
    %s
', line) ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) print doc.Format(bgcolor="#ffffff") finally: --- 160,169 ---- ' (does it have the colon?)
    %s
', line) ! if cgi_data.has_key('edit_member_options'): # passwd already checked ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! else: ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) print doc.Format(bgcolor="#ffffff") finally: *************** *** 204,210 **** print doc.Format(bgcolor="#ffffff") ! def FormatConfiguration(doc, list, category, category_suffix, cgi_data): """Produce the overall doc, *except* any processing error messages.""" for k, v in CATEGORIES: if k == category: label = v --- 246,252 ---- print doc.Format(bgcolor="#ffffff") ! def FormatConfiguration(doc, list, category, category_suffix, cgi_data, front_page=1): """Produce the overall doc, *except* any processing error messages.""" for k, v in CATEGORIES: if k == category: label = v *************** *** 253,269 **** " bottom. (You can also change your password there," " as well.)

") ! form.AddItem(FormatOptionsSection(category, list, cgi_data)) form.AddItem(Center(FormatPasswordStuff())) form.AddItem(list.GetMailmanFooter()) ! def FormatOptionsSection(category, list, cgi_data): """Produce the category-specific options table.""" if category == 'members': # Special case for members section. ! return FormatMembershipOptions(list, cgi_data) options = GetConfigOptions(list, category) big_table = Table(cellspacing=3, cellpadding=4) --- 295,311 ---- " bottom. (You can also change your password there," " as well.)

") ! form.AddItem(FormatOptionsSection(category, list, cgi_data, front_page)) form.AddItem(Center(FormatPasswordStuff())) form.AddItem(list.GetMailmanFooter()) ! def FormatOptionsSection(category, list, cgi_data, front_page): """Produce the category-specific options table.""" if category == 'members': # Special case for members section. ! return FormatMembershipOptions(list, cgi_data, front_page) options = GetConfigOptions(list, category) big_table = Table(cellspacing=3, cellpadding=4) *************** *** 398,404 **** descr = descr + "" return [descr, gui_part] ! def FormatMembershipOptions(list, cgi_data, option_info=option_info): container = Container() header = Table(width="100%") header.AddRow([Center(Header(2, "Membership Management"))]) --- 440,446 ---- descr = descr + "" return [descr, gui_part] ! def FormatMembershipOptions(list, cgi_data, front_page=1, option_info=option_info): container = Container() header = Table(width="100%") header.AddRow([Center(Header(2, "Membership Management"))]) *************** *** 408,428 **** header.AddCellInfo(max(header.GetCurrentRowIndex(), 0), 0, colspan=2, bgcolor ="#FFF0D0") container.AddItem(header) ! if cgi_data.has_key("adminpw"): ! adminpw = cgi_data["adminpw"] ! if type(adminpw) is type([]): # admin password specified more than once ! adminpw = adminpw[0].value # use the first one, i guess ! else: ! adminpw = adminpw.value ! try: ! list.ConfirmAdminPassword(adminpw) ! confirmed = 1 ! except (mm_err.MMBadPasswordError): ! confirmed = 0 ! else: ! confirmed = 0 ! if not cgi_data.has_key('edit_members') or (cgi_data.has_key('edit_members') and ! not confirmed): container.AddItem(Center('\n

To Unsubscribe Members or Edit their Options...

')) container.AddItem(Center(""" Enter the adminitrative password: --- 450,456 ---- header.AddCellInfo(max(header.GetCurrentRowIndex(), 0), 0, colspan=2, bgcolor ="#FFF0D0") container.AddItem(header) ! if front_page: container.AddItem(Center('\n

To Unsubscribe Members or Edit their Options...

')) container.AddItem(Center(""" Enter the adminitrative password: *************** *** 435,465 **** else: user_table = Table(width="90%") digest_user_table = Table(width="90%") ! user_table.AddRow([Center(Header(4, "Members"))]) user_table.AddCellInfo(user_table.GetCurrentRowIndex(), user_table.GetCurrentCellIndex(), bgcolor="#cccccc", colspan=8) for member in list.members: ! cells = [member, ! "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), ! "digest " + CheckBox(member+"_digest", "off").Format(), ! ] ! for opt in ("hide", "nomail", "ack", "norcv", "plain"): ! if list.GetUserOption(member, option_info[opt]): ! value = "on" ! checked = 1 ! else: ! value = "off" ! checked = 0 ! box = CheckBox("%s_%s" % (member, opt), value, checked) ! cells.append("%s %s" % (opt, box.Format())) ! user_table.AddRow(cells) for member in list.digest_members: ! cells = [member, "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), - "digest " + CheckBox(member+"_digest", "on", 1).Format(), ] for opt in ("hide", "nomail", "ack", "norcv", "plain"): if list.GetUserOption(member, option_info[opt]): value = "on" --- 463,508 ---- else: user_table = Table(width="90%") digest_user_table = Table(width="90%") ! user_table.AddRow([Center(Header(4, "Membership List"))]) user_table.AddCellInfo(user_table.GetCurrentRowIndex(), user_table.GetCurrentCellIndex(), bgcolor="#cccccc", colspan=8) + members = {} + digests = {} for member in list.members: ! members[member] = 1 for member in list.digest_members: ! digests[member] = 1 ! all = list.members + list.digest_members ! if len(all) > mm_cfg.DEFAULT_CHUNK_SIZE: ! chunks = mm_utils.chunkify(all) ! if not cgi_data.has_key("chunk"): ! chunk = 0 ! else: ! chunk = string.atoi(cgi_data["chunk"].value) ! all = chunks[chunk] ! footer = ("

To View other sections, click on the appropriate range listed below") ! chunk_indices = range(len(chunks)) ! chunk_indices.remove(chunk) ! buttons = [] ! pi = os.environ["PATH_INFO"] ! for ci in chunk_indices: ! start, end = chunks[ci][0], chunks[ci][-1] ! buttons.append(" from %s to %s " % ( pi, ci, start, end)) ! buttons = apply(UnorderedList, tuple(buttons)) ! footer = footer + buttons.Format() + "

" ! else: ! all.sort() ! footer = "

" ! for member in all: ! cells = [member + "" % (member), "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), ] + if members.get(member): + cells.append("digest " + CheckBox(member + "_digest", "off", 0).Format()) + else: + cells.append("digest " + CheckBox(member + "_digest", "on", 1).Format()) for opt in ("hide", "nomail", "ack", "norcv", "plain"): if list.GetUserOption(member, option_info[opt]): value = "on" *************** *** 471,483 **** cells.append("%s %s" % (opt, box.Format())) user_table.AddRow(cells) container.AddItem(Center(user_table)) # trigger member list viewing again and change_options with hidden tags... # password authentication is still done, so this should be safe ! container.AddItem("" ! "

") ! container.AddItem("Back to Mass Subscribing

" % \ ! (list.real_name)) ! return container def FormatPasswordStuff(): --- 514,529 ---- cells.append("%s %s" % (opt, box.Format())) user_table.AddRow(cells) container.AddItem(Center(user_table)) + t = Table(width="90%") + t.AddRow([Center(Header(4, "Back to Mass Subscriptions" % list.real_name))]) + t.AddCellInfo(t.GetCurrentRowIndex(), + t.GetCurrentCellIndex(), + bgcolor="#cccccc", colspan=8) + container.AddItem(Center(t)) + container.AddItem(footer) # trigger member list viewing again and change_options with hidden tags... # password authentication is still done, so this should be safe ! container.AddItem("") return container def FormatPasswordStuff(): *************** *** 590,620 **** if getattr(list, property) != value: setattr(list, property, value) dirty = 1 - elif cgi_info.has_key('edit_member_options'): - members = [] - digest_members = [] - org_user_opts = list.user_options.copy() - for member in (list.members + list.digest_members)[:]: - if not cgi_info.has_key(member + "_subscribed"): - list.DeleteMember(member, "cgi: admin/members") - continue - if not cgi_info.has_key(member + "_digest"): # no digest - members.append(member) - else: - digest_members.append(member) - for opt in ("hide", "nomail", "ack", "norcv", "plain"): - if cgi_info.has_key("%s_%s" % (member, opt)): - list.SetUserOption(member, option_info[opt], 1) - else: - list.SetUserOption(member, option_info[opt], 0) - if (list.user_options != org_user_opts): - dirty = 1 - if list.members != members: - list.members = members - dirty = 1 - if list.digest_members != digest_members: - list.digest_members = digest_members - dirty = 1 elif cgi_info.has_key('subscribees'): name_text = cgi_info['subscribees'].value name_text = string.replace(name_text, '\r', '') --- 636,641 ---- *************** *** 644,649 **** --- 665,705 ---- items = map(lambda x: "%s -- %s" % (x[0], x[1]), subscribe_errors) document.AddItem(apply(UnorderedList, tuple((items)))) document.AddItem("

") + elif cgi_info.has_key("user"): + user = cgi_info["user"] + if type(user) is type([]): + users = [] + for ui in range(len(user)): + users.append(user[ui].value) + else: + users = [user.value] + for user in users: + if not cgi_info.has_key('%s_subscribed' % (user)): + list.DeleteMember(user) + dirty = 1 + continue + if not cgi_info.has_key("%s_digest" % (user)): + if user in list.digest_members: + list.digest_members.remove(user) + dirty = 1 + if user not in list.members: + list.members.append(user) + dirty = 1 + else: + if user not in list.digest_members: + list.digest_members.append(user) + dirty = 1 + if user in list.members: + list.members.remove(user) + dirty = 1 + + for opt in ("hide", "nomail", "ack", "norcv", "plain"): + if cgi_info.has_key("%s_%s" % (user, opt)): + list.SetUserOption(user, option_info[opt], 1) + dirty = 1 + else: + list.SetUserOption(user, option_info[opt], 0) + dirty = 1 if cgi_info.has_key('newpw'): if cgi_info.has_key('confirmpw'): new = cgi_info['newpw'].value *************** *** 661,667 **** m = 'Error: You must type in your new password twice.' document.AddItem( Header(3, Italic(FontAttr(m, color="ff5060")))) ! if dirty: list.Save() --- 717,723 ---- m = 'Error: You must type in your new password twice.' document.AddItem( Header(3, Italic(FontAttr(m, color="ff5060")))) ! if dirty: list.Save() Index: modules/mm_defaults.py =================================================================== RCS file: /usr/local/cvsroot/mailman/modules/mm_defaults.py,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 mm_defaults.py *** mm_defaults.py 1998/04/21 03:27:58 1.1.1.1 --- mm_defaults.py 1998/04/21 15:52:05 *************** *** 37,42 **** --- 37,48 ---- HOME_PAGE = 'index.html' MAILMAN_OWNER = 'mailman-owner@%s' % DEFAULT_HOST_NAME + # + # break up presentation of editing member options under admin/listname/members + # into chunks of this size. + # + DEFAULT_CHUNK_SIZE=20 + # System ceiling on number of batches into which deliveries are divided: MAX_SPAWNS = 40 Index: modules/mm_utils.py =================================================================== RCS file: /usr/local/cvsroot/mailman/modules/mm_utils.py,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 mm_utils.py *** mm_utils.py 1998/04/21 03:27:58 1.1.1.1 --- mm_utils.py 1998/04/21 08:27:54 *************** *** 394,400 **** --- 394,418 ---- Logger.write(self, l) + def chunkify(members, chunksize=mm_cfg.DEFAULT_CHUNK_SIZE): + """ + return a list of lists of members + """ + members.sort() + res = [] + while 1: + if not members: + break + chunk = members[:chunksize] + res.append(chunk) + members = members[chunksize:] + return res + + + + + From klm@python.org Thu Apr 23 15:45:34 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 10:45:34 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: Message-ID: On Thu, 23 Apr 1998, Dmitry Khrustalev wrote: > Can the person responsible for python.org mailing lists fix mailman so it > will understand .su TLD (add "su" to valid_toplevels at > modules/mm_utils.py line 16)? > > I tried contacting postmaster@python.org and mailman list, but have not > heard back for several weeks. I've added it in. Sorry about the non-acknowledgement of your pleas for help - looking back through my inbox i see that your complaints arrived here last wednesday, the fifteenth, just when i left for around a week vacation - and i hadn't gotten to them when i returned. My apologies for missing it. Furthermore, i do have some questions about the strategy of qualifying registration addresses according to matches against a static list of known top level domains - i'd be interested to hear input about this on the mailman-developers list... Finally, dmitry, thanks for going so far as to track down the specific changes that needed to be done - that was beyond the call of duty. Sorry that this got in the way of participating in the python.org mailing lists! Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From guido@CNRI.Reston.Va.US Thu Apr 23 15:56:05 1998 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 23 Apr 1998 10:56:05 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: Your message of "Thu, 23 Apr 1998 10:45:34 EDT." References: Message-ID: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Ken writes: > Furthermore, i do have some questions about the strategy of qualifying > registration addresses according to matches against a static list of > known top level domains - i'd be interested to hear input about this on > the mailman-developers list... I think this is bogus; as Dmitri's mail shows it is a maintenance nightmare waiting to happen. If you really want to do a validation of an email address, use DNS to see if there's a host by that name or an MX record for that domain. What is the reason for validating addresses in the first place? If the address is invalid, the mail will bounce and the user won't be registered. Simple. Effective. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Apr 23 16:07:59 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 23 Apr 1998 11:07:59 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <13631.22799.878382.457222@anthem.CNRI.Reston.Va.US> >>>>> "Guido" == Guido van Rossum writes: Guido> I think this is bogus; as Dmitri's mail shows it is a Guido> maintenance nightmare waiting to happen. If you really Guido> want to do a validation of an email address, use DNS to see Guido> if there's a host by that name or an MX record for that Guido> domain. What is the reason for validating addresses in the Guido> first place? If the address is invalid, the mail will Guido> bounce and the user won't be registered. Simple. Guido> Effective. I agree with Guido on all counts. TLD's probably don't change that often, but if they do, you'll have to propagate changes to everyone who's running MM. That's DNS's job! -Barry From roy@endeavor.med.nyu.edu Thu Apr 23 16:14:00 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Thu, 23 Apr 1998 11:14:00 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <585634.3102318840@qwerky.med.nyu.edu> "Barry A. Warsaw" wrote: > TLD's probably don't change that often Didn't they just open up two more (.to and .cc) recently? I absolutely agree, taking any information in the DNS and committing it to a static file is a recipie for disaster in the long-term. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From klm@python.org Thu Apr 23 16:22:06 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 11:22:06 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: On Thu, 23 Apr 1998, Guido van Rossum wrote: > Ken writes: > > > Furthermore, i do have some questions about the strategy of qualifying > > registration addresses according to matches against a static list of > > known top level domains - i'd be interested to hear input about this on > > the mailman-developers list... > > I think this is bogus; as Dmitri's mail shows it is a maintenance > nightmare waiting to happen. If you really want to do a validation of > an email address, use DNS to see if there's a host by that name or an > MX record for that domain. What is the reason for validating > addresses in the first place? If the address is invalid, the mail > will bounce and the user won't be registered. Simple. Effective. While i'm inclined to agree about the list-of-known-domains check being too maintenance intensive, i do see a reason to have the check in the first place. The benefit comes into play when the web interface is in play - the user is there, and can get definite feedback about faulty addresses. Without it, they only see address failures as the absence of any subscription confirmation - a decidedly vague and uncertain kind of feedback. At this point i'm inclined to withdraw the known-domains criterion, but leave in the more definite, unchanging criterion, like presence of an '@' sign. Ken From jtv2j@cs.virginia.edu Thu Apr 23 17:17:40 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 23 Apr 1998 12:17:40 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804231617.MAA13842@adder.cs.Virginia.EDU> Oh, wow, I can not believe I ever left that code in anything I ever passed out. That was added in the first day before I put any real thought into authorization. My apologies for anyone it inconvenienced. From scott@chronis.pobox.com Thu Apr 23 18:18:45 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 13:18:45 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: ; from Ken Manheimer on Thu, Apr 23, 1998 at 11:22:06AM -0400 References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <19980423131845.48270@chronis.icgroup.com> On Thu, Apr 23, 1998 at 11:22:06AM -0400, Ken Manheimer wrote: | On Thu, 23 Apr 1998, Guido van Rossum wrote: | | > Ken writes: | > [...] | At this point i'm inclined to withdraw the known-domains criterion, but | leave in the more definite, unchanging criterion, like presence of an | '@' sign. | | Ken sounds good. maybe make sure there's atleast a dot in there to signify a FQDN. scott From klm@python.org Fri Apr 24 00:10:05 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:10:05 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <19980415230936.53080@chronis.icgroup.com> Message-ID: Hi, all. I'm finally getting my head back to the surface after returning, and starting to catch up on some of the mailman comments and developments. I also have some new items of my own to throw in the mix. On Wed, 15 Apr 1998, Scott wrote: > proposal concerning web based subscriptions: > > *allways* use confirmation, even if the list doesn't require them via > email. I'm a little confused about what you're saying. By "even if the list doesn't require them via email", are you referring to the admin approval option? Are you basically saying, don't allow the option of unconfirmed subscriptions? If so, i'm not sure what i think of this. I can see how it would usually be the right thing (tm) to require some kind of confirmation - currently either email from the user or administrator approval. To some degree, allowing unconfirmed subscriptions can amount to being a bad neighbor. It reminds me of the gun debate - how much should we protect people from each other. ("Guns don't kiss people, people kiss people." Or something:-) I guess the question is, are there valid reasons to have lists that take wholly unconfirmed subscriptions? If we're confident there aren't any lurking around the corner, then fine, lets close that door. > If you don't, it's a security hole for any mailing list that doesn't > implement it, and for out of service-attacks against the system > mailman on which mailman is running. Even if a list is not advertised, > it is still vulnerable to this, as an "attacker" could well find out > the name of list by other means. Well, it does occur to me that a list that allows unconfirmed subscriptions but also requires membership for posting privilege would not be susceptable in the simple way to denial-of-service attacks. Along related lines, it does occur to me that we should prevent mail loops, where either the list is subscribed to itself, or where some reflector loops back to the list. (The former situation was hinted at this afternoon, when someone accidentally specified the matrix-sig as their address for subscription *to* matrix-sig list; all it did was post the subscription instructions to the list, but it would have subscribed the list to itself if there was no confirmation...) What i'm doing is adding a header, "X-BeenThere: ", which will be detected and cause a hold of the message for approval, if encountered. Ken From klm@python.org Fri Apr 24 00:25:55 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:25:55 -0400 (EDT) Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: Message-ID: On 16 Apr 1998, Janne Sinkkonen wrote: > Second, here's a working answer_majordomo_mail script. The script in > 1.0b12 didn't work for me (the patch would be larger than the script > itself, hence I include this here): Included below is about what you suggested, but with what i would like to see as canonical provision for logging in mailman scripts. (Any of the scripts that i actually concentrated on have this provision, instead of the hard-wired - and failure prone - file logging.) > I would also like to ask about the archives. The README says > 'integrated with [...] external pipermail'. :) Besides the links and > authorization service provided, what does this mean in practice? > Should I run piper-hypermail from a crontab or is there something > better around somewhere? Perhaps i got a bit carried away with marketing speak. The idea is exactly that - run pipermail (or whatever archiver you want) externally, eg from crontab. Someone i know is planning to run an archiver that revises the archive as each new message comes in, but if you're using something, like pipermail, that watches a file for changes, then setting private or public archives will place the mbox file in the respective archives directory, which is the way the distinction is communicated to the external archiver. (I suppose an X-header could be added to private-archive messages, for the benefit of recipient-based archivers. Does that make sense? I'm a bit worried about sending out messages that are increasingly header heavy - adding a header seems to offer a solution to lots of problems...-) My slightly different version of answer_majordomo_mail is included below my sig. Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # Thanks for joining the PSA! # # http://www.python.org/psa/ # #!/usr/local/bin/python # This is another script that's really just for my use, but # feel free to use it if you know how... import sys sys.path.append('/home/mailman/mailman/modules') import mm_message, mm_utils try: sys.stderr = mm_utils.StampedLogger("error", label = 'answer_majordomo_mail', manual_reprime=1) except IOError: pass # Oh well - SOL on redirect, errors show thru. msg = mm_message.IncomingMessage() text = open('/home/mailman/mailman/misc/majordomo.answer.txt', 'r').read() mm_utils.SendTextToUser('Your mail to Majordomo...', text, msg.GetSender(), 'mailman-owner') From klm@python.org Fri Apr 24 00:31:39 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:31:39 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Message-ID: Janne, can you recap your current thinking about the right thing to do about the "Re:" handling w.r.t. the subject line prefix? I gather we don't want to move the "Re:" to after the prefix, because it will interfere with some MUA's thread recognition - and given that, i don't see what more there is to be done... Ken From klm@python.org Fri Apr 24 00:47:50 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:47:50 -0400 (EDT) Subject: [Mailman-developers] More polishing... In-Reply-To: Message-ID: Here's my incorporations of some of janne's patches. On 16 Apr 1998, Janne Sinkkonen wrote: > Below is a set of patches to take care of a few bugs. My earlier patch > to get rid of extra Re:'s is included in a modified form. > > Changes: > 1. No double Reply-To:'s to list mail. Reply-To:'s in some admin mail > still remain. I used "del msg['reply-to']" instead of iterating over the headers. (I had neglected to change some examples just above the added line that do the iteration, so it makes sense that's what you'd do. They're also changed in my version of the patch.) > 2. Get rid of extra Re:'s on the subject line. However, leave > "Re: PREFIX" instead of "PREFIX Re:" - the latter does not work > with some mail readers which use Re: for threading (and there was > some strange problems with answering the mail as well). I'm not doing anything with this one. I don't think mailman should trim extra "Re:"s that someone else added, mailman just should avoid adding extra ones, itself. > 3. Some people wanted to have Reply-To: in every attachment > of a MIME digest (for lists with reply_to_list true). I have implemented just about what you did, *but* i avoided using an unqualified "except" clause. Unqualified except clauses are often evil - they tend to hide bugs, like taking a pain killer to battle heart disease, it's almost always better to see the symptoms. > 4. A bug in digest topic section (wrong argument order to ""%(...)) > corrected. Some polishing of the header (to make it more > useful to the most helpless non-WWW-subscribers). I already put out a patch for the problem (which you had pointed out) on the ftp site - but had different or no polishings. I'll incorporate them soon. > 5. crontab: the right name of the script is senddigests. Whoops! Thanks. Ken ** I hope i got the order of the patch files right! Please double check before applying... ** Index: mm_deliver.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_deliver.py,v retrieving revision 1.20 diff -c -r1.20 mm_deliver.py *** mm_deliver.py 1998/04/15 02:53:01 1.20 --- mm_deliver.py 1998/04/23 23:40:24 *************** *** 113,128 **** if remove_to: # Writing to a file is better than waiting for sendmail to exit tempfile.template = tmpfile_prefix +'mailman-digest.' ! for item in msg.headers: ! if (item[0:3] == 'To:' or ! item[0:5] == 'X-To:'): ! msg.headers.remove(item) msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') --- 113,128 ---- if remove_to: # Writing to a file is better than waiting for sendmail to exit tempfile.template = tmpfile_prefix +'mailman-digest.' ! del msg['to'] ! del msg['x-to'] msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: + del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) + msg.headers.append('X-BeenThere: %s\n' % self.GetListEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') Index: mm_digest.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_digest.py,v retrieving revision 1.18 diff -c -r1.18 mm_digest.py *** mm_digest.py 1998/04/22 16:33:39 1.18 --- mm_digest.py 1998/04/23 22:27:00 *************** *** 97,107 **** body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) ! digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n\n%s" % ! (self._mime_separator, self.next_post_number, ! fromline, date, subject, ! body)) self.next_post_number = self.next_post_number + 1 topics_file.close() digest_file.close() --- 97,112 ---- body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) ! if self.reply_goes_to_list: ! maybe_replyto=('Reply-To: %s\n' ! % self.QuoteMime(self.GetListEmail())) ! else: ! maybe_replyto='' ! digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n%s\n%s" % ! (self._mime_separator, self.next_post_number, ! fromline, date, subject, maybe_replyto, ! body)) self.next_post_number = self.next_post_number + 1 topics_file.close() digest_file.close() From scott@chronis.pobox.com Fri Apr 24 00:52:40 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 19:52:40 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: ; from Ken Manheimer on Thu, Apr 23, 1998 at 07:10:05PM -0400 References: <19980415230936.53080@chronis.icgroup.com> Message-ID: <19980423195240.05994@chronis.icgroup.com> On Thu, Apr 23, 1998 at 07:10:05PM -0400, Ken Manheimer wrote: | Hi, all. I'm finally getting my head back to the surface after | returning, and starting to catch up on some of the mailman comments and | developments. I also have some new items of my own to throw in the mix. great! what have you been working on? | On Wed, 15 Apr 1998, Scott wrote: | | > proposal concerning web based subscriptions: | > | > *allways* use confirmation, even if the list doesn't require them via | > email. | | I'm a little confused about what you're saying. By "even if the list | doesn't require them via email", are you referring to the admin approval | option? no, i'm referring to the confirmation step with subscriptions that i've implemented and posted a patch for as well as an ftp location of the changed files. did you see those yet? |Are you basically saying, don't allow the option of unconfirmed | subscriptions? i'm saying don't allow the option of unconfirmed subscriptions via the web. and, if a subscription occurs with the address= option that is implemented in the patches referred to above, then require confirmation. i'd like to make it impossible for a person to subscribe some other unconsenting person to a mailling list. this practice, believe it or not, is quite common at our site. every day somone picks a victim's address and subscribes them to each of the 80-100 lists at our site with open subscription policies. that victim then essentially gets mailbombed in a real bad sortof way. i'd like it if mailman made this impossible. i think listserv makes this impossible by requiring all subscription requests to undergo a confirmation request. | If so, i'm not sure what i think of this. I can see how it would | usually be the right thing (tm) to require some kind of confirmation - | currently either email from the user or administrator approval. To some | degree, allowing unconfirmed subscriptions can amount to being a bad | neighbor. It reminds me of the gun debate - how much should we protect | people from each other. ("Guns don't kiss people, people kiss people." | Or something:-) I guess the question is, are there valid reasons to | have lists that take wholly unconfirmed subscriptions? the only reason i can think of is that people don't want subscribing to involve two steps. i don't personally find this valid given the nature of folks to abuse such services. | If we're | confident there aren't any lurking around the corner, then fine, lets | close that door. | | > If you don't, it's a security hole for any mailing list that doesn't | > implement it, and for out of service-attacks against the system | > mailman on which mailman is running. Even if a list is not advertised, | > it is still vulnerable to this, as an "attacker" could well find out | > the name of list by other means. | | Well, it does occur to me that a list that allows unconfirmed | subscriptions but also requires membership for posting privilege would | not be susceptable in the simple way to denial-of-service attacks. when mailman hosts hundreds of lists on one machine, the accumulated effect of the scenario described above can constitute an out of service attack as well. | Along related lines, it does occur to me that we should prevent mail | loops, where either the list is subscribed to itself, or where some | reflector loops back to the list. (The former situation was hinted at | this afternoon, when someone accidentally specified the matrix-sig as | their address for subscription *to* matrix-sig list; all it did was post | the subscription instructions to the list, but it would have subscribed | the list to itself if there was no confirmation...) What i'm doing is | adding a header, "X-BeenThere: ", which will be detected and | cause a hold of the message for approval, if encountered. that sounds like a good idea. scott From klm@python.org Fri Apr 24 00:52:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:52:41 -0400 (EDT) Subject: [Mailman-developers] membership management developments In-Reply-To: <19980420073740.52669@chronis.icgroup.com> Message-ID: Scott, i hope to take a closer look at your revisions tomorrow or this weekend. I'm a bit daunted by the packaging - i don't know how i can incorporate your changes to my version without specific patches for just the changes you made, and some explanation of them. Probably one of the most important aspects of this group-development effort is going to be some discipline to coordinate - otherwise we'll spend more effort trying to synch up than we will actually developing stuff. I *highly* recommend keeping your sources under version control, and really like using CVS to keep a development copy and a production copy. This makes it lots easier to mark releases as a whole, and identify changes since the last release, etc. Anyway, i'll be eager to incorporate your membership management stuff... Ken From klm@python.org Fri Apr 24 01:03:40 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 20:03:40 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <19980423195240.05994@chronis.icgroup.com> Message-ID: On Thu, 23 Apr 1998, Scott wrote: > On Thu, Apr 23, 1998 at 07:10:05PM -0400, Ken Manheimer wrote: > | Hi, all. I'm finally getting my head back to the surface after > | returning, and starting to catch up on some of the mailman comments and > | developments. I also have some new items of my own to throw in the mix. > > great! what have you been working on? Just some small things - a fix to the admin option help mechanism (and displaying the current option setting like on the regular options page - instead of 0/1/2 values for enumerations, you see the setting names on radio button with the right one checked - trivial, i know, but much more civilized...) I've forgotten what else - nothing big, but i'm starting to get a feel for some of the big pending things. > this practice, believe it or not, is quite common at our site. every > day somone picks a victim's address and subscribes them to each of the > 80-100 lists at our site with open subscription policies. that victim > then essentially gets mailbombed in a real bad sortof way. i'd like > it if mailman made this impossible. i think listserv makes this > impossible by requiring all subscription requests to undergo a > confirmation request. Yikes. I'm convinced. > | Along related lines, it does occur to me that we should prevent mail > | loops, where either the list is subscribed to itself, or where some > | reflector loops back to the list. (The former situation was hinted at > | this afternoon, when someone accidentally specified the matrix-sig as > | their address for subscription *to* matrix-sig list; all it did was post > | the subscription instructions to the list, but it would have subscribed > | the list to itself if there was no confirmation...) What i'm doing is > | adding a header, "X-BeenThere: ", which will be detected and > | cause a hold of the message for approval, if encountered. > > that sounds like a good idea. More later. Ken From scott@chronis.pobox.com Fri Apr 24 02:05:41 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 21:05:41 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <168702.3102354059@mcsv29-p5.med.nyu.edu>; from Roy Smith on Thu, Apr 23, 1998 at 09:00:59PM -0400 References: <168702.3102354059@mcsv29-p5.med.nyu.edu> Message-ID: <19980423210541.15914@chronis.icgroup.com> On Thu, Apr 23, 1998 at 09:00:59PM -0400, Roy Smith wrote: | > the only reason i can think of is that people don't want subscribing | > to involve two steps. i don't personally find this valid given the | > nature of folks to abuse such services. | | I agree. The threat of prank mass subscription is real. We've had it | happen with lists we run here. Not only is it, I would imagine, a nightmare | to the person involved, but it's a real pain to the people running the list | to sort out, especially when the victim starts to flood the list with "stop | this!" messages. | | I don't see any reason to not require a confirmation step by mail. | there seems to be one case where a confirmation step might not be necessary. if someone sends a request via mail to subscribe to a list without requesting that an address other than the sending address be subscribed, maybe that should be allowed sans confirmation. it would still be possible to do mass prank subscriptions, but much more difficult. Scott From roy@endeavor.med.nyu.edu Fri Apr 24 02:15:47 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Thu, 23 Apr 1998 21:15:47 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions Message-ID: <222139.3102354947@mcsv29-p5.med.nyu.edu> Scott wrote: > if someone sends a request via mail to subscribe to a list > without requesting that an address other than the sending address be > subscribed, maybe that should be allowed sans confirmation. it would > still be possible to do mass prank subscriptions, but much more > difficult. Spoofing return addresses is trivial. From scott@chronis.pobox.com Fri Apr 24 08:18:27 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 24 Apr 1998 03:18:27 -0400 Subject: [Mailman-developers] access to admin pages Message-ID: <19980424031827.64676@chronis.icgroup.com> i have a little concern about the ability to access administrative pages via the web without password confirmation. there are a number of pieces of displayed information that could lead spammers to view these pages and figure out how to spam lists. for example, anyone can get access to whether a list accepts posts from anyone. anyone can gain access to specific anti-spam measures a list has configured, anyone can gain access to bounce control measures about a list and determine whether or what kind of out of service attack may be possible. for all these reasons, and for the sake of the design of the administrative cgi script, it seems that it may be a good idea to stick the entire interface behind a single login and use cookies from there to allow access. the reason this seems better from a design point of view of the admin script is that i recently spent a good deal of time adding a separate type of authentication to one section. it was quite complicated, as the script was designed for authentication only when changes were requested. as more different things develop under the administrative interface, some of them will require authentication for viewing and some won't. changing around the authentication scheme every time will involve work. it would be much simpler just to have one login at the onset and to cookies from there. thoughts? scott From klm@python.org Sun Apr 26 18:47:28 1998 From: klm@python.org (Ken Manheimer) Date: Sun, 26 Apr 1998 13:47:28 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling Message-ID: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> It looks like there may be a problem, or at least some sendmail (8.8.8) sensitivities, in the way that mailman is mime-encoding the digests. Does anyone have enough MIME acquaintance to have an immediate idea whether or not the current format is correct? In any case, i responded that i would look into the problem tomorrow, and plan to look into using the python distribution mime facilities - in particular mimify.py - to use known quantities for the encoding. Clues would be appreciated... ken manheimer klm@python.org From: postmaster@mch.sni.de To: xml-sig-admin@python.org Cc: Winfried.Magerl@mch.sni.de (Winfried Magerl), Roland.Schad@mch.sbs.de (Roland Schad), Helmut.Peisl@mch.sni.de (Helmut Peisl) Subject: Problems with list xml-sig Date: Fri, 24 Apr 1998 16:49:25 +0200 (MDT) Dear Adminstrator, we have a lot of trouble with your mail sent from xml-sig@python.org It crashes (memory fault) our sendmail V8.8.8 when it attempts to deliver the mail to our local receipient. Worse, it prevents processing the whole queue because it always stumbles over your mail and then it crashes. We have tried a few things and we found that the problems is one specific line in the messageheader: HContent-type: multipart/digest; boundary="__--__--" If we remove this line, everything works fine. We send and receive some ten thousand mails a day and never run into problems like this. Would you please alterate this line so this won't happen again. Thank you very much for your assistance in helping us to solve this problem. Sincerely, Gerald Rinske Postmaster -- Internet Administration Munich Siemens Business Services, 81739 Munich, Germany Internet-Mail: postmaster@mch.sni.de From janne@avocado.pc.helsinki.fi Mon Apr 27 15:36:10 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 17:36:10 +0300 Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: Ken Manheimer's message of "Sun, 26 Apr 1998 13:47:28 -0400 (EDT)" References: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: Ken Manheimer writes: > It looks like there may be a problem, or at least some sendmail > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > digests. I have also received reports of 8.8.8 dumping core (probably) due to MIME digests. Some other mailers complain about the number of attachments. Over 20 seems to be too much for them. -- Janne From jtv2j@cs.virginia.edu Mon Apr 27 15:54:14 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 10:54:14 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling Message-ID: <199804271454.KAA08247@adder.cs.Virginia.EDU> > Ken Manheimer writes: > > > It looks like there may be a problem, or at least some sendmail > > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > > digests. > > I have also received reports of 8.8.8 dumping core (probably) due to > MIME digests. Well, I will report this bug to the sendmail developer today. Can anyone give me more specifics, such as affected operating systems? > Some other mailers complain about the number of attachments. Over 20 > seems to be too much for them. That's sad. It is unfortunate that few mailers deal with MIME digests decently. When I added the feature to mailman, I was wondering why no other package supported MIME digests. I very quickly learned that it is probably because so few mailers support them well if at all. I got so many complaints about the MIME digests that were the mailer's fault, that it became really clear to me that MIME digests need to be off by default until other mail software improves. I think Ken changed the default in the release, but if I haven't said so before, I strongly believe it should be changed back. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:07:15 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:07:15 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions References: <19980415230936.53080@chronis.icgroup.com> <19980423195240.05994@chronis.icgroup.com> Message-ID: <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US> >>>>> "S" == Scott writes: S> i'd like to make it impossible for a S> person to subscribe some other unconsenting person to a S> mailling list. ...while still allowing someone to subscribe to a list using a perfectly valid alternative address. Scott, I haven't seen your patches, but I know that other ML managers handle this in a useful way. They will send a confirmation email to the alternative address that contains a partially random string. The user need only reply to the message and include verbatim this string. This seems like a small hurdle to impose given the important nature of this defense. A small explanation included with the email (along with a link to a detailed Web page) would go a long way to easing any inconvenience. S> the only reason i can think of is that people don't want S> subscribing to involve two steps. i don't personally find this S> valid given the nature of folks to abuse such services. I highly agree! -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:14:01 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:14:01 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: Message-ID: <13636.40995.558852.780976@anthem.CNRI.Reston.Va.US> >>>>> "JS" == Janne Sinkkonen writes: JS> If the 'reply to list' option is set, mailman seems to put an JS> erroneous 'Reply-To:' header into administrative messages as JS> well, for example to reminders to administrators about pending JS> messages. (Then the administrators discuss what to do, and the JS> discussion goes to the list.) Mailman should never add a Reply-to header. Please see the seminal paper on this: "Reply-to" Munging Considered Harmful "Some forms of header munging are helpful, such as special loop-detection headers. Others are questionable. Most are ill-advised or dangerous. Many list adminstrators want to add a Reply-To header that points back to the list. This transformation also is one of the most ill-advised. Some administrators claim that Reply-To munging makes it easier for users to respond to the entire list, and helps encourage list traffic. These benefits are fallacious. Moreover, Reply-To can have harmful -- even dangerous -- effects. If you think Reply-To munging is a good idea, I hope I can change your mind." -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:20:58 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:20:58 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <13636.41496.429080.610494@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> While i'm inclined to agree about the list-of-known-domains KM> check being too maintenance intensive, i do see a reason to KM> have the check in the first place. The benefit comes into KM> play when the web interface is in play - the user is there, KM> and can get definite feedback about faulty addresses. Without KM> it, they only see address failures as the absence of any KM> subscription confirmation - a decidedly vague and uncertain KM> kind of feedback. Couldn't we do the same sort of DNS lookup when the form is submitted? -Barry From jtv2j@cs.virginia.edu Mon Apr 27 16:24:46 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:24:46 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages Message-ID: <199804271524.LAA09791@adder.cs.Virginia.EDU> > Mailman should never add a Reply-to header. Please see the seminal > paper on this: > > "Reply-to" Munging Considered Harmful > While I've certainly been a strong detractor of Reply-to ever since reading that article, there are still those who do not agree. I think adding the reply-to header should be an option, although it should be strongly discouraged. Ugh, I just went to the discussion forum off that page for the first time in quite a while. I see where well over a year ago I suggested that replies to a list should not be sent out to people who are in the TO or CC line (at least as an option). I'm pretty sure that feature is no longer in Mailman, and it should definitely go back in. If someone has time to Mailman hack in the near future, please consider adding that :) John From jtv2j@cs.virginia.edu Mon Apr 27 16:28:32 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:28:32 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804271528.LAA09939@adder.cs.Virginia.EDU> > > >>>>> "KM" == Ken Manheimer writes: > > KM> While i'm inclined to agree about the list-of-known-domains > KM> check being too maintenance intensive, i do see a reason to > KM> have the check in the first place. The benefit comes into > KM> play when the web interface is in play - the user is there, > KM> and can get definite feedback about faulty addresses. Without > KM> it, they only see address failures as the absence of any > KM> subscription confirmation - a decidedly vague and uncertain > KM> kind of feedback. > > Couldn't we do the same sort of DNS lookup when the form is submitted? Well, you can, but that would have a few problems of its own: 1) DNS lookup can be slow. People want instant feedback. 2) Sometimes DNS is flakey, and you might reject a perfectly valid email address. Sendmail will just keep it in a queue and try again periodically, so if it is a transient problem, then no problem. I would say that perhaps the list of domains *should* stay, but not be a requirement. How about, the list gets checked, and gives you a warning but not a fatal error if your address doesn't have one of the listed endings? From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:28:41 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:28:41 -0400 (EDT) Subject: [Mailman-developers] access to admin pages References: <19980424031827.64676@chronis.icgroup.com> Message-ID: <13636.42009.358344.974724@anthem.CNRI.Reston.Va.US> >>>>> "S" == Scott writes: S> for all these reasons, and for the sake of the design of the S> administrative cgi script, it seems that it may be a good idea S> to stick the entire interface behind a single login and use S> cookies from there to allow access. I agree! From roy@endeavor.med.nyu.edu Mon Apr 27 16:39:42 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Mon, 27 Apr 1998 11:39:42 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <689843.3102665982@qwerky.med.nyu.edu> "John Viega" wrote: > 1) DNS lookup can be slow. People want instant feedback. People also want correct operation. Seriously, how long can a DNS lookup take? We're talking about subscribing to a mailing list. This is not an operation one does dozens of times a day. If it takes an extra 15 seconds, who cares? > I would say that perhaps the list of domains *should* stay, but not be > a requirement. How about, the list gets checked, and gives you a > warning but not a fatal error if your address doesn't have one of the > listed endings? By saying you are going to build a file with the names of the top-level domains in it, you are essentially saying you are going to build your own manually maintained DNS cache. Well, DNS already does cacheing. What makes you think you can do a better job of it? If your DNS cache doesn't already have "edu", "com", etc in it, something is very strange. If you seriously only want to check top-level domains (a procedure which have dubious value), you can do it just as well by looking the top-level domain up in the DNS. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From jtv2j@cs.virginia.edu Mon Apr 27 16:47:56 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:47:56 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804271547.LAA11011@adder.cs.Virginia.EDU> > "John Viega" wrote: > > 1) DNS lookup can be slow. People want instant feedback. > > People also want correct operation. Seriously, how long can a DNS lookup > take? We're talking about subscribing to a mailing list. This is not an > operation one does dozens of times a day. If it takes an extra 15 seconds, > who cares? I've seen it take several minutes when a DNS server is quite loaded. I frequently see lookups that take 10-20 seconds. The vast majority of users are typing in the correct thing anyway, and don't want to have to wait around. I'd prefer to catch the most common stuff, and give a speedy response saying, "If you don't get mail from us soon, try again, because we couldn't send mail to your address". From klm@python.org Mon Apr 27 17:00:29 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 12:00:29 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: <199804271547.LAA11011@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > > "John Viega" wrote: > > > 1) DNS lookup can be slow. People want instant feedback. > > > > People also want correct operation. Seriously, how long can a DNS lookup > > take? We're talking about subscribing to a mailing list. This is not an > > operation one does dozens of times a day. If it takes an extra 15 seconds, > > who cares? > > I've seen it take several minutes when a DNS server is quite loaded. > I frequently see lookups that take 10-20 seconds. The vast majority of > users are typing in the correct thing anyway, and don't want to have > to wait around. I'd prefer to catch the most common stuff, and give a > speedy response saying, "If you don't get mail from us soon, try > again, because we couldn't send mail to your address". (I'm in the middle of something or i would have responded to several of the items going around at the moment, but i thought i'd chime in on this one immediately. I had also thought about querying the dns to do the address validation, but my gut feeling is that we can't assume we'll be able to do that everywhere in a portable way. I don't even know that we can presume that dns is used everywhere that might run mailman - they might use another name service, like nis/nis+, to deliver global host resolution to individual hosts at the site...) (ken) From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 17:23:00 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 12:23:00 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: <13636.45098.34505.337174@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: >>>>> "JV" == John Viega writes: JV> While I've certainly been a strong detractor of Reply-to ever JV> since reading that article, there are still those who do not JV> agree. I think adding the reply-to header should be an JV> option, although it should be strongly discouraged. Strongly, strongly discouraged. Even include a link that to page and some text saying: "You don't really want to do this, but if you think you do, read this document first". :-) JV> Ugh, I just went to the discussion forum off that page for the JV> first time in quite a while. I see where well over a year ago JV> I suggested that replies to a list should not be sent out to JV> people who are in the TO or CC line (at least as an option). JV> I'm pretty sure that feature is no longer in Mailman, and it JV> should definitely go back in. If someone has time to Mailman JV> hack in the near future, please consider adding that :) I guess you mean Mailman should check the To/CC address against the list of people in the expanded list, and winnow out duplicates. That would be pretty cool. -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 17:24:06 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 12:24:06 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804271528.LAA09939@adder.cs.Virginia.EDU> Message-ID: <13636.45315.167201.711850@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> Well, you can, but that would have a few problems of its own: JV> 1) DNS lookup can be slow. People want instant feedback. JV> 2) Sometimes DNS is flakey, and you might reject a perfectly JV> valid email address. Sendmail will just keep it in a queue JV> and try again periodically, so if it is a transient problem, JV> then no problem. JV> I would say that perhaps the list of domains *should* stay, JV> but not be a requirement. How about, the list gets checked, JV> and gives you a warning but not a fatal error if your address JV> doesn't have one of the listed endings? Good idea. Optional DNS lookup could be added with a similar non-fatal warning. -Barry From janne@avocado.pc.helsinki.fi Mon Apr 27 18:09:09 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 20:09:09 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Ken Manheimer's message of "Thu, 23 Apr 1998 19:31:39 -0400 (EDT)" References: Message-ID: Ken Manheimer writes: > Janne, can you recap your current thinking about the right thing to do > about the "Re:" handling w.r.t. the subject line prefix? I gather we > don't want to move the "Re:" to after the prefix, because it will > interfere with some MUA's thread recognition - and given that, i don't > see what more there is to be done... I agree now that Re: should be in front of the prefix, just because of MUA's threading by the Subject: header. However, one Re: seems to be enough, in the sense that nobody (out of 600) on my list has required several Re:'s. Maybe the MUAs do only one-level threading? Some MUAs add a Re: without caring any existing Re:'s. In addition, it seems like some other MUAs (or subscribers) remove the prefix and everything before it, and add a RE:, maybe without caring about any existing Re:'s. What's happening is not completely clear to me, but anyway the result is that in longer threads I see subject lines like Re: Re: PREFIX: RE: Re: So what is this all about? This was with majordomo. When I run mailman with my patch, which does if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): # The subject prefix is there already, possibly with some Re:'s. # Take the extra Re:'s away, leave one before the prefix_mess_rx=re.compile('^(re:? *)*' + re.escape(prefix) + '(re:? *)*', re.I) subj=re.sub(prefix_mess_rx, 'Re: ' + prefix, subj) else: # No prefix yet. subj=prefix+subj msg.SetHeader('Subject', subj) things seem much better. Now I have only three kind of subject lines: PREFIX: So what is this all about? Re: PREFIX: So what is this all about? PREFIX: RE: So what is this all about? As I said, I'm not sure how the third version appears. My proposal is that roughly the following should be done to the Subject line: 1. Remove extra Re:'s, case-insensitively, both before and after the possible prefix. Leave one Re: if there were any. 2. The prefix should appear after the Re:, or first on the line if there aren't any Re:'s. -- Janne From jtv2j@cs.virginia.edu Mon Apr 27 18:13:06 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 13:13:06 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) Message-ID: <199804271713.NAA14323@adder.cs.Virginia.EDU> One thing I've seen some mailers do which I have considered for mailman is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. Any thoughts? From janne@avocado.pc.helsinki.fi Mon Apr 27 18:15:23 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 20:15:23 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: John Viega's message of "Mon, 27 Apr 1998 13:13:06 -0400 (EDT)" References: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: John Viega writes: > One thing I've seen some mailers do which I have considered for mailman > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. > > Any thoughts? Sounds acceptable, except that the MUA's threading by Re: could be incapable to resolve these. -- Janne From klm@python.org Mon Apr 27 18:20:16 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 13:20:16 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > One thing I've seen some mailers do which I have considered for mailman > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. My feeling still is pretty soundly that mailman should do minimal messing with the subject line. It makes sense for it to introduce the prefix, and avoid duplicating it if already there - that seems clearly within the purview of the mailing list. It clearly should not introduce any "Re"s of it's own, and it i do not think it should mess with "Re"s that users introduce. It may be the user's mailer is fucked, and adding re's when it shouldn't - but it doesn't seem to me to be mailman's place to rectify that. Ken From jtv2j@cs.virginia.edu Mon Apr 27 18:25:55 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 13:25:55 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) Message-ID: <199804271725.NAA14953@adder.cs.Virginia.EDU> > On Mon, 27 Apr 1998, John Viega wrote: > > > One thing I've seen some mailers do which I have considered for mailman > > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. > > My feeling still is pretty soundly that mailman should do minimal > messing with the subject line. It makes sense for it to introduce the > prefix, and avoid duplicating it if already there - that seems clearly > within the purview of the mailing list. It clearly should not introduce > any "Re"s of it's own, and it i do not think it should mess with "Re"s > that users introduce. It may be the user's mailer is fucked, and adding > re's when it shouldn't - but it doesn't seem to me to be mailman's place > to rectify that. > > Ken To a degree I agree. However, I've been asked for such a feature many times, mainly by people who have mailers that don't thread on their own. If you change Re: to Re[1]: then you'll generally always get an extra Re and will update things properly. That having been said, I guess I'm inclined to agree that it shouldn't be there anyway. From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 18:30:49 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 13:30:49 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) References: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: <13636.49313.3187.868570@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> One thing I've seen some mailers do which I have considered JV> for mailman is to collapse Re: Re: into Re[2]: and Re: Re[n]: JV> into Re[n+1]:. Overly cute. I never really liked those type of headers. They quickly get out of sync because not every MUA does this. -Barry From scott@chronis.pobox.com Mon Apr 27 21:20:55 1998 From: scott@chronis.pobox.com (Scott) Date: Mon, 27 Apr 1998 16:20:55 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US>; from Barry A. Warsaw on Mon, Apr 27, 1998 at 11:07:15AM -0400 References: <19980415230936.53080@chronis.icgroup.com> <19980423195240.05994@chronis.icgroup.com> <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US> Message-ID: <19980427162054.23378@chronis.icgroup.com> On Mon, Apr 27, 1998 at 11:07:15AM -0400, Barry A. Warsaw wrote: | | >>>>> "S" == Scott writes: | | S> i'd like to make it impossible for a | S> person to subscribe some other unconsenting person to a | S> mailling list. | | ...while still allowing someone to subscribe to a list using a | perfectly valid alternative address. Scott, I haven't seen your | patches, but I know that other ML managers handle this in a useful | way. They will send a confirmation email to the alternative address | that contains a partially random string. The user need only reply to | the message and include verbatim this string. that is exactly what the patches do. there's still some problems synching the patches with the distribution, but this functionality is what my copy of mailman is doing right now. | This seems like a small hurdle to impose given the important nature of | this defense. A small explanation included with the email (along with | a link to a detailed Web page) would go a long way to easing any | inconvenience. it's all there, except the link to a web page, which sounds like a good idea. thanks for the feedback. scott From klm@python.org Mon Apr 27 22:03:20 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:03:20 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: I'm surfacing for a moment to respond to some of the current issues, particularly the mime item, below. I only have a moment - i need to prepare some notes to instruct some other project and system folks around here in mailman setup, so they can give it a try for some of their lists (yay!) On Sun, 26 Apr 1998, Ken Manheimer wrote: > It looks like there may be a problem, or at least some sendmail > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > digests. Does anyone have enough MIME acquaintance to have an > immediate idea whether or not the current format is correct? In any > case, i responded that i would look into the problem tomorrow, and > plan to look into using the python distribution mime facilities - in > particular mimify.py - to use known quantities for the encoding. > Clues would be appreciated... I should add, first of all, that i did suggest to them that they investigate whether sendmail 8.8.8 has any related sensitivities, since sendmail shouldn't be crashing, period, particularly from malformed content. John, i don't have any more details than the message provided, though i'll try to remember to ask them if they can provide any, when i contact them about the following change. I've actually started to revamp the digest mechanism, to be able to refine the mime presentation in an easy way. I'll go into that below. For the meanwhile, i'm using mimetools.choose_boundary() to substitute for the boundary delimiter of the mime-format digests, in the hopes that this might avoid triggering the sendmail bug, and to provide a somewhat more robust primary delimiter besides. What i'm planning to do (and have already started, in my enthusiasm) is to create a Digest class (in mm_message) to take all the digest pieces and keep them in a presentation-neutral format. It will be able to present them in both plain or mime formats. I'm planning to elaborate the mime format a bit, and to look into using a delimiter in the plain format which conforms to an old burstable-digest standard that was floating around the net. The elaboration of the mime format has the whole message as a multipart/mixed type. The top section - the masthead - will have a few text/plain; charset=us-ascii sections: - the digest header, if any - admin info (addresses, URLs, etc) - the toc followed by the digest contents, as a multipart/digest section, with a simple boundary. Finally there'll be a text/plain footer, if any. (I'm pretty close to convinced it's better to *not* have a default setting for the footer - a generic one is clutter, with info better served by the masthead admin-info section, and a list-specific one is up to the maillist admin.) What do people think? This layout is used by a maillist to which i subscribe, and i like it. But i'm not sure what the conventional wisdom is about these things. (I will respond in a different message to john's conventional wisdom about having digests default to plain, instead of mime...) Ken From klm@python.org Mon Apr 27 22:15:25 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:15:25 -0400 (EDT) Subject: [Mailman-developers] access to admin pages In-Reply-To: <19980424031827.64676@chronis.icgroup.com> Message-ID: On Fri, 24 Apr 1998, Scott wrote: > i have a little concern about the ability to access administrative > pages via the web without password confirmation. > [...] > for all these reasons, and for the sake of the design of the > administrative cgi script, it seems that it may be a good idea to > stick the entire interface behind a single login and use cookies from > there to allow access. I have the same concern, and agree that the admin pages should be behind the admin password, instead of in front of it. I've already included a cookie mechanism (gotten from off the net), for the private archives which could be adapted to the purpose - though i think it should be refined a bit to reasonable timeout the cookies, which the mechanism supports... > [...] > type of authentication to one section. it was quite complicated, as > the script was designed for authentication only when changes were > requested. as more different things develop under the administrative > interface, some of them will require authentication for viewing and > some won't. changing around the authentication scheme every time will > involve work. it would be much simpler just to have one login at the > onset and to cookies from there. There actually is already a few styles for soliciting authentication info. In several places, the authentication information is required to accompany changes. For the private archives, when you visit one of those pages and lack a cookie with sufficient authentication info, you get an authentication soliciting page, and then proceed to the page you really wanted. I agree that the latter style is much nicer for many situations. I think password changes should still use the old style, but anywhere else the prompt could come up only when there's no cookie containing the authentication... Ken From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 22:16:46 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 17:16:46 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling References: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: <13636.62831.638542.640623@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> I'm planning to elaborate the mime format a bit, and to look KM> into using a delimiter in the plain format which conforms to KM> an old burstable-digest standard that was floating around the KM> net. RFC 934 perhaps? -Barry From klm@python.org Mon Apr 27 22:24:45 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:24:45 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <13636.62831.638542.640623@anthem.CNRI.Reston.Va.US> Message-ID: On Mon, 27 Apr 1998, Barry A. Warsaw wrote: > RFC 934 perhaps? > > Thanks, i'll have two, and a side of fries. (I figured i'd just look at the emacs digest-burst function - but it may be long gone. I'll look at that. Thanks!) Ken From klm@python.org Mon Apr 27 22:59:42 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:59:42 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages In-Reply-To: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > While I've certainly been a strong detractor of Reply-to ever since > reading that article, there are still those who do not agree. I think > adding the reply-to header should be an option, although it should be > strongly discouraged. As someone suggested (in a subsequent note, i think - i'm catching up on ones i've previously scanned, here), i mention in the short description that "poster" is *strongly* recommended, and included a bit more explanation and the URL barry came up with in the long description. (And while i'm at it, someone might enjoy seeing the refinement of the long description presentation i made last week - the gui presentation of the current setting is used, instead of the data values. See http://www.python.org/mailman/admin/postal and click on one of the 'details' for an example...) > Ugh, I just went to the discussion forum off that page for the first > time in quite a while. I see where well over a year ago I suggested > that replies to a list should not be sent out to people who are in the > TO or CC line (at least as an option). I'm pretty sure that feature > is no longer in Mailman, and it should definitely go back in. If > someone has time to Mailman hack in the near future, please consider > adding that :) This would not be hard! Also would not be high priority. And i have to say, when streaming through my inbox, i often use the fact that i got a message twice as the cue that i'm among the direct recipients (something i noticed a lot today with mailman-developer's mail:). I'm not sure i'd want to be without this, despite the inbox clutter... Ken From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 23:28:01 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 18:28:01 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: <13637.1415.865073.631994@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> As someone suggested (in a subsequent note, i think - i'm KM> catching up on ones i've previously scanned, here), i mention KM> in the short description that "poster" is *strongly* KM> recommended, and included a bit more explanation and the URL KM> barry came up with in the long description. The biggest problem that I have with Reply-to munging is that I use Reply-to to control which of many inboxes I want replies to show up at. I think this is a valid for this header by end-users. Other people use it because their mail s/w is broken beyond their repair. I've had people who just cannot convince their sysadmins to fix their mailers but still want people to be able to reply to them. So they add a Reply-to they know to be valid. If Mailman munges Reply-to it's possible that those folks will just lose their messages. So at the very least, if optional Reply-to is enabled, Mailman shouldn't add or change a Reply-to if the original message had this header. KM> (And while i'm at it, someone might enjoy seeing the KM> refinement of the long description presentation i made last KM> week - the gui presentation of the current setting is used, KM> instead of the data values. See KM> http://www.python.org/mailman/admin/postal and click on one of KM> the 'details' for an example...) Not bad! KM> This would not be hard! Also would not be high priority. And KM> i have to say, when streaming through my inbox, i often use KM> the fact that i got a message twice as the cue that i'm among KM> the direct recipients (something i noticed a lot today with KM> mailman-developer's mail:). I'm not sure i'd want to be KM> without this, despite the inbox clutter... It might be a pain (or slow) but a per-user option to control this would be the way to go. -Barry From klm@python.org Mon Apr 27 23:58:34 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 18:58:34 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <199804271454.KAA08247@adder.cs.Virginia.EDU> References: <199804271454.KAA08247@adder.cs.Virginia.EDU> Message-ID: <13637.2293.465828.439310@glyph.CNRI.Reston.Va.US> John Viega writes: > [Was it janne? who wrote:] > > Some other mailers complain about the number of attachments. Over 20 > > seems to be too much for them. > > That's sad. It is unfortunate that few mailers deal with MIME digests > decently. When I added the feature to mailman, I was wondering why no > other package supported MIME digests. I very quickly learned that it I'm surprised - both of the outside, only-slightly-techie maillists to which i subscribe in digest mode are delivered in mime format. (The thinkpad list is the one from which i'm stealing my new mime layout proposal design.) > is probably because so few mailers support them well if at all. I got > so many complaints about the MIME digests that were the mailer's > fault, that it became really clear to me that MIME digests need to be > off by default until other mail software improves. I think Ken > changed the default in the release, but if I haven't said so before, I > strongly believe it should be changed back. John, you mentioned this to me early on - i'm sort of on the fence about it, and would like to discuss it more - only in the hopes that the prevailing world may have changed enough to warrant giving mime-default a try. I haven't gotten any complaints so far, except the sendmail problem - which i think is a sendmail problem, not mime/mailman... I'm ready to give up on this, though, just giving a last gasp try, just for the sake of personal preference. (I *much* prefer mime digest format, and also much prefer digest to procmail and mail-reader-sorted collections, both of which i have available.) Ken From klm@python.org Tue Apr 28 19:25:32 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 28 Apr 1998 14:25:32 -0400 (EDT) Subject: No subject Message-ID: <199804281825.OAA18771@glyph.CNRI.Reston.Va.US> Last thursday i posted a patch that was missing a piece, and would break things if used alone. It was in response to janne's patch to get rid of double reply-to's, and involved doing a "del msg[...]" instead iterating over the message headers. It turns out that the headers were part of an OutgoingMessage instance, which didn't support __delitem__. The patch below solves that - sorry about the confusion! Ken Index: mm_message.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_message.py,v retrieving revision 1.6 diff -c -r1.6 mm_message.py *** mm_message.py 1998/04/13 04:59:14 1.6 --- mm_message.py 1998/04/28 18:13:18 *************** *** 1,6 **** """Embody incoming and outgoing messages as objects.""" ! __version__ = "1.6" import sys --- 1,6 ---- """Embody incoming and outgoing messages as objects.""" ! __version__ = "1.7" import sys *************** *** 91,97 **** string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) ! # XXX Eventually (1.5.1?) Python rfc822.Message() will have it's own # __delitem__. def __delitem__(self, name): """Delete all occurrences of a specific header, if it is present.""" --- 91,97 ---- string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) ! # XXX Eventually (1.5.1?) Python rfc822.Message() will have its own # __delitem__. def __delitem__(self, name): """Delete all occurrences of a specific header, if it is present.""" *************** *** 128,140 **** self.sender = sender def SetHeaders(self, headers): ! self.headers = map(AddBackNewline, string.split(headers, '\n')) ! def CacheHeaders(header, s=self): i = string.find(header, ':') ! s.cached_headers[string.lower(string.strip(header[:i])) ! ] = header[i+2:] ! map(CacheHeaders, self.headers) def SetHeader(self, header, value, crush_duplicates=1): if value[-1] <> '\n': --- 128,141 ---- self.sender = sender def SetHeaders(self, headers): ! self.headers = map(AddBackNewline, string.split(headers, '\n')) ! self.CacheHeaders() ! def CacheHeaders(self): ! for header in self.headers: i = string.find(header, ':') ! self.cached_headers[string.lower(string.strip(header[:i])) ! ] = header[i+2:] def SetHeader(self, header, value, crush_duplicates=1): if value[-1] <> '\n': *************** *** 178,180 **** --- 179,196 ---- if not self.cached_headers.has_key(str): return None return self.cached_headers[str] + + def __delitem__(self, name): + if not self.getheader(name): + return None + newheaders = [] + name = string.lower(name) + nlen = len(name) + for h in self.headers: + if (len(h) > (nlen+1) + and h[nlen] == ":" + and string.lower(h[:nlen]) == name): + continue + newheaders.append(h) + self.headers = newheaders + self.CacheHeaders() From klm@python.org Wed Apr 29 22:28:42 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 29 Apr 1998 17:28:42 -0400 (EDT) Subject: [Mailman-developers] wrapper programs bug fix Message-ID: <199804292128.RAA23965@glyph.CNRI.Reston.Va.US> There's a bug in the new version of the cgi-wrapper.c program, which the following patch fixes, and more. The bug appears on error reporting, when the invoking process UID or GID doesn't match the configured setting - then a "%s" in the error report string causes a segfault when it's mapped onto the LEGAL_PARENT_UID or _GID. While the fix is obvious (change the two occurrences of "%s" to "%d"), the patches do a bit more than that. They also change the type of the main() routine to int, since gcc seems to expect that. (When the type was void gcc complained about it not being an int, and i figure gcc knows what it's doing. I don't, when it comes to C. (...Caveat emptor...-)) Ken Index: cgi-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/cgi-wrapper.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** cgi-wrapper.c 1998/04/03 00:12:57 1.1 --- cgi-wrapper.c 1998/04/28 22:36:07 1.2 *************** *** 53,69 **** /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %s made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %s made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! void main(int argc, char **argv, char **env) { int i; --- 53,69 ---- /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %d made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %d made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! int main(int argc, char **argv, char **env) { int i; Index: mail-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/mail-wrapper.c,v retrieving revision 1.5 retrieving revision 1.6 diff -c -r1.5 -r1.6 *** mail-wrapper.c 1998/03/30 16:28:22 1.5 --- mail-wrapper.c 1998/04/28 22:36:29 1.6 *************** *** 107,113 **** return 0; } ! void main(int argc, char **argv) { char *command; int i; --- 107,113 ---- return 0; } ! int main(int argc, char **argv) { char *command; int i; Index: alias-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/alias-wrapper.c,v retrieving revision 1.3 retrieving revision 1.5 diff -c -r1.3 -r1.5 *** alias-wrapper.c 1998/03/05 23:46:45 1.3 --- alias-wrapper.c 1998/04/28 22:38:18 1.5 *************** *** 60,66 **** } } ! void main(int argc, char **argv, char **env) { char *command; int i; --- 60,66 ---- } } ! int main(int argc, char **argv, char **env) { char *command; int i; *************** *** 78,83 **** --- 78,85 ---- else { printf("Illegal caller!\n"); + return 1; } + return 0; } From klm@python.org Thu Apr 30 18:56:01 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 30 Apr 1998 13:56:01 -0400 (EDT) Subject: [Mailman-developers] reply-to munging Message-ID: <199804301756.NAA26972@glyph.CNRI.Reston.Va.US> From the conversations about the reply-to issues, i propose changing reply_goes_to_list so it will *not* cause user specified reply-to headers, if present, to be replaced with the list's address. It just does not seem valid to override the mechanism which is intended for users to make their correct address available. Conversely, though using the reply-to at all in this way seems a bit improper, it sounds like the functionality is really necessary for some kinds of lists. (Perhaps i'm neglecting some alternate means for implementing this that was mentioned?) This will apply at least to individual messages, while digests as a whole will have the list as the reply-to addr. Objections? Ken From jtv2j@cs.virginia.edu Thu Apr 30 19:24:27 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 30 Apr 1998 14:24:27 -0400 (EDT) Subject: [Mailman-developers] reply-to munging Message-ID: <199804301824.OAA24485@adder.cs.Virginia.EDU> > >From the conversations about the reply-to issues, i propose changing > reply_goes_to_list so it will *not* cause user specified reply-to > headers, if present, to be replaced with the list's address. It just > does not seem valid to override the mechanism which is intended for > users to make their correct address available. > > Conversely, though using the reply-to at all in this way seems a bit > improper, it sounds like the functionality is really necessary for > some kinds of lists. (Perhaps i'm neglecting some alternate means for > implementing this that was mentioned?) > > This will apply at least to individual messages, while digests as a > whole will have the list as the reply-to addr. > > Objections? Yes, I object to that. Either the person sees why reply-to munging is bad, or he doesn't. If he doesn't, he's not going to want this behavior. Consistancy is important; there should not be differing behavior on a per-list basis when you hit "reply" based on the mail setup of the original sender. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Apr 30 21:27:54 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Apr 1998 16:27:54 -0400 (EDT) Subject: [Mailman-developers] reply-to munging References: <199804301824.OAA24485@adder.cs.Virginia.EDU> Message-ID: <13640.56769.497203.978760@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> Yes, I object to that. Either the person sees why reply-to JV> munging is bad, or he doesn't. If he doesn't, he's not going JV> to want this behavior. Consistancy is important; there should JV> not be differing behavior on a per-list basis when you hit JV> "reply" based on the mail setup of the original sender. I'm still really worried about allowing any reply-to munging. I just think that allowing administrators to reply-to munge message is setting them up for gobs of complaints. I know that have complained loudly and often when mailing lists I'm on do reply-to munging. A mailing list just shouldn't do this. If an admin turns this on, it *will* break for some people who are using Reply-To: in a completely valid and acceptable way. So we can still debate whether it should be allowed. Perhaps letting the site decide whether admins will be allowed to do this is another option. That way an admin would have to plead his case with the site admin to even be allowed to change this. Given my reservations in general, I agree with John. If munging is absolutely going to happen on a list, it should be consistent. At least that way they'll hear the screams earlier. -Barry From bwarsaw@python.org Thu Apr 30 21:57:49 1998 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 30 Apr 1998 16:57:49 -0400 (EDT) Subject: [Mailman-developers] Re: Welcome To "CC-Mode-Announce"! References: <199804282326.QAA11106@moldavia.unitech.com> <199804292035.NAA26098@moldavia.unitech.com> Message-ID: <13640.57633.923906.398949@anthem.CNRI.Reston.Va.US> Dan, Mailman is fairly new, so development is continuing quickly. If you are really interested in discussing some of these issues, I suggest following up to mailman-developers@python.org. You can of course join this list in the usual Mailman ways I hope you don't mind me CC'ing that list on this reply. I'd like for the wider Mailman developers audience to have a chance to respond. >>>>> "DH" == Dan Harkless writes: DH> I figured out what the problem is. Mailman does not use the DH> correct address. I send my mails from a local account called DH> "dlh", and I masquerade as "unitech.com", so my emails DH> (including this one) have this line: DH> Sender: dlh@unitech.com DH> However, my From line is set to my desired return address: DH> From: Dan Harkless DH> Right now there *is* a dlh@unitech.com, and that's where I DH> found mail from Mailman, but that account will soon go away. DH> Mailman is doing The Wrong Thing in preferring the Sender line DH> (or envelope sender information) over the From line. In these DH> days of POP mail boxes, people don't always send mail from the DH> same "account" (if such even exists) that receives it. I have never seen Sender used in this way. Typically Sender is used by a MLM to point to the list owner. Bounces will get sent to Sender, since the owner is the only person that can deal with such problems. In Mailman's case, the owner is a program that keeps track of bounces and auto-disables accounts that meet a certain threshold. I wasn't aware that Mailman uses the Sender address when deciding where to send replies. I agree it shouldn't use it, and certainly not in preference to From: or Reply-to: DH> What if I had my correct email address in the DH> even-higher-priority Reply-To line? Does it ignore that too? No. The order should be Reply-to (if present) followed by From. The list is currently debating whether Mailman should allow admins to Reply-to munge at all. We all (I think) agree it's evil, but there's some debate as to whether list admins should be allowed to configure it at all. DH> Is any of this behavior configurable? Not by users. DH> Actually I was just able to unsubscribe my old email address, DH> harkless@unitech.com, and it didn't ask me for my password. That's very strange. I just tried it with my own account and it definitely required a password. DH> I then re-subscribed with my new address, DH> dharkless@unitech.com, and it got as far as replying to the DH> verification email, but then I never heard back from the DH> server. I tried to go to the adjustments page for my new DH> address and it says that user doesn't exist. I can see that dlh@unitech.com is a member, not dharkless@unitech.com. I think that subscribing 3rd party addresses (essentially what you're doing) is something that Mailman currently doesn't support too well. It's being worked on though. If it's critical I think I can manually change the subscription to dharkless. >> If you forget your password, don't worry, you will receive a >> monthly reminder telling you what all your python.org maillist >> passwords are, DH> Hmm. That sounds pretty annoying. It'd be nice if there were DH> an option to turn that off. In practice it's not bad, but I agree. You can always get your password emailed to you via the Web interface. -Barry From stu@ekins.net Wed Apr 8 11:21:09 1998 From: stu@ekins.net (Stu Ekins) Date: Wed, 8 Apr 1998 11:21:09 +0100 Subject: [Mailman-developers] Pipermail issue... Message-ID: <199804081022.LAA06752@super.m2.com> Hi, Does anybody know of any issues with the pipermail module? It hasn't worked for me since I upped my python version to 1.5 (on Linux 2.x). I'm still learning the language and am not yet competent enough to debug it fully myself! Here's a traceback... Traceback (innermost last): File "./archive", line 31, in ? list.UpdateArchive() File "/home/mailman/mailman/modules/mm_archive.py", line 72, in UpdateArchive import pipermail File "/home/mailman/mailman/modules/pipermail.py", line 424, in ? words = string.split(datestr) TypeError: argument 1: expected read-only buffer, None found Cheers, Stu. From akuchlin@cnri.reston.va.us Wed Apr 8 15:35:58 1998 From: akuchlin@cnri.reston.va.us (Andrew Kuchling) Date: Wed, 8 Apr 1998 10:35:58 -0400 (EDT) Subject: [Mailman-developers] Pipermail issue... In-Reply-To: <199804081022.LAA06752@super.m2.com> References: <199804081022.LAA06752@super.m2.com> Message-ID: <13611.35248.129856.570523@newcnri.cnri.reston.va.us> Stu Ekins writes: >Does anybody know of any issues with the pipermail module? It hasn't worked >for me since I upped my python version to 1.5 (on Linux 2.x). I'm still >learning the language and am not yet competent enough to debug it fully >myself! I'm Pipermail's developer, and yes, there have been several issues with it. The version included with Mailman is 0.02, which is really out of date; I rewrote it almost completely for 0.04. I'm now going to try to make a new distribution of 0.05 available in the next day or two. >Here's a traceback... >Traceback (innermost last): > File "./archive", line 31, in ? > list.UpdateArchive() > File "/home/mailman/mailman/modules/mm_archive.py", line 72, in >UpdateArchive > import pipermail > File "/home/mailman/mailman/modules/pipermail.py", line 424, in ? > words = string.split(datestr) >TypeError: argument 1: expected read-only buffer, None found That looks like datestr is None, where it's being expected to be a string; this probably means that there's a message with no 'Date:' line in its headers, or, alternatively, there's an unescaped 'From' at the beginning of a line, and the program is thinking that it marks the start of a new message. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ The clerisy are those who read for pleasure, but not for idleness; who read for pastime but not to kill time; who love books, but do not live by books. -- Robertson Davies, _A Voice from the Attic_ From klm@python.org Wed Apr 8 15:47:22 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 8 Apr 1998 10:47:22 -0400 (EDT) Subject: [Mailman-developers] Pipermail issue... In-Reply-To: <13611.35248.129856.570523@newcnri.cnri.reston.va.us> Message-ID: On Wed, 8 Apr 1998, Andrew Kuchling wrote: > Stu Ekins writes: > >Does anybody know of any issues with the pipermail module? It hasn't worked > >for me since I upped my python version to 1.5 (on Linux 2.x). I'm still > >learning the language and am not yet competent enough to debug it fully > >myself! > > I'm Pipermail's developer, and yes, there have been several > issues with it. The version included with Mailman is 0.02, which is > really out of date; I rewrote it almost completely for 0.04. I'm now > going to try to make a new distribution of 0.05 available in the next > day or two. And i've continued to work on mailman, among other things disengaging the internal, old version of pipermail and tailoring it to work with an external archiver (specifically) like andrew's new version of pipermail. If you can wait, i'm going to make a new release available over the weekend, in conjunction with andrew's release of the new pipermail. (I may make a preview available on friday, in order to give some time for people to identify any major showstoppers in my release, since i'll be away for most of the subsequent week...) Ken From scott@chronis.icgroup.com Thu Apr 9 08:45:38 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 03:45:38 -0400 Subject: [Mailman-developers] wrappers: legal_caller() Message-ID: <19980409034538.10528@chronis.icgroup.com> i have installed mailman as part of pilot project to test out new mailing list managers for work. i had to change the ./mailman/mail/wrapper program to check for multiple uids and gids to get the cron jobs to work properly (uid and gid were that of mailman when sending out results). has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a patch to ./src/mail-wrapper.c (the same change can be applied to the other legal_caller() functions in the wrappers): --- src/mail-wrapper.c Tue Jun 10 12:31:16 1997 +++ src/mail-wrappernew.c Thu Apr 9 03:41:32 1998 @@ -37,9 +37,18 @@ NULL /* Sentinal, don't remove */ }; -/* Should make these arrays too... */ -const int LEGAL_PARENT_UID = 8; /* mail's UID */ -const int LEGAL_PARENT_GID = 12; /* mail's GID */ + +const int LEGAL_PARENT_UIDS[] = { + 1, /* mail's uid */ + 537, /* mailman's uid */ + -1 /* Sentinel, don't remove */ +}; + +const int LEGAL_PARENT_GIDS[] = { + 1, /* mail's gid */ + 100, /* mailman's gid */ + -1 /* Sentinel, don't remove */ +}; /* @@ -77,20 +86,45 @@ ** is the parent process allowed to call us? */ int legal_caller() { - /* compare to our parent's uid */ - if(LEGAL_PARENT_UID != getuid()) + int uid, gid, isok, idi; + isok = 0; + idi = 0; + uid = getuid(); + while (LEGAL_PARENT_UIDS[idi] != -1) + { + if(LEGAL_PARENT_UIDS[idi] == uid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) { - fprintf(f,"GOT UID %d.\n", getuid()); - return 0; + fprintf(f,"GOT UID %d.\n", uid); + return 0; } - if(LEGAL_PARENT_GID != getgid()) + isok = 0; + idi = 0; + gid = getgid(); + while (LEGAL_PARENT_GIDS[idi] != -1) { - fprintf(f,"GOT GID %d.\n", getgid()); - return 0; + if(LEGAL_PARENT_GIDS[idi] == gid) + { + isok = 1; + break; + } + idi++; + } + if ( isok == 0) + { + fprintf(f,"GOT GID %d.\n", gid); + return 0; } return 1; } + int valid_command(char *command){ int i = 0; @@ -119,7 +153,7 @@ i = strlen(argv[1]) + strlen(COMMAND_LOCATION) + 2; command = (char *)malloc(sizeof(char) * i); sprintf(command, "%s/%s", COMMAND_LOCATION, argv[1]); - + fprintf(f, "command is %s\n", command); if(!valid_command(argv[1])){ fprintf(f,"Illegal command.\n"); } Scott Cotton IC Group, Inc From scott@chronis.icgroup.com Thu Apr 9 08:51:27 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 03:51:27 -0400 Subject: [Mailman-developers] BTW Message-ID: <19980409035127.37117@chronis.icgroup.com> nice work on the upcoming release, if that is indeed what's running at python.org. is there any work in progress on a mail interface to the adminstrative functions? Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Thu Apr 9 09:06:37 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 04:06:37 -0400 Subject: [Mailman-developers] suggestion Message-ID: <19980409040637.04722@chronis.icgroup.com> i would like to suggest two things about the confirmation step in subscriptions. first, that it be an option for email based subscriptions, and second, that just hitting reply and copying in the confirmation message (with or without regular email quotations) be made to work. if there's a consensus on this, i'd be willing to make the necessary changes. Scott Cotton IC Group, Inc. From scott@blackbox.pobox.com Thu Apr 9 09:04:22 1998 From: scott@blackbox.pobox.com (scott) Date: Thu, 9 Apr 1998 04:04:22 -0400 (EDT) Subject: No subject Message-ID: <199804090804.EAA01236@blackbox.pobox.com> lists From klm@python.org Thu Apr 9 16:44:31 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 11:44:31 -0400 (EDT) Subject: [Mailman-developers] BTW In-Reply-To: <19980409035127.37117@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > nice work on the upcoming release, if that is indeed what's running at > python.org. Thanks - yes. > is there any work in progress on a mail interface to the adminstrative > functions? Not currently. It's a good idea, and wouldn't be hard to implement. However, i've identified many such things pending - i'll put it on my list, which i'll be including in the package when i release. Ken From klm@python.org Thu Apr 9 16:47:45 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 11:47:45 -0400 (EDT) Subject: [Mailman-developers] wrappers: legal_caller() In-Reply-To: <19980409034538.10528@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > i have installed mailman as part of pilot project to test out new > mailing list managers for work. > > i had to change the ./mailman/mail/wrapper program to check for > multiple uids and gids to get the cron jobs to work properly (uid and > gid were that of mailman when sending out results). > > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a > patch to ./src/mail-wrapper.c (the same change can be applied to the > other legal_caller() functions in the wrappers): This sounds fine. Note that the next release will have a somewhat simpler wrapper situation - john has consolidated all the cgi wrappers into a single source file, so there now is a total of three wrappers - the generic cgi wrapper (which is parameterized to create an executable for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. Ken From klm@python.org Thu Apr 9 17:03:15 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 12:03:15 -0400 (EDT) Subject: [Mailman-developers] suggestion In-Reply-To: <19980409040637.04722@chronis.icgroup.com> Message-ID: On Thu, 9 Apr 1998, Scott wrote: > i would like to suggest two things about the confirmation step in > subscriptions. first, that it be an option for email based > subscriptions, and second, that just hitting reply and copying in the > confirmation message (with or without regular email quotations) be > made to work. Both sound good to me, with one reservation. It's all too common for people to lazily cite an entire message when they're responding to it, so their response may be, "No don't subscribe me", followed by a citation of the entire subscription-confirmation request. That sort of thing would have to be recognized, particularly since we want to strenuously avoid having a subscription refusal lead to subscription... > if there's a consensus on this, i'd be willing to make the necessary > changes. Cool. Ken From scott@chronis.icgroup.com Thu Apr 9 17:59:01 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 9 Apr 1998 12:59:01 -0400 Subject: [Mailman-developers] wrappers: legal_caller() In-Reply-To: ; from Ken Manheimer on Thu, Apr 09, 1998 at 11:47:45AM -0400 References: <19980409034538.10528@chronis.icgroup.com> Message-ID: <19980409125901.07425@chronis.icgroup.com> On Thu, Apr 09, 1998 at 11:47:45AM -0400, Ken Manheimer wrote: | On Thu, 9 Apr 1998, Scott wrote: | | > i have installed mailman as part of pilot project to test out new | > mailing list managers for work. | > | > i had to change the ./mailman/mail/wrapper program to check for | > multiple uids and gids to get the cron jobs to work properly (uid and | > gid were that of mailman when sending out results). | > | > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a | > patch to ./src/mail-wrapper.c (the same change can be applied to the | > other legal_caller() functions in the wrappers): | | This sounds fine. Note that the next release will have a somewhat | simpler wrapper situation - john has consolidated all the cgi wrappers | into a single source file, so there now is a total of three wrappers - | the generic cgi wrapper (which is parameterized to create an executable | for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. One more thing that may make the installation easier would be to have a single header file that is #included in each c source file with something like /* legal parent uid's of the wrapper ./mailman/mail/wrapper */ const int LEGAL_MAIL_PUIDS[] = { 0, /* root */ 1, /* bin */ 537, /*mailman */ -1, /* Sentinel, do not remove */ } or if there's a worry of defining unused variables: #ifdef MAIL_WRAPPER [declaration] #endif along with a '#define MAIL_WRAPPER 1' in mail-wrapper.c this way, while whoever is installing the program, they would only have to edit one file to play with the calling uid and gid. Scott Cotton IC Group, Inc. From jtv2j@cs.virginia.edu Thu Apr 9 19:09:08 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 9 Apr 1998 14:09:08 -0400 (EDT) Subject: [Mailman-developers] wrappers: legal_caller() Message-ID: <199804091809.OAA09086@cobra.cs.Virginia.EDU> > On Thu, Apr 09, 1998 at 11:47:45AM -0400, Ken Manheimer wrote: > | On Thu, 9 Apr 1998, Scott wrote: > | > | > i have installed mailman as part of pilot project to test out new > | > mailing list managers for work. > | > > | > i had to change the ./mailman/mail/wrapper program to check for > | > multiple uids and gids to get the cron jobs to work properly (uid and > | > gid were that of mailman when sending out results). > | > > | > has this been incoporated into mailmanv1.0b1.2 yet? if not, here's a > | > patch to ./src/mail-wrapper.c (the same change can be applied to the > | > other legal_caller() functions in the wrappers): > | > | This sounds fine. Note that the next release will have a somewhat > | simpler wrapper situation - john has consolidated all the cgi wrappers > | into a single source file, so there now is a total of three wrappers - > | the generic cgi wrapper (which is parameterized to create an executable > | for each of the cgi scripts), the mail-wrapper, and the aliases wrapper. > > One more thing that may make the installation easier would be to have > a single header file that is #included in each c source file with > something like > > /* legal parent uid's of the wrapper ./mailman/mail/wrapper */ > const int LEGAL_MAIL_PUIDS[] = > { > 0, /* root */ > 1, /* bin */ > 537, /*mailman */ > -1, /* Sentinel, do not remove */ > } > > or if there's a worry of defining unused variables: > > #ifdef MAIL_WRAPPER > > [declaration] > > #endif > > along with a '#define MAIL_WRAPPER 1' in mail-wrapper.c > > this way, while whoever is installing the program, they would only > have to edit one file to play with the calling uid and gid. > > Scott Cotton > IC Group, Inc. > > > ------------------------------------------------------ > Mailman-developers maillist - Mailman-developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers Actually, the ultimate goal is to have as much configuraiton as possible picked out automatically, and the rest of it maintained by a single file, or perhaps a web page. For example, most of the uids we could do a good job of guessing based on the passwd file, and then keep it open for people to change if they have special considerations. John From klm@python.org Fri Apr 10 02:21:04 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Apr 1998 21:21:04 -0400 (EDT) Subject: [Mailman-developers] Pre-release of new mailman version Message-ID: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> I've packaged an a prerelease of my new version of mailman - the one currently running on python.org. I plan to do a real (beta) release by the end of the weekend, but would like to have people do some poking and prodding before then, to shake out any overt problems in my packaging methods... (Also, some people are doing their own work on particular pieces, and need to work w.r.t. the current version instead of the substantially different prior one.) Since there are some substantial changes, particularly in the way default site values are configured and in the maillist data structures, you should not overwrite anything you're using for production. (In particular, i haven't implemented the routine that migrates the datastructures from older list versions to the current one, so things *will* break) This relase is more for reference - yours and mine. Please let me know if you do play with it and have anything interesting to report. Thanks! ken manheimer klm@python.org From akuchlin@cnri.reston.va.us Fri Apr 10 15:39:34 1998 From: akuchlin@cnri.reston.va.us (Andrew Kuchling) Date: Fri, 10 Apr 1998 10:39:34 -0400 (EDT) Subject: [Mailman-developers] Pre-release of new Pipermail version In-Reply-To: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> References: <199804100121.VAA08035@glyph.CNRI.Reston.Va.US> Message-ID: <13614.11768.37106.671049@newcnri.cnri.reston.va.us> Following up on Ken's announcement of a Mailman prerelease, I've made a prerelease snapshot of Pipermail 0.05. Hopefully I can do some cleanups and actually write some documentation before finalizing 0.05. You can get the code from . This is the first new release since June '97. It's very, very different from 0.02; here's an except from the README: ====== This is a snapshot of the current code for Pipermail 0.05. It is almost completely different from 0.02. Version 0.02 was simply a script that imitated Hypermail quite closely. The Python SIG archives, however, steered further development, since I wanted to customize the SIG lists in various complicated ways. Pipermail has therefore mutated into an abstract base class (pipermail.T) that provides the skeleton for indexing; you use it by creating a subclass which defines methods to write indexes and format articles. The "hypermail.py" script is intended to be a Hypermail clone with most of Hypermail's features, and it also provides an example of creating a usable subclass of pipermail.T . You could further subclass HypermailFormatter, if desired; I've done this for the Python SIG mailing list archives. In other words, Pipermail isn't a list archiver, though it comes with a useful sample archiver in the form of hypermail.py . Pipermail is, instead, a framework for building your own customized message archivers. ====== -- A.M. Kuchling http://starship.skyport.net/crew/amk/ But the really great eccentrics are all inimitable; they are not possessed by a single oddity; they are, in their deepest selves, unlike the generality of mankind. -- Robertson Davies, "Lewis Carroll in the Theatre" From scott@chronis.icgroup.com Sat Apr 11 17:48:35 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 12:48:35 -0400 Subject: [Mailman-developers] prerelease feedback Message-ID: <19980411124835.50476@chronis.icgroup.com> some notes on the prerelease: atleast one of the wrappers (cgi-wrapper) was seg faulting on my machine (linux2.0.29 on a pentum). i haven't completely traced and fixed the problem yet, all i've done is commented out the check_caller() function call to make it work in the meant time. i'll track this one down more thoroughly early next week. the integration with the archiving is still using pipermail v.02. it's unclear to me whether archiving is going to be done separately (with it's own cron jobs) or called via Archiver.UpdateArchives. i am also unsure by what mechanism private archives are going to be hidden (via cgi password authentication, .htaccess or what). overall, i'd like to say yet again that mailman seems to be developing very quickly and extend thanks to ken and john and andrew. Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Sat Apr 11 17:56:49 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 12:56:49 -0400 Subject: [Mailman-developers] administrative unsubscribing Message-ID: <19980411125649.52233@chronis.icgroup.com> it seems to me like list admins need a more efficient way to (mass-)unsubscribe members than going through them one at a time the same way that a list member would unsubscribe them. some ideas for the interface are: have the mass subscibe box simply full of a list of all subscribers and be able to edit it directly. under member management administrative interface, list all the members with a checkbox allowing the adminstrator to unsubcribe people one click at a time. are there any other ideas for how to do this? if there is a consensus on whether this feature should be added and what the interface should look like, i'll add it to my list of things to implement and get startted next week. scott From klm@python.org Sat Apr 11 18:48:00 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 13:48:00 -0400 (EDT) Subject: [Mailman-developers] administrative unsubscribing In-Reply-To: <19980411125649.52233@chronis.icgroup.com> Message-ID: On Sat, 11 Apr 1998, Scott wrote: > it seems to me like list admins need a more efficient way to > (mass-)unsubscribe members than going through them one at a time the > same way that a list member would unsubscribe them. This is something i've also had in mind. > some ideas for the interface are: > > have the mass subscibe box simply full of a list of all subscribers > and be able to edit it directly. And do some kind of differencing approach, where members that you deleted from the list are deleted, and members that you added are added? My thoughts have been tending to the next option... (I should note that there's another mechanism for doing mass subscriptions which i came to rely on for transferring over my existing lists - mailman/bin/populate_new_list turns out to work better for me. In either case, you have to be careful to clean out extra stuff from the entries - you can't add "klm@python.org (ken manheimer)", for instance.) > under member management administrative interface, list all the members > with a checkbox allowing the adminstrator to unsubcribe people one > click at a time. I would have a table with an entry for each member, including their address and some check buttons, one to disable delivery, one to hide/unhide them, and one to unsubscribe them completely. There's one nuance that i think should be accounted for as well, which makes the setup slightly more elaborate than just that. I think this interface *should* include the members that have set the concealment option for their subscription. However, that means that this interface, itself, should be accessed indirectly from the membership management page, via something that requires the administrator password. Otherwise, non-administrators could visit the admin pages and get to see the concealed folks... This reminds me of a somewhat related area that really needs work - the subscription mechanisms are too basic, at the moment. There are two missing features - actual confirmation of subscription requests (currently that's finagled around), and subscription of forwarding addresses. Let me explain... I've had several requests from subscribers to be able to change their subscription address. Makes sense to me, but it so happens that the current mechanisms for preventing mischievous third-party subscriptions are not up to this. New web-based subscriptions addresses are "confirmed" by prompting an email subscription sent from the subscription address. Well, that's not really confirmation - the web-based subscription attempt isn't recorded or anything, it just prompts the helpful message desribing how to subscribe, basically. Well, i don't think we can use the same trick for subscription address changes, because the old address needs to be removed, as well as adding the new one. And we can't rely on the password for the old address because that doesn't vouch for the authority over creation of the new address - ie, someone could subscribe at their real address in order to get a password that would allow them to subscribe an arbitrary address of their choice. No good. In particular, there is no confirmation tracking done - no database of requests to be resolved against confirmations. We would need something like that to do the subscription transfers, i think. Or at least, i think that would be the right way to do it, particularly since such a mechanism would enable the other big, lacking subscription feature - the ability to subscribe a forwarding address. Ie, some people have a forwarding address at acm.org, but no actual logins there. They would like to be able to subscribe that address, but the current mechanism doesn't allow it - it is constrained to the sender/from fields, because there is no actual confirmation going on, just identification. Anyway, these are some issues i'm hoping to tackle and or yield to others... > are there any other ideas for how to do this? if there is a consensus > on whether this feature should be added and what the interface should > look like, i'll add it to my list of things to implement and get > startted next week. Cool - the membership management stuff is one of the things i had on my list! Ken From scott@chronis.icgroup.com Sat Apr 11 19:01:44 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 11 Apr 1998 14:01:44 -0400 Subject: [Mailman-developers] administrative unsubscribing In-Reply-To: ; from Ken Manheimer on Sat, Apr 11, 1998 at 01:48:00PM -0400 References: <19980411125649.52233@chronis.icgroup.com> Message-ID: <19980411140144.10696@chronis.icgroup.com> OK, i'll get started on this stuff next week. confirmation of subscription requests (allowing forwarding addresses) and an administrator-only accessed list of subscribers in a table with check buttons to change their options/unsubscribe them. Scott On Sat, Apr 11, 1998 at 01:48:00PM -0400, Ken Manheimer wrote: | On Sat, 11 Apr 1998, Scott wrote: | | > it seems to me like list admins need a more efficient way to | > (mass-)unsubscribe members than going through them one at a time the | > same way that a list member would unsubscribe them. | | This is something i've also had in mind. | | > some ideas for the interface are: | > | > have the mass subscibe box simply full of a list of all subscribers | > and be able to edit it directly. | | And do some kind of differencing approach, where members that you | deleted from the list are deleted, and members that you added are added? | My thoughts have been tending to the next option... | | (I should note that there's another mechanism for doing mass | subscriptions which i came to rely on for transferring over my existing | lists - mailman/bin/populate_new_list turns out to work better for me. | In either case, you have to be careful to clean out extra stuff from the | entries - you can't add "klm@python.org (ken manheimer)", for instance.) | | > under member management administrative interface, list all the members | > with a checkbox allowing the adminstrator to unsubcribe people one | > click at a time. | | I would have a table with an entry for each member, including their | address and some check buttons, one to disable delivery, one to | hide/unhide them, and one to unsubscribe them completely. | | There's one nuance that i think should be accounted for as well, which | makes the setup slightly more elaborate than just that. I think this | interface *should* include the members that have set the concealment | option for their subscription. However, that means that this interface, | itself, should be accessed indirectly from the membership management | page, via something that requires the administrator password. | Otherwise, non-administrators could visit the admin pages and get to see | the concealed folks... | | This reminds me of a somewhat related area that really needs work - the | subscription mechanisms are too basic, at the moment. There are two | missing features - actual confirmation of subscription requests | (currently that's finagled around), and subscription of forwarding | addresses. Let me explain... | | I've had several requests from subscribers to be able to change their | subscription address. Makes sense to me, but it so happens that the | current mechanisms for preventing mischievous third-party subscriptions | are not up to this. | | New web-based subscriptions addresses are "confirmed" by prompting an | email subscription sent from the subscription address. Well, that's not | really confirmation - the web-based subscription attempt isn't recorded | or anything, it just prompts the helpful message desribing how to | subscribe, basically. Well, i don't think we can use the same trick for | subscription address changes, because the old address needs to be | removed, as well as adding the new one. And we can't rely on the | password for the old address because that doesn't vouch for the | authority over creation of the new address - ie, someone could subscribe | at their real address in order to get a password that would allow them | to subscribe an arbitrary address of their choice. No good. | | In particular, there is no confirmation tracking done - no database of | requests to be resolved against confirmations. We would need something | like that to do the subscription transfers, i think. Or at least, i | think that would be the right way to do it, particularly since such a | mechanism would enable the other big, lacking subscription feature - the | ability to subscribe a forwarding address. Ie, some people have a | forwarding address at acm.org, but no actual logins there. They would | like to be able to subscribe that address, but the current mechanism | doesn't allow it - it is constrained to the sender/from fields, because | there is no actual confirmation going on, just identification. | | Anyway, these are some issues i'm hoping to tackle and or yield to | others... | | > are there any other ideas for how to do this? if there is a consensus | > on whether this feature should be added and what the interface should | > look like, i'll add it to my list of things to implement and get | > startted next week. | | Cool - the membership management stuff is one of the things i had on my | list! | | Ken | From klm@python.org Sat Apr 11 19:08:32 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 14:08:32 -0400 (EDT) Subject: [Mailman-developers] prerelease feedback In-Reply-To: <19980411124835.50476@chronis.icgroup.com> Message-ID: On Sat, 11 Apr 1998, Scott wrote: > atleast one of the wrappers (cgi-wrapper) was seg faulting on my > machine (linux2.0.29 on a pentum). i haven't completely traced and > fixed the problem yet, all i've done is commented out the > check_caller() function call to make it work in the meant time. i'll > track this one down more thoroughly early next week. Ok. > the integration with the archiving is still using pipermail v.02. > it's unclear to me whether archiving is going to be done separately > (with it's own cron jobs) or called via Archiver.UpdateArchives. i am > also unsure by what mechanism private archives are going to be hidden > (via cgi password authentication, .htaccess or what). I'm not clear exactly what you're saying. My intention was to deprecate but not yet remove all the stuff that implemented the internal pipermail processing. That amounted to commenting out some stuff in mm_archive.py, removing the archive-job entries from the crontab template, and so forth. The actual messages are deposited, using some remaining mm_archive.py methods, in files in either the public or private dirs, according to the configuration settings. Pipermail is supposed to be pointed at the directories, with the private stuff hidden behind a password wrapper, which i'll be including in my final package. (I also added another setgid cgi executable wrapper in the src dir makefile, etc - all of got finally working yesterday, so it's not in the package i sent out thursday eve.) > overall, i'd like to say yet again that mailman seems to be developing > very quickly and extend thanks to ken and john and andrew. Thanks! I'm looking forward to the kind of growth we can get with more contributors. Though that also has me a bit daunted, and had me a bit compulsive trying to polish up one thing or another, so people didn't build on, and lock in, shaky foundations. (Turns out there's never enough you can do about that - there's always going to be some wrong turns taken...) Ken From klm@python.org Sat Apr 11 19:57:54 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 14:57:54 -0400 (EDT) Subject: [Mailman-developers] Treating you shoddily Message-ID: <199804111857.OAA17347@glyph.CNRI.Reston.Va.US> I'm test a delivery to a list with more than a few addresses (not much more), to see whether a slightly drastic measure to deal with a subtle bug scales up. In case you're interested, the problem was with addresses that contain a quote - there's only one instance on all my lists, someone with the last name "O'hara". The single quotes were being lost in the forked sendmail (and/or before that, in the forked deliver script command line). The solution appears to be to apply repr to the addresses before exposing them to the shell. It works on the problematic addresses, and the few addresses i played with on some trial lists, but this is the first try with a middling sized list. And incidentally, one of the near changes is to switch over to direct SMTP acces to the mail delivery agent on the current machine, rather than forking sendmail and exposing the addresses to the command line. John has already provided me with an SMTP class that he's been playing with, but i was shy about diving into that so near to releasing the new version. Ken From klm@python.org Sat Apr 11 20:00:58 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 11 Apr 1998 15:00:58 -0400 (EDT) Subject: [Mailman-developers] Treating you shoddily In-Reply-To: <199804111857.OAA17347@glyph.CNRI.Reston.Va.US> Message-ID: On Sat, 11 Apr 1998, Ken Manheimer wrote: > I'm test a delivery to a list with more than a few addresses (not much > more), to see whether a slightly drastic measure to deal with a subtle > bug scales up. It seems to be fine - i got a copy of the message, and received no bounces notices... Ken From klm@python.org Mon Apr 13 15:49:02 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 10:49:02 -0400 (EDT) Subject: [Mailman-developers] late on new mailman release - soon Message-ID: <199804131449.KAA23491@glyph.CNRI.Reston.Va.US> Well, i've failed on my promise of a full-fledged release of 1.0b2 this weekend - i was within minutes of it (early this morning) when our systems folks had to shutdown the systems for emergency reasons. When i get things recovered here i'll finish it up and make it available - almost certainly later today, at the latest. Ken From klm@python.org Mon Apr 13 21:42:31 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 16:42:31 -0400 (EDT) Subject: [Mailman-developers] Mailman 1.0b2 available Message-ID: <199804132042.QAA25502@glyph.CNRI.Reston.Va.US> Finally, i've got a complete package of mailman 1.0b2 ready for consumption. This has some substantial features beyond friday(?)'s prerelease, particularly support for private archives and fix of a bug handling addresses containing quotes. It also has lots of niggles polished in preparing the release, so i'd strongly suggest using getting this version even if you got the prerelease. Here's the encompassing README. I (in the grand Python tradition - didn't mean to do it, but i can see now how this happens) will be away the rest of this week, for the most part, but may be able to field some immediate problems or whatever tomorrow. Below is the encompassing README - cheers! Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # Distribution README for mailman 1.0b2. This is mailman v1.0b2.0 - probably the first real, full-function beta-level release of V1. In case you don't know, mailman is a maillist management system with full web-based administration and membership interfaces. It is written almost wholly in Python, and nicely extensible. See the README in the mailman directory for more details. To use it, unpack the tar file and move the mailman directory to within ~mailman on your system. See the README in the mailman directory for more details. Mailman was devised by John Viega, who developed it pretty far but lost later versions in a system crash. The current version is based on an early release (1.0b1) that john did which i (ken manheimer) picked up and stashed away, until such time that i could pay attention to it. Turns out i had one of the most recent surviving copies, so it became the basis of the current system. However, that version was in some ways still at the prototype stage, so i've spent some time polishing it up, enough at first to get it running for use with the maillists here at python.org, and perhaps a bit more to get it looking better, easier to use, and a bit more solid. I'd say this release, if not ready for prime time, is ready for general use and development. Below is a list of the major new features added since the original release (1.0b1.1), bugs stomped and still pending, and thoughts about further develpment necessary and/or desirable. For anyone interested in joining in on the development crowd, or just tracking the progress, there's a maillist for you to join (we're considering using mailman to run it - kidding!), mailman-developers@python.org. Visit http://www.python.org/mailman/listinfo/mailman-developers for more info. New Features Web pages much more polished - Better organized, text more finely crafted - Easier, more refined layout - List info and admin interface overviews, enumerate all public lists (via, e.g., http://www.python.org/mailman/listinfo - sans the specific list) - Admin interface broken into sections, with help elaboration for complicated configuration options Maillist Archives - Integrated with a newer, *much* improved, external pipermail - to be found at http://starship.skyport.net/crew/amk/maintained/pipermail.html - Private archives protected with maillist members passwords, cookie-fied. Spam prevention - New spam prevention measures catch most if not all spam without operator intervention or general constraints on who can post to list: require_explicit_destination option imposes hold of any postings that do not have the list name in any of the to or cc header destination addresses. This catches the vast majority of random spam. Other options (forbidden_posters, bounce_matching_headers) provide for filtering of known transgressors. - Option obscure_addresses (default on) causes maillist subscriber lists on the web to be slightly mangled so they're not directly recognizable as email address by web spiders, which might be seeking targets for spammers. Site configuration arrangement organized - in mailman/mailman/modules: - When installing, create a mailman/modules/mm_cfg.py (if there's not one already there), using mm_cfg.py.dist as a template. mm_default.py contains the distributed defaults, including descriptions of the values. mm_cfg.py does a 'from mm_defaults.py import *' to get the distributed defaults. Include settings in mm_cfg.py for any values in mm_defaults.py that need to be customized for your site, after the 'from .. import *'. See mm_cfg.py.dist for more details. Logging - Major operations (subscription, admin approval, bounce, digestification, cgi script failure tracebacks) logged in files using a reliable mechanism - Wrapper executables log authentication complaints via syslog Wrappers - All cgi-script wrapper executables combined in a single source, easier to configure. (Mail and aliases wrappers separate.) List structure version migration - Provision for automatic update of list structures when moving to a new version of the system. See modules/versions.py. Code cleaning - Many more module docstrings, __version__ settings, more function docstrings. - Most unqualified exception catches have been replaced with more finely targeted catches, to avoid concealing bugs. - Lotsa long lines wrapped (pet peeve:). Many Bugs Stomped ----------------- Many bugs stomped. Some memorable ones: - Subscriber addresses containing quotes (eg, Ken_O'Manheimer@python.org) were not properly escaped to survive transmission through shell to sendmail - Specifying a non-existent user for editing user options now complains immediately, rather than presenting a form. - Ad-hoc /tmp log files (which could bollix things if unwritable) gone - User changing from digest to non-digest and vice versa doesn't escape sort order. - Users are not sorted by address, internally - only on presentation - htmlformat.py no longer silently hides bugs in format operations. Instead, unexpected objects show as repr() would - easier to debug, without making htmlformat fragile. - File creation bracketed by proper umask setting to ensure specified file permissions. - Notices are sent for rejections of moderated postings (but not for discarded ones). - Web pages now all have titles. - Duplicate approvals of subscription requests do not lead to duplicate memberships. Pending bugs ------------ - Mime digests a bit feeble - postings containing mime attachments not properly handled - Bounce processing - Turning off bounce processing doesn't? - Turning on non-member-post exclusion doesn't - More generally mm_utils.AddressesMatch() needs to be really thought out. For instance, klm@python.org vs klm@acm.org should be seen as different, but klm@parrot.python.org and klm@larch.python.org and klm@python.org should probably be seen as the same. There may be more criteria... - Bounces of the confirmation notices sent to people attempting web-based subscriptions are, necessarily, directed (via reply-to header) to maillist-request addr, and get mishandled there as unrecognized requests. Not sure how to solve this one short of recognizing bad subscriber addrs before sending out the notice. Pending Developments and Issues ------------------------------- Some modest Pending Refinements: - Use re module everywhere instead of regexp and regsub. - Implement a reasonable administrivia filter for lists (but less likely to misfire than majordomo's) (administrivia is, eg, unsubscribe request mistakenly sent to list posting addr) - Refine any unqualified exception guards to specify target exceptions. - Turn standard mailman exceptions into class exceptions. - Implement cookies (with moderate lifetimes) for user and admin passwords. - Unravel edit-options functionality from cgi/subscribe script - give edit-options a script of its own. (Not imperative, maybe when the bigger project of implementing member profiles is done.) - Relax constraint that everything be installed in /home/mailman. (I'll probably do this for the next release. We can probably use relative paths for most things, particularly the routine sys.path setting in all the python code, and possibly for the wrappers.) - Foolproof list deletion (bin/rmlist) a bit by asking for password (and have list admin or site password work). - Should member deletion be confirmed with email? - Submission of edited user options should return to edit-options page, like admin options pages do. - People mass subscribed on admin form should not require approval, even for closed-subscribe lists. Some bigger Pending Projects - User and Admin Guides - HOWTOs - Developers guide - documentation - Implement email interface to admin commands. - Implement a 'which' mailcmd. (Probably not hard! May be good intro project for someone wading into mailman development.) - Put the admin interface and other things like private subscriber rosters *behind* passwords, like the private archives are. Eg, instead of putting the password box on the listinfo form, have it always be just a regular link to the roster, but then the roster page would be a password page if the roster is private and there's no cookie for it. - Generalize and refine admindb so that pending bounces, subscriptions, etc are stored in the filesystem, nicely catalogued, and the interfaces for handling them (eg, admindb) shows succinct summaries, with links to see the entire things. (I may work on this.) - Develop subscription mechanisms so real confirmation happens, and use that as basis for option to change existing subscription delivery address. (Scott cotton is working on this.) - Deliver by connect to SMTP 25 instead of sendmail. (I'm checking in modules/smtplib.py module john's played with some.) - Robustify aliases handling to not just append entries if they already exist, and ideally, edit existing ones if they need to change. - Implement a real admin/membership-management section, that includes includes hidden subscribers, provides easy perusal and changing of all members (including concealed members) status, including disabling or removal from list. - Implement some automated validation of installation - check for obvious problems with options settings, file access permissions, sendmail hookup, etc. ? Have an implicit list-managers list for every site, which includes all the list managers? - Make listinfo page static, regenerated every time admin options are changed. This will speed up and reduce load for listinfo page loading. More Fundamental, or just more bigger:), Pending Projects - Refine locking to only necessary sections, so there's less room for unnecessary contention. - Implement the system as a persistent server. (John's planning to do this.) - Implement member profiles, using a class. For name, organization, description, etc, and defaults options settings. The lists, themselves, could still have copies of the specific passwords and the compact bitmaps (for the sake of efficiency) for list-specific options like digest/nondigest, but the user could set their default choices - delivery address, password, delivery mode - in their profile. From klm@python.org Mon Apr 13 21:46:52 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 13 Apr 1998 16:46:52 -0400 (EDT) Subject: [Mailman-developers] Release location Message-ID: <199804132046.QAA25554@glyph.CNRI.Reston.Va.US> Daggone it, neglected to say where to find it: ftp://ftp.python.org/pub/python/contrib/Network/mailman.tar.gz Ken From klm@python.org Tue Apr 14 23:10:28 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Apr 1998 18:10:28 -0400 (EDT) Subject: [Mailman-developers] First patch - Message-ID: <199804142210.SAA00520@glyph.CNRI.Reston.Va.US> Here's the first mailman 1.0b2 patch. For messages going to the maillist, a blank line between the message headers and the body was lacking, so if the first line of the body looked like a header (eg, 'http://www.python.org/'!), it would be included among the headers. Here's the checkin message and the patch. You need to apply the patch from the modules directory, if you use 'patch'. Ken .DeliverToList(): Was missing a newline between message headers and body, so initial body lines that looked like header would be incorporated in header. *** mm_deliver.py.1.18 Tue Apr 14 18:01:34 1998 --- mm_deliver.py Tue Apr 14 18:01:34 1998 *************** *** 122,138 **** msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') ! tmp_file.write(string.join(msg.headers,'')) ! # If replys don't go to the list, then they should go to the ! # real sender ! if self.reply_goes_to_list: ! tmp_file.write('Reply-To: %s\n\n' % self.GetListEmail()) ! if header: tmp_file.write(header + '\n') tmp_file.write(self.QuotePeriods(msg.body)) if footer: --- 122,136 ---- msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' + if self.reply_goes_to_list: + msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') + tmp_file.write(string.join(msg.headers,'') + '\n') ! if header: # The *body* header: tmp_file.write(header + '\n') tmp_file.write(self.QuotePeriods(msg.body)) if footer: From scott@chronis.icgroup.com Wed Apr 15 11:31:42 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 06:31:42 -0400 Subject: [Mailman-developers] confirmation of subscriptions Message-ID: <19980415063142.57641@chronis.icgroup.com> i have developed a working confirmation step in the subscription process for mailman. there are some things that should be presented for discussion and or polished up before this addition (hopefully) makes it to the distribution. below i've attached a patch to be applied to files in the mailman/modules directory, and an extra module (mm_pending.py). in addtion, i'll put a distribution of the changed modules/*.py files at ftp://chronis.icgroup.com/pub/mmconfirm.tgz all comments and feedback on the following are most welcome. CHANGE ROSTER: new mm_defaults variable DEFAULT_CONFIRM_SUBSCRIBE the admin/listname/privacy page no longer presents the web_subscribe_requires_confirmation, instead it present a new confirm_subscribe option. the subscribe command now uses the following syntax (backwards compatible): subscribe [arg [arg [arg]]] where can be one of: password, digest|nodigest or address=. anytime the address= is specified, the confirmation step is triggered regardless of list preference. As an administrator of a high volume mailing site, i strongly encourage us to keep it this way. this will also allow users to subscribe with forwarding addresses. there is a new mail command: confirm if the confirmation number represents an outstanding subscribe request that is pending confirmation, then the subscription will take place. TODO: make email interface to unsubscribe address= get totally rid of web_subscribe_requires_confirmation in the code because it is no longer visible check to make sure the address= address is being checked as a valid email address. clean up mm_pending.py with __version__ and stuff. NOTE: i'm getting buggy output of the mm_deliver.SUBSCRIBEACKTEXT, and am not sure if it is the result of any of my changes, though it looks like a bug unrelated to these changes at a glance. Scott ----------------------------------------------------------------------------- PATCH ----------------------------------------------------------------------------- diff -c -r /tmp/mailman/modules/maillist.py ./maillist.py *** /tmp/mailman/modules/maillist.py Sun Apr 12 00:34:01 1998 --- ./maillist.py Wed Apr 15 05:19:56 1998 *************** *** 139,144 **** --- 139,145 ---- self.welcome_msg = '' self.goodbye_msg = '' self.open_subscribe = mm_cfg.DEFAULT_OPEN_SUBSCRIBE + self.confirm_subscribe = mm_cfg.DEFAULT_CONFIRM_SUBSCRIBE self.private_roster = mm_cfg.DEFAULT_PRIVATE_ROSTER self.obscure_addresses = mm_cfg.DEFAULT_OBSCURE_ADDRESSES self.member_posting_only = mm_cfg.DEFAULT_MEMBER_POSTING_ONLY *************** *** 282,297 **** " members are admitted only at the discretion of the list" " administrator."), ! ('web_subscribe_requires_confirmation', mm_cfg.Radio, ! ('None', 'Requestor confirms via email', 'Admin approves'), 0, ! 'What confirmation is required for on-the-web subscribes?', ! ! "This option determines whether web-initiated subscribes" ! " require further confirmation, either from the subscribed" ! " address or from the list administrator. Absence of" ! " any confirmation makes web-based subscription a" ! " tempting opportunity for mischievous subscriptions by third" ! " parties."), "Membership exposure", --- 283,296 ---- " members are admitted only at the discretion of the list" " administrator."), ! ('confirm_subscribe', mm_cfg.Radio, ('No', 'Yes'), 1, ! 'Should subscriptions require confirmation step?', ! ! "This option forces all subscription requests to prompt a verification" ! " message to be sent to the subscribing address, and a response from that" ! " address before subscription takes place. This prevents malicious" ! " folk from (mass) subscribing unconsenting owners of email addresses to" ! " mailing lists."), "Membership exposure", diff -c -r /tmp/mailman/modules/mm_defaults.py ./mm_defaults.py *** /tmp/mailman/modules/mm_defaults.py Mon Apr 13 14:09:27 1998 --- ./mm_defaults.py Wed Apr 15 05:30:58 1998 *************** *** 81,86 **** --- 81,88 ---- DEFAULT_REPLY_GOES_TO_LIST = 0 # Admin approval unnecessary for subscribes? DEFAULT_OPEN_SUBSCRIBE = 1 + # confirm neccesary for subscribes? + DEFAULT_CONFIRM_SUBSCRIBE = 1 # Private_roster == 0: anyone can see, 1: members only, 2: admin only. DEFAULT_PRIVATE_ROSTER = 0 # When exposing members, make them unrecognizable as email addrs. To *************** *** 88,96 **** DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. DEFAULT_MEMBER_POSTING_ONLY = 0 - # 1 for email subscription verification, 2 for admin confirmation: - DEFAULT_WEB_SUBSCRIBE_REQUIRES_CONFIRMATION = 1 - # Digestification Defaults # # Will list be available in non-digested form? --- 90,95 ---- diff -c -r /tmp/mailman/modules/mm_mailcmd.py ./mm_mailcmd.py *** /tmp/mailman/modules/mm_mailcmd.py Thu Apr 9 19:48:30 1998 --- ./mm_mailcmd.py Wed Apr 15 05:28:59 1998 *************** *** 6,12 **** # Not implemented: get / index / which. import string, os, sys ! import mm_message, mm_err, mm_cfg, mm_utils option_descs = { 'digest' : 'receive mail from the list bundled together instead of ' --- 6,12 ---- # Not implemented: get / index / which. import string, os, sys ! import mm_message, mm_err, mm_cfg, mm_utils, mm_pending option_descs = { 'digest' : 'receive mail from the list bundled together instead of ' *************** *** 47,53 **** --- 47,55 ---- 'set' : self.ProcessSetCmd, 'options' : self.ProcessOptionsCmd, 'password' : self.ProcessPasswordCmd, + 'confirm': self.ProcessConfirmCmd } + self.__noMailCmdResponse = 0 def AddToResponse(self, text): self._response_buffer = self._response_buffer + text + "\n" *************** *** 84,90 **** self.AddError("%s: Command UNKNOWN." % cmd) else: self._cmd_dispatch[cmd](args, line, mail) ! self.SendMailCmdResponse(mail) def SendMailCmdResponse(self, mail): self.SendTextToUser(subject = 'Mailman results for %s' % --- 86,93 ---- self.AddError("%s: Command UNKNOWN." % cmd) else: self._cmd_dispatch[cmd](args, line, mail) ! if not self.__noMailCmdResponse: ! self.SendMailCmdResponse(mail) def SendMailCmdResponse(self, mail): self.SendTextToUser(subject = 'Mailman results for %s' % *************** *** 338,386 **** self.AddError("%s %s" % (sys.exc_type, sys.exc_value)) self.AddError("%s" % sys.exc_traceback) def ProcessSubscribeCmd(self, args, cmd, mail): digest = self.digest_is_default if not len(args): password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! elif len(args) == 1: ! if string.lower(args[0]) == 'digest': ! digest = 1 ! password = "%s%s" % (mm_utils.GetRandomSeed(), ! mm_utils.GetRandomSeed()) ! elif string.lower(args[0]) == 'nodigest': ! digest = 0 ! password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! else: ! password = args[0] ! ! elif len(args) == 2: ! if string.lower(args[1]) == 'nodigest': ! digest = 0 ! password = args[0] ! elif string.lower(args[1]) == 'digest': ! digest = 1 ! password = args[0] ! elif string.lower(args[0]) == 'nodigest': ! digest = 0 ! password = args[1] ! elif string.lower(args[0]) == 'digest': ! digest = 1 ! password = args[1] ! else: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return ! elif len(args) > 2: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return try: ! self.AddMember(mail.GetSender(), password, digest) self.AddToResponse("Succeeded.") except mm_err.MMBadEmailError: self.AddError("Email address '%s' not accepted by Mailman." % ! mail.GetSender()) except mm_err.MMMustDigestError: self.AddError("List only accepts digest members.") except mm_err.MMCantDigestError: --- 341,410 ---- self.AddError("%s %s" % (sys.exc_type, sys.exc_value)) self.AddError("%s" % sys.exc_traceback) + + + def ProcessSubscribeCmd(self, args, cmd, mail): digest = self.digest_is_default + password = "" + address = "" + done_digest = 0 if not len(args): password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! elif len(args) > 3: ! self.AddError("Usage: subscribe [password] [digest|nodigest]") ! return ! else: ! for arg in args: ! if string.lower(arg) == 'digest' and not done_digest: ! digest = 1 ! done_digest = 1 ! elif string.lower(arg) == 'nodigest' and not done_digest: ! digest = 0 ! done_digest = 1 ! elif string.lower(arg)[:8] == 'address=' and not address: ! address = string.lower(arg)[8:] ! elif not password: ! password = arg ! else: ! self.AddError("Usage: subscribe [arg [arg [arg]]] where can be\n" ! "\t[password]\n\t[digest|nodigest]\nor" ! "\t[address=]") ! return ! if not password: ! password = "%s%s" % (mm_utils.GetRandomSeed(), mm_utils.GetRandomSeed()) ! # we don't want people subscribing addresses other than the sender address ! # without an extra confirmation step ! if address or self.confirm_subscribe: ! if not address: ! pending_addr = mail.GetSender() ! else: ! pending_addr = address ! ! cookie = mm_pending.gencookie() ! mm_pending.add2pending(pending_addr, password, digest, cookie) ! self.SendTextToUser(subject = "%s -- confirmation of subscription req. %d" % \ ! (self.real_name, cookie), ! recipient = pending_addr, ! sender = self.GetRequestEmail(), ! text = mm_pending.VERIFY_FMT % ({"email": pending_addr, ! "listaddress": self.GetListEmail(), ! "listname": self.real_name, ! "cookie": cookie, ! "requestor": mail.GetSender()})) ! self.__noMailCmdResponse = 1 ! return ! self.FinishSubscribe(mail.GetSender(), password, digest) + def FinishSubscribe(self, addr, password, digest): try: ! self.AddMember(addr, password, digest) self.AddToResponse("Succeeded.") except mm_err.MMBadEmailError: self.AddError("Email address '%s' not accepted by Mailman." % ! addr) except mm_err.MMMustDigestError: self.AddError("List only accepts digest members.") except mm_err.MMCantDigestError: *************** *** 391,406 **** self.AddApprovalMsg(cmd) except mm_err.MMHostileAddress: self.AddError("Email address '%s' not accepted by Mailman " ! "(insecure address)" % mail.GetSender()) except mm_err.MMAlreadyAMember: ! self.AddError("%s is already a list member." % mail.GetSender()) except: # TODO: Should log the error we got if we got here. self.AddError("An unknown Mailman error occured.") self.AddError("Please forward on your request to %s" % self.GetAdminEmail()) self.AddError("%s" % sys.exc_type) ! def AddApprovalMsg(self, cmd): self.AddError('''Your request to %s: --- 415,451 ---- self.AddApprovalMsg(cmd) except mm_err.MMHostileAddress: self.AddError("Email address '%s' not accepted by Mailman " ! "(insecure address)" % addr) except mm_err.MMAlreadyAMember: ! self.AddError("%s is already a list member." % addr) except: # TODO: Should log the error we got if we got here. self.AddError("An unknown Mailman error occured.") self.AddError("Please forward on your request to %s" % self.GetAdminEmail()) self.AddError("%s" % sys.exc_type) ! ! ! def ProcessConfirmCmd(self, args, cmd, mail): ! if len(args) != 1: ! self.AddError("Usage: confirm \n") ! return ! try: ! cookie = string.atoi(args[0]) ! except: ! self.AddError("Usage: confirm \n") ! return ! pending = mm_pending.get_pending() ! if not pending.has_key(cookie): ! self.AddError("Invalid confirmation number!\n" ! "Please recheck the confirmation number and try again.") ! return ! (email_addr, password, digest, ts) = pending[cookie] ! self.FinishSubscribe(email_addr, password, digest) ! del pending[cookie] ! mm_pending.set_pending(pending) ! ! def AddApprovalMsg(self, cmd): self.AddError('''Your request to %s: ---------------------------------------------------------------------- mm_pending.py ---------------------------------------------------------------------- """ module for handling pending subscriptions """ import os import sys import posixfile import marshal import time import rand import mm_cfg DB_PATH = mm_cfg.MAILMAN_DIR + "/misc/pending_subscriptions.db" LOCK_PATH = mm_cfg.LOCK_DIR + "/pending_subscriptions.lock" VERIFY_FMT = """\ You or someone (%(requestor)s) has requested that your email address (%(email)s) be subscribed to the %(listname)s mailling list at %(listaddress)s. If you wish to fulfill this request, please reply to this message, with the following line, and only the following line in the message body: confirm %(cookie)s If you do not wish to subscribe to this list, please simply ignore or delete this message. """ # ' icky emacs font lock thing def get_pending(): " returns a dict containing pending information" try: fp = open(DB_PATH,"r" ) except IOError: return {} dict = marshal.load(fp) return dict def gencookie(p=None): if p is None: p = get_pending() while 1: newcookie = rand.rand() if p.has_key(newcookie): continue return newcookie def set_pending(p): ou = os.umask(0) try: lock_file = posixfile.open(LOCK_PATH,'a+') finally: os.umask(ou) lock_file.lock('w|', 1) fp = open(DB_PATH, "w") marshal.dump(p, fp) fp.close() lock_file.lock("u") lock_file.close() def add2pending(email_addr, password, digest, cookie): ts = int(time.time()) processed = 0 p = get_pending() p[cookie] = (email_addr, password, digest, ts) set_pending(p) def set_processed(cookie, value): p = get_pending() if p.has_key(cookie): (email_addr, listname, password, digest, processed, ts) = p[cookie] processed = value p[cookie] = (email_addr, listname, password, digest, processed, ts) set_pending(p) else: raise ValueError, "attempt to set processed field in pending to non existent cookie (%d)" % (cookie) From dima@bog.msu.su Wed Apr 15 17:33:45 1998 From: dima@bog.msu.su (Dmitry Khrustalev) Date: Wed, 15 Apr 1998 20:33:45 +0400 (MSD) Subject: [Mailman-developers] Mailman results for Thread-SIG (fwd) Message-ID: I'm getting the following error from mailman: Date: Sat, 4 Apr 1998 12:12:38 -0500 (EST) From: thread-sig-request@python.org To: dima@bog.msu.su Subject: Mailman results for Thread-SIG >>>> subscribe **** Email address 'dima@bog.msu.su' not accepted by Mailman. When trying to use web interface i get: Mailman won't accept the given email address as a valid address. (Does it have an @ in it???) ( address is dima@bog.msu.su ). Can someone look at this problem? -Dima From scott@chronis.icgroup.com Wed Apr 15 23:59:39 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 18:59:39 -0400 Subject: [Mailman-developers] confirmation of subscriptions In-Reply-To: <19980415063142.57641@chronis.icgroup.com>; from Scott on Wed, Apr 15, 1998 at 06:31:42AM -0400 References: <19980415063142.57641@chronis.icgroup.com> Message-ID: <19980415185939.30501@chronis.icgroup.com> some further developments have taken place: the subscribe cgi now uses the confirmation step instead of the old web-confirmation step when confirmations are required for subscription. i'll post more patches and a distribution later tonight. scott On Wed, Apr 15, 1998 at 06:31:42AM -0400, Scott wrote: | | i have developed a working confirmation step in the subscription | process for mailman. From janne@avocado.pc.helsinki.fi Thu Apr 16 00:38:37 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 02:38:37 +0300 Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives Message-ID: I have several minor things: First, when the "reply to the list" option of a list is set, it seems that a potential existing Reply-To: is not (always) stripped off. Instead there will be two Reply-To: headers, one for the list, one from the original sender. I guess this is a bug? Second, here's a working answer_majordomo_mail script. The script in 1.0b12 didn't work for me (the patch would be larger than the script itself, hence I include this here): #!/usr/local/bin/python # This is another script that's really just for my use, but # feel free to use it if you know how... import sys f = open('/dev/null', 'w') sys.stderr = f sys.path.append('/home/mailman/mailman/modules') import mm_message, mm_utils msg = mm_message.IncomingMessage() text = open('/home/mailman/mailman/misc/majordomo.answer.txt', 'r').read() mm_utils.SendTextToUser('Your mail to Majordomo...', text, msg.GetSender(), 'mailman-owner') I would also like to ask about the archives. The README says 'integrated with [...] external pipermail'. :) Besides the links and authorization service provided, what does this mean in practice? Should I run piper-hypermail from a crontab or is there something better around somewhere? -- Janne From scott@chronis.icgroup.com Thu Apr 16 04:09:36 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 23:09:36 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions Message-ID: <19980415230936.53080@chronis.icgroup.com> proposal concerning web based subscriptions: *allways* use confirmation, even if the list doesn't require them via email. If you don't, it's a security hole for any mailing list that doesn't implement it, and for out of service-attacks against the system mailman on which mailman is running. Even if a list is not advertised, it is still vulnerable to this, as an "attacker" could well find out the name of list by other means. it seems that as mailman becomes more widely used, more and more lists will have a problem with this. comments? Scott Cotton IC Group Inc From janne@avocado.pc.helsinki.fi Thu Apr 16 16:46:43 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 18:46:43 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Janne Sinkkonen's message of "16 Apr 1998 02:38:37 +0300" Message-ID: Here's a patch to get rid of extra Re:'s around the beginning of the subject line. I don't know whether this replaces too aggressively or not (I'm testing it on a largish mailing list). Probably not. Another question is that should we have Re: PREFIX .* or PREFIX Re: .* in replies. I'd maybe favor the latter (this is also what the patch implements). *** maillist.py Thu Apr 16 18:38:02 1998 --- maillist.py~ Sun Apr 12 07:34:01 1998 *************** *** 747,763 **** prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! else: ! if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): ! # The subject prefix is there already, possibly with some Re:'s. ! # Take the extra Re:'s away, put one behind prefix. ! prefix_mess_rx=re.compile('^(re:? *)*' + ! re.escape(prefix) + '(re:? *)*', re.I) ! subj=re.sub(prefix_mess_rx, prefix + 'Re: ', subj) ! else: ! # No prefix yet. ! subj=prefix+subj ! msg.SetHeader('Subject', subj) if self.digestable: self.SaveForDigest(msg) --- 747,755 ---- prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), ! subj, re.I): ! msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.digestable: self.SaveForDigest(msg) -- Janne Sinkkonen From janne@avocado.pc.helsinki.fi Thu Apr 16 17:29:57 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 19:29:57 +0300 Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages In-Reply-To: Scott's message of "Wed, 15 Apr 1998 18:59:39 -0400" Message-ID: If the 'reply to list' option is set, mailman seems to put an erroneous 'Reply-To:' header into administrative messages as well, for example to reminders to administrators about pending messages. (Then the administrators discuss what to do, and the discussion goes to the list.) -- Janne Sinkkonen From janne@avocado.pc.helsinki.fi Thu Apr 16 20:57:10 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 16 Apr 1998 22:57:10 +0300 Subject: [Mailman-developers] More polishing... Message-ID: Below is a set of patches to take care of a few bugs. My earlier patch to get rid of extra Re:'s is included in a modified form. Changes: 1. No double Reply-To:'s to list mail. Reply-To:'s in some admin mail still remain. 2. Get rid of extra Re:'s on the subject line. However, leave "Re: PREFIX" instead of "PREFIX Re:" - the latter does not work with some mail readers which use Re: for threading (and there was some strange problems with answering the mail as well). 3. Some people wanted to have Reply-To: in every attachment of a MIME digest (for lists with reply_to_list true). 4. A bug in digest topic section (wrong argument order to ""%(...)) corrected. Some polishing of the header (to make it more useful to the most helpless non-WWW-subscribers). 5. crontab: the right name of the script is senddigests. *** modules/mm_deliver.dist.py Wed Apr 15 20:43:04 1998 --- modules/mm_deliver.py Thu Apr 16 22:16:38 1998 *************** *** 123,128 **** --- 123,131 ---- else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: + # Get rid of old Reply-To: + for item in msg.headers: + if item[0:9] == 'Reply-To:': msg.headers.remove(item) msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) *** modules/maillist.dist.py Sun Apr 12 07:34:01 1998 --- modules/maillist.py Thu Apr 16 21:07:18 1998 *************** *** 747,755 **** prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), ! subj, re.I): ! msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.digestable: self.SaveForDigest(msg) --- 747,763 ---- prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) ! else: ! if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): ! # The subject prefix is there already, possibly with some Re:'s. ! # Take the extra Re:'s away, put one behind prefix. ! prefix_mess_rx=re.compile('^(re:? *)*' + ! re.escape(prefix) + '(re:? *)*', re.I) ! subj=re.sub(prefix_mess_rx, 'Re: ' + prefix, subj) ! else: ! # No prefix yet. ! subj=prefix+subj ! msg.SetHeader('Subject', subj) if self.digestable: self.SaveForDigest(msg) *** modules/mm_digest.dist.py Thu Apr 16 20:57:13 1998 --- modules/mm_digest.py Thu Apr 16 22:03:10 1998 *************** *** 97,106 **** body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n\n%s" % (self._mime_separator, self.next_post_number, ! fromline, date, subject, body)) self.next_post_number = self.next_post_number + 1 topics_file.close() --- 97,116 ---- body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) + try: + if self.reply_goes_to_list: + maybe_replyto='Reply-To: %s\n' % ( + self.QuoteMime(self.GetListEmail()),) + else: + maybe_replyto='' + except: + self.LogMsg("error", + "mm_digest: tried to include reply-to - not quite") + digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n%s\n%s" % (self._mime_separator, self.next_post_number, ! fromline, date, subject, maybe_replyto, body)) self.next_post_number = self.next_post_number + 1 topics_file.close() *************** *** 185,198 **** Subject: Contents of %s digest, Volume %d #%d Date: %s ! When replying, please edit your Subject line so it is more specific than "Re: Contents of %s digest..." Send %s maillist submissions to %s To subscribe or unsubscribe via the web, visit %s ! or send email to %s Topics for this digest: %s --- 195,210 ---- Subject: Contents of %s digest, Volume %d #%d Date: %s ! When replying, please edit your Subject line to be more specific than just "Re: Contents of %s digest..." Send %s maillist submissions to %s To subscribe or unsubscribe via the web, visit %s ! or send email to ! %s ! A message saying just 'help' (without the quotes) will give you a guide. Topics for this digest: %s *************** *** 200,207 **** msg.GetSender(), self.real_name, self.volume, self.next_digest_number, time.ctime(time.time()), ! self.real_name, self.GetListEmail(), ! self.real_name, self.GetScriptURL('listinfo'), self.GetRequestEmail(), topics_text) --- 212,219 ---- msg.GetSender(), self.real_name, self.volume, self.next_digest_number, time.ctime(time.time()), ! self.real_name, self.real_name, ! self.GetListEmail(), self.GetScriptURL('listinfo'), self.GetRequestEmail(), topics_text) *** cron/crontab.in~ Fri Apr 3 03:16:29 1998 --- cron/crontab.in Thu Apr 16 20:52:38 1998 *************** *** 2,8 **** 0 17 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdbs # # Noon, mail digests for lists that do periodic as well as threshhold delivery. ! 0 12 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdigests # # 5 AM on the first of each month, mail out password reminders. 0 5 1 * * /usr/local/bin/python /home/mailman/mailman/cron/mailpasswds --- 2,8 ---- 0 17 * * * /usr/local/bin/python /home/mailman/mailman/cron/checkdbs # # Noon, mail digests for lists that do periodic as well as threshhold delivery. ! 0 12 * * * /usr/local/bin/python /home/mailman/mailman/cron/senddigests # # 5 AM on the first of each month, mail out password reminders. 0 5 1 * * /usr/local/bin/python /home/mailman/mailman/cron/mailpasswds From scott@chronis.icgroup.com Mon Apr 20 00:08:02 1998 From: scott@chronis.icgroup.com (Scott) Date: Sun, 19 Apr 1998 19:08:02 -0400 Subject: [Mailman-developers] small bug with roster (and patch) Message-ID: <19980419190802.25426@chronis.icgroup.com> It seems like cgi/roster was treating lists whose roster subscribers are viewable by members of the list as only viewable by the admin. looks like an indentation error. here's a patch: *** roster Sun Apr 19 19:04:17 1998 --- roster.dist Sun Apr 19 19:05:24 1998 *************** *** 56,66 **** mm_err.MMBadPasswordError): bad = ("%s subscriber authentication failed." % list.real_name) ! else: ! # Anonymous list - admin-only visible ! # - and we already tried admin password, above. ! bad = ("%s admin authentication failed." ! % list.real_name) if bad: doc = error_page_doc(bad) doc.AddItem(list.GetMailmanFooter()) --- 56,66 ---- mm_err.MMBadPasswordError): bad = ("%s subscriber authentication failed." % list.real_name) ! else: ! # Anonymous list - admin-only visible ! # - and we already tried admin password, above. ! bad = ("%s admin authentication failed." ! % list.real_name) if bad: doc = error_page_doc(bad) doc.AddItem(list.GetMailmanFooter()) scott From scott@chronis.icgroup.com Mon Apr 20 12:37:40 1998 From: scott@chronis.icgroup.com (Scott) Date: Mon, 20 Apr 1998 07:37:40 -0400 Subject: [Mailman-developers] membership management developments Message-ID: <19980420073740.52669@chronis.icgroup.com> I have made of number of changes to membership management in my copy of mailman. First, the mass subscribe function now checks the emails, reports any errors found, and reports successfull subscriptions. i changed the error check for emails to demand a host name part, as it seemed to make sense that way. Second, there is a much more succint interface to unsubscribing members and/or changing their options. This section is hidden behind password authentication, but is still part of the "members" category in the admin cgi. to see what these changes look like, please feel free to see http://chronis.icgroup.com/mailman/admin/postal/members (password postal). i think a little more explanation of the member options is in order on the page, but appreciate any and all feedback. Since these changes have taken place after applying a few patches posted here, and i've become a bit confused as to which version is which at this point in time, i'm simply making a tarball snapshot of the modules in the mailman/modules directory and the scripts in the mailman/cgi available at ftp://chronis.icgroup.com/pub/mm_mod+cgi.tgz Scott Cotton IC Group, Inc. From scott@chronis.icgroup.com Mon Apr 20 22:06:33 1998 From: scott@chronis.icgroup.com (Scott) Date: Mon, 20 Apr 1998 17:06:33 -0400 Subject: [Mailman-developers] membership management developments In-Reply-To: ; from Janne Sinkkonen on Mon, Apr 20, 1998 at 06:53:50PM +0300 References: <19980420073740.52669@chronis.icgroup.com> Message-ID: <19980420170633.30680@chronis.icgroup.com> On Mon, Apr 20, 1998 at 06:53:50PM +0300, Janne Sinkkonen wrote: | Scott writes: | | > to see what these changes look like, please feel free to see | > http://chronis.icgroup.com/mailman/admin/postal/members (password | > postal). i think a little more explanation of the member options is | > in order on the page, but appreciate any and all feedback. | | Seems great. | | A couple of problems though. I get this when trying to get to the 'privacy | options' page: woops. thanks. lets see, each mailling needs to have an attribute defined (confirm_subscribe). (1= on, 0=off). try this: import mm_utils, maillist for listname in mm_utils.list_names(): list = maillist.MailList(listname) list.confirm_subscribe = 0 # or 1 list.Save() | | Traceback (innermost last): | File "/home/mailman/mailman/cgi/admin", line 682, in ? | main() | File "/home/mailman/mailman/cgi/admin", line 124, in main | FormatConfiguration(doc, list, category, category_suffix, cgi_data) | File "/home/mailman/mailman/cgi/admin", line 256, in FormatConfiguration | form.AddItem(FormatOptionsSection(category, list, cgi_data)) | File "/home/mailman/mailman/cgi/admin", line 305, in FormatOptionsSection | big_table.AddRow(GetGuiItem(item, category, list)) | File "/home/mailman/mailman/cgi/admin", line 372, in GetGuiItem | gui_part = RadioButtonArray(varname, params, getattr(list, varname)) | AttributeError: confirm_subscribe | | | Another problem is that with a large mailing list, Netscape draws the | members page with all the options switch very very slowly (making the | page useless, actually). i anticipated as much, and will be working on making it separate the list mmebers table into chunks if the list is large enough over the next few days. One problem that will need to be solved in this respect is authentication. Is it too annoying to require the password for viewing each chunk? is it acceptable to use cookies for authentication of this section? what should the cutoff size of the list be for chunkifying the section? thanks for your feedback Scott From scott@chronis.icgroup.com Thu Apr 16 03:20:37 1998 From: scott@chronis.icgroup.com (Scott) Date: Wed, 15 Apr 1998 22:20:37 -0400 Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: ; from Janne Sinkkonen on Thu, Apr 16, 1998 at 02:38:37AM +0300 References: Message-ID: <19980415222037.22717@chronis.icgroup.com> On Thu, Apr 16, 1998 at 02:38:37AM +0300, Janne Sinkkonen wrote: | | I have several minor things: [...] | I would also like to ask about the archives. The README says | 'integrated with [...] external pipermail'. :) Besides the links and | authorization service provided, what does this mean in practice? | Should I run piper-hypermail from a crontab or is there something | better around somewhere? Not that i know of. It's honestly taken me about as long to get private archiving working on a list on my system as it did to develop the confirmation step in subscribing. I don't doubt that mailman and pipermail should be separate packages, but it sure would be nice to have drop-in archiving available with the new pipermail. From what i understand, this would probably involve writing a custom archiving class from the pipermail.T class, that deals with archive volume incrementing and can present a cgi interface to the list admin. any takers? Scott From klm@python.org Mon Apr 20 23:43:24 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 20 Apr 1998 18:43:24 -0400 (EDT) Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: <19980415222037.22717@chronis.icgroup.com> Message-ID: (I probably should have first posted a note mentioning that i was approving a posting of scott's that was held due to not explicitly mentioning the mailman-developer's list name among the recipients - that's why his 5 day old posting just showed... Ken.) From janne@avocado.pc.helsinki.fi Tue Apr 21 12:28:48 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 21 Apr 1998 14:28:48 +0300 Subject: [Mailman-developers] Mailer daemons on the list Message-ID: I found two mailer daemons from my mailing list. Not good. :) Here's a theory of how they ended up there: somebody has sent a 'help' to the list-request address. Mailman has replied, but for some reason the reply address has been dysfunctional. The mailer daemon then sends a bounce to the list-request address with the help message in an attachment. mailman processes the message, finds 'subscribe' in there, and subscribes. Would it be possible to include some kind of tag or cookie (maybe an X header) in the outgoing messages? We could then search every incoming request message for the tag, and if we find one, we would then know the history of the message. -- Janne From scott@chronis.icgroup.com Tue Apr 21 16:59:27 1998 From: scott@chronis.icgroup.com (Scott) Date: Tue, 21 Apr 1998 11:59:27 -0400 Subject: [Mailman-developers] membership management developments: chunkifying Message-ID: <19980421115927.08362@chronis.icgroup.com> i have somehow managed to get the membership management section chunkified, with proper authentication. there is a new variable in mm_defaults called DEFAULT_CHUNK_SIZE, which as commented sets the size of the chunk of members presented at a time to admins editing their options/ unsubscribing them. this section of membership management uses cookie authentication. As Authentication is getting particulary messy in the program cgi/admin, i wouldn't suggest (m)any futher develops that involve special authentication without rewriting the script from the bottom up. anyway, here is a patch, as applied against the distribution version that i posted about the other day that does an improved job of membership management stuff. scott Index: cgi/admin =================================================================== RCS file: /usr/local/cvsroot/mailman/cgi/admin,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 admin *** admin 1998/04/21 03:27:57 1.1.1.1 --- admin 1998/04/21 15:45:15 *************** *** 9,17 **** --- 9,20 ---- import sys sys.path.append('/home/mailman/mailman/modules') + # XXX need to fix this, this directory should be configurable. + sys.path.append('/home/mailman/cgi-bin') import os, cgi, string, crypt, types import mm_utils, maillist, mm_cfg, mm_err from htmlformat import * + import Cookie try: sys.stderr = mm_utils.StampedLogger("error", label = 'admin', *************** *** 27,32 **** --- 30,38 ---- ('bounce', "Bounce Options"), ('archive', "Archival Options")] + # + # XXX this this data is also in mm_mailcmd (i think), it should become shared + # option_info = { 'digest' : 0, 'nomail' : mm_cfg.DisableDelivery, 'norcv' : mm_cfg.DontReceiveOwnPosts, *************** *** 36,42 **** } - def main(): """Process and produce list options form. --- 42,47 ---- *************** *** 80,86 **** FormatOptionHelp(doc, cgi_data['VARHELP'].value, list) print doc.Format(bgcolor="#ffffff") return ! if not cgi_data.has_key('adminpw'): AddErrorMessage(doc, 'Error: You must supply the admin password to' ' change options.') --- 85,125 ---- FormatOptionHelp(doc, cgi_data['VARHELP'].value, list) print doc.Format(bgcolor="#ffffff") return ! if cgi_data.has_key('adminpw') and cgi_data.has_key('edit_members'): ! adminpw = cgi_data["adminpw"] ! if type(adminpw) is type([]): ! adminpw = adminpw[0].value # use the first one, i guess -scott cotton ! else: ! adminpw = adminpw.value ! try: ! list.ConfirmAdminPassword(adminpw) ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! c = Cookie.Cookie() ! c[list.real_name] = hash(list.real_name) ! print c ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 1) ! print doc.Format(bgcolor="#ffffff") ! return ! elif cgi_data.has_key('chunk'): ! if os.environ.has_key("HTTP_COOKIE"): ! cookie = Cookie.Cookie(os.environ["HTTP_COOKIE"]) ! if cookie.has_key(list.real_name): ! if cookie[list.real_name].value == hash(list.real_name): ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! print doc.Format(bgcolor="#ffffff") ! return ! else: ! AddErrorMessage(doc, "Error: Invalid Cookie value") ! else: ! AddErrorMessage(doc, "Error, no cookie for list!") ! else: ! AddErrorMessage(doc, "no cookie!") ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) ! print doc.Format(bgcolor="#ffffff") ! return ! elif not cgi_data.has_key('adminpw') : AddErrorMessage(doc, 'Error: You must supply the admin password to' ' change options.') *************** *** 90,103 **** adminpw = adminpw[0].value # use the first one, i guess -scott cotton else: adminpw = adminpw.value ! try: list.ConfirmAdminPassword(adminpw) ! ChangeOptions(list, category, cgi_data, doc) # Yuck. This shouldn't need to be here. WTF?!? ! if not list.digestable and not list.nondigestable: list.nondigestable = 1 ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') if not list.digestable and len(list.digest_members): AddErrorMessage(doc, --- 129,142 ---- adminpw = adminpw[0].value # use the first one, i guess -scott cotton else: adminpw = adminpw.value ! try: list.ConfirmAdminPassword(adminpw) ! ChangeOptions(list, category, cgi_data, doc) # Yuck. This shouldn't need to be here. WTF?!? ! if not list.digestable and not list.nondigestable: list.nondigestable = 1 ! except mm_err.MMBadPasswordError: ! AddErrorMessage(doc, 'Error: Incorrect admin password.') if not list.digestable and len(list.digest_members): AddErrorMessage(doc, *************** *** 121,127 **** ' (does it have the colon?)

    %s
', line) ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) print doc.Format(bgcolor="#ffffff") finally: --- 160,169 ---- ' (does it have the colon?)
    %s
', line) ! if cgi_data.has_key('edit_member_options'): # passwd already checked ! FormatConfiguration(doc, list, category, category_suffix, cgi_data, 0) ! else: ! FormatConfiguration(doc, list, category, category_suffix, cgi_data) print doc.Format(bgcolor="#ffffff") finally: *************** *** 204,210 **** print doc.Format(bgcolor="#ffffff") ! def FormatConfiguration(doc, list, category, category_suffix, cgi_data): """Produce the overall doc, *except* any processing error messages.""" for k, v in CATEGORIES: if k == category: label = v --- 246,252 ---- print doc.Format(bgcolor="#ffffff") ! def FormatConfiguration(doc, list, category, category_suffix, cgi_data, front_page=1): """Produce the overall doc, *except* any processing error messages.""" for k, v in CATEGORIES: if k == category: label = v *************** *** 253,269 **** " bottom. (You can also change your password there," " as well.)

") ! form.AddItem(FormatOptionsSection(category, list, cgi_data)) form.AddItem(Center(FormatPasswordStuff())) form.AddItem(list.GetMailmanFooter()) ! def FormatOptionsSection(category, list, cgi_data): """Produce the category-specific options table.""" if category == 'members': # Special case for members section. ! return FormatMembershipOptions(list, cgi_data) options = GetConfigOptions(list, category) big_table = Table(cellspacing=3, cellpadding=4) --- 295,311 ---- " bottom. (You can also change your password there," " as well.)

") ! form.AddItem(FormatOptionsSection(category, list, cgi_data, front_page)) form.AddItem(Center(FormatPasswordStuff())) form.AddItem(list.GetMailmanFooter()) ! def FormatOptionsSection(category, list, cgi_data, front_page): """Produce the category-specific options table.""" if category == 'members': # Special case for members section. ! return FormatMembershipOptions(list, cgi_data, front_page) options = GetConfigOptions(list, category) big_table = Table(cellspacing=3, cellpadding=4) *************** *** 398,404 **** descr = descr + "" return [descr, gui_part] ! def FormatMembershipOptions(list, cgi_data, option_info=option_info): container = Container() header = Table(width="100%") header.AddRow([Center(Header(2, "Membership Management"))]) --- 440,446 ---- descr = descr + "" return [descr, gui_part] ! def FormatMembershipOptions(list, cgi_data, front_page=1, option_info=option_info): container = Container() header = Table(width="100%") header.AddRow([Center(Header(2, "Membership Management"))]) *************** *** 408,428 **** header.AddCellInfo(max(header.GetCurrentRowIndex(), 0), 0, colspan=2, bgcolor ="#FFF0D0") container.AddItem(header) ! if cgi_data.has_key("adminpw"): ! adminpw = cgi_data["adminpw"] ! if type(adminpw) is type([]): # admin password specified more than once ! adminpw = adminpw[0].value # use the first one, i guess ! else: ! adminpw = adminpw.value ! try: ! list.ConfirmAdminPassword(adminpw) ! confirmed = 1 ! except (mm_err.MMBadPasswordError): ! confirmed = 0 ! else: ! confirmed = 0 ! if not cgi_data.has_key('edit_members') or (cgi_data.has_key('edit_members') and ! not confirmed): container.AddItem(Center('\n

To Unsubscribe Members or Edit their Options...

')) container.AddItem(Center(""" Enter the adminitrative password: --- 450,456 ---- header.AddCellInfo(max(header.GetCurrentRowIndex(), 0), 0, colspan=2, bgcolor ="#FFF0D0") container.AddItem(header) ! if front_page: container.AddItem(Center('\n

To Unsubscribe Members or Edit their Options...

')) container.AddItem(Center(""" Enter the adminitrative password: *************** *** 435,465 **** else: user_table = Table(width="90%") digest_user_table = Table(width="90%") ! user_table.AddRow([Center(Header(4, "Members"))]) user_table.AddCellInfo(user_table.GetCurrentRowIndex(), user_table.GetCurrentCellIndex(), bgcolor="#cccccc", colspan=8) for member in list.members: ! cells = [member, ! "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), ! "digest " + CheckBox(member+"_digest", "off").Format(), ! ] ! for opt in ("hide", "nomail", "ack", "norcv", "plain"): ! if list.GetUserOption(member, option_info[opt]): ! value = "on" ! checked = 1 ! else: ! value = "off" ! checked = 0 ! box = CheckBox("%s_%s" % (member, opt), value, checked) ! cells.append("%s %s" % (opt, box.Format())) ! user_table.AddRow(cells) for member in list.digest_members: ! cells = [member, "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), - "digest " + CheckBox(member+"_digest", "on", 1).Format(), ] for opt in ("hide", "nomail", "ack", "norcv", "plain"): if list.GetUserOption(member, option_info[opt]): value = "on" --- 463,508 ---- else: user_table = Table(width="90%") digest_user_table = Table(width="90%") ! user_table.AddRow([Center(Header(4, "Membership List"))]) user_table.AddCellInfo(user_table.GetCurrentRowIndex(), user_table.GetCurrentCellIndex(), bgcolor="#cccccc", colspan=8) + members = {} + digests = {} for member in list.members: ! members[member] = 1 for member in list.digest_members: ! digests[member] = 1 ! all = list.members + list.digest_members ! if len(all) > mm_cfg.DEFAULT_CHUNK_SIZE: ! chunks = mm_utils.chunkify(all) ! if not cgi_data.has_key("chunk"): ! chunk = 0 ! else: ! chunk = string.atoi(cgi_data["chunk"].value) ! all = chunks[chunk] ! footer = ("

To View other sections, click on the appropriate range listed below") ! chunk_indices = range(len(chunks)) ! chunk_indices.remove(chunk) ! buttons = [] ! pi = os.environ["PATH_INFO"] ! for ci in chunk_indices: ! start, end = chunks[ci][0], chunks[ci][-1] ! buttons.append(" from %s to %s " % ( pi, ci, start, end)) ! buttons = apply(UnorderedList, tuple(buttons)) ! footer = footer + buttons.Format() + "

" ! else: ! all.sort() ! footer = "

" ! for member in all: ! cells = [member + "" % (member), "subscribed " +CheckBox(member + "_subscribed", "on", 1).Format(), ] + if members.get(member): + cells.append("digest " + CheckBox(member + "_digest", "off", 0).Format()) + else: + cells.append("digest " + CheckBox(member + "_digest", "on", 1).Format()) for opt in ("hide", "nomail", "ack", "norcv", "plain"): if list.GetUserOption(member, option_info[opt]): value = "on" *************** *** 471,483 **** cells.append("%s %s" % (opt, box.Format())) user_table.AddRow(cells) container.AddItem(Center(user_table)) # trigger member list viewing again and change_options with hidden tags... # password authentication is still done, so this should be safe ! container.AddItem("" ! "

") ! container.AddItem("Back to Mass Subscribing

" % \ ! (list.real_name)) ! return container def FormatPasswordStuff(): --- 514,529 ---- cells.append("%s %s" % (opt, box.Format())) user_table.AddRow(cells) container.AddItem(Center(user_table)) + t = Table(width="90%") + t.AddRow([Center(Header(4, "Back to Mass Subscriptions" % list.real_name))]) + t.AddCellInfo(t.GetCurrentRowIndex(), + t.GetCurrentCellIndex(), + bgcolor="#cccccc", colspan=8) + container.AddItem(Center(t)) + container.AddItem(footer) # trigger member list viewing again and change_options with hidden tags... # password authentication is still done, so this should be safe ! container.AddItem("") return container def FormatPasswordStuff(): *************** *** 590,620 **** if getattr(list, property) != value: setattr(list, property, value) dirty = 1 - elif cgi_info.has_key('edit_member_options'): - members = [] - digest_members = [] - org_user_opts = list.user_options.copy() - for member in (list.members + list.digest_members)[:]: - if not cgi_info.has_key(member + "_subscribed"): - list.DeleteMember(member, "cgi: admin/members") - continue - if not cgi_info.has_key(member + "_digest"): # no digest - members.append(member) - else: - digest_members.append(member) - for opt in ("hide", "nomail", "ack", "norcv", "plain"): - if cgi_info.has_key("%s_%s" % (member, opt)): - list.SetUserOption(member, option_info[opt], 1) - else: - list.SetUserOption(member, option_info[opt], 0) - if (list.user_options != org_user_opts): - dirty = 1 - if list.members != members: - list.members = members - dirty = 1 - if list.digest_members != digest_members: - list.digest_members = digest_members - dirty = 1 elif cgi_info.has_key('subscribees'): name_text = cgi_info['subscribees'].value name_text = string.replace(name_text, '\r', '') --- 636,641 ---- *************** *** 644,649 **** --- 665,705 ---- items = map(lambda x: "%s -- %s" % (x[0], x[1]), subscribe_errors) document.AddItem(apply(UnorderedList, tuple((items)))) document.AddItem("

") + elif cgi_info.has_key("user"): + user = cgi_info["user"] + if type(user) is type([]): + users = [] + for ui in range(len(user)): + users.append(user[ui].value) + else: + users = [user.value] + for user in users: + if not cgi_info.has_key('%s_subscribed' % (user)): + list.DeleteMember(user) + dirty = 1 + continue + if not cgi_info.has_key("%s_digest" % (user)): + if user in list.digest_members: + list.digest_members.remove(user) + dirty = 1 + if user not in list.members: + list.members.append(user) + dirty = 1 + else: + if user not in list.digest_members: + list.digest_members.append(user) + dirty = 1 + if user in list.members: + list.members.remove(user) + dirty = 1 + + for opt in ("hide", "nomail", "ack", "norcv", "plain"): + if cgi_info.has_key("%s_%s" % (user, opt)): + list.SetUserOption(user, option_info[opt], 1) + dirty = 1 + else: + list.SetUserOption(user, option_info[opt], 0) + dirty = 1 if cgi_info.has_key('newpw'): if cgi_info.has_key('confirmpw'): new = cgi_info['newpw'].value *************** *** 661,667 **** m = 'Error: You must type in your new password twice.' document.AddItem( Header(3, Italic(FontAttr(m, color="ff5060")))) ! if dirty: list.Save() --- 717,723 ---- m = 'Error: You must type in your new password twice.' document.AddItem( Header(3, Italic(FontAttr(m, color="ff5060")))) ! if dirty: list.Save() Index: modules/mm_defaults.py =================================================================== RCS file: /usr/local/cvsroot/mailman/modules/mm_defaults.py,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 mm_defaults.py *** mm_defaults.py 1998/04/21 03:27:58 1.1.1.1 --- mm_defaults.py 1998/04/21 15:52:05 *************** *** 37,42 **** --- 37,48 ---- HOME_PAGE = 'index.html' MAILMAN_OWNER = 'mailman-owner@%s' % DEFAULT_HOST_NAME + # + # break up presentation of editing member options under admin/listname/members + # into chunks of this size. + # + DEFAULT_CHUNK_SIZE=20 + # System ceiling on number of batches into which deliveries are divided: MAX_SPAWNS = 40 Index: modules/mm_utils.py =================================================================== RCS file: /usr/local/cvsroot/mailman/modules/mm_utils.py,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 mm_utils.py *** mm_utils.py 1998/04/21 03:27:58 1.1.1.1 --- mm_utils.py 1998/04/21 08:27:54 *************** *** 394,400 **** --- 394,418 ---- Logger.write(self, l) + def chunkify(members, chunksize=mm_cfg.DEFAULT_CHUNK_SIZE): + """ + return a list of lists of members + """ + members.sort() + res = [] + while 1: + if not members: + break + chunk = members[:chunksize] + res.append(chunk) + members = members[chunksize:] + return res + + + + + From klm@python.org Thu Apr 23 15:45:34 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 10:45:34 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: Message-ID: On Thu, 23 Apr 1998, Dmitry Khrustalev wrote: > Can the person responsible for python.org mailing lists fix mailman so it > will understand .su TLD (add "su" to valid_toplevels at > modules/mm_utils.py line 16)? > > I tried contacting postmaster@python.org and mailman list, but have not > heard back for several weeks. I've added it in. Sorry about the non-acknowledgement of your pleas for help - looking back through my inbox i see that your complaints arrived here last wednesday, the fifteenth, just when i left for around a week vacation - and i hadn't gotten to them when i returned. My apologies for missing it. Furthermore, i do have some questions about the strategy of qualifying registration addresses according to matches against a static list of known top level domains - i'd be interested to hear input about this on the mailman-developers list... Finally, dmitry, thanks for going so far as to track down the specific changes that needed to be done - that was beyond the call of duty. Sorry that this got in the way of participating in the python.org mailing lists! Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From guido@CNRI.Reston.Va.US Thu Apr 23 15:56:05 1998 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 23 Apr 1998 10:56:05 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: Your message of "Thu, 23 Apr 1998 10:45:34 EDT." References: Message-ID: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Ken writes: > Furthermore, i do have some questions about the strategy of qualifying > registration addresses according to matches against a static list of > known top level domains - i'd be interested to hear input about this on > the mailman-developers list... I think this is bogus; as Dmitri's mail shows it is a maintenance nightmare waiting to happen. If you really want to do a validation of an email address, use DNS to see if there's a host by that name or an MX record for that domain. What is the reason for validating addresses in the first place? If the address is invalid, the mail will bounce and the user won't be registered. Simple. Effective. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Apr 23 16:07:59 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 23 Apr 1998 11:07:59 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <13631.22799.878382.457222@anthem.CNRI.Reston.Va.US> >>>>> "Guido" == Guido van Rossum writes: Guido> I think this is bogus; as Dmitri's mail shows it is a Guido> maintenance nightmare waiting to happen. If you really Guido> want to do a validation of an email address, use DNS to see Guido> if there's a host by that name or an MX record for that Guido> domain. What is the reason for validating addresses in the Guido> first place? If the address is invalid, the mail will Guido> bounce and the user won't be registered. Simple. Guido> Effective. I agree with Guido on all counts. TLD's probably don't change that often, but if they do, you'll have to propagate changes to everyone who's running MM. That's DNS's job! -Barry From roy@endeavor.med.nyu.edu Thu Apr 23 16:14:00 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Thu, 23 Apr 1998 11:14:00 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <585634.3102318840@qwerky.med.nyu.edu> "Barry A. Warsaw" wrote: > TLD's probably don't change that often Didn't they just open up two more (.to and .cc) recently? I absolutely agree, taking any information in the DNS and committing it to a static file is a recipie for disaster in the long-term. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From klm@python.org Thu Apr 23 16:22:06 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 11:22:06 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: On Thu, 23 Apr 1998, Guido van Rossum wrote: > Ken writes: > > > Furthermore, i do have some questions about the strategy of qualifying > > registration addresses according to matches against a static list of > > known top level domains - i'd be interested to hear input about this on > > the mailman-developers list... > > I think this is bogus; as Dmitri's mail shows it is a maintenance > nightmare waiting to happen. If you really want to do a validation of > an email address, use DNS to see if there's a host by that name or an > MX record for that domain. What is the reason for validating > addresses in the first place? If the address is invalid, the mail > will bounce and the user won't be registered. Simple. Effective. While i'm inclined to agree about the list-of-known-domains check being too maintenance intensive, i do see a reason to have the check in the first place. The benefit comes into play when the web interface is in play - the user is there, and can get definite feedback about faulty addresses. Without it, they only see address failures as the absence of any subscription confirmation - a decidedly vague and uncertain kind of feedback. At this point i'm inclined to withdraw the known-domains criterion, but leave in the more definite, unchanging criterion, like presence of an '@' sign. Ken From jtv2j@cs.virginia.edu Thu Apr 23 17:17:40 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 23 Apr 1998 12:17:40 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804231617.MAA13842@adder.cs.Virginia.EDU> Oh, wow, I can not believe I ever left that code in anything I ever passed out. That was added in the first day before I put any real thought into authorization. My apologies for anyone it inconvenienced. From scott@chronis.pobox.com Thu Apr 23 18:18:45 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 13:18:45 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: ; from Ken Manheimer on Thu, Apr 23, 1998 at 11:22:06AM -0400 References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <19980423131845.48270@chronis.icgroup.com> On Thu, Apr 23, 1998 at 11:22:06AM -0400, Ken Manheimer wrote: | On Thu, 23 Apr 1998, Guido van Rossum wrote: | | > Ken writes: | > [...] | At this point i'm inclined to withdraw the known-domains criterion, but | leave in the more definite, unchanging criterion, like presence of an | '@' sign. | | Ken sounds good. maybe make sure there's atleast a dot in there to signify a FQDN. scott From klm@python.org Fri Apr 24 00:10:05 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:10:05 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <19980415230936.53080@chronis.icgroup.com> Message-ID: Hi, all. I'm finally getting my head back to the surface after returning, and starting to catch up on some of the mailman comments and developments. I also have some new items of my own to throw in the mix. On Wed, 15 Apr 1998, Scott wrote: > proposal concerning web based subscriptions: > > *allways* use confirmation, even if the list doesn't require them via > email. I'm a little confused about what you're saying. By "even if the list doesn't require them via email", are you referring to the admin approval option? Are you basically saying, don't allow the option of unconfirmed subscriptions? If so, i'm not sure what i think of this. I can see how it would usually be the right thing (tm) to require some kind of confirmation - currently either email from the user or administrator approval. To some degree, allowing unconfirmed subscriptions can amount to being a bad neighbor. It reminds me of the gun debate - how much should we protect people from each other. ("Guns don't kiss people, people kiss people." Or something:-) I guess the question is, are there valid reasons to have lists that take wholly unconfirmed subscriptions? If we're confident there aren't any lurking around the corner, then fine, lets close that door. > If you don't, it's a security hole for any mailing list that doesn't > implement it, and for out of service-attacks against the system > mailman on which mailman is running. Even if a list is not advertised, > it is still vulnerable to this, as an "attacker" could well find out > the name of list by other means. Well, it does occur to me that a list that allows unconfirmed subscriptions but also requires membership for posting privilege would not be susceptable in the simple way to denial-of-service attacks. Along related lines, it does occur to me that we should prevent mail loops, where either the list is subscribed to itself, or where some reflector loops back to the list. (The former situation was hinted at this afternoon, when someone accidentally specified the matrix-sig as their address for subscription *to* matrix-sig list; all it did was post the subscription instructions to the list, but it would have subscribed the list to itself if there was no confirmation...) What i'm doing is adding a header, "X-BeenThere: ", which will be detected and cause a hold of the message for approval, if encountered. Ken From klm@python.org Fri Apr 24 00:25:55 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:25:55 -0400 (EDT) Subject: [Mailman-developers] Double Reply-To:, answer_majordomo_mail, archives In-Reply-To: Message-ID: On 16 Apr 1998, Janne Sinkkonen wrote: > Second, here's a working answer_majordomo_mail script. The script in > 1.0b12 didn't work for me (the patch would be larger than the script > itself, hence I include this here): Included below is about what you suggested, but with what i would like to see as canonical provision for logging in mailman scripts. (Any of the scripts that i actually concentrated on have this provision, instead of the hard-wired - and failure prone - file logging.) > I would also like to ask about the archives. The README says > 'integrated with [...] external pipermail'. :) Besides the links and > authorization service provided, what does this mean in practice? > Should I run piper-hypermail from a crontab or is there something > better around somewhere? Perhaps i got a bit carried away with marketing speak. The idea is exactly that - run pipermail (or whatever archiver you want) externally, eg from crontab. Someone i know is planning to run an archiver that revises the archive as each new message comes in, but if you're using something, like pipermail, that watches a file for changes, then setting private or public archives will place the mbox file in the respective archives directory, which is the way the distinction is communicated to the external archiver. (I suppose an X-header could be added to private-archive messages, for the benefit of recipient-based archivers. Does that make sense? I'm a bit worried about sending out messages that are increasingly header heavy - adding a header seems to offer a solution to lots of problems...-) My slightly different version of answer_majordomo_mail is included below my sig. Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # Thanks for joining the PSA! # # http://www.python.org/psa/ # #!/usr/local/bin/python # This is another script that's really just for my use, but # feel free to use it if you know how... import sys sys.path.append('/home/mailman/mailman/modules') import mm_message, mm_utils try: sys.stderr = mm_utils.StampedLogger("error", label = 'answer_majordomo_mail', manual_reprime=1) except IOError: pass # Oh well - SOL on redirect, errors show thru. msg = mm_message.IncomingMessage() text = open('/home/mailman/mailman/misc/majordomo.answer.txt', 'r').read() mm_utils.SendTextToUser('Your mail to Majordomo...', text, msg.GetSender(), 'mailman-owner') From klm@python.org Fri Apr 24 00:31:39 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:31:39 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Message-ID: Janne, can you recap your current thinking about the right thing to do about the "Re:" handling w.r.t. the subject line prefix? I gather we don't want to move the "Re:" to after the prefix, because it will interfere with some MUA's thread recognition - and given that, i don't see what more there is to be done... Ken From klm@python.org Fri Apr 24 00:47:50 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:47:50 -0400 (EDT) Subject: [Mailman-developers] More polishing... In-Reply-To: Message-ID: Here's my incorporations of some of janne's patches. On 16 Apr 1998, Janne Sinkkonen wrote: > Below is a set of patches to take care of a few bugs. My earlier patch > to get rid of extra Re:'s is included in a modified form. > > Changes: > 1. No double Reply-To:'s to list mail. Reply-To:'s in some admin mail > still remain. I used "del msg['reply-to']" instead of iterating over the headers. (I had neglected to change some examples just above the added line that do the iteration, so it makes sense that's what you'd do. They're also changed in my version of the patch.) > 2. Get rid of extra Re:'s on the subject line. However, leave > "Re: PREFIX" instead of "PREFIX Re:" - the latter does not work > with some mail readers which use Re: for threading (and there was > some strange problems with answering the mail as well). I'm not doing anything with this one. I don't think mailman should trim extra "Re:"s that someone else added, mailman just should avoid adding extra ones, itself. > 3. Some people wanted to have Reply-To: in every attachment > of a MIME digest (for lists with reply_to_list true). I have implemented just about what you did, *but* i avoided using an unqualified "except" clause. Unqualified except clauses are often evil - they tend to hide bugs, like taking a pain killer to battle heart disease, it's almost always better to see the symptoms. > 4. A bug in digest topic section (wrong argument order to ""%(...)) > corrected. Some polishing of the header (to make it more > useful to the most helpless non-WWW-subscribers). I already put out a patch for the problem (which you had pointed out) on the ftp site - but had different or no polishings. I'll incorporate them soon. > 5. crontab: the right name of the script is senddigests. Whoops! Thanks. Ken ** I hope i got the order of the patch files right! Please double check before applying... ** Index: mm_deliver.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_deliver.py,v retrieving revision 1.20 diff -c -r1.20 mm_deliver.py *** mm_deliver.py 1998/04/15 02:53:01 1.20 --- mm_deliver.py 1998/04/23 23:40:24 *************** *** 113,128 **** if remove_to: # Writing to a file is better than waiting for sendmail to exit tempfile.template = tmpfile_prefix +'mailman-digest.' ! for item in msg.headers: ! if (item[0:3] == 'To:' or ! item[0:5] == 'X-To:'): ! msg.headers.remove(item) msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') --- 113,128 ---- if remove_to: # Writing to a file is better than waiting for sendmail to exit tempfile.template = tmpfile_prefix +'mailman-digest.' ! del msg['to'] ! del msg['x-to'] msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' if self.reply_goes_to_list: + del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) + msg.headers.append('X-BeenThere: %s\n' % self.GetListEmail()) tmp_file_name = tempfile.mktemp() tmp_file = open(tmp_file_name, 'w+') Index: mm_digest.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_digest.py,v retrieving revision 1.18 diff -c -r1.18 mm_digest.py *** mm_digest.py 1998/04/22 16:33:39 1.18 --- mm_digest.py 1998/04/23 22:27:00 *************** *** 97,107 **** body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) ! digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n\n%s" % ! (self._mime_separator, self.next_post_number, ! fromline, date, subject, ! body)) self.next_post_number = self.next_post_number + 1 topics_file.close() digest_file.close() --- 97,112 ---- body = self.QuoteMime(post.body) topics_file.write(" %d. %s (%s)\n" % (self.next_post_number, subject, sender)) ! if self.reply_goes_to_list: ! maybe_replyto=('Reply-To: %s\n' ! % self.QuoteMime(self.GetListEmail())) ! else: ! maybe_replyto='' ! digest_file.write("--%s\n\nMessage: %d" ! "\nFrom: %s\nDate: %s\nSubject: %s\n%s\n%s" % ! (self._mime_separator, self.next_post_number, ! fromline, date, subject, maybe_replyto, ! body)) self.next_post_number = self.next_post_number + 1 topics_file.close() digest_file.close() From scott@chronis.pobox.com Fri Apr 24 00:52:40 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 19:52:40 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: ; from Ken Manheimer on Thu, Apr 23, 1998 at 07:10:05PM -0400 References: <19980415230936.53080@chronis.icgroup.com> Message-ID: <19980423195240.05994@chronis.icgroup.com> On Thu, Apr 23, 1998 at 07:10:05PM -0400, Ken Manheimer wrote: | Hi, all. I'm finally getting my head back to the surface after | returning, and starting to catch up on some of the mailman comments and | developments. I also have some new items of my own to throw in the mix. great! what have you been working on? | On Wed, 15 Apr 1998, Scott wrote: | | > proposal concerning web based subscriptions: | > | > *allways* use confirmation, even if the list doesn't require them via | > email. | | I'm a little confused about what you're saying. By "even if the list | doesn't require them via email", are you referring to the admin approval | option? no, i'm referring to the confirmation step with subscriptions that i've implemented and posted a patch for as well as an ftp location of the changed files. did you see those yet? |Are you basically saying, don't allow the option of unconfirmed | subscriptions? i'm saying don't allow the option of unconfirmed subscriptions via the web. and, if a subscription occurs with the address= option that is implemented in the patches referred to above, then require confirmation. i'd like to make it impossible for a person to subscribe some other unconsenting person to a mailling list. this practice, believe it or not, is quite common at our site. every day somone picks a victim's address and subscribes them to each of the 80-100 lists at our site with open subscription policies. that victim then essentially gets mailbombed in a real bad sortof way. i'd like it if mailman made this impossible. i think listserv makes this impossible by requiring all subscription requests to undergo a confirmation request. | If so, i'm not sure what i think of this. I can see how it would | usually be the right thing (tm) to require some kind of confirmation - | currently either email from the user or administrator approval. To some | degree, allowing unconfirmed subscriptions can amount to being a bad | neighbor. It reminds me of the gun debate - how much should we protect | people from each other. ("Guns don't kiss people, people kiss people." | Or something:-) I guess the question is, are there valid reasons to | have lists that take wholly unconfirmed subscriptions? the only reason i can think of is that people don't want subscribing to involve two steps. i don't personally find this valid given the nature of folks to abuse such services. | If we're | confident there aren't any lurking around the corner, then fine, lets | close that door. | | > If you don't, it's a security hole for any mailing list that doesn't | > implement it, and for out of service-attacks against the system | > mailman on which mailman is running. Even if a list is not advertised, | > it is still vulnerable to this, as an "attacker" could well find out | > the name of list by other means. | | Well, it does occur to me that a list that allows unconfirmed | subscriptions but also requires membership for posting privilege would | not be susceptable in the simple way to denial-of-service attacks. when mailman hosts hundreds of lists on one machine, the accumulated effect of the scenario described above can constitute an out of service attack as well. | Along related lines, it does occur to me that we should prevent mail | loops, where either the list is subscribed to itself, or where some | reflector loops back to the list. (The former situation was hinted at | this afternoon, when someone accidentally specified the matrix-sig as | their address for subscription *to* matrix-sig list; all it did was post | the subscription instructions to the list, but it would have subscribed | the list to itself if there was no confirmation...) What i'm doing is | adding a header, "X-BeenThere: ", which will be detected and | cause a hold of the message for approval, if encountered. that sounds like a good idea. scott From klm@python.org Fri Apr 24 00:52:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 19:52:41 -0400 (EDT) Subject: [Mailman-developers] membership management developments In-Reply-To: <19980420073740.52669@chronis.icgroup.com> Message-ID: Scott, i hope to take a closer look at your revisions tomorrow or this weekend. I'm a bit daunted by the packaging - i don't know how i can incorporate your changes to my version without specific patches for just the changes you made, and some explanation of them. Probably one of the most important aspects of this group-development effort is going to be some discipline to coordinate - otherwise we'll spend more effort trying to synch up than we will actually developing stuff. I *highly* recommend keeping your sources under version control, and really like using CVS to keep a development copy and a production copy. This makes it lots easier to mark releases as a whole, and identify changes since the last release, etc. Anyway, i'll be eager to incorporate your membership management stuff... Ken From klm@python.org Fri Apr 24 01:03:40 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 23 Apr 1998 20:03:40 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <19980423195240.05994@chronis.icgroup.com> Message-ID: On Thu, 23 Apr 1998, Scott wrote: > On Thu, Apr 23, 1998 at 07:10:05PM -0400, Ken Manheimer wrote: > | Hi, all. I'm finally getting my head back to the surface after > | returning, and starting to catch up on some of the mailman comments and > | developments. I also have some new items of my own to throw in the mix. > > great! what have you been working on? Just some small things - a fix to the admin option help mechanism (and displaying the current option setting like on the regular options page - instead of 0/1/2 values for enumerations, you see the setting names on radio button with the right one checked - trivial, i know, but much more civilized...) I've forgotten what else - nothing big, but i'm starting to get a feel for some of the big pending things. > this practice, believe it or not, is quite common at our site. every > day somone picks a victim's address and subscribes them to each of the > 80-100 lists at our site with open subscription policies. that victim > then essentially gets mailbombed in a real bad sortof way. i'd like > it if mailman made this impossible. i think listserv makes this > impossible by requiring all subscription requests to undergo a > confirmation request. Yikes. I'm convinced. > | Along related lines, it does occur to me that we should prevent mail > | loops, where either the list is subscribed to itself, or where some > | reflector loops back to the list. (The former situation was hinted at > | this afternoon, when someone accidentally specified the matrix-sig as > | their address for subscription *to* matrix-sig list; all it did was post > | the subscription instructions to the list, but it would have subscribed > | the list to itself if there was no confirmation...) What i'm doing is > | adding a header, "X-BeenThere: ", which will be detected and > | cause a hold of the message for approval, if encountered. > > that sounds like a good idea. More later. Ken From scott@chronis.pobox.com Fri Apr 24 02:05:41 1998 From: scott@chronis.pobox.com (Scott) Date: Thu, 23 Apr 1998 21:05:41 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <168702.3102354059@mcsv29-p5.med.nyu.edu>; from Roy Smith on Thu, Apr 23, 1998 at 09:00:59PM -0400 References: <168702.3102354059@mcsv29-p5.med.nyu.edu> Message-ID: <19980423210541.15914@chronis.icgroup.com> On Thu, Apr 23, 1998 at 09:00:59PM -0400, Roy Smith wrote: | > the only reason i can think of is that people don't want subscribing | > to involve two steps. i don't personally find this valid given the | > nature of folks to abuse such services. | | I agree. The threat of prank mass subscription is real. We've had it | happen with lists we run here. Not only is it, I would imagine, a nightmare | to the person involved, but it's a real pain to the people running the list | to sort out, especially when the victim starts to flood the list with "stop | this!" messages. | | I don't see any reason to not require a confirmation step by mail. | there seems to be one case where a confirmation step might not be necessary. if someone sends a request via mail to subscribe to a list without requesting that an address other than the sending address be subscribed, maybe that should be allowed sans confirmation. it would still be possible to do mass prank subscriptions, but much more difficult. Scott From roy@endeavor.med.nyu.edu Fri Apr 24 02:15:47 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Thu, 23 Apr 1998 21:15:47 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions Message-ID: <222139.3102354947@mcsv29-p5.med.nyu.edu> Scott wrote: > if someone sends a request via mail to subscribe to a list > without requesting that an address other than the sending address be > subscribed, maybe that should be allowed sans confirmation. it would > still be possible to do mass prank subscriptions, but much more > difficult. Spoofing return addresses is trivial. From scott@chronis.pobox.com Fri Apr 24 08:18:27 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 24 Apr 1998 03:18:27 -0400 Subject: [Mailman-developers] access to admin pages Message-ID: <19980424031827.64676@chronis.icgroup.com> i have a little concern about the ability to access administrative pages via the web without password confirmation. there are a number of pieces of displayed information that could lead spammers to view these pages and figure out how to spam lists. for example, anyone can get access to whether a list accepts posts from anyone. anyone can gain access to specific anti-spam measures a list has configured, anyone can gain access to bounce control measures about a list and determine whether or what kind of out of service attack may be possible. for all these reasons, and for the sake of the design of the administrative cgi script, it seems that it may be a good idea to stick the entire interface behind a single login and use cookies from there to allow access. the reason this seems better from a design point of view of the admin script is that i recently spent a good deal of time adding a separate type of authentication to one section. it was quite complicated, as the script was designed for authentication only when changes were requested. as more different things develop under the administrative interface, some of them will require authentication for viewing and some won't. changing around the authentication scheme every time will involve work. it would be much simpler just to have one login at the onset and to cookies from there. thoughts? scott From klm@python.org Sun Apr 26 18:47:28 1998 From: klm@python.org (Ken Manheimer) Date: Sun, 26 Apr 1998 13:47:28 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling Message-ID: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> It looks like there may be a problem, or at least some sendmail (8.8.8) sensitivities, in the way that mailman is mime-encoding the digests. Does anyone have enough MIME acquaintance to have an immediate idea whether or not the current format is correct? In any case, i responded that i would look into the problem tomorrow, and plan to look into using the python distribution mime facilities - in particular mimify.py - to use known quantities for the encoding. Clues would be appreciated... ken manheimer klm@python.org From: postmaster@mch.sni.de To: xml-sig-admin@python.org Cc: Winfried.Magerl@mch.sni.de (Winfried Magerl), Roland.Schad@mch.sbs.de (Roland Schad), Helmut.Peisl@mch.sni.de (Helmut Peisl) Subject: Problems with list xml-sig Date: Fri, 24 Apr 1998 16:49:25 +0200 (MDT) Dear Adminstrator, we have a lot of trouble with your mail sent from xml-sig@python.org It crashes (memory fault) our sendmail V8.8.8 when it attempts to deliver the mail to our local receipient. Worse, it prevents processing the whole queue because it always stumbles over your mail and then it crashes. We have tried a few things and we found that the problems is one specific line in the messageheader: HContent-type: multipart/digest; boundary="__--__--" If we remove this line, everything works fine. We send and receive some ten thousand mails a day and never run into problems like this. Would you please alterate this line so this won't happen again. Thank you very much for your assistance in helping us to solve this problem. Sincerely, Gerald Rinske Postmaster -- Internet Administration Munich Siemens Business Services, 81739 Munich, Germany Internet-Mail: postmaster@mch.sni.de From janne@avocado.pc.helsinki.fi Mon Apr 27 15:36:10 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 17:36:10 +0300 Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: Ken Manheimer's message of "Sun, 26 Apr 1998 13:47:28 -0400 (EDT)" References: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: Ken Manheimer writes: > It looks like there may be a problem, or at least some sendmail > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > digests. I have also received reports of 8.8.8 dumping core (probably) due to MIME digests. Some other mailers complain about the number of attachments. Over 20 seems to be too much for them. -- Janne From jtv2j@cs.virginia.edu Mon Apr 27 15:54:14 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 10:54:14 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling Message-ID: <199804271454.KAA08247@adder.cs.Virginia.EDU> > Ken Manheimer writes: > > > It looks like there may be a problem, or at least some sendmail > > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > > digests. > > I have also received reports of 8.8.8 dumping core (probably) due to > MIME digests. Well, I will report this bug to the sendmail developer today. Can anyone give me more specifics, such as affected operating systems? > Some other mailers complain about the number of attachments. Over 20 > seems to be too much for them. That's sad. It is unfortunate that few mailers deal with MIME digests decently. When I added the feature to mailman, I was wondering why no other package supported MIME digests. I very quickly learned that it is probably because so few mailers support them well if at all. I got so many complaints about the MIME digests that were the mailer's fault, that it became really clear to me that MIME digests need to be off by default until other mail software improves. I think Ken changed the default in the release, but if I haven't said so before, I strongly believe it should be changed back. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:07:15 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:07:15 -0400 (EDT) Subject: [Mailman-developers] what to do with confirmation of web based subscriptions References: <19980415230936.53080@chronis.icgroup.com> <19980423195240.05994@chronis.icgroup.com> Message-ID: <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US> >>>>> "S" == Scott writes: S> i'd like to make it impossible for a S> person to subscribe some other unconsenting person to a S> mailling list. ...while still allowing someone to subscribe to a list using a perfectly valid alternative address. Scott, I haven't seen your patches, but I know that other ML managers handle this in a useful way. They will send a confirmation email to the alternative address that contains a partially random string. The user need only reply to the message and include verbatim this string. This seems like a small hurdle to impose given the important nature of this defense. A small explanation included with the email (along with a link to a detailed Web page) would go a long way to easing any inconvenience. S> the only reason i can think of is that people don't want S> subscribing to involve two steps. i don't personally find this S> valid given the nature of folks to abuse such services. I highly agree! -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:14:01 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:14:01 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: Message-ID: <13636.40995.558852.780976@anthem.CNRI.Reston.Va.US> >>>>> "JS" == Janne Sinkkonen writes: JS> If the 'reply to list' option is set, mailman seems to put an JS> erroneous 'Reply-To:' header into administrative messages as JS> well, for example to reminders to administrators about pending JS> messages. (Then the administrators discuss what to do, and the JS> discussion goes to the list.) Mailman should never add a Reply-to header. Please see the seminal paper on this: "Reply-to" Munging Considered Harmful "Some forms of header munging are helpful, such as special loop-detection headers. Others are questionable. Most are ill-advised or dangerous. Many list adminstrators want to add a Reply-To header that points back to the list. This transformation also is one of the most ill-advised. Some administrators claim that Reply-To munging makes it easier for users to respond to the entire list, and helps encourage list traffic. These benefits are fallacious. Moreover, Reply-To can have harmful -- even dangerous -- effects. If you think Reply-To munging is a good idea, I hope I can change your mind." -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:20:58 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:20:58 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804231456.KAA02566@eric.CNRI.Reston.Va.US> Message-ID: <13636.41496.429080.610494@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> While i'm inclined to agree about the list-of-known-domains KM> check being too maintenance intensive, i do see a reason to KM> have the check in the first place. The benefit comes into KM> play when the web interface is in play - the user is there, KM> and can get definite feedback about faulty addresses. Without KM> it, they only see address failures as the absence of any KM> subscription confirmation - a decidedly vague and uncertain KM> kind of feedback. Couldn't we do the same sort of DNS lookup when the form is submitted? -Barry From jtv2j@cs.virginia.edu Mon Apr 27 16:24:46 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:24:46 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages Message-ID: <199804271524.LAA09791@adder.cs.Virginia.EDU> > Mailman should never add a Reply-to header. Please see the seminal > paper on this: > > "Reply-to" Munging Considered Harmful > While I've certainly been a strong detractor of Reply-to ever since reading that article, there are still those who do not agree. I think adding the reply-to header should be an option, although it should be strongly discouraged. Ugh, I just went to the discussion forum off that page for the first time in quite a while. I see where well over a year ago I suggested that replies to a list should not be sent out to people who are in the TO or CC line (at least as an option). I'm pretty sure that feature is no longer in Mailman, and it should definitely go back in. If someone has time to Mailman hack in the near future, please consider adding that :) John From jtv2j@cs.virginia.edu Mon Apr 27 16:28:32 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:28:32 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804271528.LAA09939@adder.cs.Virginia.EDU> > > >>>>> "KM" == Ken Manheimer writes: > > KM> While i'm inclined to agree about the list-of-known-domains > KM> check being too maintenance intensive, i do see a reason to > KM> have the check in the first place. The benefit comes into > KM> play when the web interface is in play - the user is there, > KM> and can get definite feedback about faulty addresses. Without > KM> it, they only see address failures as the absence of any > KM> subscription confirmation - a decidedly vague and uncertain > KM> kind of feedback. > > Couldn't we do the same sort of DNS lookup when the form is submitted? Well, you can, but that would have a few problems of its own: 1) DNS lookup can be slow. People want instant feedback. 2) Sometimes DNS is flakey, and you might reject a perfectly valid email address. Sendmail will just keep it in a queue and try again periodically, so if it is a transient problem, then no problem. I would say that perhaps the list of domains *should* stay, but not be a requirement. How about, the list gets checked, and gives you a warning but not a fatal error if your address doesn't have one of the listed endings? From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 16:28:41 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 11:28:41 -0400 (EDT) Subject: [Mailman-developers] access to admin pages References: <19980424031827.64676@chronis.icgroup.com> Message-ID: <13636.42009.358344.974724@anthem.CNRI.Reston.Va.US> >>>>> "S" == Scott writes: S> for all these reasons, and for the sake of the design of the S> administrative cgi script, it seems that it may be a good idea S> to stick the entire interface behind a single login and use S> cookies from there to allow access. I agree! From roy@endeavor.med.nyu.edu Mon Apr 27 16:39:42 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Mon, 27 Apr 1998 11:39:42 -0400 Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <689843.3102665982@qwerky.med.nyu.edu> "John Viega" wrote: > 1) DNS lookup can be slow. People want instant feedback. People also want correct operation. Seriously, how long can a DNS lookup take? We're talking about subscribing to a mailing list. This is not an operation one does dozens of times a day. If it takes an extra 15 seconds, who cares? > I would say that perhaps the list of domains *should* stay, but not be > a requirement. How about, the list gets checked, and gives you a > warning but not a fatal error if your address doesn't have one of the > listed endings? By saying you are going to build a file with the names of the top-level domains in it, you are essentially saying you are going to build your own manually maintained DNS cache. Well, DNS already does cacheing. What makes you think you can do a better job of it? If your DNS cache doesn't already have "edu", "com", etc in it, something is very strange. If you seriously only want to check top-level domains (a procedure which have dubious value), you can do it just as well by looking the top-level domain up in the DNS. Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From jtv2j@cs.virginia.edu Mon Apr 27 16:47:56 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 11:47:56 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems Message-ID: <199804271547.LAA11011@adder.cs.Virginia.EDU> > "John Viega" wrote: > > 1) DNS lookup can be slow. People want instant feedback. > > People also want correct operation. Seriously, how long can a DNS lookup > take? We're talking about subscribing to a mailing list. This is not an > operation one does dozens of times a day. If it takes an extra 15 seconds, > who cares? I've seen it take several minutes when a DNS server is quite loaded. I frequently see lookups that take 10-20 seconds. The vast majority of users are typing in the correct thing anyway, and don't want to have to wait around. I'd prefer to catch the most common stuff, and give a speedy response saying, "If you don't get mail from us soon, try again, because we couldn't send mail to your address". From klm@python.org Mon Apr 27 17:00:29 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 12:00:29 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems In-Reply-To: <199804271547.LAA11011@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > > "John Viega" wrote: > > > 1) DNS lookup can be slow. People want instant feedback. > > > > People also want correct operation. Seriously, how long can a DNS lookup > > take? We're talking about subscribing to a mailing list. This is not an > > operation one does dozens of times a day. If it takes an extra 15 seconds, > > who cares? > > I've seen it take several minutes when a DNS server is quite loaded. > I frequently see lookups that take 10-20 seconds. The vast majority of > users are typing in the correct thing anyway, and don't want to have > to wait around. I'd prefer to catch the most common stuff, and give a > speedy response saying, "If you don't get mail from us soon, try > again, because we couldn't send mail to your address". (I'm in the middle of something or i would have responded to several of the items going around at the moment, but i thought i'd chime in on this one immediately. I had also thought about querying the dns to do the address validation, but my gut feeling is that we can't assume we'll be able to do that everywhere in a portable way. I don't even know that we can presume that dns is used everywhere that might run mailman - they might use another name service, like nis/nis+, to deliver global host resolution to individual hosts at the site...) (ken) From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 17:23:00 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 12:23:00 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: <13636.45098.34505.337174@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: >>>>> "JV" == John Viega writes: JV> While I've certainly been a strong detractor of Reply-to ever JV> since reading that article, there are still those who do not JV> agree. I think adding the reply-to header should be an JV> option, although it should be strongly discouraged. Strongly, strongly discouraged. Even include a link that to page and some text saying: "You don't really want to do this, but if you think you do, read this document first". :-) JV> Ugh, I just went to the discussion forum off that page for the JV> first time in quite a while. I see where well over a year ago JV> I suggested that replies to a list should not be sent out to JV> people who are in the TO or CC line (at least as an option). JV> I'm pretty sure that feature is no longer in Mailman, and it JV> should definitely go back in. If someone has time to Mailman JV> hack in the near future, please consider adding that :) I guess you mean Mailman should check the To/CC address against the list of people in the expanded list, and winnow out duplicates. That would be pretty cool. -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 17:24:06 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 12:24:06 -0400 (EDT) Subject: [Mailman-developers] Re: [meta-sig] mailman problems References: <199804271528.LAA09939@adder.cs.Virginia.EDU> Message-ID: <13636.45315.167201.711850@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> Well, you can, but that would have a few problems of its own: JV> 1) DNS lookup can be slow. People want instant feedback. JV> 2) Sometimes DNS is flakey, and you might reject a perfectly JV> valid email address. Sendmail will just keep it in a queue JV> and try again periodically, so if it is a transient problem, JV> then no problem. JV> I would say that perhaps the list of domains *should* stay, JV> but not be a requirement. How about, the list gets checked, JV> and gives you a warning but not a fatal error if your address JV> doesn't have one of the listed endings? Good idea. Optional DNS lookup could be added with a similar non-fatal warning. -Barry From janne@avocado.pc.helsinki.fi Mon Apr 27 18:09:09 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 20:09:09 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: Ken Manheimer's message of "Thu, 23 Apr 1998 19:31:39 -0400 (EDT)" References: Message-ID: Ken Manheimer writes: > Janne, can you recap your current thinking about the right thing to do > about the "Re:" handling w.r.t. the subject line prefix? I gather we > don't want to move the "Re:" to after the prefix, because it will > interfere with some MUA's thread recognition - and given that, i don't > see what more there is to be done... I agree now that Re: should be in front of the prefix, just because of MUA's threading by the Subject: header. However, one Re: seems to be enough, in the sense that nobody (out of 600) on my list has required several Re:'s. Maybe the MUAs do only one-level threading? Some MUAs add a Re: without caring any existing Re:'s. In addition, it seems like some other MUAs (or subscribers) remove the prefix and everything before it, and add a RE:, maybe without caring about any existing Re:'s. What's happening is not completely clear to me, but anyway the result is that in longer threads I see subject lines like Re: Re: PREFIX: RE: Re: So what is this all about? This was with majordomo. When I run mailman with my patch, which does if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: if re.match("(re:? *)*" + re.escape(prefix), subj, re.I): # The subject prefix is there already, possibly with some Re:'s. # Take the extra Re:'s away, leave one before the prefix_mess_rx=re.compile('^(re:? *)*' + re.escape(prefix) + '(re:? *)*', re.I) subj=re.sub(prefix_mess_rx, 'Re: ' + prefix, subj) else: # No prefix yet. subj=prefix+subj msg.SetHeader('Subject', subj) things seem much better. Now I have only three kind of subject lines: PREFIX: So what is this all about? Re: PREFIX: So what is this all about? PREFIX: RE: So what is this all about? As I said, I'm not sure how the third version appears. My proposal is that roughly the following should be done to the Subject line: 1. Remove extra Re:'s, case-insensitively, both before and after the possible prefix. Leave one Re: if there were any. 2. The prefix should appear after the Re:, or first on the line if there aren't any Re:'s. -- Janne From jtv2j@cs.virginia.edu Mon Apr 27 18:13:06 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 13:13:06 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) Message-ID: <199804271713.NAA14323@adder.cs.Virginia.EDU> One thing I've seen some mailers do which I have considered for mailman is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. Any thoughts? From janne@avocado.pc.helsinki.fi Mon Apr 27 18:15:23 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 27 Apr 1998 20:15:23 +0300 Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: John Viega's message of "Mon, 27 Apr 1998 13:13:06 -0400 (EDT)" References: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: John Viega writes: > One thing I've seen some mailers do which I have considered for mailman > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. > > Any thoughts? Sounds acceptable, except that the MUA's threading by Re: could be incapable to resolve these. -- Janne From klm@python.org Mon Apr 27 18:20:16 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 13:20:16 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) In-Reply-To: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > One thing I've seen some mailers do which I have considered for mailman > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. My feeling still is pretty soundly that mailman should do minimal messing with the subject line. It makes sense for it to introduce the prefix, and avoid duplicating it if already there - that seems clearly within the purview of the mailing list. It clearly should not introduce any "Re"s of it's own, and it i do not think it should mess with "Re"s that users introduce. It may be the user's mailer is fucked, and adding re's when it shouldn't - but it doesn't seem to me to be mailman's place to rectify that. Ken From jtv2j@cs.virginia.edu Mon Apr 27 18:25:55 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Mon, 27 Apr 1998 13:25:55 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) Message-ID: <199804271725.NAA14953@adder.cs.Virginia.EDU> > On Mon, 27 Apr 1998, John Viega wrote: > > > One thing I've seen some mailers do which I have considered for mailman > > is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. > > My feeling still is pretty soundly that mailman should do minimal > messing with the subject line. It makes sense for it to introduce the > prefix, and avoid duplicating it if already there - that seems clearly > within the purview of the mailing list. It clearly should not introduce > any "Re"s of it's own, and it i do not think it should mess with "Re"s > that users introduce. It may be the user's mailer is fucked, and adding > re's when it shouldn't - but it doesn't seem to me to be mailman's place > to rectify that. > > Ken To a degree I agree. However, I've been asked for such a feature many times, mainly by people who have mailers that don't thread on their own. If you change Re: to Re[1]: then you'll generally always get an extra Re and will update things properly. That having been said, I guess I'm inclined to agree that it shouldn't be there anyway. From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 18:30:49 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 13:30:49 -0400 (EDT) Subject: [Mailman-developers] Subject line, Re:, subject prefix (a small patch) References: <199804271713.NAA14323@adder.cs.Virginia.EDU> Message-ID: <13636.49313.3187.868570@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> One thing I've seen some mailers do which I have considered JV> for mailman is to collapse Re: Re: into Re[2]: and Re: Re[n]: JV> into Re[n+1]:. Overly cute. I never really liked those type of headers. They quickly get out of sync because not every MUA does this. -Barry From scott@chronis.pobox.com Mon Apr 27 21:20:55 1998 From: scott@chronis.pobox.com (Scott) Date: Mon, 27 Apr 1998 16:20:55 -0400 Subject: [Mailman-developers] what to do with confirmation of web based subscriptions In-Reply-To: <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US>; from Barry A. Warsaw on Mon, Apr 27, 1998 at 11:07:15AM -0400 References: <19980415230936.53080@chronis.icgroup.com> <19980423195240.05994@chronis.icgroup.com> <13636.40494.277373.388061@anthem.CNRI.Reston.Va.US> Message-ID: <19980427162054.23378@chronis.icgroup.com> On Mon, Apr 27, 1998 at 11:07:15AM -0400, Barry A. Warsaw wrote: | | >>>>> "S" == Scott writes: | | S> i'd like to make it impossible for a | S> person to subscribe some other unconsenting person to a | S> mailling list. | | ...while still allowing someone to subscribe to a list using a | perfectly valid alternative address. Scott, I haven't seen your | patches, but I know that other ML managers handle this in a useful | way. They will send a confirmation email to the alternative address | that contains a partially random string. The user need only reply to | the message and include verbatim this string. that is exactly what the patches do. there's still some problems synching the patches with the distribution, but this functionality is what my copy of mailman is doing right now. | This seems like a small hurdle to impose given the important nature of | this defense. A small explanation included with the email (along with | a link to a detailed Web page) would go a long way to easing any | inconvenience. it's all there, except the link to a web page, which sounds like a good idea. thanks for the feedback. scott From klm@python.org Mon Apr 27 22:03:20 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:03:20 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: I'm surfacing for a moment to respond to some of the current issues, particularly the mime item, below. I only have a moment - i need to prepare some notes to instruct some other project and system folks around here in mailman setup, so they can give it a try for some of their lists (yay!) On Sun, 26 Apr 1998, Ken Manheimer wrote: > It looks like there may be a problem, or at least some sendmail > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > digests. Does anyone have enough MIME acquaintance to have an > immediate idea whether or not the current format is correct? In any > case, i responded that i would look into the problem tomorrow, and > plan to look into using the python distribution mime facilities - in > particular mimify.py - to use known quantities for the encoding. > Clues would be appreciated... I should add, first of all, that i did suggest to them that they investigate whether sendmail 8.8.8 has any related sensitivities, since sendmail shouldn't be crashing, period, particularly from malformed content. John, i don't have any more details than the message provided, though i'll try to remember to ask them if they can provide any, when i contact them about the following change. I've actually started to revamp the digest mechanism, to be able to refine the mime presentation in an easy way. I'll go into that below. For the meanwhile, i'm using mimetools.choose_boundary() to substitute for the boundary delimiter of the mime-format digests, in the hopes that this might avoid triggering the sendmail bug, and to provide a somewhat more robust primary delimiter besides. What i'm planning to do (and have already started, in my enthusiasm) is to create a Digest class (in mm_message) to take all the digest pieces and keep them in a presentation-neutral format. It will be able to present them in both plain or mime formats. I'm planning to elaborate the mime format a bit, and to look into using a delimiter in the plain format which conforms to an old burstable-digest standard that was floating around the net. The elaboration of the mime format has the whole message as a multipart/mixed type. The top section - the masthead - will have a few text/plain; charset=us-ascii sections: - the digest header, if any - admin info (addresses, URLs, etc) - the toc followed by the digest contents, as a multipart/digest section, with a simple boundary. Finally there'll be a text/plain footer, if any. (I'm pretty close to convinced it's better to *not* have a default setting for the footer - a generic one is clutter, with info better served by the masthead admin-info section, and a list-specific one is up to the maillist admin.) What do people think? This layout is used by a maillist to which i subscribe, and i like it. But i'm not sure what the conventional wisdom is about these things. (I will respond in a different message to john's conventional wisdom about having digests default to plain, instead of mime...) Ken From klm@python.org Mon Apr 27 22:15:25 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:15:25 -0400 (EDT) Subject: [Mailman-developers] access to admin pages In-Reply-To: <19980424031827.64676@chronis.icgroup.com> Message-ID: On Fri, 24 Apr 1998, Scott wrote: > i have a little concern about the ability to access administrative > pages via the web without password confirmation. > [...] > for all these reasons, and for the sake of the design of the > administrative cgi script, it seems that it may be a good idea to > stick the entire interface behind a single login and use cookies from > there to allow access. I have the same concern, and agree that the admin pages should be behind the admin password, instead of in front of it. I've already included a cookie mechanism (gotten from off the net), for the private archives which could be adapted to the purpose - though i think it should be refined a bit to reasonable timeout the cookies, which the mechanism supports... > [...] > type of authentication to one section. it was quite complicated, as > the script was designed for authentication only when changes were > requested. as more different things develop under the administrative > interface, some of them will require authentication for viewing and > some won't. changing around the authentication scheme every time will > involve work. it would be much simpler just to have one login at the > onset and to cookies from there. There actually is already a few styles for soliciting authentication info. In several places, the authentication information is required to accompany changes. For the private archives, when you visit one of those pages and lack a cookie with sufficient authentication info, you get an authentication soliciting page, and then proceed to the page you really wanted. I agree that the latter style is much nicer for many situations. I think password changes should still use the old style, but anywhere else the prompt could come up only when there's no cookie containing the authentication... Ken From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 22:16:46 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 17:16:46 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling References: <13635.29122.780922.961470@glyph.CNRI.Reston.Va.US> Message-ID: <13636.62831.638542.640623@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> I'm planning to elaborate the mime format a bit, and to look KM> into using a delimiter in the plain format which conforms to KM> an old burstable-digest standard that was floating around the KM> net. RFC 934 perhaps? -Barry From klm@python.org Mon Apr 27 22:24:45 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:24:45 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <13636.62831.638542.640623@anthem.CNRI.Reston.Va.US> Message-ID: On Mon, 27 Apr 1998, Barry A. Warsaw wrote: > RFC 934 perhaps? > > Thanks, i'll have two, and a side of fries. (I figured i'd just look at the emacs digest-burst function - but it may be long gone. I'll look at that. Thanks!) Ken From klm@python.org Mon Apr 27 22:59:42 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 17:59:42 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages In-Reply-To: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: On Mon, 27 Apr 1998, John Viega wrote: > While I've certainly been a strong detractor of Reply-to ever since > reading that article, there are still those who do not agree. I think > adding the reply-to header should be an option, although it should be > strongly discouraged. As someone suggested (in a subsequent note, i think - i'm catching up on ones i've previously scanned, here), i mention in the short description that "poster" is *strongly* recommended, and included a bit more explanation and the URL barry came up with in the long description. (And while i'm at it, someone might enjoy seeing the refinement of the long description presentation i made last week - the gui presentation of the current setting is used, instead of the data values. See http://www.python.org/mailman/admin/postal and click on one of the 'details' for an example...) > Ugh, I just went to the discussion forum off that page for the first > time in quite a while. I see where well over a year ago I suggested > that replies to a list should not be sent out to people who are in the > TO or CC line (at least as an option). I'm pretty sure that feature > is no longer in Mailman, and it should definitely go back in. If > someone has time to Mailman hack in the near future, please consider > adding that :) This would not be hard! Also would not be high priority. And i have to say, when streaming through my inbox, i often use the fact that i got a message twice as the cue that i'm among the direct recipients (something i noticed a lot today with mailman-developer's mail:). I'm not sure i'd want to be without this, despite the inbox clutter... Ken From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Apr 27 23:28:01 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Apr 1998 18:28:01 -0400 (EDT) Subject: [Mailman-developers] Bug: includes Reply-To in administrative messages References: <199804271524.LAA09791@adder.cs.Virginia.EDU> Message-ID: <13637.1415.865073.631994@anthem.CNRI.Reston.Va.US> >>>>> "KM" == Ken Manheimer writes: KM> As someone suggested (in a subsequent note, i think - i'm KM> catching up on ones i've previously scanned, here), i mention KM> in the short description that "poster" is *strongly* KM> recommended, and included a bit more explanation and the URL KM> barry came up with in the long description. The biggest problem that I have with Reply-to munging is that I use Reply-to to control which of many inboxes I want replies to show up at. I think this is a valid for this header by end-users. Other people use it because their mail s/w is broken beyond their repair. I've had people who just cannot convince their sysadmins to fix their mailers but still want people to be able to reply to them. So they add a Reply-to they know to be valid. If Mailman munges Reply-to it's possible that those folks will just lose their messages. So at the very least, if optional Reply-to is enabled, Mailman shouldn't add or change a Reply-to if the original message had this header. KM> (And while i'm at it, someone might enjoy seeing the KM> refinement of the long description presentation i made last KM> week - the gui presentation of the current setting is used, KM> instead of the data values. See KM> http://www.python.org/mailman/admin/postal and click on one of KM> the 'details' for an example...) Not bad! KM> This would not be hard! Also would not be high priority. And KM> i have to say, when streaming through my inbox, i often use KM> the fact that i got a message twice as the cue that i'm among KM> the direct recipients (something i noticed a lot today with KM> mailman-developer's mail:). I'm not sure i'd want to be KM> without this, despite the inbox clutter... It might be a pain (or slow) but a per-user option to control this would be the way to go. -Barry From klm@python.org Mon Apr 27 23:58:34 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 27 Apr 1998 18:58:34 -0400 (EDT) Subject: [Mailman-developers] forwarded message from Andrew Kuchling In-Reply-To: <199804271454.KAA08247@adder.cs.Virginia.EDU> References: <199804271454.KAA08247@adder.cs.Virginia.EDU> Message-ID: <13637.2293.465828.439310@glyph.CNRI.Reston.Va.US> John Viega writes: > [Was it janne? who wrote:] > > Some other mailers complain about the number of attachments. Over 20 > > seems to be too much for them. > > That's sad. It is unfortunate that few mailers deal with MIME digests > decently. When I added the feature to mailman, I was wondering why no > other package supported MIME digests. I very quickly learned that it I'm surprised - both of the outside, only-slightly-techie maillists to which i subscribe in digest mode are delivered in mime format. (The thinkpad list is the one from which i'm stealing my new mime layout proposal design.) > is probably because so few mailers support them well if at all. I got > so many complaints about the MIME digests that were the mailer's > fault, that it became really clear to me that MIME digests need to be > off by default until other mail software improves. I think Ken > changed the default in the release, but if I haven't said so before, I > strongly believe it should be changed back. John, you mentioned this to me early on - i'm sort of on the fence about it, and would like to discuss it more - only in the hopes that the prevailing world may have changed enough to warrant giving mime-default a try. I haven't gotten any complaints so far, except the sendmail problem - which i think is a sendmail problem, not mime/mailman... I'm ready to give up on this, though, just giving a last gasp try, just for the sake of personal preference. (I *much* prefer mime digest format, and also much prefer digest to procmail and mail-reader-sorted collections, both of which i have available.) Ken From klm@python.org Tue Apr 28 19:25:32 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 28 Apr 1998 14:25:32 -0400 (EDT) Subject: No subject Message-ID: <199804281825.OAA18771@glyph.CNRI.Reston.Va.US> Last thursday i posted a patch that was missing a piece, and would break things if used alone. It was in response to janne's patch to get rid of double reply-to's, and involved doing a "del msg[...]" instead iterating over the message headers. It turns out that the headers were part of an OutgoingMessage instance, which didn't support __delitem__. The patch below solves that - sorry about the confusion! Ken Index: mm_message.py =================================================================== RCS file: /hosts/parrot/local/cvsroot/mailman/modules/mm_message.py,v retrieving revision 1.6 diff -c -r1.6 mm_message.py *** mm_message.py 1998/04/13 04:59:14 1.6 --- mm_message.py 1998/04/28 18:13:18 *************** *** 1,6 **** """Embody incoming and outgoing messages as objects.""" ! __version__ = "1.6" import sys --- 1,6 ---- """Embody incoming and outgoing messages as objects.""" ! __version__ = "1.7" import sys *************** *** 91,97 **** string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) ! # XXX Eventually (1.5.1?) Python rfc822.Message() will have it's own # __delitem__. def __delitem__(self, name): """Delete all occurrences of a specific header, if it is present.""" --- 91,97 ---- string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) ! # XXX Eventually (1.5.1?) Python rfc822.Message() will have its own # __delitem__. def __delitem__(self, name): """Delete all occurrences of a specific header, if it is present.""" *************** *** 128,140 **** self.sender = sender def SetHeaders(self, headers): ! self.headers = map(AddBackNewline, string.split(headers, '\n')) ! def CacheHeaders(header, s=self): i = string.find(header, ':') ! s.cached_headers[string.lower(string.strip(header[:i])) ! ] = header[i+2:] ! map(CacheHeaders, self.headers) def SetHeader(self, header, value, crush_duplicates=1): if value[-1] <> '\n': --- 128,141 ---- self.sender = sender def SetHeaders(self, headers): ! self.headers = map(AddBackNewline, string.split(headers, '\n')) ! self.CacheHeaders() ! def CacheHeaders(self): ! for header in self.headers: i = string.find(header, ':') ! self.cached_headers[string.lower(string.strip(header[:i])) ! ] = header[i+2:] def SetHeader(self, header, value, crush_duplicates=1): if value[-1] <> '\n': *************** *** 178,180 **** --- 179,196 ---- if not self.cached_headers.has_key(str): return None return self.cached_headers[str] + + def __delitem__(self, name): + if not self.getheader(name): + return None + newheaders = [] + name = string.lower(name) + nlen = len(name) + for h in self.headers: + if (len(h) > (nlen+1) + and h[nlen] == ":" + and string.lower(h[:nlen]) == name): + continue + newheaders.append(h) + self.headers = newheaders + self.CacheHeaders() From klm@python.org Wed Apr 29 22:28:42 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 29 Apr 1998 17:28:42 -0400 (EDT) Subject: [Mailman-developers] wrapper programs bug fix Message-ID: <199804292128.RAA23965@glyph.CNRI.Reston.Va.US> There's a bug in the new version of the cgi-wrapper.c program, which the following patch fixes, and more. The bug appears on error reporting, when the invoking process UID or GID doesn't match the configured setting - then a "%s" in the error report string causes a segfault when it's mapped onto the LEGAL_PARENT_UID or _GID. While the fix is obvious (change the two occurrences of "%s" to "%d"), the patches do a bit more than that. They also change the type of the main() routine to int, since gcc seems to expect that. (When the type was void gcc complained about it not being an int, and i figure gcc knows what it's doing. I don't, when it comes to C. (...Caveat emptor...-)) Ken Index: cgi-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/cgi-wrapper.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** cgi-wrapper.c 1998/04/03 00:12:57 1.1 --- cgi-wrapper.c 1998/04/28 22:36:07 1.2 *************** *** 53,69 **** /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %s made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %s made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! void main(int argc, char **argv, char **env) { int i; --- 53,69 ---- /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %d made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %d made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! int main(int argc, char **argv, char **env) { int i; Index: mail-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/mail-wrapper.c,v retrieving revision 1.5 retrieving revision 1.6 diff -c -r1.5 -r1.6 *** mail-wrapper.c 1998/03/30 16:28:22 1.5 --- mail-wrapper.c 1998/04/28 22:36:29 1.6 *************** *** 107,113 **** return 0; } ! void main(int argc, char **argv) { char *command; int i; --- 107,113 ---- return 0; } ! int main(int argc, char **argv) { char *command; int i; Index: alias-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/alias-wrapper.c,v retrieving revision 1.3 retrieving revision 1.5 diff -c -r1.3 -r1.5 *** alias-wrapper.c 1998/03/05 23:46:45 1.3 --- alias-wrapper.c 1998/04/28 22:38:18 1.5 *************** *** 60,66 **** } } ! void main(int argc, char **argv, char **env) { char *command; int i; --- 60,66 ---- } } ! int main(int argc, char **argv, char **env) { char *command; int i; *************** *** 78,83 **** --- 78,85 ---- else { printf("Illegal caller!\n"); + return 1; } + return 0; } From klm@python.org Thu Apr 30 18:56:01 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 30 Apr 1998 13:56:01 -0400 (EDT) Subject: [Mailman-developers] reply-to munging Message-ID: <199804301756.NAA26972@glyph.CNRI.Reston.Va.US> From the conversations about the reply-to issues, i propose changing reply_goes_to_list so it will *not* cause user specified reply-to headers, if present, to be replaced with the list's address. It just does not seem valid to override the mechanism which is intended for users to make their correct address available. Conversely, though using the reply-to at all in this way seems a bit improper, it sounds like the functionality is really necessary for some kinds of lists. (Perhaps i'm neglecting some alternate means for implementing this that was mentioned?) This will apply at least to individual messages, while digests as a whole will have the list as the reply-to addr. Objections? Ken From jtv2j@cs.virginia.edu Thu Apr 30 19:24:27 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Thu, 30 Apr 1998 14:24:27 -0400 (EDT) Subject: [Mailman-developers] reply-to munging Message-ID: <199804301824.OAA24485@adder.cs.Virginia.EDU> > >From the conversations about the reply-to issues, i propose changing > reply_goes_to_list so it will *not* cause user specified reply-to > headers, if present, to be replaced with the list's address. It just > does not seem valid to override the mechanism which is intended for > users to make their correct address available. > > Conversely, though using the reply-to at all in this way seems a bit > improper, it sounds like the functionality is really necessary for > some kinds of lists. (Perhaps i'm neglecting some alternate means for > implementing this that was mentioned?) > > This will apply at least to individual messages, while digests as a > whole will have the list as the reply-to addr. > > Objections? Yes, I object to that. Either the person sees why reply-to munging is bad, or he doesn't. If he doesn't, he's not going to want this behavior. Consistancy is important; there should not be differing behavior on a per-list basis when you hit "reply" based on the mail setup of the original sender. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Apr 30 21:27:54 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Apr 1998 16:27:54 -0400 (EDT) Subject: [Mailman-developers] reply-to munging References: <199804301824.OAA24485@adder.cs.Virginia.EDU> Message-ID: <13640.56769.497203.978760@anthem.CNRI.Reston.Va.US> >>>>> "JV" == John Viega writes: JV> Yes, I object to that. Either the person sees why reply-to JV> munging is bad, or he doesn't. If he doesn't, he's not going JV> to want this behavior. Consistancy is important; there should JV> not be differing behavior on a per-list basis when you hit JV> "reply" based on the mail setup of the original sender. I'm still really worried about allowing any reply-to munging. I just think that allowing administrators to reply-to munge message is setting them up for gobs of complaints. I know that have complained loudly and often when mailing lists I'm on do reply-to munging. A mailing list just shouldn't do this. If an admin turns this on, it *will* break for some people who are using Reply-To: in a completely valid and acceptable way. So we can still debate whether it should be allowed. Perhaps letting the site decide whether admins will be allowed to do this is another option. That way an admin would have to plead his case with the site admin to even be allowed to change this. Given my reservations in general, I agree with John. If munging is absolutely going to happen on a list, it should be consistent. At least that way they'll hear the screams earlier. -Barry From bwarsaw@python.org Thu Apr 30 21:57:49 1998 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 30 Apr 1998 16:57:49 -0400 (EDT) Subject: [Mailman-developers] Re: Welcome To "CC-Mode-Announce"! References: <199804282326.QAA11106@moldavia.unitech.com> <199804292035.NAA26098@moldavia.unitech.com> Message-ID: <13640.57633.923906.398949@anthem.CNRI.Reston.Va.US> Dan, Mailman is fairly new, so development is continuing quickly. If you are really interested in discussing some of these issues, I suggest following up to mailman-developers@python.org. You can of course join this list in the usual Mailman ways I hope you don't mind me CC'ing that list on this reply. I'd like for the wider Mailman developers audience to have a chance to respond. >>>>> "DH" == Dan Harkless writes: DH> I figured out what the problem is. Mailman does not use the DH> correct address. I send my mails from a local account called DH> "dlh", and I masquerade as "unitech.com", so my emails DH> (including this one) have this line: DH> Sender: dlh@unitech.com DH> However, my From line is set to my desired return address: DH> From: Dan Harkless DH> Right now there *is* a dlh@unitech.com, and that's where I DH> found mail from Mailman, but that account will soon go away. DH> Mailman is doing The Wrong Thing in preferring the Sender line DH> (or envelope sender information) over the From line. In these DH> days of POP mail boxes, people don't always send mail from the DH> same "account" (if such even exists) that receives it. I have never seen Sender used in this way. Typically Sender is used by a MLM to point to the list owner. Bounces will get sent to Sender, since the owner is the only person that can deal with such problems. In Mailman's case, the owner is a program that keeps track of bounces and auto-disables accounts that meet a certain threshold. I wasn't aware that Mailman uses the Sender address when deciding where to send replies. I agree it shouldn't use it, and certainly not in preference to From: or Reply-to: DH> What if I had my correct email address in the DH> even-higher-priority Reply-To line? Does it ignore that too? No. The order should be Reply-to (if present) followed by From. The list is currently debating whether Mailman should allow admins to Reply-to munge at all. We all (I think) agree it's evil, but there's some debate as to whether list admins should be allowed to configure it at all. DH> Is any of this behavior configurable? Not by users. DH> Actually I was just able to unsubscribe my old email address, DH> harkless@unitech.com, and it didn't ask me for my password. That's very strange. I just tried it with my own account and it definitely required a password. DH> I then re-subscribed with my new address, DH> dharkless@unitech.com, and it got as far as replying to the DH> verification email, but then I never heard back from the DH> server. I tried to go to the adjustments page for my new DH> address and it says that user doesn't exist. I can see that dlh@unitech.com is a member, not dharkless@unitech.com. I think that subscribing 3rd party addresses (essentially what you're doing) is something that Mailman currently doesn't support too well. It's being worked on though. If it's critical I think I can manually change the subscription to dharkless. >> If you forget your password, don't worry, you will receive a >> monthly reminder telling you what all your python.org maillist >> passwords are, DH> Hmm. That sounds pretty annoying. It'd be nice if there were DH> an option to turn that off. In practice it's not bad, but I agree. You can always get your password emailed to you via the Web interface. -Barry