From terri at zone12.com Tue Mar 1 07:28:45 2005 From: terri at zone12.com (Terri Oda) Date: Tue Mar 1 07:27:30 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <1108666518.10068.37.camel@geddy.wooz.org> References: <20050217182300.A9B4B1E4005@bag.python.org> <1108666518.10068.37.camel@geddy.wooz.org> Message-ID: <6d5a1de31f70691721e325915120f0c1@zone12.com> On Feb 17, 2005, at 1:55 PM, Barry Warsaw wrote: > It's unfortunate that your developer can't adapt to the Mailman coding > style. I work on tons of open source software, and of course lots of > software at my job, and each project has its own coding guidelines. > "When in Rome..." is the operative phrase here. > > Hopefully someone else will adapt the code to the style guide. Could someone who's seen it suggest how hard it'll be to adapt? It sounds like great stuff that I know my users would like... From mark at mdt-consulting.com Tue Mar 1 07:47:34 2005 From: mark at mdt-consulting.com (Mark Tilden) Date: Tue Mar 1 07:47:36 2005 Subject: [Mailman-Developers] Using an external system to generate passwords, etc.. Message-ID: I'm wondering if anybody has integrated Mailman's user name/password system with external systems that generate the user names and passwords. I've searched the archives and found a few references to using MySQL or LDAP, but nothing concrete enough to tell if it's actually implemented somewhere. My goal is to integrate Mailman and it's admin pages into a larger site that already has a system of creating user names and passwords (using email addresses as user names). I run several smaller Mailman lists, and we're trying to integrate one of these lists with the existing site. If anybody has any pointers, I'd appreciate it. I've been running Mailman for a couple of years, but haven't dug deeply into the code (and hope to avoid having to...). Thanks! Mark From msapiro at value.net Tue Mar 1 18:17:40 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue Mar 1 18:18:02 2005 Subject: [Mailman-Developers] Using an external system to generate passwords, etc.. In-Reply-To: Message-ID: Mark Tilden wrote: >I'm wondering if anybody has integrated Mailman's user name/password system >with external systems that generate the user names and passwords. I've >searched the archives and found a few references to using MySQL or LDAP, but >nothing concrete enough to tell if it's actually implemented somewhere. See http://sourceforge.net/tracker/index.php?func=detail&aid=839386&group_id=103&atid=300103 and http://sourceforge.net/tracker/index.php?func=detail&aid=871062&group_id=103&atid=300103 for existing implementations. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stefan.schlott at informatik.uni-ulm.de Tue Mar 1 21:01:06 2005 From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott) Date: Tue Mar 1 21:01:33 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <20050228174022.GT6533@banach.uvt.nl> References: <20050228174022.GT6533@banach.uvt.nl> Message-ID: <4224CA02.2030903@informatik.uni-ulm.de> Hi Joost, > I will write and publish a patch which integrates PGP signature > validation and re-encryption of encrypted posts to mailman. Specs are: Don't duplicate work which has already been done :-) I made modifications to mailman 2.1.5 for encrypted mailinglists, but I kept quiet for testing. The test installation seems to behave pretty stable now, so this seems to be a goot point making the patch public. The patch (and a german status of the project) is here: http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml Direct link to the patch: http://medien.informatik.uni-ulm.de/~stefan/mailman-2.1.5-gpg_2005-02-22.diff.gz > - A post will be distributed only if the PGP signature on the post is from > one of the list members. Not implemented in my patch. Signatures are recognised but not used as means of authentication for sending to the list. > - For sending encrypted email, a list member encrypts to the public key of > the list. The post will be decrypted and re-encrypted to the public keys > of all list members. Done. > (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to > RFC 2440 (OpenPGP)). Modular extension of my patch should be possible. Features of the patch: - Web interface for key upload (list key, users' keys) - Several policies for accepting and delivering mails: - Incoming mail must not / may / must be encrypted - Outgoing mails must not / may / must be encrypted - Information on poster's signature embedded in redistributed message - Incoming mail formats: Inline-PGP and PGP/MIME - Outgoing mail formats: Currently PGP/MIME only Current problems: Inline-PGP has never been standardised. This is awful. Every mailer does it a little bit different (content type of mail, encryption of attachments, treatment of encoding scheme). There is still work to do. > So, the plan: > > I think one way to implement it would be to add two modules to > GLOBAL_PIPELINE: in front, before SpamDetect, there would be 'PGPCheck'. At this place, I implemented decryption (and encryption policy enforcement). > A second new module in GLOBAL_PIPELINE would be 'PGPRecrypt', to be > called after CookHeaders' and before 'ToDigest'. This would, if needed, > decrypt the message and reencrypt it to all recipients, and would sign > it. I found no elegant way for distributing encrypted mails, so I patched a copy of the SMTPDirect handler. Currently, every mail is delivered separately (as done for personalised mails); I didn't figure out at first glance how chunking works... otherwise, a mail might be encrypted to several recipients - increasing its length by several bytes, but reducing the number of forks of gpg processes. > For all PGP handling, I plan to use Frank J. Tobin's GnuPGInterface ( > http://py-gnupg.sourceforge.net/ ). That's what I used. Mind that py-gnupg (and gpgme, too) forks a gpg process for every operation. In large lists, this is pretty costly. What do you think? The whole signature thing you planned is still missing, and inline-pgp needs some more work. Stefan. From brad at stop.mail-abuse.org Tue Mar 1 22:16:49 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Mar 1 22:55:39 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <4224CA02.2030903@informatik.uni-ulm.de> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> Message-ID: At 9:01 PM +0100 2005-03-01, Stefan Schlott wrote: >> I will write and publish a patch which integrates PGP signature >> validation and re-encryption of encrypted posts to mailman. Specs are: > > Don't duplicate work which has already been done :-) I made > modifications to mailman 2.1.5 for encrypted mailinglists, but I > kept quiet for testing. The test installation seems to behave > pretty stable now, so this seems to be a goot point making the > patch public. Have either of you solved the problem of Mailman not preserving white space in the message body? This kind of thing is death to messages signed or encrypted with PGP, and I have yet to hear of anyone who has addressed this issue. > I didn't figure out at > first glance how chunking works... otherwise, a mail might be encrypted > to several recipients - increasing its length by several bytes, but > reducing the number of forks of gpg processes. You definitely need to encrypt the message to all recipients, then send out one copy. Anything else would be prohibitively expensive in terms of computation time for any reasonable number of recipients. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From stefan.schlott at informatik.uni-ulm.de Wed Mar 2 08:31:56 2005 From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott) Date: Wed Mar 2 08:32:00 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> Message-ID: <42256BEC.8050702@informatik.uni-ulm.de> Hi, > Have either of you solved the problem of Mailman not preserving > white space in the message body? This kind of thing is death to > messages signed or encrypted with PGP, and I have yet to hear of anyone > who has addressed this issue. As already mentioned, I didn't cover the sign-only case; I tried to implement an encrypted mailinglist, thus the space-signature-killer was no concern :-) >> I didn't figure out at >> first glance how chunking works... otherwise, a mail might be encrypted >> to several recipients - increasing its length by several bytes, but >> reducing the number of forks of gpg processes. > > You definitely need to encrypt the message to all recipients, then > send out one copy. Anything else would be prohibitively expensive in > terms of computation time for any reasonable number of recipients. This will create huge messages in large MLs. Further, this will reveal all recipients' key ids - something not wanted in anonymous lists. Imho the tradeoff lies somewhere inbetween - encrypt messages to n recipients (yet to be implemented). Stefan. From j.e.vanbaal at uvt.nl Wed Mar 2 10:17:36 2005 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Wed Mar 2 10:13:52 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <42256BEC.8050702@informatik.uni-ulm.de> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> Message-ID: <20050302091736.GB26829@banach.uvt.nl> Hi, Stefan: thanks a lot for publishing your patch! Of course, this is _very_ helpful! On Wed, Mar 02, 2005 at 08:31:56AM +0100, Stefan Schlott wrote: > >> I didn't figure out at > >> first glance how chunking works... otherwise, a mail might be encrypted > >> to several recipients - increasing its length by several bytes, but > >> reducing the number of forks of gpg processes. > > > > You definitely need to encrypt the message to all recipients, then > >send out one copy. Anything else would be prohibitively expensive in > >terms of computation time for any reasonable number of recipients. > > This will create huge messages in large MLs. Further, this will reveal > all recipients' key ids - something not wanted in anonymous lists. > Imho the tradeoff lies somewhere inbetween - encrypt messages to n > recipients (yet to be implemented). I guess gpg's --throw-keyid option is useful here. Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050302/7b1c9d8a/attachment.pgp From stefan.schlott at informatik.uni-ulm.de Wed Mar 2 10:28:07 2005 From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott) Date: Wed Mar 2 10:28:13 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <20050302091736.GB26829@banach.uvt.nl> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> <20050302091736.GB26829@banach.uvt.nl> Message-ID: <42258727.1040207@informatik.uni-ulm.de> Hi, > Stefan: thanks a lot for publishing your patch! Of course, this is > _very_ helpful! Great to hear that :-) >>This will create huge messages in large MLs. Further, this will reveal >>all recipients' key ids - something not wanted in anonymous lists. >>Imho the tradeoff lies somewhere inbetween - encrypt messages to n >>recipients (yet to be implemented). > > I guess gpg's --throw-keyid option is useful here. Good point, thanks for the hint. It would be great if your efforts and the development of my patch could stay consistent, i.e. if you make more modifications to my patches, please let me know. Besides of that, any advice concerning inline-pgp is welcome. A fully pgp-enabled mailman would be a great thing. Stefan. From brad at stop.mail-abuse.org Wed Mar 2 12:37:41 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Mar 2 12:39:23 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <42256BEC.8050702@informatik.uni-ulm.de> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> Message-ID: At 8:31 AM +0100 2005-03-02, Stefan Schlott wrote: > This will create huge messages in large MLs. Each additional recipient would be a few extra bytes in the encrypted message. However, since the message is compressed first, unless you've got a list of thousands and thousands of recipients, then odds are that the result would still be smaller in size than a message that was only PGP-signed. > Further, this will reveal > all recipients' key ids - something not wanted in anonymous lists. True. A session key would be encrypted to each key id, so the key ids would be visible. However, subscriber information is not too hard to get from Mailman even when it's supposedly limited to being available only to the admin, so I think there may be bigger fish to fry elsewhere. > Imho the tradeoff lies somewhere inbetween - encrypt messages to n > recipients (yet to be implemented). The problem is that encrypting a message is a very CPU-intensive process, and you don't want to figure off thousands and thousands of message encryption processes for every single submission -- you'd DoS yourself to death. You'd have to make n pretty large in order to be able to make this scalable. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From Nigel.Metheringham at dev.intechnology.co.uk Wed Mar 2 13:01:36 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed Mar 2 13:01:37 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> Message-ID: <1109764896.20072.11.camel@angua.localnet> On Wed, 2005-03-02 at 12:37 +0100, Brad Knowles wrote: > At 8:31 AM +0100 2005-03-02, Stefan Schlott wrote: > > Further, this will reveal > > all recipients' key ids - something not wanted in anonymous lists. > > True. A session key would be encrypted to each key id, so the > key ids would be visible. However, subscriber information is not too > hard to get from Mailman even when it's supposedly limited to being > available only to the admin, so I think there may be bigger fish to > fry elsewhere. > > > Imho the tradeoff lies somewhere inbetween - encrypt messages to n > > recipients (yet to be implemented). > > The problem is that encrypting a message is a very CPU-intensive > process, and you don't want to figure off thousands and thousands of > message encryption processes for every single submission -- you'd DoS > yourself to death. You'd have to make n pretty large in order to be > able to make this scalable. In theory, you could encrypt the message once with a session key, and then distribute it n times, each time adding the packet which has the session key encrypted with the public key of the recipient. This should cost you very little more in encryption CPU requirements than a message encrypted to n recipients in the normal fashion. The rest of the additional required overhead is basically the same as turning personalisation on for a list. Not sure how amenable GPG is to doing this sort of hacking, but it sounds plausible to me (obviously too few coffees this morning). Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From stefan.schlott at informatik.uni-ulm.de Wed Mar 2 13:28:59 2005 From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott) Date: Wed Mar 2 13:29:10 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <1109764896.20072.11.camel@angua.localnet> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> <1109764896.20072.11.camel@angua.localnet> Message-ID: <4225B18B.7050908@informatik.uni-ulm.de> Nigel Metheringham wrote: > In theory, you could encrypt the message once with a session key, and > then distribute it n times, each time adding the packet which has the > session key encrypted with the public key of the recipient. ...which is the very thing making gpg encryption so slow :-) The expensive part is the public key operation, not the symmetric encryption. Stefan. From Nigel.Metheringham at dev.intechnology.co.uk Wed Mar 2 13:36:59 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed Mar 2 13:37:00 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: <4225B18B.7050908@informatik.uni-ulm.de> References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> <1109764896.20072.11.camel@angua.localnet> <4225B18B.7050908@informatik.uni-ulm.de> Message-ID: <1109767019.20072.18.camel@angua.localnet> On Wed, 2005-03-02 at 13:28 +0100, Stefan Schlott wrote: > Nigel Metheringham wrote: > > > In theory, you could encrypt the message once with a session key, and > > then distribute it n times, each time adding the packet which has the > > session key encrypted with the public key of the recipient. > > ...which is the very thing making gpg encryption so slow :-) > The expensive part is the public key operation, not the symmetric > encryption. True. But you need to do n public key operations for n recipients anyway. All I am changing is whether or not you attach them all to one message, or make n copies of the message each with one public key encrypted session key packet. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From stefan.schlott at informatik.uni-ulm.de Wed Mar 2 13:58:29 2005 From: stefan.schlott at informatik.uni-ulm.de (Stefan Schlott) Date: Wed Mar 2 13:58:34 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> Message-ID: <4225B875.6060303@informatik.uni-ulm.de> Brad Knowles wrote: >> Further, this will reveal >> all recipients' key ids - something not wanted in anonymous lists. > > True. A session key would be encrypted to each key id, so the key > ids would be visible. However, subscriber information is not too hard > to get from Mailman even when it's supposedly limited to being available > only to the admin, so I think there may be bigger fish to fry elsewhere. Right. And as it has already been pointed out, --throw-keyid should help. >> Imho the tradeoff lies somewhere inbetween - encrypt messages to n >> recipients (yet to be implemented). > > The problem is that encrypting a message is a very CPU-intensive > process, and you don't want to figure off thousands and thousands of > message encryption processes for every single submission -- you'd DoS > yourself to death. You'd have to make n pretty large in order to be > able to make this scalable. A quick test gave the following (254 bytes text file as input): - ASCII-Armored result, 10 recipients: 4211 bytes - ASCII-Armored result, 20 recipients: 8931 bytes - ASCII-Armored result, 30 recipients: 14700 bytes - ASCII-Armored result, 40 recipients: 19242 bytes Every recipient seems to increase file size by approx. 500 bytes. --throw-keyid didn't change file lenghts. Creating chunks larger than 20 or 30 recipients results in really large mails; repeated calls of gpg result in high load. Not good for large lists indeed... Stefan. From claw at kanga.nu Thu Mar 3 01:25:32 2005 From: claw at kanga.nu (J C Lawrence) Date: Thu Mar 3 01:25:43 2005 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: Message from Brad Knowles of "Wed, 02 Mar 2005 12:37:41 +0100." References: <20050228174022.GT6533@banach.uvt.nl> <4224CA02.2030903@informatik.uni-ulm.de> <42256BEC.8050702@informatik.uni-ulm.de> Message-ID: <3203.1109809532@kanga.nu> On Wed, 2 Mar 2005 12:37:41 +0100 Brad Knowles wrote: > True. A session key would be encrypted to each key id, so the key ids > would be visible. However, subscriber information is not too hard to > get from Mailman even when it's supposedly limited to being available > only to the admin, so I think there may be bigger fish to fry > elsewhere. There's also the difference between using a key for a list subscription which is publicly distributed on key servers, and a special-purpose key that you don't otherwise distribute and use for smaller more privacy critical cases. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From terri at zone12.com Thu Mar 3 19:38:38 2005 From: terri at zone12.com (Terri Oda) Date: Thu Mar 3 19:37:20 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: On Feb 16, 2005, at 8:54 AM, Tobias Eigen wrote: > I'm sorry to say it, but Mailman's web interfaces are extremely > daunting and confusing. As someone who's spent time documenting them... yes! They're useable, and people can learn them, but I know I noticed things that simply don't make sense to a lot of users. We've fixed the ones that came up a lot for me, but I'm sure there's others that I simply don't *see* any more because I'm so used to it. > And we're only talking about the frontend (listinfo interface) here > now, not even the backend (admin interface) for list owners. The > backend is so incredibly complex and overwhelming that it has become a > serious stumbling block for us in offering a service that people will > actually use. Oh yes! I'm partway through documenting our existing admin interface and it's... hard. I love the flexibility offered through mailman, but explaining it to people is horribly difficult, and that's a bad sign for useability. My biggest problem with mailman's interfaces is that they're *really* designed to expose the underlying mechanics. If you know how Mailman works, they're relatively easy to use. I don't usually mind this for the admin interfaces because I work with list admins who actually are motivated to learn some about how the system works. But a lot of list members (and list admins, just not mine) don't know how it works (and shouldn't need to know), and things fall apart then. The biggest one is the seperate-logins-for-all-lists sort of stuff. Many user don't understand (or care) that this reflects our (now seemingly flawed) architecture, and telling them "that's just the way it was designed" is kinda lame when it's clearly not the way it should work. > Has anybody considered having a usability expert look at the Mailman > interfaces and redesign them so they make more sense from a user's > point of view? This *is* a good idea, especially for mailman 3, where I think we'll be redesigning a lot of the interfaces. It's harder with 2.1 because *changing* stuff can cause as many usability problems as it solves, but as I said, we've tweaked a few things since I started documenting, and minor changes can make things a whole lot easier sometimes. So, any usability experts around who are willing to volunteer some time? Okay, I'll admit it: I actually have some formal training in usability, but I'd rather someone with more if there's anyone out there. (hellooo? If you don't want to admit it publicly, at least send me an email so I know who to ask?) The gist of all usability studies is that the USERS are the one who should drive design of the interfaces. Not programmers, not usability experts, not managers of the users, not documenters of the interface. And darned if we don't all have users. :) So no excuses here -- we *can* do at least some simple usability studies. Ask your users what they love/hate about the interface! Ask them what "stupid" mistakes they make -- if lots of people do the same thing, it's probably our fault and not theirs. If you've got physical access to your users, see if you can watch them do certain tasks and note what they do wrong, what takes a long time, etc. Most of us *are* users as well as developers/admins/etc. What do we find to be a pain in the neck? Heck, what do we get asked over and over again? (I used to have people ask me regularly "How do I unsubscribe" until we changed the button "Edit Options" to say "Unsubscribe or Edit Options") What bugs are reported related to the interface? (this includes bugs that aren't really bugs, but rather that the user couldn't find the right way to do things) What behaves in ways that users don't expect? What feature requests are made? So, gathering usability data isn't impossible. It's not going to be the best data ever, because there are much more scientific ways to go about this, but it *is* valid data and can be useful to us. I think going through and gathering this data would be *really* helpful and could lead to a much better interface. What would be the best way to gather this information? Should we set up some pages in the wiki and make sure they're well known to users as a place to report this sort of thing? The only problem with wikis is that people will see that something's been reported and not bother to duplicate, whereas we will want to know how *many* people are bothered by things. Perhaps something with some quick voting-style "this bugs me too" option? How can we make it easy for people to report usability concerns? Any thoughts on how to do this? I'm willing to do a bit of coordination here to make sure this happens if people think we'll actually be able to use the information to make things better. Terri From brad at stop.mail-abuse.org Thu Mar 3 20:32:58 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Mar 3 20:33:33 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: At 1:38 PM -0500 2005-03-03, Terri Oda wrote: > The biggest one is the seperate-logins-for-all-lists sort of stuff. > Many user don't understand (or care) that this reflects our (now > seemingly flawed) architecture, and telling them "that's just the way it > was designed" is kinda lame when it's clearly not the way it should work. That's being addressed in mm3. I'm not sure we can fix this problem before then. > I think going through and gathering this data would be *really* helpful > and could lead to a much better interface. What would be the best way > to gather this information? Should we set up some pages in the wiki and > make sure they're well known to users as a place to report this sort of > thing? I think a wiki would be a bad idea. Wikis are complex enough for those of us who are Internet-savvy. Something like bugzilla (or other bug/issue-tracking system) would also be too complex. If you're going to collect data from end-users, you've got to make it simple enough that your two-year old can do it. Scratch that -- an AOL user has to be able to do it, and that's far worse. > Perhaps something with some quick voting-style "this bugs me too" option? That's much more likely to be able to collect useful information. > How can we make it easy for people to report usability concerns? I fear that the problem is that you need a system with very high usability in order to collect the usability information, but this is a vicious circle. Myself, I think I'd be inclined to look towards Internet voting sites as the model to follow. I can't think of any off the top of my head, but I recall having used some in the past which seemed pretty simple -- nothing but radio buttons and the odd multiple-choice selection. Whatever is done, I think the underlying concept has to be KISS, and to stick with that. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From j.e.vanbaal at uvt.nl Fri Mar 4 10:57:50 2005 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Fri Mar 4 10:53:55 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: <20050304095750.GU26829@banach.uvt.nl> On Thu, Mar 03, 2005 at 01:38:38PM -0500, Terri Oda wrote: > On Feb 16, 2005, at 8:54 AM, Tobias Eigen wrote: > >I'm sorry to say it, but Mailman's web interfaces are extremely > >daunting and confusing. > >And we're only talking about the frontend (listinfo interface) here > >now, not even the backend (admin interface) for list owners. The > >backend is so incredibly complex and overwhelming that it has become a > >serious stumbling block for us in offering a service that people will > >actually use. Same here. I am considering writing a wrapper in front of the admin pages, with _lots_ of buttons removed. (Don't hold your breath for that, though.) Perhaps a newbie/expert toggle on the interface would be helpful. Lots of listadmins at the site here are overwhelmed by the sheer _amount_ of buttons. Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050304/bc5be91b/attachment.pgp From fil at rezo.net Fri Mar 4 11:50:16 2005 From: fil at rezo.net (Fil) Date: Fri Mar 4 11:50:37 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <20050304095750.GU26829@banach.uvt.nl> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> Message-ID: <20050304105013.GA30696@rezo.net> > Same here. I am considering writing a wrapper in front of the admin > pages, with _lots_ of buttons removed. (Don't hold your breath for > that, though.) Perhaps a newbie/expert toggle on the interface would be > helpful. Lots of listadmins at the site here are overwhelmed by the > sheer _amount_ of buttons. Most people don't care about options. On my site I have tried to streamline the registration process: there is a popup window where you can type in your email, and sub/unsub (whether you are or not already subscribed). See for instance http://listes.rezo.net/popup/ (click on the first link). But the second most important place for usability is the welcome message, which is loaded with options and jargon. I have replaced it with (in French): <<<<<<<<<<<<<<<< ---------------------------------------------------------- %(welcome)s Votre adresse est inscrite sur la liste %(real_name)s@%(host_name)s Merci. ---------------------------------------------------------- Pour vous d?sabonner, une page vous est r?serv?e %(optionsurl)s %(umbrella)s Ce mot de passe emp?chera quiconque de vous d?sabonner contre votre gr? : %(password)s. Autres informations sur la liste %(real_name)s : %(listinfo_url)s >>>>>>>>>>>> But I still find it too complex; we should get rid of the password thing. People just nedd to know where they can see more options. As for the web interface, from what I've seen I think GoogleGroups has got the slickest interface for the moment. -- Fil From tobias at kabissa.org Fri Mar 4 14:54:21 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Fri Mar 4 14:53:45 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <20050304105013.GA30696@rezo.net> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> Message-ID: Hi all, I'm glad to see this thread continuing. I agree completely with Terri, Fil and Joost. I'm really impressed with Googlegroups.. I used it recently and it works well from a usability standpoint. I think Joost has hit the nail on the head about how Mailman works well if you want to understand exactly what it is doing and how it works - most people (as shown by Yahoogroups) don't need this anymore and can expect to be shielded from it. Likewise the passwords in the welcome message. It sounds like through changes to the email interfaces/templates, new wrappers (liked that idea very much) and a toggle for expert/newbie interfaces, as well as integration with forums for discussion lists, we *can* make Mailman more usable by ordinary people. BTW, for those (like Kabissa) considering non-open source options, I see that Jive Forums has an "email gateway" that can handle Mailman integration and MBOX importing. http://www.jivesoftware.com - they have a nonprofit license option that is in the realm of the affordable. Something for the FAQ? So yes, Terri, count me in! I have a ready group of Kabissa members and list owners who would be willing to help out with usability testing. We also do training regularly and have training partners in Africa, so could possibly take advantage of that to do usability testing with them. Waiting for MM3 might be too long for me - I am in the process of overhauling Kabissa's interfaces and integrating them, and need to be making more rapid progress on making Mailman work for me or replacing it with something easier. Cheers, Tobias On Mar 4, 2005, at 5:50 AM, Fil wrote: >> Same here. I am considering writing a wrapper in front of the admin >> pages, with _lots_ of buttons removed. (Don't hold your breath for >> that, though.) Perhaps a newbie/expert toggle on the interface would >> be >> helpful. Lots of listadmins at the site here are overwhelmed by the >> sheer _amount_ of buttons. > > Most people don't care about options. On my site I have tried to > streamline > the registration process: there is a popup window where you can type > in your > email, and sub/unsub (whether you are or not already subscribed). > > See for instance http://listes.rezo.net/popup/ (click on the first > link). > > But the second most important place for usability is the welcome > message, > which is loaded with options and jargon. I have replaced it with (in > French): > > <<<<<<<<<<<<<<<< > > ---------------------------------------------------------- > > %(welcome)s > Votre adresse est inscrite sur la liste %(real_name)s@%(host_name)s > > Merci. > > ---------------------------------------------------------- > > Pour vous d?sabonner, une page vous est r?serv?e > %(optionsurl)s > %(umbrella)s > Ce mot de passe emp?chera quiconque de vous > d?sabonner contre votre gr? : %(password)s. > > Autres informations sur la liste %(real_name)s : > %(listinfo_url)s > >>>>>>>>>>>>> > > But I still find it too complex; we should get rid of the password > thing. > People just nedd to know where they can see more options. > > As for the web interface, from what I've seen I think GoogleGroups has > got > the slickest interface for the moment. > > -- Fil > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: > http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/ > tobias%40kabissa.org > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show& > file=faq01.027.htp > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From Dale at Newfield.org Fri Mar 4 15:36:23 2005 From: Dale at Newfield.org (Dale Newfield) Date: Fri Mar 4 15:36:23 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> Message-ID: <42287267.9020402@Newfield.org> Tobias Eigen wrote: > I'm really impressed with Googlegroups. There are important tradeoffs to consider. My only interaction with google groups is that I now receive about 150 pieces of spam from them every day. I am unable to stem this, and google won't help me to do so. As a result I have added a .procmail filter to junk every message that comes from google groups. I would argue that this makes google groups completely un-usable. I hope that mailman doesn't become so simple to use that it becomes more of a spam tool than it already is. -Dale From brad at stop.mail-abuse.org Fri Mar 4 15:57:41 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Mar 4 15:58:03 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> Message-ID: At 8:54 AM -0500 2005-03-04, Tobias Eigen wrote: > BTW, for those (like Kabissa) considering non-open source options, I see > that Jive Forums has an "email gateway" that can handle Mailman > integration and MBOX importing. http://www.jivesoftware.com - they have > a nonprofit license option that is in the realm of the affordable. > Something for the FAQ? Done. FAQ 1.26 is updated. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fehwalker at gmail.com Fri Mar 4 18:11:55 2005 From: fehwalker at gmail.com (Bryan Fullerton) Date: Fri Mar 4 18:11:58 2005 Subject: [Mailman-Developers] Mailman 2.1.6b4 In-Reply-To: <1108665979.10068.29.camel@geddy.wooz.org> References: <1108665979.10068.29.camel@geddy.wooz.org> Message-ID: <35de0c3005030409115a8d3935@mail.gmail.com> Is there an updated timeline for the final 2.1.6 release? It won't be in February... :) Thanks, Bryan On Thu, 17 Feb 2005 13:46:19 -0500, Barry Warsaw wrote: > Okay, I've pushed the 2.1.6b4 tarball out to SourceForge (now that file > uploads are working again ;). I will likely be off-line until Tuesday. > > -Barry From Nigel.Metheringham at dev.intechnology.co.uk Fri Mar 4 18:37:59 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Fri Mar 4 18:38:01 2005 Subject: [Mailman-Developers] Mailman 2.1.6b4 In-Reply-To: <35de0c3005030409115a8d3935@mail.gmail.com> References: <1108665979.10068.29.camel@geddy.wooz.org> <35de0c3005030409115a8d3935@mail.gmail.com> Message-ID: <1109957879.16133.7.camel@angua.localnet> On Fri, 2005-03-04 at 12:11 -0500, Bryan Fullerton wrote: > Is there an updated timeline for the final 2.1.6 release? It won't be > in February... :) Is there a booking form for Guido's time machine? Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From r_correia at telkomsa.net Fri Mar 4 18:49:21 2005 From: r_correia at telkomsa.net (Rui Correia) Date: Fri Mar 4 18:49:38 2005 Subject: [Mailman-Developers] Suggestion on Spam Message-ID: <004501c520e2$8278cde0$0500000a@Laptop> Hi All Would it be feasible to create a feature that would automate a search for a pre-agreed phrase set by list owner typed on each individual email posted to a list? An email would then begin with the pre-agreed phrase, eg: "We all love red wine", which Mailman would have been programmed to recognise. A "reply to" post would be exempt from such. Anyone initiating a new string and forgetting to include the key-phrase would receive an auto-response notification to resend including key-phrase. This would in most cases replace the "your posting is being held for approval", as most lists have open posting for their members. It would be a matter of days before everybody got used to including the key-phrase in their postings - to make life easier, members can even include it in their signature. Rui ________________________________________________ ? ? Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214 From terri at zone12.com Fri Mar 4 21:43:01 2005 From: terri at zone12.com (Terri Oda) Date: Fri Mar 4 21:41:42 2005 Subject: [Mailman-Developers] Suggestion on Spam In-Reply-To: <004501c520e2$8278cde0$0500000a@Laptop> References: <004501c520e2$8278cde0$0500000a@Laptop> Message-ID: <7fea0eeda0fdebc43367fd3e7c58eb83@zone12.com> On Mar 4, 2005, at 12:49 PM, Rui Correia wrote: > Would it be feasible to create a feature that would automate a search > for a > pre-agreed phrase set by list owner typed on each individual email > posted to > a list? How does the email authentication thing work right now? I may be mis-remembering, but I think you can stick a header in to make your messages automatically authorized. If this sort of thing is already built in, extending it to search more than the one header shouldn't be impossible. But it's entirely possible that this functionality doesn't exist. I'm really fuzzy on how the email admin interface works, and I may be thinking of another system I used. Terri From terri at zone12.com Fri Mar 4 21:50:19 2005 From: terri at zone12.com (Terri Oda) Date: Fri Mar 4 21:48:58 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <42287267.9020402@Newfield.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> <42287267.9020402@Newfield.org> Message-ID: <1d94296e70dc85eeceb778211fa841fc@zone12.com> On Mar 4, 2005, at 9:36 AM, Dale Newfield wrote: > There are important tradeoffs to consider. My only interaction with > google groups is that I now receive about 150 pieces of spam from them > every day. I am unable to stem this, and google won't help me to do > so. As a result I have added a .procmail filter to junk every message > that comes from google groups. I would argue that this makes google > groups completely un-usable. I hope that mailman doesn't become so > simple to use that it becomes more of a spam tool than it already is. I'm confused... do you feel it's the interface and ease of use of that interface that makes google groups more of a source of spam, or is this just a general comment about the disadvantages of their system? I'm just trying to see if you're trying to indicate something we should avoid if we start looking to them for inspiration on improving usability, or if you're just commenting on the other problems of the system (like suddenly making piles of email addresses available on the web when they'd been much safer from spammers while sitting on usenet. I know google groups has increased the amount of spam I receive, but it's unrelated to their interface...) Terri From terri at zone12.com Fri Mar 4 21:56:01 2005 From: terri at zone12.com (Terri Oda) Date: Fri Mar 4 21:54:42 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> Message-ID: <4dcfb42e01481522af118e0bf3059916@zone12.com> On Mar 4, 2005, at 8:54 AM, Tobias Eigen wrote: > Waiting for MM3 might be too long for me - I am in the process of > overhauling Kabissa's interfaces and integrating them, and need to be > making more rapid progress on making Mailman work for me or replacing > it with something easier. Fixing some of the interface issues is probably easier in 3 (a lot of the way in which we handle list member preferences, especially) but I wouldn't be adverse to making changes in the 2.1 series if doing so looks feasible and we aren't going to cause heart attacks in users. I'm trying to avoid doing *anything* code-wise until 2.1.6 is out, but I'd be willing to look at it after that. Terri From terri at zone12.com Fri Mar 4 22:09:28 2005 From: terri at zone12.com (Terri Oda) Date: Fri Mar 4 22:08:10 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <20050304105013.GA30696@rezo.net> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> Message-ID: <4a103c769f2ed2315483c534aa32fb6a@zone12.com> On Mar 4, 2005, at 5:50 AM, Fil wrote: > But I still find it too complex; we should get rid of the password > thing. > People just nedd to know where they can see more options. I've been thinking a bunch about this since it was mentioned as a security problem a while back, and the more I think about it, the more I like the idea of not having passwords for regular users. (Or having it possible for admins to disable passwords for regular users.) I was thinking that it'd be best replaced with timed email-authorization things, the way you can currently unsubscribe without a password. I don't know how long the timeout on those things are, but having it send you an email with a link to the archives or your options seems feasible. Having the links only be valid for a given time (say, an hour?) would reduce the threat of dictionary attacks *and* mean that more users can figure out how to do things on their own. ;) Terri From Dale at Newfield.org Fri Mar 4 23:05:33 2005 From: Dale at Newfield.org (Dale Newfield) Date: Fri Mar 4 23:06:48 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <1d94296e70dc85eeceb778211fa841fc@zone12.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> <42287267.9020402@Newfield.org> <1d94296e70dc85eeceb778211fa841fc@zone12.com> Message-ID: <517-SnapperMsg420417FABE4E8C75@[68.244.127.186]> On Fri, 4 Mar 2005 15:50:19 -0500 "Terri Oda" wrote: >I'm confused... do you feel it's the interface and ease of use of that >interface that makes google groups more of a source of spam, or is this >just a general comment about the disadvantages of their system? > >I'm just trying to see if you're trying to indicate something we should >avoid if we start looking to them for inspiration on improving >usability, or if you're just commenting on the other problems of the >system I don't actually know. I know that someone created many google groups accounts with bogus personal info that wind up in my mailbox. I know that I cannot reset the password without knowing that bogus personal info, and they have no "email me a new password" feature. As a result I cannot unsubscribe or prevent those accounts from being subscribed to various additional groups. At least the "give me control over my account" parts of their UI blow. I don't believe I've seen any other parts as I cannot login. Certainly the ability to quickly subscribe to many mailing lists without having ever proved you receive mail sent to the email address in question is of dubious value. -Dale@Newfield.org Dale Newfield From jwblist at olympus.net Fri Mar 4 23:26:51 2005 From: jwblist at olympus.net (John W. Baxter) Date: Fri Mar 4 23:27:10 2005 Subject: [Mailman-Developers] Mailman 2.1.6b4 In-Reply-To: <1109957879.16133.7.camel@angua.localnet> Message-ID: On 3/4/2005 9:37, "Nigel Metheringham" wrote: > On Fri, 2005-03-04 at 12:11 -0500, Bryan Fullerton wrote: >> Is there an updated timeline for the final 2.1.6 release? It won't be >> in February... :) > > Is there a booking form for Guido's time machine? Of course it will be in February. Perhaps February 35th, perhaps 48th... --John (this comes from growing up in California, where the legislature had a ritual of the presiding person ordering the Sergeant at Arms to stop the clock a few minutes before midnight on budget deadline night. Then it entailed climbing a ladder to stop the clock) From brad at stop.mail-abuse.org Sat Mar 5 02:04:17 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Mar 5 02:12:43 2005 Subject: [Mailman-Developers] Suggestion on Spam In-Reply-To: <7fea0eeda0fdebc43367fd3e7c58eb83@zone12.com> References: <004501c520e2$8278cde0$0500000a@Laptop> <7fea0eeda0fdebc43367fd3e7c58eb83@zone12.com> Message-ID: At 3:43 PM -0500 2005-03-04, Terri Oda quoted Rui Correia: >> Would it be feasible to create a feature that would automate a search for a >> pre-agreed phrase set by list owner typed on each individual email posted to >> a list? > > How does the email authentication thing work right now? I may be > mis-remembering, but I think you can stick a header in to make your > messages automatically authorized. If this sort of thing is already > built in, extending it to search more than the one header shouldn't > be impossible. You can put on an "Approved:" header. They're trivially easy to fake. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Sat Mar 5 02:06:18 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Mar 5 02:12:45 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <4dcfb42e01481522af118e0bf3059916@zone12.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> <4dcfb42e01481522af118e0bf3059916@zone12.com> Message-ID: At 3:56 PM -0500 2005-03-04, Terri Oda wrote: > Fixing some of the interface issues is probably easier in 3 (a lot of the > way in which we handle list member preferences, especially) but I wouldn't > be adverse to making changes in the 2.1 series if doing so looks feasible > and we aren't going to cause heart attacks in users. The problem is that to really fix a lot of things, you're going to need architectural changes within the system. By the time you've done that, you've done more work than to finish off all the work for mm3. I think we have to prioritize things and decide what can feasibly be looked at to fix in the 2.x tree, and what's going to have to wait for mm3. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From clif at eugeneweb.com Sat Mar 5 04:55:12 2005 From: clif at eugeneweb.com (clif) Date: Sat Mar 5 04:55:15 2005 Subject: [Mailman-Developers] Postfix.py extension for virtual_domain management Message-ID: Hi Mike, I've also wished mailman handled Virtual lists better. PostfixVirtual.py Works great, and I also tried removeing the name change restriction in General.py: vi /usr/lib/mailman/Mailman/Gui/General.py /real_name # Lets try this just for fun... if property == 'real_name_NOT' and \ I did some quick testing and found most of the obvious references to com.foo.test became test without any problems. Though the URLs and some other text still refers to it by the "correct" name. Anyway you mentioned in your post that you had customized mailman in other ways. Do you feel like publishing them as well? Thanks, Clif From terri at zone12.com Sat Mar 5 07:45:19 2005 From: terri at zone12.com (Terri Oda) Date: Sat Mar 5 07:43:58 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <20050304095750.GU26829@banach.uvt.nl> <20050304105013.GA30696@rezo.net> <4dcfb42e01481522af118e0bf3059916@zone12.com> Message-ID: <26555faca0930f5c0734257026206980@zone12.com> On Mar 4, 2005, at 8:06 PM, Brad Knowles wrote: > I think we have to prioritize things and decide what can feasibly be > looked at to fix in the 2.x tree, and what's going to have to wait for > mm3. ... and all of this is a moot point until we see what people actually want in the way of improved interfaces! Brad has hit the nail on the head, though -- mm3 is more attractive and reasonable than 2.x because a full redesign of the interface might as well be done concurrently with the rest. I just have this gut feeling that if we start asking questions, we'll find some fairly simple changes that can be done to improve 2.x usability too. Terri From msapiro at value.net Sat Mar 5 23:16:11 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Mar 5 23:16:32 2005 Subject: [Mailman-Developers] Mailman Usability In-Reply-To: <4a103c769f2ed2315483c534aa32fb6a@zone12.com> Message-ID: Terri Oda wrote: > >I was thinking that it'd be best replaced with timed >email-authorization things, the way you can currently unsubscribe >without a password. I don't know how long the timeout on those things >are, but having it send you an email with a link to the archives or >your options seems feasible. Having the links only be valid for a >given time (say, an hour?) would reduce the threat of dictionary >attacks *and* mean that more users can figure out how to do things on >their own. ;) I don't see how any kind of "on demand" e-mail authorization for private archives could work well. People want to be able to visit the archives at times/from places where they may not have access to e-mail sent to their subscribed address. Also people want to be able to post links to messages in private archives and the readers of such posts should be able to follow those links with a minimum of extra burden. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From sub1.dev.mailman at msquared.id.au Sun Mar 6 02:09:59 2005 From: sub1.dev.mailman at msquared.id.au (Msquared) Date: Sun Mar 6 02:10:06 2005 Subject: [Mailman-Developers] Suggestion on Spam In-Reply-To: References: <004501c520e2$8278cde0$0500000a@Laptop> <7fea0eeda0fdebc43367fd3e7c58eb83@zone12.com> Message-ID: <20050306010959.GW24152@sliderule.msquared.com.au> On Sat, Mar 05, 2005 at 02:04:17AM +0100, Brad Knowles wrote: > You can put on an "Approved:" header. They're trivially easy to fake. Does it require a password? Surely that's harder to fake. :o) Regards, Msquared... From mgabriel at ecology.uni-kiel.de Sun Mar 6 11:58:40 2005 From: mgabriel at ecology.uni-kiel.de (Mike Gabriel) Date: Sun Mar 6 11:58:57 2005 Subject: [Mailman-Developers] Postfix.py extension for virtual_domain management In-Reply-To: References: Message-ID: <200503061158.40975.mgabriel@ecology.uni-kiel.de> hi clif, [clif's posting is refereing to http://mail.python.org/pipermail/mailman-developers/2005-January/017673.html ] > I've also wished mailman handled Virtual lists better. > PostfixVirtual.py Works great, and I also tried removeing the that is indeed good to hear. however, i do not like the idea of customized bits of extra-code here and there, as new versions of mailman might handle things differently in the future. this would mean that admins on mailman-customized sites had to adapt the scripts whenever a major change has occured in the mailman source code tree. and mostly you only realize the major change in code by some sort of list failure. this is not acceptable on productive sites. what i would like to fancy, is that the PostfixVirtual.py code would be perceived by the Postfix-coders on this list... and PostfixVirtual.py is just a suggestion how virtual lists could be handled... > name change restriction in General.py: > > vi /usr/lib/mailman/Mailman/Gui/General.py > /real_name > # Lets try this just for fun... > if property == 'real_name_NOT' and \ > I did some quick testing and found most of the obvious references to > com.foo.test became test without any problems. Though the URLs and some > other text still refers to it by the "correct" name. i do not think that a very good idea, unless you make sure, that all locations, the listname is used at also gets updated (filenames, directories, archives, URLs for the WWW-interface, etc.). furthermore, if renaming was posssible, there should also be a garantuee, that there is no other list on the site, bearing the same name as the one the list is to be renamed to. i do think that there is a proper reason, why list renaming is (so far) prohibited. however, list renaming would be a very fine feature!!! > Anyway you mentioned in your post that you had customized mailman in other > ways. Do you feel like publishing them as well? i have studied my former posting very thoroughly, but cannot guess what you are pointing at... have a good time, mike -- network administration, ecology centre, kiel university, germany Mike Gabriel, olshausenstr 75, 24118 kiel, germany fon-work: +49 431 880-1186 fon-home: +49 431 6474196 mail: mgabriel@ecology.uni-kiel.de www: http://www.ecology.uni-kiel.de, http://zope.ecology.uni-kiel.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050306/d2ae9115/attachment.pgp From mgabriel at ecology.uni-kiel.de Sun Mar 6 12:03:28 2005 From: mgabriel at ecology.uni-kiel.de (Mike Gabriel) Date: Sun Mar 6 12:03:48 2005 Subject: [Mailman-Developers] changes in host_name field does does not update postfix's aliases files In-Reply-To: References: Message-ID: <200503061203.29224.mgabriel@ecology.uni-kiel.de> hi there, with mailman 2.1.5 a change in the host_name field (changing the default virtual domain to the one the list should be addressable under) does not appear in the postfix'aliases files. for now i have set up a CRON job, that runs bin/genaliases every hour, to make sure, host_name changes in the webfrontend appear (belatedly) in the aliases files... is this behaviour intentional??? salut, mike -- network administration, ecology centre, kiel university, germany Mike Gabriel, olshausenstr 75, 24118 kiel, germany fon-work: +49 431 880-1186 fon-home: +49 431 6474196 mail: mgabriel@ecology.uni-kiel.de www: http://www.ecology.uni-kiel.de, http://zope.ecology.uni-kiel.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050306/21247857/attachment.pgp From clif at eugeneweb.com Sun Mar 6 18:59:21 2005 From: clif at eugeneweb.com (clif) Date: Sun Mar 6 18:59:24 2005 Subject: [Mailman-Developers] Postfix.py extension for virtual_domain management In-Reply-To: <200503061158.40975.mgabriel@ecology.uni-kiel.de> Message-ID: Hi Mike, I was refering to what you said here: "...it in my very own special mailman setup." Maybe I missunderstood but it sounded like "special" here implied non-typical customizations. No? Yes good points, I think thats why we're here, to talk about the possibility of better virtual list support in mailman, hopefully to avoid the pitfalls you mention. Have fun, Clif On Sun, 6 Mar 2005, Mike Gabriel wrote: > hi clif, > > [clif's posting is refereing to > > http://mail.python.org/pipermail/mailman-developers/2005-January/017673.html > > ] > > > I've also wished mailman handled Virtual lists better. > > PostfixVirtual.py Works great, and I also tried removeing the > > that is indeed good to hear. however, i do not like the idea of customized > bits of extra-code here and there, as new versions of mailman might handle > things differently in the future. this would mean that admins on > mailman-customized sites had to adapt the scripts whenever a major change has > occured in the mailman source code tree. and mostly you only realize the > major change in code by some sort of list failure. this is not acceptable on > productive sites. what i would like to fancy, is that the PostfixVirtual.py > code would be perceived by the Postfix-coders on this list... and > PostfixVirtual.py is just a suggestion how virtual lists could be handled... > > > name change restriction in General.py: > > > > vi /usr/lib/mailman/Mailman/Gui/General.py > > /real_name > > # Lets try this just for fun... > > if property == 'real_name_NOT' and \ > > I did some quick testing and found most of the obvious references to > > com.foo.test became test without any problems. Though the URLs and some > > other text still refers to it by the "correct" name. > > i do not think that a very good idea, unless you make sure, that all > locations, the listname is used at also gets updated (filenames, directories, > archives, URLs for the WWW-interface, etc.). furthermore, if renaming was > posssible, there should also be a garantuee, that there is no other list on > the site, bearing the same name as the one the list is to be renamed to. > > i do think that there is a proper reason, why list renaming is (so far) > prohibited. > > however, list renaming would be a very fine feature!!! > > > Anyway you mentioned in your post that you had customized mailman in other > > ways. Do you feel like publishing them as well? > > i have studied my former posting very thoroughly, but cannot guess what you > are pointing at... > > have a good time, > mike > > -- > network administration, ecology centre, kiel university, germany > Mike Gabriel, olshausenstr 75, 24118 kiel, germany > > fon-work: +49 431 880-1186 > fon-home: +49 431 6474196 > mail: mgabriel@ecology.uni-kiel.de > www: http://www.ecology.uni-kiel.de, http://zope.ecology.uni-kiel.de > From tobias at kabissa.org Mon Mar 7 12:31:54 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Mon Mar 7 12:30:48 2005 Subject: [Mailman-Developers] Fwd: Design for Civil Society / Technology and Social Action Message-ID: Hi all, The link below might be of interest in the context of usability discussions we've been having. Best wishes, Tobias Begin forwarded message: > From: Maja van der Velden > Date: March 4, 2005 10:11:01 AM EST > To: Maja van der Velden > Cc: Subject: Design for Civil Society / Technology and Social > Action > > FYI, some work I am participating in: > > A special issue of Interacting with Computers - Volume 17, Issue 1, > Pages 1-120 (January 2005) - on Design for Civil Society, edited by > Steve Walker and Andy Dearden, is available full text online as a > complementary issue. Yu can read the articles online, download them or > send them in pdf format. > > A follow-up on this is a project called Technology and Social Action > (see http://www.technologyandsocialaction.org ): "a project to foster > dialogue and collaboration between activists in social movements, > voluntary and community organisations and technology designers. We are > committed to supporting communities of practice exploring effective > ways of using technology to support social action, and of ensuring > that technological innovation responds to social priorities. > > Greetings, Maja > > The (very unhandy) link to the Design for Civil Society issue is: > http://www.sciencedirect.com/science? > _ob=IssueURL&_tockey=%23TOC%235644%232005%23999829998%23549345%23FLA%23 > Volume_17,_Issue_1,_Pages_1 > -120_(January_2005)%2BMDesign_for_Civil_Society%2BMEdited_by_S._Walker_ > and_A._Dearden&_auth=y&view=c&_acct=C000050221&_version=1&_urlVersion=0 > &_userid=10&md5=59c069dfff5e2e729975cf03dfead78b > > It has the following articles: > > 1. Inside Front Cover > Page CO2 > > 2. Designing for civil society? ? EDITORIAL > Pages 1-8 > Steve Walker and Andy Dearden > > 3. Participating in civil society: the case of networked communities? > ? ARTICLE > Pages 9-33 > Andrea Kavanaugh, John M. Carroll, Mary Beth Rosson, Debbie D. Reese > and Than T. Zin > > 4. Net neighbours: adapting HCI methods to cross the digital divide? ? > ARTICLE > Pages 35-56 > Mark Blythe and Andrew Monk > > 5. Fairtrade.com versus Fairtrade.org?how Fairtrade organisations use > the Internet? ? ARTICLE > Pages 57-83 > Dorothea Kleine > > 6. Online design for bilingual civil society: a Welsh perspective? ? > ARTICLE > Pages 85-104 > Daniel Cunliffe and Dilwyn Roberts-Young > > 7. Programming for cognitive justice: Towards an ethical framework for > democratic code? ? ARTICLE > Pages 105-120 > Maja van der Velden > > > Maja van der Velden > Oslo, Norway > http://www.globalagenda.org > http://blogger.xs4all.nl/ > maja_______________________________________________ > incom-l mailing list > incom-l@incommunicado.info > http://mail.kein.org/mailman/listinfo/incom-l > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From carbonnb at sympatico.ca Thu Mar 10 03:50:58 2005 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Thu Mar 10 03:51:03 2005 Subject: [Mailman-Developers] XHTML Compliant Web UI 2.1.6b4 Patch Message-ID: <422F6FC2.27187.B0E8AD@localhost> I have just uploaded a patch that will make the web UI for MM 2.1.6b4 XHTML 1 strict compliant. Well, the start of a patch. Currently only the listinfo pages are xhtml 1 compliant and some minor CSS formating ability. As time goes by, I'm going to update the patch to include more of the UI pages. Since this is my first atempt at something like this I thought I'd post it incrementally in case anyone finds something terrible wrong with what I'm doing :) It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it. -- Bryan Carbonnell - carbonnb@sympatico.ca "When they put 'unknown' at the end of a quote, that means they probably don't know how to spell 'anonymous'." ~Author Unknown From msapiro at value.net Fri Mar 11 18:05:02 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri Mar 11 18:05:15 2005 Subject: [Mailman-Developers] Appropriate text for private archive login Message-ID: Much of the template templates/en/private.html is based on (copied from) the template templates/en/admlogin.html. Thus, the language about cookies is not appropriate for this function. I have submitted a patch with suggested changes to the english template at https://sourceforge.net/tracker/index.php?func=detail&aid=1161505&group_id=103&atid=300103 -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From jpr at uab.edu Fri Mar 11 21:42:55 2005 From: jpr at uab.edu (John-Paul Robinson) Date: Fri Mar 11 21:43:01 2005 Subject: [Mailman-Developers] middleware requirements contribution Message-ID: Hello Mailman Developers, Some of you may be aware of an Internet2 sponsored and NSF funded effort to improve the integration of popular open source mailing list software with emerging middleware technologies for identity management and authorization. http://middleware.internet2.edu/mlist The mlist working group of Internet2 has been gathering information related to mailing list software needs of higher education and working on integration scenarios for mailing list software related to these needs. As part of this effort, we have put together much of the knowledge we have gathered over the past year into a how-to guide for mailing list developers. http://webapp.lab.ac.uab.edu/wiki/mlist/index.php/HomePage Our initial version of this guide has been put together over the past few weeks in the hopes that it is useful to the Mailman developers in light of the upcoming Mailman developer sprint at PyCon2005. We hope that it will contribute positively to the development requirements of the next major release of Mailman. As I mentioned, this is our initial version of the document. We have put it online as a wiki in order to solicit feedback on the utility of the information and to allow people to easily contribute to this discussion. Please let us know if you find this information useful or if there are areas you feel should be improved. Our goal is to provide requirements guidance to mailing list system developers to help promote the changing needs of the higher education community. We feel that these same requirements represent the future needs of many organizations that use Mailman and that by addressing the general requirements Mailman will continue to be a popular and adaptable part of future mailing list systems. Thanks for your time and let me know if you have any questions or requests. Thanks, ~jpr From barry at python.org Mon Mar 14 20:44:04 2005 From: barry at python.org (Barry Warsaw) Date: Mon Mar 14 20:44:08 2005 Subject: [Mailman-Developers] Can you donate a public subversion repository for Pycon sprints? Message-ID: <1110829380.15320.82.camel@geddy.wooz.org> I'm wondering if anybody out there can donate a Subversion repository for use at the upcoming Pycon sprint next week (actually, starting Saturday). I had a machine that I was going to use for this, but it lost its disk over the weekend, and it doesn't look like I'm going to be able to get it back online in time. :( Ideally, someone who will be coming to the sprint would be able to donate a repository, since we'll need to set up access control once we're there and we know who's going to be participating. It will be tough to coordinate this if you're not at the sprint, but if you're willing to be accessible via IM or IRC, we might be able to work around that. I'd like for us to have a separate repository, not tainted by other projects or code. Access can be by http or ssh+svn, whichever you prefer (although the latter requires us to coordinate pubkeys, so that's less desirable). I would send you a dump file of my private repository, and then you'd send me a dump file when the sprints are all done. This will not be the permanent subversion repository for Mailman3. For the long term, we'll either host at SourceForge when they make Subversion available, or I'll host it at my site after I get my machine back online. We just need something we can use for the week of Pycon. If you think you can help out, please respond to me directly. Thanks! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050314/09b1e176/attachment.pgp From barry at python.org Mon Mar 14 23:23:13 2005 From: barry at python.org (Barry Warsaw) Date: Mon Mar 14 23:23:16 2005 Subject: [Mailman-Developers] Re: Can you donate a public subversion repository for Pycon sprints? In-Reply-To: <1110829380.15320.82.camel@geddy.wooz.org> References: <1110829380.15320.82.camel@geddy.wooz.org> Message-ID: <1110838993.16647.12.camel@geddy.wooz.org> On Mon, 2005-03-14 at 14:44, Barry Warsaw wrote: > I'm wondering if anybody out there can donate a Subversion repository > for use at the upcoming Pycon sprint next week (actually, starting > Saturday). We have a winner! John Viega reminds me that we can use list.org! Whodah thunk? :) The machine recently got rebuilt with plenty of disk space and already has svn on it, so we just need to set up the access infrastructure. I should be able to have the repo up before Saturday, and I will send (read-only) instructions when it's available. We'll work out write perms at the sprint. Thanks everyone who offered to help. I hope to see you all at Pycon, if not the sprints. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050314/7b2cfd3b/attachment.pgp From jelly+mailman-dev at mail.iskon.hr Tue Mar 15 21:45:07 2005 From: jelly+mailman-dev at mail.iskon.hr (Zoran Dzelajlija) Date: Tue Mar 15 21:48:56 2005 Subject: [Mailman-Developers] bug in ListAdmin._UpdateRecords in 2.1.5 - 2.1.6b4? Message-ID: <20050315204507.7E6C.0.NOFFLE@islands.iskon.hr> Hello. I have been trying to migrate from 2.0.13 to 2.1.5 a few lists at a time, and run 2.0 and 2.1 in parallel. We have a lot of pending requests around, and we would not like to lose them. Luckily, it looks like almost everything is handled in bin/update, although some things require special attention, like pending_subscriptions.db (haven't tried yet, but it looks like it should be enough to copy it over to the Mailman 2.1 installation each time a list is migrated, and run bin/update or the relevant portion thereof). Most other stuff is done on a per-list basis, like held messages. class ListAdmin has an sort-of-private function _UpdateRecords, used in bin/update to upgrade from 2.0-style request.db which holds the held messages metadata. It writes the entries to the new database like this: if op == SUBSCRIPTION: [munge...] # Here's the new layout self.__db[id] = when, addr, fullname, passwd, digest, lang However, other code uses it like: type, data = self.__db[id] Seems like the correct way should be something like self.__db[id] = TYPE, (when, addr, fullname, passwd, digest, lang) I'v made a script to mv files and directories from 2.0 to 2.1 installation, fix the aliases, and do stuff withlist, _UpdateRecords() among other. After this, some of the migrated lists would have munged requests without a request type. AFAICT this would happen on a regular 2.0.x -> 2.1.5 upgrade with bin/update too. So here's a patch for 2.1.5 which includes crude heuristics to guess the forgotten request type, it can be used in withlist to fix the damage, or in bin/update. I'm not sure if this is adequate to put in the main tree. It applies to 2.1.6b4 too, but I've not tested yet if it works. Should I file a bug report at sourceforge? Regards, Zoran Index: ListAdmin.py =================================================================== RCS file: /var/lib/cvs/mailman-conf/ListAdmin.py,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- ListAdmin.py 7 Sep 2004 02:48:50 -0000 1.1 +++ ListAdmin.py 7 Sep 2004 03:33:17 -0000 1.3 @@ -530,7 +530,19 @@ except IOError, e: if e.errno <> errno.ENOENT: raise self.__db = {} - for id, (op, info) in self.__db.items(): + for id, rest in self.__db.items(): + if len(rest) == 2: + op, info = rest + # repair junk from 2.1.5 + elif len(rest) == 6: + op = SUBSCRIPTION + if len(rest[5]) > 10 and rest[2] != '': + op = HELDMSG + self.__db[id] = op, rest + continue + else: + assert len(rest) == 2, 'Found broken database' + continue if op == SUBSCRIPTION: if len(info) == 4: # pre-2.1a2 compatibility @@ -545,7 +557,7 @@ assert len(info) == 6, 'Unknown subscription record layout' continue # Here's the new layout - self.__db[id] = when, addr, fullname, passwd, digest, lang + self.__db[id] = op, (when, addr, fullname, passwd, digest, lang) elif op == HELDMSG: if len(info) == 5: when, sender, subject, reason, text = info @@ -554,7 +566,7 @@ assert len(info) == 6, 'Unknown held msg record layout' continue # Here's the new layout - self.__db[id] = when, sender, subject, reason, text, msgdata + self.__db[id] = op, (when, sender, subject, reason, text, msgdata) # All done self.__closedb() From mcn4 at leicester.ac.uk Wed Mar 16 14:36:41 2005 From: mcn4 at leicester.ac.uk (Matthew Newton) Date: Wed Mar 16 14:36:43 2005 Subject: [Mailman-Developers] Two patches for site-wide configuration Message-ID: <20050316133641.GA4126@ultra.le.ac.uk> Hi! I've written two small patches for Mailman that add the following functionality: site_hide_list_options.patch, sourceforge number 1164457 Lets the site administrator stop list owners from changing certain configuration options. Example is to stop the list owner making someone else the owner. transform_address_hook.patch, sourceforge number 1164464 Gives a hook into the add member routines that allow the subscribers address to be changed before it is added to the list. This could be dangerous if used incorrectly, but is needed for sites that have two "identical" domain names, such as "leicester.ac.uk" and "le.ac.uk". Any comments on these patches would be most appreciated! Is there a better way of doing these things, or are there any improvements that could be made to the patches? Patches apply to 2.1.5. Thanks! Matthew -- Matthew Newton UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom From claw at kanga.nu Thu Mar 17 00:39:50 2005 From: claw at kanga.nu (J C Lawrence) Date: Thu Mar 17 00:39:59 2005 Subject: [Mailman-Developers] Two patches for site-wide configuration In-Reply-To: Message from Matthew Newton of "Wed, 16 Mar 2005 13:36:41 GMT." <20050316133641.GA4126@ultra.le.ac.uk> References: <20050316133641.GA4126@ultra.le.ac.uk> Message-ID: <31742.1111016390@kanga.nu> On Wed, 16 Mar 2005 13:36:41 +0000 Matthew Newton wrote: I've not reviewd the patches and so am reacting to their descriptions only. > Lets the site administrator stop list owners from changing certain > configuration options. Example is to stop the list owner making > someone else the owner. +1 (this is also useful to me) > Gives a hook into the add member routines that allow the subscribers > address to be changed before it is added to the list. This could be > dangerous if used incorrectly, but is needed for sites that have two > "identical" domain names, such as "leicester.ac.uk" and "le.ac.uk". +1 as a hidden hook. -0 as an exposed feature. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry at python.org Thu Mar 17 17:32:03 2005 From: barry at python.org (Barry Warsaw) Date: Thu Mar 17 17:32:09 2005 Subject: [Mailman-Developers] Mailman 3 Sprint at Pycon2005 Message-ID: <1111077123.9861.19.camel@geddy.wooz.org> Just a reminder that we're going to do a Mailman 3 sprint again this year at Pycon2005, which starts Saturday. I plan on being there all four sprint days (Sat-Tues) and I hope you will be able to join us. For the meager information on the MM3 sprint see: http://www.python.org/moin/Mailman3Sprint Please sign up on this page if you plan on coming. Remember that the sprint days at Pycon are free; for more information on the conference in general see: http://www.pycon.org I plan on logging into the #mailman channel on irc.freenode.net so if you can't make it and have questions, we'll try to discuss things there, although we might be too busy to pay much attention to irc. I should have more information about the Subversion repository for MM3 later today. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050317/cb4e6ef4/attachment.pgp From bob at nleaudio.com Thu Mar 17 18:02:30 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu Mar 17 18:10:51 2005 Subject: [Mailman-Developers] list-owner address spam Message-ID: <4239B826.4000600@nleaudio.com> Hi Gang, I've got a list where the -owner address is getting directly spammed. Any ideas on how to combat this? I don't suppose I can just change it to owner- and still have mailman pass along admin requests, huh? Bob From claw at kanga.nu Thu Mar 17 21:20:13 2005 From: claw at kanga.nu (claw@kanga.nu) Date: Thu Mar 17 22:44:15 2005 Subject: [Mailman-Developers] Re: list-owner address spam References: <4239B826.4000600@nleaudio.com> Message-ID: Bob Puff@NLE wrote: > I've got a list where the -owner address is getting > directly spammed. Yep. Each of mine gets about 300 spam per day. > Any ideas on how to combat this? I run TMDA as an inbound filter on all role addresses. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From mss at mawhrin.net Fri Mar 18 12:22:07 2005 From: mss at mawhrin.net (Mikhail Sobolev) Date: Fri Mar 18 12:22:11 2005 Subject: [Mailman-Developers] Re: Can you donate a public subversion repository for Pycon sprints? In-Reply-To: <1110838993.16647.12.camel@geddy.wooz.org> References: <1110829380.15320.82.camel@geddy.wooz.org> <1110838993.16647.12.camel@geddy.wooz.org> Message-ID: <20050318112207.GA7869@mawhrin.net> On Mon, Mar 14, 2005 at 05:23:13PM -0500, Barry Warsaw wrote: > On Mon, 2005-03-14 at 14:44, Barry Warsaw wrote: > > I'm wondering if anybody out there can donate a Subversion repository > > for use at the upcoming Pycon sprint next week (actually, starting > > Saturday). > > We have a winner! John Viega reminds me that we can use list.org! > Whodah thunk? :) The machine recently got rebuilt with plenty of disk > space and already has svn on it, so we just need to set up the access > infrastructure. I should be able to have the repo up before Saturday, > and I will send (read-only) instructions when it's available. We'll > work out write perms at the sprint. Completely unrelated question: are there any plans on moving the current repository to Subversion? :)) Regards -- Misha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050318/e2f7b519/attachment.pgp From barry at python.org Fri Mar 18 15:29:07 2005 From: barry at python.org (Barry Warsaw) Date: Fri Mar 18 15:29:11 2005 Subject: [Mailman-Developers] Re: Can you donate a public subversion repository for Pycon sprints? In-Reply-To: <20050318112207.GA7869@mawhrin.net> References: <1110829380.15320.82.camel@geddy.wooz.org> <1110838993.16647.12.camel@geddy.wooz.org> <20050318112207.GA7869@mawhrin.net> Message-ID: <1111156147.20406.36.camel@presto.wooz.org> On Fri, 2005-03-18 at 06:22, Mikhail Sobolev wrote: > Completely unrelated question: are there any plans on moving the current > repository to Subversion? :)) Personally, I'd be all for it, but since most people (Tokio being the most important) are already used to using CVS to access MM2, I won't make that decision unilaterally. I'd like the answer to be "eventually, yes", but what "eventually" means is up for debate. At some point SF will be making Subversion available, so another question is whether we put any future MM2 svn repo on SF or move it to list.org too. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050318/754df1fd/attachment.pgp From beuc at beuc.net Sat Mar 19 10:15:10 2005 From: beuc at beuc.net (Sylvain Beucler) Date: Sat Mar 19 10:19:57 2005 Subject: [Mailman-Developers] EOL handling in Mailman Message-ID: <20050319091510.GA8684@dink.localdomain> Hi, I'm a Savane (gna.org/p/savane) developer, and we noticed that when we send mail with newlines in the \r\n format, Mailman converts them to \n\n. I would like to get your point on what we should do to fix the problem. I had a look at RFC 822; the EOL (end of line) description is not very clear, but it seems that the standard EOL convention is \r\n (CRLF). The issue can be fixed if I make Savane convert all \r\n to \n before to send the notifications, but I am not sure this is very compliant. Anyway I do think this is a bug in Mailman. What do you think we (Mailman and Savane) should do? I posted a detailed bug report at: http://sourceforge.net/tracker/index.php?func=detail&aid=1151439&group_id=103&at +id=100103 for more information. The Savane bug report counterpart is at: https://gna.org/bugs/?func=detailitem&item_id=1980 -- Sylvain From msapiro at value.net Sat Mar 19 18:59:46 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Mar 19 19:00:04 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: <20050319091510.GA8684@dink.localdomain> Message-ID: Sylvain Beucler wrote: > >I'm a Savane (gna.org/p/savane) developer, and we noticed that when we >send mail with newlines in the \r\n format, Mailman converts them to >\n\n. > >I would like to get your point on what we should do to fix the >problem. I had a look at RFC 822; the EOL (end of line) description is >not very clear, but it seems that the standard EOL convention is \r\n >(CRLF). RFC 822 is obsolete. The current standards are RFC 2821 SMTP and RFC 2822 Internet Message Format. Both these standards are very clear. For example RFC 2821 says: 2.3.7 Lines SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3). In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a sequence. RFC 2822 says 2.3 Body The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: - CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. - Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF. Note: As was stated earlier, there are other standards documents, specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] that extend this standard to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document. >The issue can be fixed if I make Savane convert all \r\n to \n before >to send the notifications, but I am not sure this is very >compliant. Anyway I do think this is a bug in Mailman. What do you >think we (Mailman and Savane) should do? I don't see any issues with mail delivered from Mailman having any "doubling" of line terminators resulting in extra blank lines. How does Savane inject its messages into the internet mail transport system? If it is sending via SMTP, then it MUST send line terminators as (or \r\n). If this results in doubling, then the receiving SMTP server is non compliant. If it is sending messages via some non SMTP intermediary, then it needs to format the messages as expected by the intermediary. Does Savane perhaps pipe outgoing messages directly to the Mailman wrapper in the same way that an incoming MTA might do? If so, this is _not_ an SMTP transfer and end of line sequences should be those of the platform, i.e just \n for Unix. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Sat Mar 19 23:46:55 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Mar 19 23:47:29 2005 Subject: [Savane-dev] Re: [Mailman-Developers] EOL handling in Mailman In-Reply-To: Message-ID: Mathieu Roy wrote: >Mark Sapiro tapota : >> >> How does Savane inject its messages into the internet mail transport >> system? If it is sending via SMTP, then it MUST send line terminators >> as (or \r\n). > >I do not remember the specifics exactly but Sylvain wrote previously >"we noticed that when we send mail with newlines in the \r\n format, >Mailman converts them to \n\n.". So I assume Savane is sending >newlines in the \r\n format. > > >> If this results in doubling, then the receiving SMTP server is non >> compliant. If it is sending messages via some non SMTP intermediary, >> then it needs to format the messages as expected by the >> intermediary. >> >> Does Savane perhaps pipe outgoing messages directly to the Mailman >> wrapper in the same way that an incoming MTA might do? If so, this is >> _not_ an SMTP transfer and end of line sequences should be those of >> the platform, i.e just \n for Unix. > > >It uses the default mail() function provided by PHP, which would send >the mail via the locally available SMTP server -- maybe through a pipe >but still there's an SMTP server between Savane and mailman. > >The main reason why we have the feeling that the bug comes from >mailman is the fact that only mails redistributed by mailman >mailing-list have this problem -- not copies sent directly to users or >mailing-list managed by other list managers. > >Savane and the SMTP server itself are completely unaffected by this >problem when mailman is not involved. I certainly understand why you would think this given your observations, but I have never seen this problem from Mailman, nor have I seen any report of it other than yours, so I'm inclined to be more skeptical. Here's a suggestion for a test. Presumably, your current MTA that delivers to Mailman has aliases (or equivalents) to hand off incomming mail to Mailman. In particular, the posting address for listname has something like listname@example.com: "|/usr/local/mailman/mail/mailman post listname" The path to mailman/mail/mailman may be different, but assuming there is an alias like this, you could change it temporarily to something like listname@example.com: "|tee somefile|/usr/local/mailman/mail/mailman post listname" i.e. you could capture a copy in somefile of the incoming message as delivered to Mailman. Then, by comparing this copy both to what you're sending and to what Mailman sends, you should be able to pinpoint where the problem is. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From jwblist at olympus.net Sun Mar 20 01:27:51 2005 From: jwblist at olympus.net (John W. Baxter) Date: Sun Mar 20 01:28:07 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: Message-ID: On 3/19/2005 9:59, "Mark Sapiro" wrote: > Sylvain Beucler wrote: >> >> I'm a Savane (gna.org/p/savane) developer, and we noticed that when we >> send mail with newlines in the \r\n format, Mailman converts them to >> \n\n. >> >> I would like to get your point on what we should do to fix the >> problem. I had a look at RFC 822; the EOL (end of line) description is >> not very clear, but it seems that the standard EOL convention is \r\n >> (CRLF). > > RFC 822 is obsolete. The current standards are RFC 2821 SMTP and RFC > 2822 Internet Message Format. Both these standards are very clear. For > example RFC 2821 says: > > > 2.3.7 Lines > > SMTP commands and, unless altered by a service extension, message > data, are transmitted in "lines". Lines consist of zero or more data > characters terminated by the sequence ASCII character "CR" (hex value > 0D) followed immediately by ASCII character "LF" (hex value 0A). This > termination sequence is denoted as in this document. Conforming > implementations MUST NOT recognize or generate any other character or > character sequence as a line terminator. Limits MAY be imposed on line > lengths by servers (see section 4.5.3). > > In addition, the appearance of "bare" "CR" or "LF" characters in > text (i.e., either without the other) has a long history of causing > problems in mail implementations and applications that use the mail > system as a tool. SMTP client implementations MUST NOT transmit these > characters except when they are intended as line terminators and then > MUST, as indicated above, transmit them only as a sequence. > > > RFC 2822 says > > > 2.3 Body > > The body of a message is simply lines of US-ASCII characters. The > only two limitations on the body are as follows: > > - CR and LF MUST only occur together as CRLF; they MUST NOT appear > independently in the body. > > - Lines of characters in the body MUST be limited to 998 characters, > and SHOULD be limited to 78 characters, excluding the CRLF. > > Note: As was stated earlier, there are other standards documents, > specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] > that extend this standard to allow for different sorts of message > bodies. Again, these mechanisms are beyond the scope of this document. > > > >> The issue can be fixed if I make Savane convert all \r\n to \n before >> to send the notifications, but I am not sure this is very >> compliant. Anyway I do think this is a bug in Mailman. What do you >> think we (Mailman and Savane) should do? > > I don't see any issues with mail delivered from Mailman having any > "doubling" of line terminators resulting in extra blank lines. > > How does Savane inject its messages into the internet mail transport > system? If it is sending via SMTP, then it MUST send line terminators > as (or \r\n). If this results in doubling, then the receiving > SMTP server is non compliant. If it is sending messages via some non > SMTP intermediary, then it needs to format the messages as expected by > the intermediary. > > Does Savane perhaps pipe outgoing messages directly to the Mailman > wrapper in the same way that an incoming MTA might do? If so, this is > _not_ an SMTP transfer and end of line sequences should be those of > the platform, i.e just \n for Unix. > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/jwblist%40olympus.ne> t Note that 2821 is talking about how messages are transmitted over the wire as part of the SMTP transaction. An MTA will usually present the message to mailboxes, scripts, etc in the native form expected on the platform (for Unix, newline = ASCII linefeed). Mailman is very likely operating on that expectation (in particular, Mailman is not one end of an SMTP conversation, so the SMTP RFC doesn't apply). I believe things will work much better if Savane presents Unix-like data to the Mailman scripts, not SMTP data. The same is likely true of at least some other entities that Savane talks to. --John From barry at python.org Sun Mar 20 04:58:58 2005 From: barry at python.org (Barry Warsaw) Date: Sun Mar 20 04:59:02 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: References: Message-ID: <1111291138.25203.16.camel@geddy.wooz.org> On Sat, 2005-03-19 at 19:27, John W. Baxter wrote: > Note that 2821 is talking about how messages are transmitted over the wire > as part of the SMTP transaction. An MTA will usually present the message to > mailboxes, scripts, etc in the native form expected on the platform (for > Unix, newline = ASCII linefeed). Mailman is very likely operating on that > expectation (in particular, Mailman is not one end of an SMTP conversation, > so the SMTP RFC doesn't apply). Exactly. Mailman isn't going to convert line endings. The email package is the component that parses messages and generates the flattened text from the message objects. If anything was converting newlines it would be the email package. But the email package tries very hard to preserve whatever line endings it finds in the messages it parses. John is right that typically the MTA will present the message to mail programs using native line endings. The on-the-wire representation really has no bearing on the issue. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050319/8e2b6231/attachment.pgp From beuc at beuc.net Sun Mar 20 08:43:13 2005 From: beuc at beuc.net (Sylvain Beucler) Date: Sun Mar 20 08:48:13 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: References: <20050319091510.GA8684@dink.localdomain> Message-ID: <20050320074211.GA918@dink.mshome.net> On Sat, Mar 19, 2005 at 09:59:46AM -0800, Mark Sapiro wrote: > Sylvain Beucler wrote: > > > >I'm a Savane (gna.org/p/savane) developer, and we noticed that when we > >send mail with newlines in the \r\n format, Mailman converts them to > >\n\n. > > > >I would like to get your point on what we should do to fix the > >problem. I had a look at RFC 822; the EOL (end of line) description is > >not very clear, but it seems that the standard EOL convention is \r\n > >(CRLF). > > RFC 822 is obsolete. The current standards are RFC 2821 SMTP and RFC > 2822 Internet Message Format. Both these standards are very clear. For > example RFC 2821 says: > > > 2.3.7 Lines > > SMTP commands and, unless altered by a service extension, message > data, are transmitted in "lines". Lines consist of zero or more data > characters terminated by the sequence ASCII character "CR" (hex value > 0D) followed immediately by ASCII character "LF" (hex value 0A). This > termination sequence is denoted as in this document. Conforming > implementations MUST NOT recognize or generate any other character or > character sequence as a line terminator. Limits MAY be imposed on line > lengths by servers (see section 4.5.3). > > In addition, the appearance of "bare" "CR" or "LF" characters in > text (i.e., either without the other) has a long history of causing > problems in mail implementations and applications that use the mail > system as a tool. SMTP client implementations MUST NOT transmit these > characters except when they are intended as line terminators and then > MUST, as indicated above, transmit them only as a sequence. > > > RFC 2822 says > > > 2.3 Body > > The body of a message is simply lines of US-ASCII characters. The > only two limitations on the body are as follows: > > - CR and LF MUST only occur together as CRLF; they MUST NOT appear > independently in the body. > > - Lines of characters in the body MUST be limited to 998 characters, > and SHOULD be limited to 78 characters, excluding the CRLF. > > Note: As was stated earlier, there are other standards documents, > specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] > that extend this standard to allow for different sorts of message > bodies. Again, these mechanisms are beyond the scope of this document. > Thanks for the pointer. So we should use CRLF anywhere. > >The issue can be fixed if I make Savane convert all \r\n to \n before > >to send the notifications, but I am not sure this is very > >compliant. Anyway I do think this is a bug in Mailman. What do you > >think we (Mailman and Savane) should do? > > I don't see any issues with mail delivered from Mailman having any > "doubling" of line terminators resulting in extra blank lines. > > How does Savane inject its messages into the internet mail transport > system? If it is sending via SMTP, then it MUST send line terminators > as (or \r\n). If this results in doubling, then the receiving > SMTP server is non compliant. If it is sending messages via some non > SMTP intermediary, then it needs to format the messages as expected by > the intermediary. > > Does Savane perhaps pipe outgoing messages directly to the Mailman > wrapper in the same way that an incoming MTA might do? If so, this is > _not_ an SMTP transfer and end of line sequences should be those of > the platform, i.e just \n for Unix. Savane uses the PHP "mail()" function, that executes the local sendmail-compatible command. At both GNU Savannah (savannah.gnu.org) and Gna! (gna.org), we use the Exim version packaged by Debian. In both cases, the mail we receive via mailing lists (and in the Mailman archives) have the newlines doubled. The mails we receive at our personnal mail addresses is correct (no doubling). As far as I'm concerned, line doubling _does_ look ugly and unprofessional ;) As a result, I was under the impression that Mailman is the one that doubles the newlines. Now maybe Exim as an SMTP server (not as a sendmail-compatible command) is doubling lines. But are you completely sure Mailman (or a Python library used by Mailman) is not converting \r\n to \n\n? -- Sylvain From barry at python.org Sun Mar 20 14:21:14 2005 From: barry at python.org (Barry Warsaw) Date: Sun Mar 20 14:21:19 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: <20050320074211.GA918@dink.mshome.net> References: <20050319091510.GA8684@dink.localdomain> <20050320074211.GA918@dink.mshome.net> Message-ID: <1111324874.3894.5.camel@geddy.wooz.org> On Sun, 2005-03-20 at 02:43, Sylvain Beucler wrote: > As a result, I was under the impression that Mailman is the one that > doubles the newlines. Now maybe Exim as an SMTP server (not as a > sendmail-compatible command) is doubling lines. But are you completely > sure Mailman (or a Python library used by Mailman) is not converting > \r\n to \n\n? I could be wrong of course, but I can't think of anything in either Python or Mailman that would do that conversion. Another simple experiment is to write a little Python mail program that just parses stdin, then writes the flattened text out to a file. See if that has the newline problem. You're basically going to have to work your way up your tool chain to see where the transformation is happening. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050320/39603034/attachment.pgp From mads at kiilerich.com Sun Mar 20 14:29:27 2005 From: mads at kiilerich.com (Mads Kiilerich) Date: Sun Mar 20 14:33:12 2005 Subject: [Mailman-Developers] EOL handling in Mailmanc In-Reply-To: <20050320074211.GA918@dink.mshome.net> References: <20050319091510.GA8684@dink.localdomain> <20050320074211.GA918@dink.mshome.net> Message-ID: Today I got mail from Sylvain Beucler: > Thanks for the pointer. So we should use CRLF anywhere. On the network, yes. Not locally through the sendmail interface. > Savane uses the PHP "mail()" function, that executes the local > sendmail-compatible command. Php mail() is IMHO quite buggy. On windows it connects to an smtp server and sends whatever the user provided directly - \r\n is thus mandatory. (But IIRC php internally adds some header lines ending with \n.) On unix php uses sendmail (and can NOT be configured to use smtp :-( and can thus NOT confirm to the php script that the local MTA has received and accepted the message) and the message should thus not contain CRLF. Only the windows behaviour seems documented in the php docs. > At both GNU Savannah (savannah.gnu.org) and Gna! (gna.org), we use the > Exim version packaged by Debian. In both cases, the mail we receive > via mailing lists (and in the Mailman archives) have the newlines > doubled. The mails we receive at our personnal mail addresses is > correct (no doubling). As far as I'm concerned, line doubling _does_ > look ugly and unprofessional ;) > > As a result, I was under the impression that Mailman is the one that > doubles the newlines. Now maybe Exim as an SMTP server (not as a > sendmail-compatible command) is doubling lines. But are you completely > sure Mailman (or a Python library used by Mailman) is not converting > \r\n to \n\n? My guess: When exim receives \r\n at its sendmail interface it is kind and cleans it up and converts it to a \n, and when sending over SMTP it converts to \r\n. When Mailman receives \r\n it trusts the user and considers it a line with a \r before the lineending \n. When Mailman delivers the mail over SMTP it writes the lineending \n as \r\n, ending up with SMTP lines ending with \r\r\n. A receiving MTA might consider that a malformed (mac) lineending followed by a wellformed one and be kind enough to make the first wellformed, causing two linefeeds... I suggest that you try to convert all \r\n to \n before calling mail(), that you avoid using mail() and delivers through smtp instead, and finally that you fix mail() ;-) Regards, Mads Kiilerich From barry at python.org Sun Mar 20 14:44:22 2005 From: barry at python.org (Barry Warsaw) Date: Sun Mar 20 14:44:26 2005 Subject: [Mailman-Developers] EOL handling in Mailmanc In-Reply-To: References: <20050319091510.GA8684@dink.localdomain> <20050320074211.GA918@dink.mshome.net> Message-ID: <1111326262.3896.28.camel@geddy.wooz.org> On Sun, 2005-03-20 at 08:29, Mads Kiilerich wrote: > When Mailman delivers the mail over SMTP it writes > the lineending \n as \r\n, ending up with SMTP lines ending with \r\r\n. Actually, that bit would happen by Python's smtplib module, which must ensure that the data it sends over the wire is RFC compliant. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050320/c241e18b/attachment.pgp From jwblist at olympus.net Sun Mar 20 18:41:18 2005 From: jwblist at olympus.net (John W. Baxter) Date: Sun Mar 20 18:41:35 2005 Subject: [Mailman-Developers] EOL handling in Mailman In-Reply-To: <20050320074211.GA918@dink.mshome.net> Message-ID: On 3/19/2005 23:43, "Sylvain Beucler" wrote: > Savane uses the PHP "mail()" function, that executes the local > sendmail-compatible command. > > At both GNU Savannah (savannah.gnu.org) and Gna! (gna.org), we use the > Exim version packaged by Debian. In both cases, the mail we receive > via mailing lists (and in the Mailman archives) have the newlines > doubled. The mails we receive at our personnal mail addresses is > correct (no doubling). As far as I'm concerned, line doubling _does_ > look ugly and unprofessional ;) > > As a result, I was under the impression that Mailman is the one that > doubles the newlines. Now maybe Exim as an SMTP server (not as a > sendmail-compatible command) is doubling lines. But are you completely > sure Mailman (or a Python library used by Mailman) is not converting > \r\n to \n\n? Ever since Philip Hazel tried to accommodate some broken email producers by messing with incoming line endings, there have been problems with products broken in different ways. As I recall, Philip has done various tuneups over the last many Exim versions. You didn't say what version of Exim is running in your Debian installation...there are backports of newish Exim versions available which would likely fix your problem. Note that switching from the Exim 3.x series to Exim 4.x involves a significant reconfiguration of Exim...it's likely best done by running debconfig and answering the Exim configuration questions as if you were starting from scratch. This will not be something to tackle the day before a vacations on your production server. --John From j.e.vanbaal at uvt.nl Tue Mar 22 17:38:29 2005 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Tue Mar 22 17:38:31 2005 Subject: mailman-2.1.5-gpg_2005-02-22-ssls_2005-03-22.patch.gz available (was: Re: [Mailman-Developers] PGP and Mailman) In-Reply-To: <20050228174022.GT6533@banach.uvt.nl> References: <20050228174022.GT6533@banach.uvt.nl> Message-ID: <20050322163829.GH8643@banach.uvt.nl> On Mon, Feb 28, 2005 at 06:40:22PM +0100, Joost van Baal wrote: > > I will write and publish a patch which integrates PGP signature > validation and re-encryption of encrypted posts to mailman. Specs are: > > - A post will be distributed only if the PGP signature on the post is from > one of the list members. > - For sending encrypted email, a list member encrypts to the public key of > the list. The post will be decrypted and re-encrypted to the public keys > of all list members. > > (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to > RFC 2440 (OpenPGP)). > So, the plan: > Any insight to share on this? Thanks a lot for all feedback. Thanks to Stefan Schlott's fine work he has done earlier, the first test-able version is available now, from http://www.non-gnu.uvt.nl/pub/mailman/ . For those of you running Debian GNU/Linux, packages are available too (both pre-build and source packages). The patch is still a bit rough on the edges, but could be interesting for developers. Comments on the code are welcome (but you guessed that :) The patch is submitted to the patch tracker too: it's Mailman patch #1167696 . Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050322/fb838c38/attachment.pgp From tobias at kabissa.org Wed Mar 23 12:42:44 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Wed Mar 23 12:41:31 2005 Subject: [Mailman-Developers] Fwd: [SourceForge.net Release] m2f : m2f Message-ID: <699b27aa3111e549fae2bf31830bc295@kabissa.org> Dear friends, I thought you might be interested in the fact that mail2forum, the hack that provides phpbb/list gatewaying, has released a new 'stable' version. Haven't tried it yet but will do so once I get back from the nonprofit technology conference in Chicago. Sorry to be missing all the Mailman visitors to DC - hope you have a productive and fruitful time at PyCon DC! Cheers, Tobias Begin forwarded message: > From: "SourceForge.net" > Date: March 22, 2005 3:39:38 PM EST > To: noreply@sourceforge.net > Subject: [SourceForge.net Release] m2f : m2f > > Project: mail2forum (m2f) > Package: m2f > Date : 2005-03-22 16:39 > > Project "mail2forum" ('m2f') has released the new version of package > 'm2f'. > You can download it from SourceForge.net by following this link: > group_id=68964&release_id=314792> > or browse Release Notes and ChangeLog by visiting this link: > From MagicFab at gmail.com Wed Mar 23 19:03:41 2005 From: MagicFab at gmail.com (MF) Date: Wed Mar 23 19:03:48 2005 Subject: [Mailman-Developers] Where to post RFEs ? Message-ID: <4241AF7D.8010801@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am new to this list. I am the admin of several mailman-based lists and I'd like to submit a RFE to be able to recover admin passwords (NOT subscriber passwords). I haven't seen this submitted as a bug or as an RFE in the Sourceforge site, and I see the RFEs there don't seem to be maintained/assigned. Where should I post this ? Thanks for any pointers :) Cheers, Fabian -----BEGIN PGP SIGNATURE----- iIcEARECAEcFAkJBr3xAGmh0dHA6Ly93d3cuZmFiaWFucm9kcmlndWV6LmNvbS9l bmNyeXB0aW9uL3RoYXd0ZV93b3QucGhwI3BvbGljeQAKCRB9RxNcWvKk1Q9AAJ9B 9i+3n+dMYy3ggIrAs8Mu2JO0EQCcDJUu/hbK/zyyugSqPKSfUkby21U= =gSdj -----END PGP SIGNATURE----- From msapiro at value.net Wed Mar 23 19:30:38 2005 From: msapiro at value.net (Mark Sapiro) Date: Wed Mar 23 19:30:55 2005 Subject: [Mailman-Developers] Where to post RFEs ? In-Reply-To: <4241AF7D.8010801@gmail.com> Message-ID: MF wrote: > >I am new to this list. I am the admin of several mailman-based lists >and I'd like to submit a RFE to be able to recover admin passwords >(NOT subscriber passwords). I haven't seen this submitted as a bug or >as an RFE in the Sourceforge site, and I see the RFEs there don't seem >to be maintained/assigned. Where should I post this ? Sourceforge is the place, but in this case, here will do. You can't retrieve list admin passwords by design because they are not stored anywhere except as a non-reversable hash. If a list admin password is lost, a mailman site admin can use the site password to access the list's password page and set a new list password or can use the bin/change_pw script to set a new password for the list. If the site password is lost, a site admin can set a new one with bin/mmsitepass. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Thu Mar 24 01:23:23 2005 From: barry at python.org (Barry Warsaw) Date: Thu Mar 24 01:23:30 2005 Subject: [Mailman-Developers] Where to post RFEs ? In-Reply-To: <4241AF7D.8010801@gmail.com> References: <4241AF7D.8010801@gmail.com> Message-ID: <1111623803.11977.0.camel@geddy.wooz.org> On Wed, 2005-03-23 at 13:03, MF wrote: > I am new to this list. I am the admin of several mailman-based lists > and I'd like to submit a RFE to be able to recover admin passwords > (NOT subscriber passwords). I haven't seen this submitted as a bug or > as an RFE in the Sourceforge site, and I see the RFEs there don't seem > to be maintained/assigned. Where should I post this ? Mark's answered the specific question, but I'll just add that soon now we'll have a brand new Mailman-only wiki up on list.org. It probably won't happen until after the Python conference. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050323/12f6f7b0/attachment.pgp From dman at dman13.dyndns.org Thu Mar 24 02:06:21 2005 From: dman at dman13.dyndns.org (Derrick Hudson) Date: Thu Mar 24 02:06:27 2005 Subject: [Mailman-Developers] postfix deployment scenario needs to be supported Message-ID: <20050324010620.GA3016@dman13.dyndns.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050323/9bc5b342/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Thu Mar 24 04:47:25 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Mar 24 04:47:37 2005 Subject: [Mailman-Developers] Mailman 2.1.6 beta 5 released Message-ID: <4242384D.8040609@is.kochi-u.ac.jp> Hi, Sorry for the delay of 2.1.6 but a serious bug was found in the previous beta releases. I put a final beta release before jumping up to the release candidate. The bug is related to 'Privacy -> SPAM filter -> header_filter_rules'. So, I want all of you, who have had brave souls to upgrade 2.1.6 beta and who use this feature, to upgrade again to 2.1.6 beta 5. The tarball is placed at http://mm.tkikuchi.net/mailman-2.1.6b5.tgz # Sorry but it looks like I have not access to the file releases on SF. -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From fehwalker at gmail.com Thu Mar 24 06:03:28 2005 From: fehwalker at gmail.com (Bryan Fullerton) Date: Thu Mar 24 06:03:30 2005 Subject: [Mailman-Developers] Mailman 2.1.6 beta 5 released In-Reply-To: <4242384D.8040609@is.kochi-u.ac.jp> References: <4242384D.8040609@is.kochi-u.ac.jp> Message-ID: <35de0c30050323210326eb8474@mail.gmail.com> Yay, upgraded. :) Is the bug you mentioned below filed on SF? Just wondering what the issue is, and specifically if this will fix a problem I've seen with SpamAssassin-tagged mail leaking through to my mailman@ list despite a header_filter_rule that really should be blocking it... but haven't had time to double-check everything is setup properly here before reporting it as a bug. Thanks! Bryan On Thu, 24 Mar 2005 12:47:25 +0900, Tokio Kikuchi wrote: > Hi, > > Sorry for the delay of 2.1.6 but a serious bug was found in the previous > beta releases. I put a final beta release before jumping up to the > release candidate. The bug is related to 'Privacy -> SPAM filter -> > header_filter_rules'. So, I want all of you, who have had brave souls to > upgrade 2.1.6 beta and who use this feature, to upgrade again to 2.1.6 > beta 5. > > The tarball is placed at > > http://mm.tkikuchi.net/mailman-2.1.6b5.tgz > > # Sorry but it looks like I have not access to the file releases on SF. > > -- > Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp > http://weather.is.kochi-u.ac.jp/ > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/fehwalker%40gmail.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > From tkikuchi at is.kochi-u.ac.jp Thu Mar 24 06:18:18 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Mar 24 06:18:28 2005 Subject: [Mailman-Developers] Mailman 2.1.6 beta 5 released In-Reply-To: <35de0c30050323210326eb8474@mail.gmail.com> References: <4242384D.8040609@is.kochi-u.ac.jp> <35de0c30050323210326eb8474@mail.gmail.com> Message-ID: <42424D9A.1040509@is.kochi-u.ac.jp> Bryan Fullerton wrote: > Yay, upgraded. :) > > Is the bug you mentioned below filed on SF? No. > Just wondering what the > issue is, and specifically if this will fix a problem I've seen with > SpamAssassin-tagged mail leaking through to my mailman@ list despite a > header_filter_rule that really should be blocking it... but haven't > had time to double-check everything is setup properly here before > reporting it as a bug. Sorry for the inconvenience. The shame is on me. While applying my patch, by hand, to collect subpart headers, I might have something out of mind and an intermediate version has gone out. I am going to give some seminar on the security of mailman this weekend in Tokyo and while preparing my presentation I wanted to check the new feature. Then, the bug is there! You can check what was wrong using diff in CVS. http://cvs.sourceforge.net/viewcvs.py/mailman/mailman/Mailman/Handlers/SpamDetect.py?r1=2.3.2.2&r2=2.3.2.3 -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From hatukanezumi at users.sourceforge.net Mon Mar 28 12:38:06 2005 From: hatukanezumi at users.sourceforge.net (Hatuka*nezumi) Date: Mon Mar 28 12:38:11 2005 Subject: [Mailman-Developers] qmail MTA hook Message-ID: <20050328193806.13822b7a.hatukanezumi@users.sourceforge.net> Hi Mailman folks. I wrote an MTA hook for qmail to automate creation/deletion of list aliases. This seems to work well on my environment (I tested this on FreeBSD 4.11-STABLE with qmail-1.03 and Mailman 2.1.5 installed from FreeBSD ports): http://sourceforge.net/tracker/index.php?func=detail&aid=1170429&group_id=103&atid=300103 The qmail-to-mailman.py script also detect newly-created lists automatically. But "accept and verify" approach by this script seems not to able to prevent/reduce generating unuseful bounces (so-called "backscatter mails") in its nature. My approach will make their reduction somewhat possible --- combined with a patch for qmail. For details, please read submitted attachment README.qmail. --- nezumi