From barry at list.org Mon Mar 2 18:19:10 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 2 Mar 2009 12:19:10 -0500 Subject: [Mailman-Developers] MM3: Content filter rules Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As you know, Mailman 2 can filter the content of a message before it's forwarded on to the list membership. It can reorganize the MIME structure of a message, based on settings for MIME type and file extension. The rules are fairly complex though: * If the outer MIME type or file extension matches a filter pattern, the entire message is disposed of. * If there are pass filters and the outer MIME type or file extension does not match a pass filter, the message is disposed of. * If a subpart's MIME type or file extension matches a filter pattern, that part is disposed of. * If there are pass filters and a subpart's MIME type or file extension does not match a pass filter, the subpart is disposed of. * After all that, multipart/alternatives can be collapsed. * After all that, text/html parts can be converted to text/plain * After all that, if the outer message's body is empty and it has exactly one subpart, the subpart "becomes" the outer part. Disposal of messages can be one of: * Reject the message to the original author * Forward the message to the list owner and discard * Preserve the message in the 'bad' queue and discard The Zen of Python says: "Complex is better than complicated." "If the implementation is hard to explain, it's a bad idea." and I think the implementation is both complicated and hard to explain, and the u/i is no model of comprehension. I'm not entirely sure how people use this feature though. Some of the python.org lists have pass-types allowing multipart/mixed, multipart/alternative and text/plain, while filtering out various file extensions. So I'd like to solicit your input on how you use the feature, and if you have any ideas for an approach that would be easier to understand, more useful, or both. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmsFQ4ACgkQ2YZpQepbvXEIAACffKwhPLRK4hIbJ7Hs2Cfsitjk xr8An1RqTVblud9OipgfanywU3Wr8kWV =E7Nw -----END PGP SIGNATURE----- From adam-mailman at amyl.org.uk Mon Mar 2 18:39:10 2009 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Mon, 2 Mar 2009 17:39:10 +0000 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: References: Message-ID: <20090302173910.GI6339@amyl.org.uk> On Mon, Mar 02, 2009 at 12:19:10PM -0500, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As you know, Mailman 2 can filter the content of a message before it's > forwarded on to the list membership. It can reorganize the MIME > structure of a message, based on settings for MIME type and file > extension. > > The rules are fairly complex though: [...] > and I think the implementation is both complicated and hard to > explain, and the u/i is no model of comprehension. I'm not entirely > sure how people use this feature though. [...] > So I'd like to solicit your input on how you use the feature, and if > you have any ideas for an approach that would be easier to understand, > more useful, or both. Ok, I'm lazy, and could never really be bothered using content-filters all that much in MM2. I'm wondering if it would make sense to use mailcap(5) -- either the system's, or MM user's should one exist, to generate a list of MIME-Types for Mailman, and nice tickboxes alongside to select "Reject, Discard, Allow, Forward to Admins" or something similar (read-in mailcap on each load of the relevant part of the admin web-URI?/each execution of the command-line util?). It would be grand (IMO) to have a Reject message using something like: (auto-generated) "$LISTNAME doesn't accept $MIMETYPE" plus, perhaps the opportunity to provide some more 'useful' information: "your mail client's broken", "HTML's for the web, not email", "we don't like MS Word", "stop using proprietry formats" or some other customizable message Maybe I should draw what I'd like... Perhaps (shudder), allowing an over-ride to let *some* users use a specified content, whilst rejecting for others... Have I over-complicated things? Or am I barking mad? From mark at msapiro.net Mon Mar 2 20:15:57 2009 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 2 Mar 2009 11:15:57 -0800 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: Message-ID: Barry Warsaw wrote: > >So I'd like to solicit your input on how you use the feature, and if >you have any ideas for an approach that would be easier to understand, >more useful, or both. My typical list is set up as follows to allow plain text only. List mail is not signed so I don't have that issue. filter_content -> Yes filter_mime_types -> empty pass_mime_types multipart message/rfc822 text/plain text/html filter_filename_extensions -> default, but irrelevant pass_filename_extensions -> empty collapse_alternatives -> Yes convert_html_to_plaintext -> Yes filter_action -> Reject I have one list which is used to discuss the planning for an annual event (century bicycle ride) which we run as a fund raiser. Since it is not possible to get all the people involved to understand that there are alternatives to attaching spread sheets and word processing documents, this list is set up as above except that pass_mime_types is set to multipart message/rfc822 text/plain text/html application/pdf application/vnd.oasis.opendocument.spreadsheet application/vnd.ms-excel application/vnd.oasis.opendocument.text application/vnd.openxmlformats-officedocument.wordprocessingml.document application/msword This generally works except for one user's misconfigured Microsoft Outlook/Exchange that attaches a PDF as application/octet-stream. There's no good way around that (other than fixing the source). We could accept all MIME types and filter only on file name extension, but that would accept anything without a name or with a name without an extension. In fact, given the nature of this list and its membership, I could probably accept everything and just collapse alternatives and convert HTML to plain text and it would be OK. BTW, as an aside regarding collapse_alternatives, I have seen on a non-Mailman list, non-compliant posts from a Lotus notes user that have the text/html alternative preceding the text/plain alternative in a multipart/alternative part. I don't know what you do about that... As far as ideas for improvement go, I don't know if anyone actually uses filter_mime_types. It seems best to "whitelist" what you want rather than trying to "blacklist" what you don't want. I think we could probably do without filter_mime_types. The other confusing point for some users is they have to allow various multipart/* types in order to allow the sub-parts they want. Possibly we could do something where you just specify the elemental content types you want to allow, and we examine all multipart parts implicitly and accept those elemental sub-parts that are allowed. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Mon Mar 2 21:40:02 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 2 Mar 2009 15:40:02 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <20090302185036.GM21066@monkey.uchicago.edu> References: <20090302185036.GM21066@monkey.uchicago.edu> Message-ID: <6F3D83A2-E228-4A36-A6E8-D338E9159776@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With David's permission, I quote his message On Mar 2, 2009, at 1:50 PM, David Champion wrote: > This is a crazy idea I haven't really thought through, and completely > tangent to what you're asking, but what about implementing a Milter > interface (the MTA component, not the filter component) in Mailman > and adopting its semantics? > > Then Mailman could take advantage of an existing framework with many > instances in the field already, while limiting the use of those > filters > to Mailman (not the whole MTA) and being completely independent of > whichever MTA you're indeed using. > > The pymilter project makes writing Milter filters in Python rather > easy, > so that Mailman-specific milters can be contributed and distributed > with > Mailman. http://www.bmsi.com/python/milter.html This occurred to me too, so let's explore it. MM3 has a lot of plugin points, and content filtering could definitely be one as well. For example, I could imagine a filter such as "leave nothing but the first text/plain", "strip out all word documents", etc. implemented as Python modules. Some would come with stock MM3, others could be added by the site administrator. In fact, I think the current mime_delete.py handler could be implemented as a plugin (though I'm not sure you'd want to ;). The advantage of a plugin architecture here is that I think it is simpler to implement, understand, explain, and skin. The disadvantage is that the individual plugins would be less flexible, and you'd need a site administrator to add third party plugins. I'm not sure that the milter API is quite appropriate for Mailman, which has a much different architecture than an MTA. For example, it doesn't make sense for Mailman to expose SMTP callbacks since that will have happened long before Mailman gets its paws on the message. But something /like/ this could make a lot of sense. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmsRCIACgkQ2YZpQepbvXG2ZwCeLhv5WOiuS2iwrxznGqOmZsYj Al8An3GjQVGTBDN2sIJhjwOKuBZslw5b =0tfj -----END PGP SIGNATURE----- From barry at list.org Mon Mar 2 21:45:19 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 2 Mar 2009 15:45:19 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: References: Message-ID: <7E229527-39F7-4138-AA3B-E2CB590F1207@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2009, at 2:15 PM, Mark Sapiro wrote: > My typical list is set up as follows to allow plain text only. List > mail is not signed so I don't have that issue. > > filter_content -> Yes > filter_mime_types -> empty > pass_mime_types > multipart > message/rfc822 > text/plain > text/html > filter_filename_extensions -> default, but irrelevant > pass_filename_extensions -> empty > collapse_alternatives -> Yes > convert_html_to_plaintext -> Yes > filter_action -> Reject It's interesting how simple it is for you to explain what you want, but how complicated it is for you to make Mailman do it! > I have one list which is used to discuss the planning for an annual > event (century bicycle ride) which we run as a fund raiser. Since it > is not possible to get all the people involved to understand that > there are alternatives to attaching spread sheets and word processing > documents, this list is set up as above except that pass_mime_types is > set to > > multipart > message/rfc822 > text/plain > text/html > application/pdf > application/vnd.oasis.opendocument.spreadsheet > application/vnd.ms-excel > application/vnd.oasis.opendocument.text > application/vnd.openxmlformats- > officedocument.wordprocessingml.document > application/msword > > This generally works except for one user's misconfigured Microsoft > Outlook/Exchange that attaches a PDF as application/octet-stream. > There's no good way around that (other than fixing the source). We > could accept all MIME types and filter only on file name extension, > but that would accept anything without a name or with a name without > an extension. Touching on the plugin idea, let's say you had a generic whitelist filter. It would seem that some level of user configurability should be exposed in order to allow you to configure this. > In fact, given the nature of this list and its membership, I could > probably accept everything and just collapse alternatives and convert > HTML to plain text and it would be OK. > > BTW, as an aside regarding collapse_alternatives, I have seen on a > non-Mailman list, non-compliant posts from a Lotus notes user that > have the text/html alternative preceding the text/plain alternative in > a multipart/alternative part. I don't know what you do about that... I'm not sure either, except perhaps it shouldn't be called 'collapse_alternatives' but instead something like 'select_text_plain_alternative'. > As far as ideas for improvement go, I don't know if anyone actually > uses filter_mime_types. It seems best to "whitelist" what you want > rather than trying to "blacklist" what you don't want. I think we > could probably do without filter_mime_types. And probably the same with extension types? I think I agree with you! > The other confusing point for some users is they have to allow various > multipart/* types in order to allow the sub-parts they want. Possibly > we could do something where you just specify the elemental content > types you want to allow, and we examine all multipart parts implicitly > and accept those elemental sub-parts that are allowed. This is a good idea too. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmsRV8ACgkQ2YZpQepbvXEi9gCfaHM0wf5dkmi1LQWzTo8RYnj8 eZ4An1nkLrJJdzxY+ZaYarHLI1fJKudu =kDC3 -----END PGP SIGNATURE----- From barry at list.org Mon Mar 2 21:46:10 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 2 Mar 2009 15:46:10 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <49AC3FF4.9070407@nleaudio.com> References: <49AC3FF4.9070407@nleaudio.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2009, at 3:22 PM, Bob Puff at NLE wrote: > If there was a way to have the filters also work based on file > extensions, that would be a definite plus. Granted, mime types are > usually right, but as you pointed out, not always. Same thing goes > for file extensions. Its a messy world! The current mime-delete module does work on both MIME type and file extensions. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmsRZIACgkQ2YZpQepbvXH2swCfTo8XQmL9hwBSLWA5TkUfwDYF dcMAniLnnE4gL2nUD8wClby81iSHv61U =evRn -----END PGP SIGNATURE----- From bob at nleaudio.com Mon Mar 2 21:22:12 2009 From: bob at nleaudio.com (Bob Puff@NLE) Date: Mon, 02 Mar 2009 15:22:12 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: References: Message-ID: <49AC3FF4.9070407@nleaudio.com> Mark Sapiro wrote: > Barry Warsaw wrote: > >> So I'd like to solicit your input on how you use the feature, and if >> you have any ideas for an approach that would be easier to understand, >> more useful, or both. >> > > > My typical list is set up as follows to allow plain text only. List > mail is not signed so I don't have that issue. > > filter_content -> Yes > filter_mime_types -> empty > pass_mime_types > multipart > message/rfc822 > text/plain > text/html > filter_filename_extensions -> default, but irrelevant > pass_filename_extensions -> empty > collapse_alternatives -> Yes > convert_html_to_plaintext -> Yes > filter_action -> Reject > > > I have one list which is used to discuss the planning for an annual > event (century bicycle ride) which we run as a fund raiser. Since it > is not possible to get all the people involved to understand that > there are alternatives to attaching spread sheets and word processing > documents, this list is set up as above except that pass_mime_types is > set to > > multipart > message/rfc822 > text/plain > text/html > application/pdf > application/vnd.oasis.opendocument.spreadsheet > application/vnd.ms-excel > application/vnd.oasis.opendocument.text > application/vnd.openxmlformats-officedocument.wordprocessingml.document > application/msword > > This generally works except for one user's misconfigured Microsoft > Outlook/Exchange that attaches a PDF as application/octet-stream. > There's no good way around that (other than fixing the source). We > could accept all MIME types and filter only on file name extension, > but that would accept anything without a name or with a name without > an extension. > > In fact, given the nature of this list and its membership, I could > probably accept everything and just collapse alternatives and convert > HTML to plain text and it would be OK. > > BTW, as an aside regarding collapse_alternatives, I have seen on a > non-Mailman list, non-compliant posts from a Lotus notes user that > have the text/html alternative preceding the text/plain alternative in > a multipart/alternative part. I don't know what you do about that... > > As far as ideas for improvement go, I don't know if anyone actually > uses filter_mime_types. It seems best to "whitelist" what you want > rather than trying to "blacklist" what you don't want. I think we > could probably do without filter_mime_types. > > The other confusing point for some users is they have to allow various > multipart/* types in order to allow the sub-parts they want. Possibly > we could do something where you just specify the elemental content > types you want to allow, and we examine all multipart parts implicitly > and accept those elemental sub-parts that are allowed. > > If there was a way to have the filters also work based on file extensions, that would be a definite plus. Granted, mime types are usually right, but as you pointed out, not always. Same thing goes for file extensions. Its a messy world! Bob From barry at list.org Mon Mar 2 21:51:51 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 2 Mar 2009 15:51:51 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <20090302173910.GI6339@amyl.org.uk> References: <20090302173910.GI6339@amyl.org.uk> Message-ID: <30D7495E-2ABC-4B58-979A-871B45B15843@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2009, at 12:39 PM, Adam McGreggor wrote: > I'm wondering if it would make sense to use mailcap(5) -- either the > system's, or MM user's should one exist, to generate a list of > MIME-Types for Mailman, and nice tickboxes alongside to select > "Reject, > Discard, Allow, Forward to Admins" or something similar (read-in > mailcap > on each load of the relevant part of the admin web-URI?/each execution > of the command-line util?). Python has a mailcap module, so that would make the most sense. > It would be grand (IMO) to have a Reject message using something like: > (auto-generated) "$LISTNAME doesn't accept $MIMETYPE" plus, perhaps > the > opportunity to provide some more 'useful' information: > "your mail client's broken", > "HTML's for the web, not email", > "we don't like MS Word", > "stop using proprietry formats" > or some other customizable message This isn't an area I've addressed yet, but customizable messages needs to be thought about, especially when multilingual rejection messages are considered. > Maybe I should draw what I'd like... > > Perhaps (shudder), allowing an over-ride to let *some* users use a > specified content, whilst rejecting for others... > > Have I over-complicated things? Or am I barking mad? I'm not sure per-user filters are feasible. I'm also not sure you want to see 35 or more checkboxes on the whitelist/blacklist page. That's how many entries are in mailcap.getcaps() on OS X. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmsRucACgkQ2YZpQepbvXFvAgCeN93hjXPTQuCeDo5PFz8N2dsO cYIAn3L2eGOU6+3BvpBBc8erMm2AewM0 =y2uD -----END PGP SIGNATURE----- From p at state-of-mind.de Mon Mar 2 22:47:05 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 2 Mar 2009 22:47:05 +0100 Subject: [Mailman-Developers] Short introduction & request for input Message-ID: <20090302214704.GC7658@state-of-mind.de> Mailman Developers, I've recently sent the one or the other mail to this mailing list concerning Mailman and Postfix as well as development of a new web interface for MM3. You might have wondered who I am and why I started posting to the MM developer list without any introduction. Please let me make up for this now. My name is Patrick Ben Koetter. People who use Postfix may now my name from my involvement in the Postfix community. At LISA'07 I was asked by Brad Knowles to join the Python postmaster team, which I did a few months ago. This involved introducing myself to Barry and we started talking about MM3 development, the webinterface, the plan for a REST client/server architecture etc. To cut things short we - my business partner Andreas and Florian, who's been working with us for years - will attend the Mailman sprint at Pycon 2009. The plan is to introduce us to MM3 code and architecture and start to develop a new web interface based on a REST client/server architecture. Andreas and Florian will focus on programming and I will work on the web interface, documentation etc. I hope this gives an idea what our motivation is about and why you (hopefully) are going to see more posts from us to this list in the next time. To start let me ask you for your input on MM3 web interface plans. Barry told me several plans/feature/wish lists have been written and that he would like them to be the base for further development. So far I have found the following links: Do you know of more? Thanks, p at rick P.S. We hope to meet all of you at Pycon 2009! -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 45227227 81669 M?nchen Telefax +49 89 45227226 Amtsgericht M?nchen Partnerschaftsregister PR 563 From adam-mailman at amyl.org.uk Tue Mar 3 19:46:23 2009 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Tue, 3 Mar 2009 18:46:23 +0000 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <30D7495E-2ABC-4B58-979A-871B45B15843@list.org> References: <20090302173910.GI6339@amyl.org.uk> <30D7495E-2ABC-4B58-979A-871B45B15843@list.org> Message-ID: <20090303184623.GR6339@amyl.org.uk> On Mon, Mar 02, 2009 at 03:51:51PM -0500, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 2, 2009, at 12:39 PM, Adam McGreggor wrote: > > >I'm wondering if it would make sense to use mailcap(5) -- either the > >system's, or MM user's should one exist, to generate a list of > >MIME-Types for Mailman, and nice tickboxes alongside to select > >"Reject, > >Discard, Allow, Forward to Admins" or something similar (read-in > >mailcap > >on each load of the relevant part of the admin web-URI?/each execution > >of the command-line util?). > > Python has a mailcap module, so that would make the most sense. Ah-ha ;) > >It would be grand (IMO) to have a Reject message using something like: > >(auto-generated) "$LISTNAME doesn't accept $MIMETYPE" plus, perhaps > >the > >opportunity to provide some more 'useful' information: > > "your mail client's broken", > > "HTML's for the web, not email", > > "we don't like MS Word", > > "stop using proprietry formats" > >or some other customizable message > > This isn't an area I've addressed yet, but customizable messages > needs to be thought about, especially when multilingual rejection > messages are considered. I'd not thought about that, but presumably, that's something that can be addressed via the standard "stanza-in-a-po-file" method? I've not got any multi-lingual lists running (yet), and am a bit in the dark here (although, i rejoined the users/devs lists over an i18n issue, oddly enough) > >Maybe I should draw what I'd like... > > > >Perhaps (shudder), allowing an over-ride to let *some* users use a > >specified content, whilst rejecting for others... > > > >Have I over-complicated things? Or am I barking mad? > > I'm not sure per-user filters are feasible. I'm also not sure you > want to see 35 or more checkboxes on the whitelist/blacklist page. Fair point that, yes. Perhaps not in a listing per the current set-up, but perhaps some sort of 'advanced/more' settings giving the options? I dunno. I could see DB hackery becoming quite messy (particularly if allowing given email addresses different settings for different lists) From barry at list.org Wed Mar 4 04:03:35 2009 From: barry at list.org (Barry Warsaw) Date: Tue, 3 Mar 2009 22:03:35 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <20090303184623.GR6339@amyl.org.uk> References: <20090302173910.GI6339@amyl.org.uk> <30D7495E-2ABC-4B58-979A-871B45B15843@list.org> <20090303184623.GR6339@amyl.org.uk> Message-ID: <29CEE292-45D1-40EE-A464-B5A7366B0891@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 3, 2009, at 1:46 PM, Adam McGreggor wrote: >> This isn't an area I've addressed yet, but customizable messages >> needs to be thought about, especially when multilingual rejection >> messages are considered. > > I'd not thought about that, but presumably, that's something that > can be > addressed via the standard "stanza-in-a-po-file" method? > > I've not got any multi-lingual lists running (yet), and am a bit in > the > dark here (although, i rejoined the users/devs lists over an i18n > issue, oddly enough) The thing is, I think Mailman has a pretty good story for multilingual system messages, such as canned strings in the source. We're okay, but will do better with the web templates. But it's the strings that come from users that I think need to be handled. For example, say you wanted a list description for your French list in both French and English, right now you can't do that. I'd like for it to be possible to set those kinds of messages in multiple languages. > >>> Maybe I should draw what I'd like... >>> >>> Perhaps (shudder), allowing an over-ride to let *some* users use a >>> specified content, whilst rejecting for others... >>> >>> Have I over-complicated things? Or am I barking mad? >> >> I'm not sure per-user filters are feasible. I'm also not sure you >> want to see 35 or more checkboxes on the whitelist/blacklist page. > > Fair point that, yes. Perhaps not in a listing per the current set-up, > but perhaps some sort of 'advanced/more' settings giving the > options? I > dunno. I could see DB hackery becoming quite messy (particularly if > allowing given email addresses different settings for different lists) I've thought more about this, and I've also gotten the current module working again. Ultimately I think fleshing out the plugin architecture will be the right thing here, and then I can migrate the current mime-delete module into a plugin (well, a built-in plugin). It should be easy for others to write handlers that can do MIME filter in different ways. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmt74gACgkQ2YZpQepbvXGS/gCfd/7NNRh+7eXrsePVO0OAHepp P1YAn0O85KDQBjqPJ9SsFomUVWRr3ror =cuFN -----END PGP SIGNATURE----- From stefan.schlott at ulm.ccc.de Wed Mar 4 19:45:09 2009 From: stefan.schlott at ulm.ccc.de (Stefan Schlott) Date: Wed, 04 Mar 2009 19:45:09 +0100 Subject: [Mailman-Developers] mailman-pgp-smime: talks at FOSDEM and in Ulm, new release In-Reply-To: <49671979.2010505@ulm.ccc.de> References: <20090107172025.GH12474@bruhat.mdcc.cx> <49671979.2010505@ulm.ccc.de> Message-ID: <49AECC35.3060306@ulm.ccc.de> Hi all, >>> On monday january 12 I'll talk at the Chaos Seminar in Ulm, Germany, >>> see http://ulm.ccc.de/ChaosSeminar/2009/01_Mailman_PGP_SMIME . > >> Very cool! I wish I could be there. > > The CCC team of Ulm usually records these talks on video (although it > sometimes takes some time until they are published). The recordings are now available at https://ulm.ccc.de/ChaosSeminar/2009/01_Mailman_PGP_SMIME Have fun, Stefan. From cmpalmer at metalab.unc.edu Thu Mar 5 00:00:29 2009 From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Wed, 4 Mar 2009 18:00:29 -0500 Subject: [Mailman-Developers] MM3: Content filter rules In-Reply-To: <29CEE292-45D1-40EE-A464-B5A7366B0891@list.org> References: <20090302173910.GI6339@amyl.org.uk> <30D7495E-2ABC-4B58-979A-871B45B15843@list.org> <20090303184623.GR6339@amyl.org.uk> <29CEE292-45D1-40EE-A464-B5A7366B0891@list.org> Message-ID: <20090304230029.GS22221@garp.metalab.unc.edu> On Tue, Mar 03, 2009 at 10:03:35PM -0500, Barry Warsaw wrote: > For example, say you wanted > a list description for your French list in both French and English, right > now you can't do that. I'd like for it to be possible to set those kinds > of messages in multiple languages. That would rock! Please let's have that, yes. Cheers, -- Crist?bal Palmer ibiblio.org systems administrator cdla.unc.edu research assistant From barry at list.org Thu Mar 5 05:12:23 2009 From: barry at list.org (Barry Warsaw) Date: Wed, 4 Mar 2009 23:12:23 -0500 Subject: [Mailman-Developers] mailman-pgp-smime: talks at FOSDEM and in Ulm, new release In-Reply-To: <49AECC35.3060306@ulm.ccc.de> References: <20090107172025.GH12474@bruhat.mdcc.cx> <49671979.2010505@ulm.ccc.de> <49AECC35.3060306@ulm.ccc.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 4, 2009, at 1:45 PM, Stefan Schlott wrote: >>>> On monday january 12 I'll talk at the Chaos Seminar in Ulm, >>>> Germany, >>>> see http://ulm.ccc.de/ChaosSeminar/2009/01_Mailman_PGP_SMIME . >> >>> Very cool! I wish I could be there. >> >> The CCC team of Ulm usually records these talks on video (although it >> sometimes takes some time until they are published). > > The recordings are now available at > https://ulm.ccc.de/ChaosSeminar/2009/01_Mailman_PGP_SMIME Thanks! I did get a chance to watch this over the course of the evening. It was hard to hear the questions in the audience until the end, but there was some good information in the talk. I think this is the first time I've actually seen any kind of comparison of Mailman's use vs. the other list servers out there. Nice! I also smiled when Joost got the question about the "little bit of C" in Mailman. I think this is interesting work for Mailman and I'd like to find a way to help port it to 3.0. I really think it's more appropriate as a plugin rather than in the core, and if Joost et al are interested in exploring this, it will spur me to work out a plugin API that will work for you. I've been thinking a lot about this lately, especially w.r.t. the MIME cleaning stuff but the PGP/SMIME support might make a more interesting test case. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmvUScACgkQ2YZpQepbvXEARgCcCu7Di5l1B5JAfVSK2iglqkJH OzsAniuh/5JzWxdIW6Jry5K+mBx12feb =CYbo -----END PGP SIGNATURE----- From barry at list.org Thu Mar 5 05:31:59 2009 From: barry at list.org (Barry Warsaw) Date: Wed, 4 Mar 2009 23:31:59 -0500 Subject: [Mailman-Developers] Short introduction & request for input In-Reply-To: <20090302214704.GC7658@state-of-mind.de> References: <20090302214704.GC7658@state-of-mind.de> Message-ID: <02C352AD-6A43-41E7-B615-2CB3FE1B6FDC@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2009, at 4:47 PM, Patrick Ben Koetter wrote: > To start let me ask you for your input on MM3 web interface plans. > Barry told > me several plans/feature/wish lists have been written and that he > would like > them to be the base for further development. > > So far I have found the following links: > > > > Do you know of more? There's this branch, which I believe contains the work that Maki and Andrew did at last year's sprint for Mailman 2.2: https://code.edge.launchpad.net/~mk2s/mailman/restserver We should at least review this to decide how much is relevant for the MM3 sprint at Pycon. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmvVcAACgkQ2YZpQepbvXHoiQCdEAIcN18resZtpPukbPWbaMqw GqsAn2cikHzEQFz1U4Q000lWZ76AUdiK =pZfE -----END PGP SIGNATURE----- From barry at python.org Sun Mar 15 00:12:25 2009 From: barry at python.org (Barry Warsaw) Date: Sat, 14 Mar 2009 19:12:25 -0400 Subject: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-coders/mailman/2.2] Rev 1046: - Changed some old messages for more current meaning. In-Reply-To: <20090314222207.13953.88809.launchpad@loganberry.canonical.com> References: <20090314222207.13953.88809.launchpad@loganberry.canonical.com> Message-ID: <4FDDD474-72B7-4F50-8F95-FA18D6D4A230@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 14, 2009, at 6:22 PM, noreply at launchpad.net wrote: > > @@ -510,6 +507,12 @@ > try: > msgfp = open(pckfile) > msg = cPickle.load(msgfp) > + if data == {}: This looks a little Pythonically weird; maybe if len(data) == 0 instead? > + # There was no .db file. Is this a post 2.1.5 .pck? > + try: > + data = cPickle.load(msgfp) > + except EOFError: > + pass > os.unlink(pckfile) > except EnvironmentError, e: > if e.errno <> errno.ENOENT: raise Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSbw52nEjvBPtnXfVAQKhmQP/aZDty8h2jtExUlcSUjsV98zIsxxajO92 ZmxdMc6NQd+42N+ZVvMJqdaQatUUbUArap+gvlLTxuPJOoFe0JjWfed79VMSFwkQ lvmR4EdJTby/tT95U72/w/gKjA/+KH9m6SgHdu06iUGTVaM+pzwLkqQK6/qQKpIY XHaxZpebxZ8= =lsE0 -----END PGP SIGNATURE----- From mark at msapiro.net Sun Mar 15 00:40:32 2009 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 14 Mar 2009 16:40:32 -0700 Subject: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev 1046: - Changed someold messages for more current meaning. In-Reply-To: <4FDDD474-72B7-4F50-8F95-FA18D6D4A230@python.org> Message-ID: Barry Warsaw wrote: > >On Mar 14, 2009, at 6:22 PM, noreply at launchpad.net wrote: >> >> @@ -510,6 +507,12 @@ >> try: >> msgfp = open(pckfile) >> msg = cPickle.load(msgfp) >> + if data == {}: > >This looks a little Pythonically weird; maybe if len(data) == 0 instead? > Thanks Barry. Actually, I was concerned about the possibility that data could be None, but upon closer inspection, that can't happen, and even if it did, it wouldn't matter, so just if data: should be good. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sun Mar 15 00:44:25 2009 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 14 Mar 2009 16:44:25 -0700 Subject: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev1046: - Changed someold messages for more current meaning. In-Reply-To: Message-ID: Mark Sapiro wrote: > >Actually, I was concerned about the possibility that data could be >None, but upon closer inspection, that can't happen, and even if it >did, it wouldn't matter, so just if data: should be good. Ooops. I mean if not data: -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Mon Mar 16 18:18:25 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 16 Mar 2009 13:18:25 -0400 Subject: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev 1046: - Changed someold messages for more current meaning. In-Reply-To: References: <4FDDD474-72B7-4F50-8F95-FA18D6D4A230@python.org> Message-ID: <20090316131825.4305c217@driven.localdomain> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 14, 2009, at 04:40 PM, Mark Sapiro wrote: >Barry Warsaw wrote: >> >>On Mar 14, 2009, at 6:22 PM, noreply at launchpad.net wrote: >>> >>> @@ -510,6 +507,12 @@ >>> try: >>> msgfp = open(pckfile) >>> msg = cPickle.load(msgfp) >>> + if data == {}: >> >>This looks a little Pythonically weird; maybe if len(data) == 0 instead? >> > >Actually, I was concerned about the possibility that data could be >None, but upon closer inspection, that can't happen, and even if it >did, it wouldn't matter, so just if data: should be good. Hi Mark, A style I've adopted for MM3 is that if the object is definitely supposed to be a sequence, emptiness is checked with len(). E.g. for a string, list, tuple, dictionary, you'd use: if len(data) == 0: If the object could be a sequence or None, then bare if would be used, but I generally add a comment to explain things, e.g.: # data could be an empty dictionary or None if not data: What do you think? MM2 is pretty inconsistent here so I'm not sure whether it's worth adopting or (in 2.2) converting to this style. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm+ieEACgkQ2YZpQepbvXG5kgCgssRqZ73I6YuWWJOCd6RRjK+v g4UAnR/qLSW52K9vVrqkWEVSw4Sp9yXd =1o90 -----END PGP SIGNATURE----- From mark at msapiro.net Mon Mar 16 18:50:24 2009 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 16 Mar 2009 10:50:24 -0700 Subject: [Mailman-Developers] Mailman 2.1.12 - Python 2.4.[456] incompatibility Message-ID: <49BE9160.9020805@msapiro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is an internal inconsistency in the 3.0.2 email package that shipped with Python 2.4.4 through 2.4.6. This has to do with the Charset.Charset() constructor setting input_charset to a unicode which then causes TypeError: decoding Unicode is not supported exceptions in other parts of the email package. This problem does not seem to occur with email 3.0.1 and Python 2.4.[123]. This (along with other stuff) is discussed in the bug report at and there is a patch for email/Charset.py at At this point, the best advice seems to be use Python 2.5 or 2.6 with Mailman 2.1.12. - -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFJvpFfVVuXXpU7hpMRAt1PAKDJ6BY84Fx271paX1m4BrtUikMFvQCePbyg 8xyRMCTeV2GB5v0ZZhjCf7E= =ji8z -----END PGP SIGNATURE----- From stephen at xemacs.org Mon Mar 16 19:03:25 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 17 Mar 2009 03:03:25 +0900 Subject: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev 1046: - Changed someold messages for more current meaning. In-Reply-To: <20090316131825.4305c217@driven.localdomain> References: <4FDDD474-72B7-4F50-8F95-FA18D6D4A230@python.org> <20090316131825.4305c217@driven.localdomain> Message-ID: <87ocw173bm.fsf@xemacs.org> Barry Warsaw writes: > A style I've adopted for MM3 is that if the object is definitely supposed to > be a sequence, emptiness is checked with len(). E.g. for a string, list, > tuple, dictionary, you'd use: > > if len(data) == 0: > > If the object could be a sequence or None, then bare if would be used, but I > generally add a comment to explain things, e.g.: > > # data could be an empty dictionary or None > if not data: If you document the style in a developer's guide or something like that, I'd rather not have the comment every time. "None" would seem to indicate "Yo! Initialize me!", and you'd check for that with "if data is None". "if not data" would be the case where either there never was anything to do, or nothing is left to do, so stop doing it. And if len(data) == 0 is a terminal condition for initialized data. So I don't think you need the comment. Or are there other usages you have in mind that I've missed? From barry at list.org Mon Mar 16 20:06:08 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 16 Mar 2009 15:06:08 -0400 Subject: [Mailman-Developers] [Branch~mailman-coders/mailman/2.2] Rev 1046: - Changed someold messages for more current meaning. In-Reply-To: <87ocw173bm.fsf@xemacs.org> References: <4FDDD474-72B7-4F50-8F95-FA18D6D4A230@python.org> <20090316131825.4305c217@driven.localdomain> <87ocw173bm.fsf@xemacs.org> Message-ID: <20090316150608.09df6aca@driven.localdomain> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 17, 2009, at 03:03 AM, Stephen J. Turnbull wrote: >If you document the style in a developer's guide or something like >that, I'd rather not have the comment every time. That's a good point, and I do intend to update the Mailman style guide to cover this. >"None" would seem >to indicate "Yo! Initialize me!", and you'd check for that with "if >data is None". Exactly right. >"if not data" would be the case where either there >never was anything to do, or nothing is left to do, so stop doing it. >And if len(data) == 0 is a terminal condition for initialized data. >So I don't think you need the comment. > >Or are there other usages you have in mind that I've missed? Nope, that about covers it. So maybe the comment is overkill given a(n updated) style guide to work from. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm+oyAACgkQ2YZpQepbvXGHCQCfdYsd5pD56cIirnqGPZ+sOBUa woIAn2D4cpKo7/Bj++c7cXQEQr+Zysu3 =8SKO -----END PGP SIGNATURE----- From barry at list.org Thu Mar 19 03:07:26 2009 From: barry at list.org (Barry Warsaw) Date: Wed, 18 Mar 2009 22:07:26 -0400 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090223152046.GH18852@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> Message-ID: <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 23, 2009, at 10:20 AM, Patrick Ben Koetter wrote: > I am collecting information for my work on the MM3 Webinterface > while we meet > at PyCon 2009 sprint. Which I'm really looking forward to! Apologies for not responding sooner. > So far I have found the "Summer of Code summary" > . > > Any other information/writing I should collect and read before we > meet? The only other thing to look at is this branch: https://code.edge.launchpad.net/~mk2s/mailman/restserver It's the work that Maki and Andrew did at last year's sprint. This is for the Mailman 2.2 branch, but there's some interesting work there regarding the REST server. I don't know if we should use this branch in the 3.0 version, but it's worth discussing as a starting point. > I also believe I had seen a page where you (?) had noted a link for > a design > you favoured, but I can't find it. Can you post the link or come up > with a > list of sites you like? (Not that we weren't able to develop design. > I just > want to get an idea.). Oh man, it either wasn't me or I don't remember. ;) Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknBqN4ACgkQ2YZpQepbvXFOegCcDB4gi1f/rOkepVUrF4qgMCZB RvcAoLbFUhSEraOnhWXZJTq1s29E6Bam =9Btc -----END PGP SIGNATURE----- From p at state-of-mind.de Thu Mar 19 08:03:36 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Thu, 19 Mar 2009 08:03:36 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> Message-ID: <20090319070331.GA9469@state-of-mind.de> * Barry Warsaw : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 23, 2009, at 10:20 AM, Patrick Ben Koetter wrote: > >> I am collecting information for my work on the MM3 Webinterface while >> we meet >> at PyCon 2009 sprint. > > Which I'm really looking forward to! Apologies for not responding > sooner. I guess you have work to do, too. ;) >> So far I have found the "Summer of Code summary" >> . >> >> Any other information/writing I should collect and read before we >> meet? > > The only other thing to look at is this branch: > > https://code.edge.launchpad.net/~mk2s/mailman/restserver > > It's the work that Maki and Andrew did at last year's sprint. This is > for the Mailman 2.2 branch, but there's some interesting work there > regarding the REST server. I don't know if we should use this branch in > the 3.0 version, but it's worth discussing as a starting point. Agreed. Same idea here. >> I also believe I had seen a page where you (?) had noted a link for a >> design you favoured, but I can't find it. Can you post the link or come up >> with a list of sites you like? (Not that we weren't able to develop design. >> I just want to get an idea.). > > Oh man, it either wasn't me or I don't remember. ;) Aesthetic design is something we can turn to later. I for myself want to use our sprint time to work on information architecture, client features etc. I am currently working on a proposal to rearrange the information structure and I am writing down some basic requirements we should want from the interface (W3A, etc.). I'll put it up on a wiki and send the link to the list as soon as I am done. This should put us in the middle of work and not at its beginning when we meet. p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 45227227 81669 M?nchen Telefax +49 89 45227226 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From p at state-of-mind.de Fri Mar 20 23:22:37 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Fri, 20 Mar 2009 23:22:37 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090319070331.GA9469@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> Message-ID: <20090320222237.GA16638@state-of-mind.de> * Patrick Ben Koetter

: > Aesthetic design is something we can turn to later. I for myself want to use > our sprint time to work on information architecture, client features etc. > > I am currently working on a proposal to rearrange the information structure > and I am writing down some basic requirements we should want from the > interface (W3A, etc.). Here's the link to a wiki I've put up to get started: I will add more as I get to it. Comments, ideas, improvements are welcome. The server part, for example, is completely empty at the moment... p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 45227227 81669 M?nchen Telefax +49 89 45227226 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From skip at pobox.com Sat Mar 21 00:12:13 2009 From: skip at pobox.com (skip at pobox.com) Date: Fri, 20 Mar 2009 18:12:13 -0500 Subject: [Mailman-Developers] Sprint on Mailman/SpamBayes integration at PyCon? Message-ID: <18884.8909.847281.718326@montanaro.dyndns.org> Would any Mailman experts like to help me out with a bit better Mailman/SpamBayes integration at the PyCon sprints? I plan to be there just a couple days. I was able to integrate SpamBayes into gate_news, but there is no user interface for training and no direct integration into other parts of SpamBayes. (SpamBayes is invoked on mail.python.org long before mail messages get to Mailman.) So, would anyone be interested in at least being a subject matter expert on the Mailman site of things? -- Skip Montanaro - skip at pobox.com - http://www.smontanaro.net/ From p at state-of-mind.de Mon Mar 23 14:25:29 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 23 Mar 2009 14:25:29 +0100 Subject: [Mailman-Developers] Web Interface: Login Message-ID: <20090323132528.GA32098@state-of-mind.de> Is there any reason why there need to be two login screens? One for regular users and another one for moderatores/admin? p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From barry at list.org Mon Mar 23 14:26:11 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 09:26:11 -0400 Subject: [Mailman-Developers] Web Interface: Login In-Reply-To: <20090323132528.GA32098@state-of-mind.de> References: <20090323132528.GA32098@state-of-mind.de> Message-ID: <885C6D25-556F-4F6A-9BF5-C8AAEE33C616@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 23, 2009, at 9:25 AM, Patrick Ben Koetter wrote: > Is there any reason why there need to be two login screens? > One for regular users and another one for moderatores/admin? No. Well, no /good/ reason. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHjfQACgkQ2YZpQepbvXEyHACfVyyCHbatJyDv14iRCtVIzGOB zXQAn0V4D3belLBFitwvrlhdRTqq9HI2 =LWOA -----END PGP SIGNATURE----- From p at state-of-mind.de Mon Mar 23 14:47:23 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 23 Mar 2009 14:47:23 +0100 Subject: [Mailman-Developers] Web Interface: Login In-Reply-To: <885C6D25-556F-4F6A-9BF5-C8AAEE33C616@list.org> References: <20090323132528.GA32098@state-of-mind.de> <885C6D25-556F-4F6A-9BF5-C8AAEE33C616@list.org> Message-ID: <20090323134723.GB32098@state-of-mind.de> * Barry Warsaw : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 23, 2009, at 9:25 AM, Patrick Ben Koetter wrote: > >> Is there any reason why there need to be two login screens? >> One for regular users and another one for moderatores/admin? I think it makes sense to simplify the interface and have only one login page, but ... Subscribers need to provide their mail address (authentication identity) and their password. Admin and moderators currently don't have to. If we had only one login page, would that require admin and moderators to provide an authentication identity too and not only their password? (At the moment I believe this would be a benefit. One could have more than one admin without having them share one password.) Would that break any upgrade compatibility for none MM3 lists? p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From barry at list.org Mon Mar 23 15:08:49 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 10:08:49 -0400 Subject: [Mailman-Developers] Web Interface: Login In-Reply-To: <20090323134723.GB32098@state-of-mind.de> References: <20090323132528.GA32098@state-of-mind.de> <885C6D25-556F-4F6A-9BF5-C8AAEE33C616@list.org> <20090323134723.GB32098@state-of-mind.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 23, 2009, at 9:47 AM, Patrick Ben Koetter wrote: > I think it makes sense to simplify the interface and have only one > login page, > but ... > > Subscribers need to provide their mail address (authentication > identity) and > their password. Admin and moderators currently don't have to. This is broken, for many reasons. It's this way because MM2 doesn't have a notion of roles, so "admin" and "moderator" is defined solely because you know a password. This password is shared among all people sharing that role, which is another reason why this is broken. Ideally, (in MM3) Mailman would have accounts, which would be separate from but linked with the email addresses it manages for lists and such. It should be separate in the sense that authentication information may come from external systems, e.g. your content management user accounts, or Launchpad, or OpenID, etc. > If we had only one login page, would that require admin and > moderators to > provide an authentication identity too and not only their password? > (At the > moment I believe this would be a benefit. One could have more than > one admin > without having them share one password.) > > Would that break any upgrade compatibility for none MM3 lists? Let's worry only about MM3 lists here. We'll have to deal with upgrading/importing from MM2 at some point, but if possibly I'd like to not compromise the MM3 design with worrying about importing from MM2. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHl/EACgkQ2YZpQepbvXG7qwCgqfdB0eGVgWol0NcDqUoxpN3p t9MAnRRCLi08H6t5wEPQtWFw5iG9B5TV =L3oK -----END PGP SIGNATURE----- From p at state-of-mind.de Mon Mar 23 15:20:38 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 23 Mar 2009 15:20:38 +0100 Subject: [Mailman-Developers] Web Interface: Login In-Reply-To: References: <20090323132528.GA32098@state-of-mind.de> <885C6D25-556F-4F6A-9BF5-C8AAEE33C616@list.org> <20090323134723.GB32098@state-of-mind.de> Message-ID: <20090323142038.GC32098@state-of-mind.de> * Barry Warsaw : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 23, 2009, at 9:47 AM, Patrick Ben Koetter wrote: > >> I think it makes sense to simplify the interface and have only one >> login page, >> but ... >> >> Subscribers need to provide their mail address (authentication >> identity) and >> their password. Admin and moderators currently don't have to. > > This is broken, for many reasons. It's this way because MM2 doesn't > have a notion of roles, so "admin" and "moderator" is defined solely > because you know a password. This password is shared among all people > sharing that role, which is another reason why this is broken. Agreed. > Ideally, (in MM3) Mailman would have accounts, which would be separate > from but linked with the email addresses it manages for lists and such. > It should be separate in the sense that authentication information may > come from external systems, e.g. your content management user accounts, > or Launchpad, or OpenID, etc. Yes, I think a role model is a good idea and using external services is IMO a good idea too. >> If we had only one login page, would that require admin and moderators to >> provide an authentication identity too and not only their password? (At >> the moment I believe this would be a benefit. One could have more than one >> admin without having them share one password.) >> >> Would that break any upgrade compatibility for none MM3 lists? > > Let's worry only about MM3 lists here. We'll have to deal with > upgrading/importing from MM2 at some point, but if possibly I'd like to > not compromise the MM3 design with worrying about importing from MM2. Fine. I will work with a unified login model then. p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From barry at list.org Mon Mar 23 15:28:38 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 10:28:38 -0400 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090320222237.GA16638@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 20, 2009, at 6:22 PM, Patrick Ben Koetter wrote: > Here's the link to a wiki I've put up to get started: > > Hi Patrick, Do you think the Mailman wiki would be a better place for this? > I will add more as I get to it. Comments, ideas, improvements are > welcome. > The server part, for example, is completely empty at the moment... One thing we discussed at last year's sprint, is the model that the REST interface will have full admin access to Mailman's data model. I.e. it will by design be fully authenticated. The reason for this is that we'd like it to act as an API that other systems can use to integrate mailing list services into their systems. For example, if you had a web site running PHP that you wanted to use Mailman for your mailing lists, it could use this REST API to control and query Mailman. What this means though is that when you deploy Mailman's REST interface, you must take care to protect it. You wouldn't want to expose it to the internet for example. You'd want to make sure that its interface is accessibly on via your data center, or via localhost if you were running a turnkey standalone system. Still, this provides great advantages, such as the ability for us to ship a web interface as an add on, and for sites to easily swap out the web interface, or create their own ways of accessing and controlling Mailman without having to write Python code (which they can do in MM2 and will be able to do in MM3, though few sites apparently do this). So while an account/login model is necessary (e.g. for the email interface), it needn't be required for accessing the REST API. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHnJYACgkQ2YZpQepbvXG61QCaAyejP3BWk8XuTVoPWUfgxwy1 0f8An1uI13rnc97QoLJg/gQTBvmU/WW7 =lnPY -----END PGP SIGNATURE----- From barry at list.org Mon Mar 23 15:30:08 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 10:30:08 -0400 Subject: [Mailman-Developers] Sprint on Mailman/SpamBayes integration at PyCon? In-Reply-To: <18884.8909.847281.718326@montanaro.dyndns.org> References: <18884.8909.847281.718326@montanaro.dyndns.org> Message-ID: <3887A277-5CE7-4198-9FB6-1D18E2F8F5CF@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 20, 2009, at 7:12 PM, skip at pobox.com wrote: > Would any Mailman experts like to help me out with a bit better > Mailman/SpamBayes integration at the PyCon sprints? I plan to be > there just > a couple days. I was able to integrate SpamBayes into gate_news, > but there > is no user interface for training and no direct integration into > other parts > of SpamBayes. (SpamBayes is invoked on mail.python.org long before > mail > messages get to Mailman.) > > So, would anyone be interested in at least being a subject matter > expert on > the Mailman site of things? Hi Skip. I'll be sprinting and yes, I would like to help you out with this. We can talk about how to do the MM2 integration, but I'd also like to use this as an experiment on defining the plugin architecture for MM3. I would love to have Spambayes available as a MM3 plugin and I don't think it would be too difficult. It would make a nice first test case. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHnPAACgkQ2YZpQepbvXHtgACgqYEaT+OfQPNX+sX+EXwgwSYw PsgAn3Ictr5Yjs+bXOGfnRArMMWCIix7 =suPq -----END PGP SIGNATURE----- From skip at pobox.com Mon Mar 23 15:46:09 2009 From: skip at pobox.com (skip at pobox.com) Date: Mon, 23 Mar 2009 09:46:09 -0500 Subject: [Mailman-Developers] Sprint on Mailman/SpamBayes integration at PyCon? In-Reply-To: <3887A277-5CE7-4198-9FB6-1D18E2F8F5CF@list.org> References: <18884.8909.847281.718326@montanaro.dyndns.org> <3887A277-5CE7-4198-9FB6-1D18E2F8F5CF@list.org> Message-ID: <18887.41137.97890.587419@montanaro.dyndns.org> Barry> Hi Skip. I'll be sprinting and yes, I would like to help you out Barry> with this. That's good to hear. I will only be sprinting for two days of the four. If you let me know when you'll be focusing on this stuff I will plan to be there. Skip From p at state-of-mind.de Mon Mar 23 15:55:57 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 23 Mar 2009 15:55:57 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> Message-ID: <20090323145556.GD32098@state-of-mind.de> * Barry Warsaw : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 20, 2009, at 6:22 PM, Patrick Ben Koetter wrote: > >> Here's the link to a wiki I've put up to get started: >> >> > > Hi Patrick, > > Do you think the Mailman wiki would be a better place for this? Yes. It keeps everything in one place. I would have to work around the freemind mindmap flash fancy stuff though, which I've just fallen in love with. But let's not let this get in the way. How do we do it? Do I get write access to Mailman wiki? >> I will add more as I get to it. Comments, ideas, improvements are >> welcome. >> The server part, for example, is completely empty at the moment... > > One thing we discussed at last year's sprint, is the model that the REST > interface will have full admin access to Mailman's data model. I.e. it > will by design be fully authenticated. The reason for this is that we'd > like it to act as an API that other systems can use to integrate mailing > list services into their systems. For example, if you had a web site > running PHP that you wanted to use Mailman for your mailing lists, it > could use this REST API to control and query Mailman. We've thought about different client technologies too. That's the client technology part I wrote about in the wiki. Which we didn't discuss was fully authenticated access for the REST server by design. If I understand this correctly than any party that is able to communicate with the REST server will have full admin access to Mailman's data model. In other words: It's upon any REST client to protect the REST server from abuse. I feel a little uneasy not having the server control that itself unless we find a good way to control who may connect to the server or the server is able to identify valid clients by some client identity (ACL). > What this means though is that when you deploy Mailman's REST interface, > you must take care to protect it. You wouldn't want to expose it to the > internet for example. You'd want to make sure that its interface is > accessibly on via your data center, or via localhost if you were running > a turnkey standalone system. I was thinking of TLS client/server authentication for open networks. Not that I have spent time yet to find out if Python (REST) tools provide such functionality - I am sure it does, but given my low Python experience, I'd rather verify... > Still, this provides great advantages, such as the ability for us to > ship a web interface as an add on, and for sites to easily swap out the > web interface, or create their own ways of accessing and controlling > Mailman without having to write Python code (which they can do in MM2 and > will be able to do in MM3, though few sites apparently do this). Same idea here. p at rick > So while an account/login model is necessary (e.g. for the email > interface), it needn't be required for accessing the REST API. > > Barry > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > > iEYEARECAAYFAknHnJYACgkQ2YZpQepbvXG61QCaAyejP3BWk8XuTVoPWUfgxwy1 > 0f8An1uI13rnc97QoLJg/gQTBvmU/WW7 > =lnPY > -----END PGP SIGNATURE----- -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From barry at list.org Mon Mar 23 17:47:22 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 12:47:22 -0400 Subject: [Mailman-Developers] Sprint on Mailman/SpamBayes integration at PyCon? In-Reply-To: <18887.41137.97890.587419@montanaro.dyndns.org> References: <18884.8909.847281.718326@montanaro.dyndns.org> <3887A277-5CE7-4198-9FB6-1D18E2F8F5CF@list.org> <18887.41137.97890.587419@montanaro.dyndns.org> Message-ID: <0D3CBC6B-425A-4A7A-9D62-40FDFE090831@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 23, 2009, at 10:46 AM, skip at pobox.com wrote: > Barry> Hi Skip. I'll be sprinting and yes, I would like to help > you out > Barry> with this. > > That's good to hear. I will only be sprinting for two days of the > four. If > you let me know when you'll be focusing on this stuff I will plan to > be > there. We're planning the main sprint day for Tuesday the 31st and we'll try to get some time in on Wednesday and Thursday if possible. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknHvRoACgkQ2YZpQepbvXHhKwCfcBMNdQrej9tGmuDqmv9hmQ6L d3sAn1jYp5A7eUO4otTPddbJZEcHxYSF =l5AH -----END PGP SIGNATURE----- From barry at list.org Tue Mar 24 00:48:16 2009 From: barry at list.org (Barry Warsaw) Date: Mon, 23 Mar 2009 19:48:16 -0400 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090323145556.GD32098@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> Message-ID: <957254C5-6009-46B6-BBA3-3491552336EE@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 23, 2009, at 10:55 AM, Patrick Ben Koetter wrote: > Yes. It keeps everything in one place. I would have to work around the > freemind mindmap flash fancy stuff though, which I've just fallen in > love > with. But let's not let this get in the way. > > How do we do it? Do I get write access to Mailman wiki? You should have write access just by virtue of having an account on the wiki. There are only a few pages that aren't generally writable by every logged in user. If you're having a problem with a specific page, let me know. > We've thought about different client technologies too. That's the > client > technology part I wrote about in the wiki. > > Which we didn't discuss was fully authenticated access for the REST > server by > design. If I understand this correctly than any party that is able to > communicate with the REST server will have full admin access to > Mailman's data > model. In other words: It's upon any REST client to protect the REST > server > from abuse. That's basically correct. > I feel a little uneasy not having the server control that itself > unless we > find a good way to control who may connect to the server or the > server is able > to identify valid clients by some client identity (ACL). It depends on whether we view the REST API as a user feature or an admin interface. I've always thought about it as the latter, but I'm open to other opinions. OTOH, I think there's a lot of functionality that a privileged process could need, that the general public won't need at all. Another way to think about it is that there doesn't need to be just one REST API. >> What this means though is that when you deploy Mailman's REST >> interface, >> you must take care to protect it. You wouldn't want to expose it >> to the >> internet for example. You'd want to make sure that its interface is >> accessibly on via your data center, or via localhost if you were >> running >> a turnkey standalone system. > > I was thinking of TLS client/server authentication for open > networks. Not that > I have spent time yet to find out if Python (REST) tools provide such > functionality - I am sure it does, but given my low Python > experience, I'd > rather verify... I'm not sure about this either. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknIH8AACgkQ2YZpQepbvXHdPACeOlFuUp985yiVMpDqcMUEjIyc 3rcAoJukYnubROsC9yK1SMt6KV7yjFBk =yOAo -----END PGP SIGNATURE----- From p at state-of-mind.de Tue Mar 24 07:44:18 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 24 Mar 2009 07:44:18 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <957254C5-6009-46B6-BBA3-3491552336EE@list.org> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> <957254C5-6009-46B6-BBA3-3491552336EE@list.org> Message-ID: <20090324064414.GA8967@state-of-mind.de> * Barry Warsaw : >> How do we do it? Do I get write access to Mailman wiki? > > You should have write access just by virtue of having an account on the > wiki. There are only a few pages that aren't generally writable by every > logged in user. If you're having a problem with a specific page, let me > know. I'll give it a try later. >> We've thought about different client technologies too. That's the client >> technology part I wrote about in the wiki. >> >> Which we didn't discuss was fully authenticated access for the REST server >> by design. If I understand this correctly than any party that is able to >> communicate with the REST server will have full admin access to Mailman's >> data model. In other words: It's upon any REST client to protect the REST >> server from abuse. > > That's basically correct. > >> I feel a little uneasy not having the server control that itself unless we >> find a good way to control who may connect to the server or the server is >> able to identify valid clients by some client identity (ACL). > > It depends on whether we view the REST API as a user feature or an admin > interface. I've always thought about it as the latter, but I'm open to It's probably both, depending on the users role. > other opinions. OTOH, I think there's a lot of functionality that a > privileged process could need, that the general public won't need at all. That's what I think, too. > Another way to think about it is that there doesn't need to be just one > REST API. Yes and I think this would make maintaining code, setting the whole system up and configuring it more complicated. Currently one REST server that uses a role model to determine access level to MM's data model seems the best approach to me. I am open to suggestions. >>> What this means though is that when you deploy Mailman's REST interface, >>> you must take care to protect it. You wouldn't want to expose it to the >>> internet for example. You'd want to make sure that its interface is Exposing it to the internet is a typical use case in my eyes e.g. run the server on the internet, but control it from a different host. I can see mailman providers offering access to their MM server to customers who integrate their client on their servers - on the internet. >>> accessibly on via your data center, or via localhost if you were running >>> a turnkey standalone system. >> >> I was thinking of TLS client/server authentication for open networks. Not >> that I have spent time yet to find out if Python (REST) tools provide such >> functionality - I am sure it does, but given my low Python experience, I'd >> rather verify... > > I'm not sure about this either. We should check. Client/server communication will send/receive personal data that IMHO should always be protected during transport regardless of the REST data access control model we choose. p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 45227227 81669 M?nchen Telefax +49 89 45227226 Amtsgericht M?nchen Partnerschaftsregister PR 563 From p at state-of-mind.de Tue Mar 24 10:16:31 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 24 Mar 2009 10:16:31 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090324064414.GA8967@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> <957254C5-6009-46B6-BBA3-3491552336EE@list.org> <20090324064414.GA8967@state-of-mind.de> Message-ID: <20090324091631.GA31189@state-of-mind.de> * Patrick Ben Koetter

: > * Barry Warsaw : > >> How do we do it? Do I get write access to Mailman wiki? > > > > You should have write access just by virtue of having an account on the > > wiki. There are only a few pages that aren't generally writable by every > > logged in user. If you're having a problem with a specific page, let me > > know. > > I'll give it a try later. Any special place I should migrate our wiki to? These locations already exist, but I wouldn't want to modify their content: I could create sub-pages. Any preferences, ideas? p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From barry at list.org Tue Mar 24 11:56:14 2009 From: barry at list.org (Barry Warsaw) Date: Tue, 24 Mar 2009 06:56:14 -0400 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <20090324091631.GA31189@state-of-mind.de> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> <957254C5-6009-46B6-BBA3-3491552336EE@list.org> <20090324064414.GA8967@state-of-mind.de> <20090324091631.GA31189@state-of-mind.de> Message-ID: <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 24, 2009, at 5:16 AM, Patrick Ben Koetter wrote: > * Patrick Ben Koetter

: >> * Barry Warsaw : >>>> How do we do it? Do I get write access to Mailman wiki? >>> >>> You should have write access just by virtue of having an account >>> on the >>> wiki. There are only a few pages that aren't generally writable >>> by every >>> logged in user. If you're having a problem with a specific page, >>> let me >>> know. >> >> I'll give it a try later. > > Any special place I should migrate our wiki to? > These locations already exist, but I wouldn't want to modify their > content: > > > > > I could create sub-pages. > > Any preferences, ideas? You could either add to the bottom of those pages (which will make them easier to garden later), or you could make them subpages of http://wiki.list.org/display/DEV/PyCon+Sprint+2009 BTW, has the wiki been slow for anybody else? Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknIvE4ACgkQ2YZpQepbvXHa+ACfcSFh4QtSx/TCE/v/MWw321ed GVAAoKEEQ4NB29BVNr1L9AjPM9v9R2VC =3CN4 -----END PGP SIGNATURE----- From p at state-of-mind.de Tue Mar 24 13:26:44 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 24 Mar 2009 13:26:44 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> <957254C5-6009-46B6-BBA3-3491552336EE@list.org> <20090324064414.GA8967@state-of-mind.de> <20090324091631.GA31189@state-of-mind.de> <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> Message-ID: <20090324122643.GE31189@state-of-mind.de> * Barry Warsaw : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 24, 2009, at 5:16 AM, Patrick Ben Koetter wrote: > >> * Patrick Ben Koetter

: >>> * Barry Warsaw : >>>>> How do we do it? Do I get write access to Mailman wiki? >>>> >>>> You should have write access just by virtue of having an account >>>> on the >>>> wiki. There are only a few pages that aren't generally writable >>>> by every >>>> logged in user. If you're having a problem with a specific page, >>>> let me >>>> know. >>> >>> I'll give it a try later. >> >> Any special place I should migrate our wiki to? >> These locations already exist, but I wouldn't want to modify their >> content: >> >> >> >> >> I could create sub-pages. >> >> Any preferences, ideas? > > You could either add to the bottom of those pages (which will make them > easier to garden later), or you could make them subpages of > > http://wiki.list.org/display/DEV/PyCon+Sprint+2009 I'll make them subpages of Sprint+2009. > > BTW, has the wiki been slow for anybody else? Yep. p at rick > Barry > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > > iEYEARECAAYFAknIvE4ACgkQ2YZpQepbvXHa+ACfcSFh4QtSx/TCE/v/MWw321ed > GVAAoKEEQ4NB29BVNr1L9AjPM9v9R2VC > =3CN4 > -----END PGP SIGNATURE----- -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From p at state-of-mind.de Tue Mar 24 14:15:31 2009 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 24 Mar 2009 14:15:31 +0100 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> References: <20090223152046.GH18852@state-of-mind.de> <2599058C-AD85-426E-A37E-CDD240A67F3A@list.org> <20090319070331.GA9469@state-of-mind.de> <20090320222237.GA16638@state-of-mind.de> <20090323145556.GD32098@state-of-mind.de> <957254C5-6009-46B6-BBA3-3491552336EE@list.org> <20090324064414.GA8967@state-of-mind.de> <20090324091631.GA31189@state-of-mind.de> <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> Message-ID: <20090324131531.GF31189@state-of-mind.de> * Barry Warsaw : > http://wiki.list.org/display/DEV/PyCon+Sprint+2009 > > BTW, has the wiki been slow for anybody else? It's so slow at the moment it's a pain to work with. Any chance to bring this back to normal? thanks, p at rick -- state of mind Agentur f?r Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From mark at msapiro.net Tue Mar 24 18:26:39 2009 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 24 Mar 2009 10:26:39 -0700 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: <31CB93AD-F1FD-423D-B06B-6B69ADC1012C@list.org> Message-ID: Barry Warsaw wrote: > >BTW, has the wiki been slow for anybody else? For me it has sometimes been slow, but not consistently so. /Mark -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From terri at zone12.com Tue Mar 24 18:31:33 2009 From: terri at zone12.com (Terri Oda) Date: Tue, 24 Mar 2009 13:31:33 -0400 Subject: [Mailman-Developers] PyCon 2009 sprint: Webinterface In-Reply-To: References: Message-ID: <49C918F5.2000205@zone12.com> Mark Sapiro wrote: > Barry Warsaw wrote: >> BTW, has the wiki been slow for anybody else? > > > For me it has sometimes been slow, but not consistently so. Agreed. And it's also been so slow that it's been unusable at times and I've had to just come back later. Terri From terri at zone12.com Sun Mar 29 06:10:22 2009 From: terri at zone12.com (Terri Oda) Date: Sun, 29 Mar 2009 00:10:22 -0400 Subject: [Mailman-Developers] Putting the FAQ link in with error messages? Message-ID: <49CEF4AE.7030801@zone12.com> We often *have* the answers in the FAQ, people aren't always finding them there, often because it hasn't occurred to them to look. I was mentioned this to the last person who I helped with a Mailman problem, and he offered this brilliant suggestion: Why don't we print the FAQ (or at least the wiki link) with error messages generated by mailman? Just a quick "For more information on this error, consult the documentation at http://wiki.list.org/x/Bw" or something along those lines. I know, it's another line of work for the translators, and it won't solve the problems that aren't heralded by error messages, but hopefully it'll result in more people actually finding the information they need on their own! Terri From barry at list.org Sun Mar 29 15:33:27 2009 From: barry at list.org (Barry Warsaw) Date: Sun, 29 Mar 2009 08:33:27 -0500 Subject: [Mailman-Developers] Putting the FAQ link in with error messages? In-Reply-To: <49CEF4AE.7030801@zone12.com> References: <49CEF4AE.7030801@zone12.com> Message-ID: <0AF3FB6F-97BF-4443-96E9-D06B4CD3D03C@list.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 28, 2009, at 11:10 PM, Terri Oda wrote: > We often *have* the answers in the FAQ, people aren't always finding > them there, often because it hasn't occurred to them to look. > > I was mentioned this to the last person who I helped with a Mailman > problem, and he offered this brilliant suggestion: Why don't we > print the FAQ (or at least the wiki link) with error messages > generated by mailman? > > Just a quick "For more information on this error, consult the > documentation at http://wiki.list.org/x/Bw" or something along those > lines. > > I know, it's another line of work for the translators, and it won't > solve the problems that aren't heralded by error messages, but > hopefully it'll result in more people actually finding the > information they need on their own! This is a very interesting idea. When you say "error messages" do you mean e.g. Python tracebacks and such? In that case, we may not have to worry about translators, for example we don't translate log messages. It would mean going through various exceptions that Mailman raises and adding information to tie it to a FAQ entry (or as you point out, more easily just the top wiki link). Tougher would be to attach FAQ links to exceptions that Python throws that percolate up to the top interpreter loop. Still, it's a really interesting idea to pursue, and it would make for a neat general Python facility. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknPeKgACgkQ2YZpQepbvXGVcwCgh9cjzC0CGo5LrLq7q+Msxnyj tEgAoJXSbxPcbFOGyJu6QLRnKPIRlJRM =ujfL -----END PGP SIGNATURE----- From stephen at xemacs.org Sun Mar 29 16:04:17 2009 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 29 Mar 2009 23:04:17 +0900 Subject: [Mailman-Developers] Putting the FAQ link in with error messages? In-Reply-To: <49CEF4AE.7030801@zone12.com> References: <49CEF4AE.7030801@zone12.com> Message-ID: <87ocvkwhlq.fsf@xemacs.org> Terri Oda writes: > I know, it's another line of work for the translators, This is not a problem. This is precisely what they signed up for. Communicating important information. From dgero at CIS.FU-Berlin.DE Sun Mar 29 21:24:30 2009 From: dgero at CIS.FU-Berlin.DE (Gero Eggers) Date: Sun, 29 Mar 2009 21:24:30 +0200 Subject: [Mailman-Developers] Putting the FAQ link in with error messages? In-Reply-To: <49CEF4AE.7030801@zone12.com> References: <49CEF4AE.7030801@zone12.com> Message-ID: <20090329192430.GA31678691@CIS.FU-Berlin.DE> Hello there! On Sun, Mar 29, 2009 at 12:10:22AM -0400, Terri Oda wrote: > Just a quick "For more information on this error, consult the documentation > at http://wiki.list.org/x/Bw" or something along those lines. I'd like to throw in the idea of not using a wiki URL, but a more generic one that is http-redirected to the current, software-specific URL. example: output URL: http://www.list.org/faq/4.36 redirect to: -> http://wiki.list.org/pages/viewpage.action?pageId=4030705 cheers, Gero PS: I'm more of a mailman user, therefore this is my first post here. :) From asaf at lingnu.com Tue Mar 31 15:43:48 2009 From: asaf at lingnu.com (Asaf) Date: Tue, 31 Mar 2009 16:43:48 +0300 Subject: [Mailman-Developers] Inserting content to an html message (aka: unsubscribe link). Message-ID: <49D21E14.8020604@lingnu.com> Hello Is anyone working on the subject ? can anyone suggest approaches, I'm pretty new to mailman's code I know the its considered impossible, and that html messages are considered bad, but there is no other way to format, for example , bidi languages in non-html emails, and listserv, for example, can embed link (e.g : unsubscribe) in the footer of an html message (AFAIK) I'd like to implement this, I think it shouldn't be that hard, and would work in most cases. -- Asaf Ohaion Lingnu Open Source Consulting Ltd. http://www.lingnu.com