From fmouse-mailman at fmp.com Fri Nov 3 21:43:01 2006 From: fmouse-mailman at fmp.com (Lindsay Haisley) Date: Fri, 3 Nov 2006 14:43:01 -0600 Subject: [Mailman-Developers] courier-to-mailman.py Message-ID: <20061103204301.GA16217@fmp.com> I'm attaching a current version of courier-to-mailman.py for possible inclusion in mailman's contrib directory in the source tree. I recently updated it a tad to properly handle confirmation address cookies in newer versions of mailman, and the script is in use, quite happily, on a production system. This script is based on Bruce Perens' qmail-to-mailman.py, but it's specific to the Courier MTA and the code and the install instructions (in the file comments) have been modified accordingly. Additional changes to the configure script would be necessary to do the proper token replacements at build time. It ought to be noted that qmail-to-mailman.py probably won't work as-is at this point, since it allows neither for the current format of VERP addresses in bounce messages nor for the use of confirmation addresses with cookies. The flip side is that although qmail has been largely unsupported for some time, the script provides a useful example of how to do this stuff creatively. -- Lindsay Haisley | "Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate | http://www.fmp.com | dandelions" | | (Pamela Jones) | -------------- next part -------------- A non-text attachment was scrubbed... Name: courier-to-mailman.py Type: text/x-python Size: 4156 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20061103/60ce6f9b/attachment.py From n8gray at caltech.edu Sat Nov 4 01:18:59 2006 From: n8gray at caltech.edu (Nathaniel Gray) Date: Fri, 03 Nov 2006 16:18:59 -0800 Subject: [Mailman-Developers] Crypto-sign to post Message-ID: <454BDC73.8000508@caltech.edu> Hi Mailmen & Mailwomen, I'm an open-source butterfly, flitting from project to project. I ask questions here, contribute patches there, and report bugs elsewhere. As you can probably imagine, subscribe-to-post seriously annoys me. I can't tell you how many times I've done the "subscribe, disable delivery, ask for CC on replies" mambo, and it's getting to the point where I just won't bother unless I've got a serious issue. The thing is, I don't blame the list maintainers for enabling subscribe-to-post -- it's just the only easily accessible solution to the spam crisis at this point -- but I would really like to see them have a better option. Since Mailman has already taken over the world you guys are in a great position to give it to them! I brought this up on the Cairo mailing list recently and Carl Worth brought up the idea of a simple option to accept any post that's cryptographically signed, regardless of subscriber status. I liked this idea for several reasons. 1. I've never seen signed spam 2. Most mail programs have some way to sign mails 2. When spammers do start signing spam it allows a straightforward transition to a real web-of-trust style model. After a bit of searching I found RFE 893870 , which seems to have been dismissed on a technicality. Are there serious technical or philosophical problems with the idea, or is this just a matter of finding somebody with the time and talent to do an implementation? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From barry at python.org Sat Nov 4 19:32:13 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 4 Nov 2006 13:32:13 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <454BDC73.8000508@caltech.edu> References: <454BDC73.8000508@caltech.edu> Message-ID: <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 3, 2006, at 7:18 PM, Nathaniel Gray wrote: > As > you can probably imagine, subscribe-to-post seriously annoys me. I > can't tell you how many times I've done the "subscribe, disable > delivery, ask for CC on replies" mambo, and it's getting to the point > where I just won't bother unless I've got a serious issue. I'm with you. > I brought this up on the Cairo mailing list recently > 008345.html> > and Carl Worth brought up the idea of a simple option to accept any > post > that's cryptographically signed, regardless of subscriber status. I > liked this idea for several reasons. > > 1. I've never seen signed spam > 2. Most mail programs have some way to sign mails > 2. When spammers do start signing spam it allows a straightforward > transition to a real web-of-trust style model. > > After a bit of searching I found RFE 893870 > func=detail&atid=350103&aid=893870&group_id=103>, > which seems to have been dismissed on a technicality. Are there > serious > technical or philosophical problems with the idea, or is this just a > matter of finding somebody with the time and talent to do an > implementation? Given that this could be a posting option that list admins could choose or not, I'm all for it. I'd like to augment the "who can post to this list" options with at least one other workflow: self- verification. IOW, even if you're not a member of the list, you would get a confirmation message, which when replied to would enable your posts to the list, without you having to subscribe. This is clearly a Mailman 2.2 feature though, so if you decide to whip something up, please do so against the trunk. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRUzcsnEjvBPtnXfVAQLQbAQAiDZi0bkxiwysgnWYwZkobn+6K7961ssz yJ/Vu+QPeipBDSToqOw00htXErpUv+XwPW5NIE/VZyi4HHdJ0IRVuNBm34nxtuqG vSBaBHNdQ+IelrjykuDKlcnJpNRt1gyIQvsT+jhuQAtM8L3K2H6s+fYxU0ssRI1M AOKxK6IKueg= =kTI3 -----END PGP SIGNATURE----- From n8gray at caltech.edu Sun Nov 5 01:43:30 2006 From: n8gray at caltech.edu (Nathaniel Gray) Date: Sat, 04 Nov 2006 16:43:30 -0800 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> Message-ID: <454D33B2.9000005@caltech.edu> Barry Warsaw wrote: > On Nov 3, 2006, at 7:18 PM, Nathaniel Gray wrote: > >> As >> you can probably imagine, subscribe-to-post seriously annoys me. I >> can't tell you how many times I've done the "subscribe, disable >> delivery, ask for CC on replies" mambo, and it's getting to the point >> where I just won't bother unless I've got a serious issue. > > I'm with you. Glad to hear it! >> I brought this up on the Cairo mailing list recently >> >> and Carl Worth brought up the idea of a simple option to accept any post >> that's cryptographically signed, regardless of subscriber status. I >> liked this idea for several reasons. >> >> 1. I've never seen signed spam >> 2. Most mail programs have some way to sign mails >> 2. When spammers do start signing spam it allows a straightforward >> transition to a real web-of-trust style model. >> >> After a bit of searching I found RFE 893870 >> , >> >> which seems to have been dismissed on a technicality. Are there serious >> technical or philosophical problems with the idea, or is this just a >> matter of finding somebody with the time and talent to do an >> implementation? > > Given that this could be a posting option that list admins could choose > or not, I'm all for it. I'd like to augment the "who can post to this > list" options with at least one other workflow: self-verification. IOW, > even if you're not a member of the list, you would get a confirmation > message, which when replied to would enable your posts to the list, > without you having to subscribe. That would help as well. It would also be nice if Mailman would auto-CC replies to the sender if they aren't subscribed. > This is clearly a Mailman 2.2 feature though, so if you decide to whip > something up, please do so against the trunk. Sadly, I don't think I can volunteer for this. I don't think it would be too tough to implement for somebody with the proper expertise but I don't have any serious experience with either mail, crypto, or the Mailman code base. My hope is that somebody on this list does and perhaps understands the improvement this feature could offer. At the very least I'm happy to hear that you're thinking about the subcribe-to-post problem. Thanks, -Nathan -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From huston at astro.princeton.edu Sun Nov 5 19:04:44 2006 From: huston at astro.princeton.edu (Steve Huston) Date: Sun, 05 Nov 2006 13:04:44 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> Message-ID: <454E27BC.3020009@astro.princeton.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/06 1:32 PM, Barry Warsaw wrote: > Given that this could be a posting option that list admins could > choose or not, I'm all for it. I'd like to add my $.02 as well. I think this would be a great feature, and since admins could choose to use it or not I think it might be helpful to have it on by default. But since many list readers (and possibly owners) might not understand exactly how it works, here's my thought. Have it turned on by default, but when Mailman sends out the message it adds a header to the mail; as Nathan later suggested, having it automatically set the "Reply-To" to include the sender so they get copies of replies would be good - better would be for Mailman to do it automagically, but that would require a bit more work to keep track of who submitted what mail, etc (things which MM isn't currently stateful enough to track, though I don't know what other 2.2 plans are in the works). The other would be a "header" in the body of the message, perhaps something like: [This sender is not subscribed to the list, but their email is being sent through because it is cryptographically signed - replies to the email should be CC'd to the original sender] Having it on by default might be seen as a "back door" to some, but off by default means people would have to see the benefits of turning it on before they'd do so. Since signed mails are likely to only be done by people who know what they're doing, and I'll guess are also less likely to be the type to post nonsense to mailing lists only to add to clutter, I'd think it would be safe to leave on. And by having the header there, it would probably alleviate those readers/admins that would wonder, "How the hell did they post on here when they're not subscribed..." - -- Steve Huston - W2SRH - Unix Sysadmin, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTie8CCKCCLIg8RMRAoUgAJ9Lhu7V3rH8j5ayIhoMoPEd24H8AwCeJnyN 0aRAWpvuhzu1wP8jezEBLXk= =lc5i -----END PGP SIGNATURE----- From bob at nleaudio.com Sun Nov 5 22:37:35 2006 From: bob at nleaudio.com (Bob Puff) Date: Sun, 5 Nov 2006 16:37:35 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <454E27BC.3020009@astro.princeton.edu> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> <454E27BC.3020009@astro.princeton.edu> Message-ID: <20061105213448.M19172@nleaudio.com> I think Barry's idea that non-subscribers could ack their own messages is excellent. I'm not sure that simply having a signed message enter the system is a good thing to default to being on though... In fact, I can think of a few lists wherein that behaviour would be disasterous, and if it were defaulted to ON and was a new feature that the admins weren't aware of, some stuff would definitely hit the fan. Bob ---------- Original Message ----------- From: Steve Huston To: mailman-developers at python.org Sent: Sun, 05 Nov 2006 13:04:44 -0500 Subject: Re: [Mailman-Developers] Crypto-sign to post > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/4/06 1:32 PM, Barry Warsaw wrote: > > Given that this could be a posting option that list admins could > > choose or not, I'm all for it. > > I'd like to add my $.02 as well. I think this would be a great > feature, and since admins could choose to use it or not I think it > might be helpful to have it on by default. But since many list > readers (and possibly owners) might not understand exactly how it > works, here's my thought. > > Have it turned on by default, but when Mailman sends out the message > it adds a header to the mail; as Nathan later suggested, having it > automatically set the "Reply-To" to include the sender so they get > copies of replies would be good - better would be for Mailman to do > it automagically, but that would require a bit more work to keep > track of who submitted what mail, etc (things which MM isn't > currently stateful enough to track, though I don't know what other > 2.2 plans are in the works). The other would be a "header" in the > body of the message, perhaps something like: > > [This sender is not subscribed to the list, but their email is being > sent through because it is cryptographically signed - replies to the > email should be CC'd to the original sender] > > Having it on by default might be seen as a "back door" to some, but off > by default means people would have to see the benefits of turning it > on before they'd do so. Since signed mails are likely to only be > done by people who know what they're doing, and I'll guess are also > less likely to be the type to post nonsense to mailing lists only to > add to clutter, I'd think it would be safe to leave on. And by > having the header there, it would probably alleviate those > readers/admins that would wonder, "How the hell did they post on > here when they're not subscribed..." > > - -- > Steve Huston - W2SRH - Unix Sysadmin, Dept. of Astrophysical Sciences > Princeton University | ICBM Address: 40.346525 -74.651285 > 126 Peyton Hall |"On my ship, the Rocinante, wheeling through > Princeton, NJ 08544 | the galaxies; headed for the heart of > Cygnus, > (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1' > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFTie8CCKCCLIg8RMRAoUgAJ9Lhu7V3rH8j5ayIhoMoPEd24H8AwCeJnyN > 0aRAWpvuhzu1wP8jezEBLXk= > =lc5i > -----END PGP SIGNATURE----- > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ------- End of Original Message ------- From lionel at mamane.lu Mon Nov 6 07:39:49 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Mon, 6 Nov 2006 07:39:49 +0100 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <454BDC73.8000508@caltech.edu> References: <454BDC73.8000508@caltech.edu> Message-ID: <20061106063949.GA3001@capsaicin.mamane.lu> On Fri, Nov 03, 2006 at 04:18:59PM -0800, Nathaniel Gray wrote: > I can't tell you how many times I've done the "subscribe, disable > delivery, ask for CC on replies" mambo, and it's getting to the > point where I just won't bother unless I've got a serious issue. > The thing is, I don't blame the list maintainers for enabling > subscribe-to-post -- it's just the only easily accessible solution > to the spam crisis at this point -- > Carl Worth brought up the idea of a simple option to accept any post > that's cryptographically signed, regardless of subscriber status. I > liked this idea for several reasons. > 1. I've never seen signed spam > 2. Most mail programs have some way to sign mails > 2. When spammers do start signing spam it allows a straightforward > transition to a real web-of-trust style model. You may want to have a look at http://www.non-gnu.uvt.nl/mailman-ssls/ If it cannot do it already, at least it brings a GnuPG-integration framework that will make it less work to implement what you want. -- Lionel From iane at sussex.ac.uk Mon Nov 6 12:59:49 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 06 Nov 2006 11:59:49 +0000 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> Message-ID: --On 4 November 2006 13:32:13 -0500 Barry Warsaw wrote: > > Given that this could be a posting option that list admins could > choose or not, I'm all for it. I'd like to augment the "who can post > to this list" options with at least one other workflow: self- > verification. IOW, even if you're not a member of the list, you > would get a confirmation message, which when replied to would enable > your posts to the list, without you having to subscribe. > > This is clearly a Mailman 2.2 feature though, so if you decide to > whip something up, please do so against the trunk. > > - -Barry This can be useful if enabled for specific domains - for example, we'd use it for our own domain. However, if you blindly respond to spam with confirmation messages, you'll be generating collateral spam. That'll already get you blacklisted with spamcop. So, I'm in favour if it's implemented carefully. -- Ian Eiloart IT Services, University of Sussex From anne.ramey at ncmail.net Mon Nov 6 18:35:02 2006 From: anne.ramey at ncmail.net (Anne Ramey) Date: Mon, 06 Nov 2006 12:35:02 -0500 Subject: [Mailman-Developers] LDAP auth Message-ID: <454F7246.8090908@ncmail.net> Forgive me if this has already been discussed, but I couldn't find it in the archives. I'm interested in replacing the logon screen for the list with one that asks for the email address and password for the user, checks if they are an owner or moderator, then if so, checks to see if they can bind successfully to the given ldap, and if so, logs them in with their owner or moderator permissions. Has anyone implemented or worked on anything like this? -- Anne From barry at python.org Mon Nov 6 19:46:33 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 6 Nov 2006 13:46:33 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <454E27BC.3020009@astro.princeton.edu> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> <454E27BC.3020009@astro.princeton.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 5, 2006, at 1:04 PM, Steve Huston wrote: > Having it on by default might be seen as a "back door" to some, but > off > by default means people would have to see the benefits of turning > it on > before they'd do so. Since signed mails are likely to only be done by > people who know what they're doing, and I'll guess are also less > likely > to be the type to post nonsense to mailing lists only to add to > clutter, > I'd think it would be safe to leave on. And by having the header > there, > it would probably alleviate those readers/admins that would wonder, > "How > the hell did they post on here when they're not subscribed..." OTOH, you could argue that any list where a significant population of non-subscribers would be expected to post signed messages would be tech-savvy enough to have an admin that could enable the feature. My initial gut feeling is that it should be disabled by default, but I am planning on implementing 'list styles' for 2.2 so it should be easy to set that once and have all your new lists automatically pick that up (I'm not planning on letting styles change existing lists). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRU+DD3EjvBPtnXfVAQLHoAP6A9N89zoScMuwZErdz4tc3RSrT4K46TLG iSd+i4SE4QXzMKSRamPRyg6iagnGHdpbOZZ+7jft/W369tj2iCH7xcweYsUN+4Hc EC7YUZ+FQOlOaC505XBLGVgsN72lOvwMht8RllbrQGXPF6ZfKcMTkuQLxu1LAco2 JZh2rbkLvIs= =CGN3 -----END PGP SIGNATURE----- From barry at python.org Mon Nov 6 19:49:15 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 6 Nov 2006 13:49:15 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2006, at 6:59 AM, Ian Eiloart wrote: > This can be useful if enabled for specific domains - for example, > we'd use > it for our own domain. However, if you blindly respond to spam with > confirmation messages, you'll be generating collateral spam. That'll > already get you blacklisted with spamcop. So, I'm in favour if it's > implemented carefully. This is a much more general problem with replybots. Mailman already tries to be very careful about when and how it auto-responds to unsolicited queries. We're probably not doing the best job we can here, so my plan is to build in a more general "governor" subsystem and route all autoresponses through that. I agree that we need to be very very careful about the balance between helpfulness and spamminess. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRU+DrHEjvBPtnXfVAQLswwQAh1FIRetkBya1LqNvro+99+5a0e4L2v/l ZN3Jwkg+XaJ6cB1jxrdcvtaRHTJAt0wbxYFg8S+drkMGHhn+5+8peQ1aWGAdhOVX NKt3nCXY3wpTCAgBSqGgCbgozV+AB6rfmUiPaCeyk4ehAP+jrBgEHmgJZbGj3ECt QSvCvHdKw1U= =yAiE -----END PGP SIGNATURE----- From stephen at xemacs.org Tue Nov 7 04:40:56 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Tue, 07 Nov 2006 12:40:56 +0900 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> Message-ID: <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> Ian Eiloart writes: > This can be useful if enabled for specific domains - for example, we'd use > it for our own domain. However, if you blindly respond to spam with > confirmation messages, you'll be generating collateral spam. That'll > already get you blacklisted with spamcop. What "blindly"? As far as I can tell, any autoreponse to spam puts you at risk from spamcop, no matter how much care you put into inbound filtering. From wilder at eskimo.com Tue Nov 7 06:43:18 2006 From: wilder at eskimo.com (Dan Wilder) Date: Mon, 6 Nov 2006 21:43:18 -0800 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20061107054318.GA28211@eskimo.com> On Tue, Nov 07, 2006 at 12:40:56PM +0900, stephen at xemacs.org wrote: > What "blindly"? As far as I can tell, any autoreponse to spam puts > you at risk from spamcop, no matter how much care you put into inbound > filtering. As does operating any mailing list or website. From my personal experience. -- Dan Wilder From iane at sussex.ac.uk Tue Nov 7 16:46:45 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 07 Nov 2006 15:46:45 +0000 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: --On 7 November 2006 12:40:56 +0900 stephen at xemacs.org wrote: > Ian Eiloart writes: > > > This can be useful if enabled for specific domains - for example, we'd > use > it for our own domain. However, if you blindly respond to spam > with > confirmation messages, you'll be generating collateral spam. > That'll > already get you blacklisted with spamcop. > > What "blindly"? As far as I can tell, any autoreponse to spam puts > you at risk from spamcop, no matter how much care you put into inbound > filtering. > "blindly respond to spam" - respond to email without knowing whether it's spam. "blindly walk off a cliff" - take a step forward without knowing the ground level ahead. -- Ian Eiloart IT Services, University of Sussex From stephen at xemacs.org Tue Nov 7 19:53:38 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Wed, 08 Nov 2006 03:53:38 +0900 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <58121975-F626-4D62-AFE6-1EE4577E7B47@python.org> <87fycvdiuv.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87ac33cclp.fsf@uwakimon.sk.tsukuba.ac.jp> Ian Eiloart writes: > "blindly respond to spam" - respond to email without knowing > whether it's spam. Since I specified "careful filtering", I guess what you're saying is that all mail one wishes to reply to must be read by the responsible human (unless the replybot is owned by the recipient's boss, and therefore by definition is not spam for the recipient)? I thought the whole point of Mailman was to avoid that. That's certainly why my project uses Mailman! From stefan.schlott at ulm.ccc.de Thu Nov 9 11:54:38 2006 From: stefan.schlott at ulm.ccc.de (Stefan Schlott) Date: Thu, 09 Nov 2006 11:54:38 +0100 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <454BDC73.8000508@caltech.edu> References: <454BDC73.8000508@caltech.edu> Message-ID: <455308EE.804@ulm.ccc.de> Re-hi, > I brought this up on the Cairo mailing list recently > > and Carl Worth brought up the idea of a simple option to accept any post > that's cryptographically signed, regardless of subscriber status. I > liked this idea for several reasons. > > 1. I've never seen signed spam > 2. Most mail programs have some way to sign mails > 2. When spammers do start signing spam it allows a straightforward > transition to a real web-of-trust style model. I already received some spam messages including GPG markings. They were fake, of course; they were used to fool simple scoring systems (e.g. if message contains "BEGIN PGP SIGNED MESSAGE", it is most likely no spam). As you mentioned, signing of a message is easy; so it is easy to sign a spam message, too. The problem is: Which key is used to sign the message, and how do you determine whether a key belongs to a spammer or to an ordinary user? The signature alone does not solve your problem. The (only?) way to tell the mailing list that your key is to be trusted is the same procedure as usual: Register before post. The advantage you'll gain by verifying signatures is independence of the sender's address: - Sender spoofing becomes impossible (the signature cannot be forged) - No more hassle with different mail accounts (as long as the signature verifies, the ml will deliver the mail regardless of the sender's address) Follow-up problem (or implementation detail, call it as you like it): Message freshness and partially signed messages. A spammer could capture a signed mail and repost it to a list; the spam message could be inserted at an unsigned part. If the list checks if some part is signed, the spam will be delivered; if the list verifies that the whole message is signed, you might have a lot of trouble with users using a buggy mail client. Another possible problem: Verifying a cryptographic signature is a rather "expensive" operations (in terms of CPU time), on a high traffic server this will have a severe impact. Please don't get me wrong: I think using signatures (and probably encryption, too) is a good idea - I'm just pointing out thoughts we made up when trying to hack gpg and/or s/mime support into mailman. In course of that project, we tried to implement a "post if signature verifies", too. If you want to have a look at it, see: http://non-gnu.uvt.nl/mailman-ssls/ My initial efforts for an encrypted mailing list are at: http://stefan.ploing.de/linux/gpg-mailman Stefan. From huston at astro.princeton.edu Thu Nov 9 16:25:07 2006 From: huston at astro.princeton.edu (Steve Huston) Date: Thu, 09 Nov 2006 10:25:07 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <455308EE.804@ulm.ccc.de> References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> Message-ID: <45534853.3020204@astro.princeton.edu> On 11/9/06 5:54 AM, Stefan Schlott wrote: > As you mentioned, signing of a message is easy; so it is easy to sign a spam > message, too. The problem is: Which key is used to sign the message, and how > do you determine whether a key belongs to a spammer or to an ordinary user? > The signature alone does not solve your problem. This would be for a project other than Mailman, however there already exists various blacklists and such which MTAs can use to determine if a host is likely to be a spammer. Likewise, I'm sure it wouldn't take very much to setup a daemon that contains a list of "known spammy keys", and populate ones GPG keyring with those keys and flagged as untrusted. Then it would be a matter of allowing any signed mail from a non-untrusted key (so either trusted, or unknown). -- Steve Huston - W2SRH - Unix Sysadmin, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1' From jwblist3 at olympus.net Fri Nov 10 01:25:10 2006 From: jwblist3 at olympus.net (John W. Baxter) Date: Thu, 09 Nov 2006 16:25:10 -0800 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <455308EE.804@ulm.ccc.de> Message-ID: On 11/9/06 2:54 AM, "Stefan Schlott" wrote: > Another possible problem: And yet another problem: the proliferation of different ways to create signed messages, and recognizing them successfully. I could sign messages at least three ways just using Apple's Mail.app: GPG with a suitable plug-in (what I do) in SMIME form BEGIN SIGNED MESSAGE form Whatever is native to Mail.app (involves getting a [free] personal certificate from Thawte, and putting it into the keychain. Signing is automatic at that point). I don't know what format that produces--I've been meaning to find out. (No, you won't find me on the public key servers--we use this inhouse only.) I think all traces of the signature need to be stripped after it is used for verification (but I could be wrong). All that (and the other problems cited in this thread) aside, I advocated this idea about 5 years ago, and still favor it. --John From stephen at xemacs.org Fri Nov 10 02:53:18 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Fri, 10 Nov 2006 10:53:18 +0900 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <455308EE.804@ulm.ccc.de> Message-ID: <87mz70kqy9.fsf@uwakimon.sk.tsukuba.ac.jp> John W. Baxter writes: > I think all traces of the signature need to be stripped after it is used for > verification (but I could be wrong). This should be an option or at least there should be an easy way to work around it; suppose the message is something like a collection of checksums for a distro, or a signed patch for projects that use such things? However, for general purposes I think that stripping the signature would be a good idea. Specifically, I would imagine that even if you sign "the whole message", this still leaves room for spammish use of the preamble and trailer (or even the Subject header), while the signed body of the message is used in a replay attack. From barry at python.org Sun Nov 12 03:08:12 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 11 Nov 2006 21:08:12 -0500 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman In-Reply-To: References: Message-ID: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 8, 2006, at 8:14 PM, tkikuchi at users.sourceforge.net wrote: > Revision: 8090 > http://svn.sourceforge.net/mailman/?rev=8090&view=rev > Author: tkikuchi > Date: 2006-11-08 17:13:59 -0800 (Wed, 08 Nov 2006) > > Log Message: > ----------- > MailList.py ... GetScriptURL() absolute again because we need it > for email > notifications. > wsgi_app.py ... URI normalization by stripping trailing slash. We > need > Special care for 'private'. > Strip dot only components in the PATH_INFO for sanitization. Hi Tokio, I'm not so sure about this change. It breaks the ability to access the web page urls by both the wsgi path and the apache ScriptAlias path at the same time. I've tried to make sure that worked because it's pretty useful for debugging. I'm trying to keep the principle that all internal web page urls are relative, which is why we currently try to figure out the prefix to the script and then reproduce that in the cookie path (see SecurityManager.py). I've also been thinking about trying to get rid of mlist.web_page_url (I don't much like hard coding that in the list's data). I understand that we'll need absolute paths in the email notifications, and I've read the note about not exposing wsgi_app interface to the internet. I'm not sure I agree with the latter though, and besides, I'd like us to be as flexible as possible for wsgi integration. I think we should try to find some other way to do the email notification urls and keep GetScriptURL() returning relative paths. E.g. when I try to use r8090 via the Apache ScriptAlias path, I end up getting three slashes between the host and the 'mailman' prefix. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVaCEXEjvBPtnXfVAQIOIQP8DTdlILSlUli9+WgSdskfl2+i44ON3gvx 0uoEZZ1lPon6NgJFg5Y3BCAr7YLAXsrj4pyXrhAxxLomgnjt6eM9BKdIWkSmZMl9 smQ/En31Xs5tKd69jtekaiMNMy4kMx0Yo53ci0E7yp6tVkpIh05Vg0wAB/wQr71Y 6etMJUeeJ78= =gFtd -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Sun Nov 12 03:38:56 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 12 Nov 2006 11:38:56 +0900 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman In-Reply-To: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> References: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> Message-ID: <45568940.9010201@is.kochi-u.ac.jp> > Hi Tokio, > > I'm not so sure about this change. It breaks the ability to access > the web page urls by both the wsgi path and the apache ScriptAlias > path at the same time. I've tried to make sure that worked because > it's pretty useful for debugging. Well, I was inclined to abolish ScriptAlias (CGI) method because of SGUI complexities. ;-) > > I'm trying to keep the principle that all internal web page urls are > relative, which is why we currently try to figure out the prefix to > the script and then reproduce that in the cookie path (see > SecurityManager.py). I've also been thinking about trying to get rid > of mlist.web_page_url (I don't much like hard coding that in the > list's data). > > I understand that we'll need absolute paths in the email > notifications, and I've read the note about not exposing wsgi_app > interface to the internet. I'm not sure I agree with the latter > though, and besides, I'd like us to be as flexible as possible for > wsgi integration. I think we should try to find some other way to do > the email notification urls and keep GetScriptURL() returning > relative paths. > Like VirtualHostMonster in Zope? > E.g. when I try to use r8090 via the Apache ScriptAlias path, I end > up getting three slashes between the host and the 'mailman' prefix. Oops, I'll try restore ScriptAlias. > > - -Barry -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Sun Nov 12 03:54:28 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 11 Nov 2006 21:54:28 -0500 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman In-Reply-To: <45568940.9010201@is.kochi-u.ac.jp> References: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> <45568940.9010201@is.kochi-u.ac.jp> Message-ID: <8A17B4D8-6AE2-41B7-B71C-9C2BAB8E0362@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 11, 2006, at 9:38 PM, Tokio Kikuchi wrote: >> I'm not so sure about this change. It breaks the ability to access >> the web page urls by both the wsgi path and the apache ScriptAlias >> path at the same time. I've tried to make sure that worked because >> it's pretty useful for debugging. > > Well, I was inclined to abolish ScriptAlias (CGI) method because of > SGUI > complexities. ;-) That's definitely another way to go. OTOH, it's possible that folks will reverse proxy MM2.2 through the /mailman/ prefix, or possibly a totally different prefix, so I think we still need to support relative urls as much as possible. But you might be right that it's unreasonable to continue to support CGI now that we have a better way to do it. >> I understand that we'll need absolute paths in the email >> notifications, and I've read the note about not exposing wsgi_app >> interface to the internet. I'm not sure I agree with the latter >> though, and besides, I'd like us to be as flexible as possible for >> wsgi integration. I think we should try to find some other way to do >> the email notification urls and keep GetScriptURL() returning >> relative paths. >> > Like VirtualHostMonster in Zope? Possibly something like it -- which I think ultimately boils down to encoding enough of the original url in a rewrite rule so that the back-end Mailman in this case can figure out how the front-end was accessed. The only other alternative would be to hard code it in the config file I guess. >> E.g. when I try to use r8090 via the Apache ScriptAlias path, I end >> up getting three slashes between the host and the 'mailman' prefix. > > Oops, I'll try restore ScriptAlias. Cool, thanks. I may commit a few changes in this area, but I'll try not to mess you up too much ;). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVaM5XEjvBPtnXfVAQKiDwP/XxPA/yi9MG+uewogi+pOH22U2L5iwBgq WK9ZFsZxgLMxx3w11oHFemSVyzujqi+WMudqjahRzb7w4V8Chl1IxwUHf98F4zg/ rCZnSWfT3nfnTp02Pa9kC9DVTfLe1X/r9XjDnD+W7id2wQ7OrwGZ2VOa2n0Rdfqp tpniGsxaYj4= =NZu5 -----END PGP SIGNATURE----- From barry at python.org Sun Nov 12 05:03:52 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 11 Nov 2006 23:03:52 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <455308EE.804@ulm.ccc.de> References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 9, 2006, at 5:54 AM, Stefan Schlott wrote: > I already received some spam messages including GPG markings. They > were fake, > of course; they were used to fool simple scoring systems (e.g. if > message > contains "BEGIN PGP SIGNED MESSAGE", it is most likely no spam). > > As you mentioned, signing of a message is easy; so it is easy to > sign a spam > message, too. The problem is: Which key is used to sign the > message, and how > do you determine whether a key belongs to a spammer or to an > ordinary user? > The signature alone does not solve your problem. I suppose you could also have each mailing list publish a pubkey and require that messages be encrypted with that pubkey in order to get posted. Of course that increases the cycles involved on both ends, but it allows you to accept messages without requiring the registration of each sender's key. Sure, spammers could use the same key to sign spam, but I wonder if that wouldn't be more work than is worthwhile for a botnet. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVadKHEjvBPtnXfVAQKeXAP/fvdpKqWbXWBubOkpzexyHQXha3EcJBlT xfV2BKmJkc0cPXiyXgG+V1kKtg3kp+6/tCqRQDXjmAgjjvGZEuB5cWi+ebmqMfcW ETC4Ma246yuYZNq/yoMu8+o7NlXaIlPQrqSZhzG5rV97BQ8gSa20BxJ+uQNufs4D /KTeGdA6C9s= =J1L6 -----END PGP SIGNATURE----- From huston at astro.princeton.edu Sun Nov 12 19:38:10 2006 From: huston at astro.princeton.edu (Steve Huston) Date: Sun, 12 Nov 2006 13:38:10 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> Message-ID: <45576A12.5030505@astro.princeton.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/06 11:03 PM, Barry Warsaw wrote: > I suppose you could also have each mailing list publish a pubkey and > require that messages be encrypted with that pubkey in order to get > posted. Of course that increases the cycles involved on both ends, > but it allows you to accept messages without requiring the > registration of each sender's key. Sure, spammers could use the same > key to sign spam, but I wonder if that wouldn't be more work than is > worthwhile for a botnet. Now there's something which I'm sure it's a small subset of people would be interested in, but it would definitely be nice.. the ability to run an entirely encrypted mailing list. You encrypt your message to the "list key", and Mailman decrypts it, inserts some bit in the message about the original signing key, and encrypts it to each recipient. Subscribers would have to either submit a key to Mailman, or at least a key ID which could be retrieved from a keyserver. With verp I would think that encrypting to individuals would be slightly simpler - but again, a lot of CPU cycles to make it work. And I'm not sure how many lists would take advantage of it. Would also make archiving an interesting proposition... Sorry; thinking aloud again :> - -- Steve Huston - W2SRH - Unix Sysadmin, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFV2oSCCKCCLIg8RMRAgCcAKDt8BY24u6lda2PtC0+jdxRNiqfcwCbB4dX +bj5fzpqp1sx5UbUnzrSUvg= =im3W -----END PGP SIGNATURE----- From stephen at xemacs.org Mon Nov 13 08:55:01 2006 From: stephen at xemacs.org (stephen at xemacs.org) Date: Mon, 13 Nov 2006 16:55:01 +0900 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> Message-ID: <87mz6v4w8a.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > I suppose you could also have each mailing list publish a pubkey and > require that messages be encrypted with that pubkey in order to get > posted. Hey, that's great, we can update RFC 2369 with a List-Pubkey header! I bet Gmane learns to use it within a week after proposal! > Sure, spammers could use the same key to sign spam, but I wonder if > that wouldn't be more work than is worthwhile for a botnet. Don't bet on it. As Brad points out, a botnet has effectively unbounded resources per message. If this becomes a standard feature of any software as widely distributed as Mailman, some spammer will decide to exploit it, and there goes the neighborhood. From stefan.schlott at ulm.ccc.de Mon Nov 13 09:45:51 2006 From: stefan.schlott at ulm.ccc.de (Stefan Schlott) Date: Mon, 13 Nov 2006 09:45:51 +0100 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <45576A12.5030505@astro.princeton.edu> References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> <45576A12.5030505@astro.princeton.edu> Message-ID: <455830BF.30500@ulm.ccc.de> Hi, >>> I suppose you could also have each mailing list publish a pubkey and >>> require that messages be encrypted with that pubkey in order to get >>> posted. > Now there's something which I'm sure it's a small subset of people would > be interested in, but it would definitely be nice.. the ability to run > an entirely encrypted mailing list. This is exactly what my gpg-mailman hack does :-) Joost started with "authentication by signature" and s/mime, I wanted an gpg-encrypted mailinglist. Joost tried to merge both patches, the result is available as a darcs repository. > think that encrypting to individuals would be slightly simpler - but > again, a lot of CPU cycles to make it work. And I'm not sure how many > lists would take advantage of it. If you want to do it properly witch out-of-the-box software (like gpg or s/mime), you have to create an individually encrypted mail for each recipient. Up to now, mailman was concerned with the number of "sendmail jobs" - mailman sends mails in "chunks" with a certain number of recipients and lets the mailserver multiply the mail on delivery. With public key encryption, this is no longer possible; but this wouldn't matter since the public key operations are horribly expensive (in terms of CPU cycles) - it would hardly make a difference :-) For low traffic lists or lists with only a few members, public key encrpytion can be done without killing the ml server. For large lists, I doubt that this would work. Using specialized software, it would be possible, but special software for an encrypted list would bring the acceptance rate close to 0% :-( > Would also make archiving an interesting proposition... Store the decrypted mails, allow https access only, require authentication by ml members - that would do it in most cases. If you have special requirements (e.g. members may only access the time interval of their own membership) would require special software, though. Stefan. From iane at sussex.ac.uk Mon Nov 13 10:55:40 2006 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 13 Nov 2006 09:55:40 +0000 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> Message-ID: --On 11 November 2006 23:03:52 -0500 Barry Warsaw wrote: > > I suppose you could also have each mailing list publish a pubkey and > require that messages be encrypted with that pubkey in order to get > posted. Of course that increases the cycles involved on both ends, > but it allows you to accept messages without requiring the > registration of each sender's key. Sure, spammers could use the same > key to sign spam, but I wonder if that wouldn't be more work than is > worthwhile for a botnet. > > - -Barry Wouldn't it be easier just to join the list? -- Ian Eiloart IT Services, University of Sussex From tkikuchi at is.kochi-u.ac.jp Mon Nov 13 13:53:52 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 13 Nov 2006 21:53:52 +0900 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman In-Reply-To: <8A17B4D8-6AE2-41B7-B71C-9C2BAB8E0362@python.org> References: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> <45568940.9010201@is.kochi-u.ac.jp> <8A17B4D8-6AE2-41B7-B71C-9C2BAB8E0362@python.org> Message-ID: <45586AE0.7000902@is.kochi-u.ac.jp> Hi Barry, > >>> E.g. when I try to use r8090 via the Apache ScriptAlias path, I end >>> up getting three slashes between the host and the 'mailman' prefix. >> Oops, I'll try restore ScriptAlias. > > Cool, thanks. I may commit a few changes in this area, but I'll try > not to mess you up too much ;). I was wrong in writing wsgi_app.py at SCRIPT_NAME CGI environment variable. It was not merely the name of the script but the script path. Now the script can be accessed by /listinfo, /mailman/listinfo, or even /mailman/blah/listinfo etc. etc. You can now write httpd.conf like so: ProxyPass /mailman/ http://localhost:2580/mailman/ By this, we can use the same SCRIPT_NAME (or script path) for both wsgi backend and apache frontend. We might be able to get rid of the HTTP_REFERER and '../' things from our code but I've only checked in thus far. Please check and test it. -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Mon Nov 13 14:02:01 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 13 Nov 2006 08:02:01 -0500 Subject: [Mailman-Developers] Crypto-sign to post In-Reply-To: <87mz6v4w8a.fsf@uwakimon.sk.tsukuba.ac.jp> References: <454BDC73.8000508@caltech.edu> <455308EE.804@ulm.ccc.de> <87mz6v4w8a.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 13, 2006, at 2:55 AM, stephen at xemacs.org wrote: > Barry Warsaw writes: > >> I suppose you could also have each mailing list publish a pubkey and >> require that messages be encrypted with that pubkey in order to get >> posted. > > Hey, that's great, we can update RFC 2369 with a List-Pubkey header! > I bet Gmane learns to use it within a week after proposal! :) >> Sure, spammers could use the same key to sign spam, but I wonder if >> that wouldn't be more work than is worthwhile for a botnet. > > Don't bet on it. As Brad points out, a botnet has effectively > unbounded resources per message. If this becomes a standard feature > of any software as widely distributed as Mailman, some spammer will > decide to exploit it, and there goes the neighborhood. Sure, but then they've also got to distribute all the pubkeys for all the lists they want to spam to all the bots. Yeah, you're probably right that we're doomed anyway, at least until forced upgrades to Real OSes for all pwned machines are mandated under threat of UN muscle. - -B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVhs1HEjvBPtnXfVAQIqfgP/SCZTN3C18ksCZsJzcJVqPIKQ6OlkKtNG XEaB1YQUd7mAlTlbPFkaOGmJTL3l4rZuqvfbraI849cO7J4WTXKLuxBXbtVBAxi9 jCP1JCH1DtIUH8JCEe/+f8QKMS5c+iik8MBH8C+aIL7+f5iE9PhkIRwWVFUBbk7p O/LSW3Q/Gys= =eFjI -----END PGP SIGNATURE----- From lennon at reed.edu Wed Nov 15 18:07:59 2006 From: lennon at reed.edu (Lennon Day-Reynolds) Date: Wed, 15 Nov 2006 09:07:59 -0800 Subject: [Mailman-Developers] LDAP auth In-Reply-To: <454F7246.8090908@ncmail.net> References: <454F7246.8090908@ncmail.net> Message-ID: <84ABC92B-2464-4943-8184-F13E02E38549@reed.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2006, at 9:35 AM, Anne Ramey wrote: > Forgive me if this has already been discussed, but I couldn't find > it in > the archives. I'm interested in replacing the logon screen for the > list > with one that asks for the email address and password for the user, > checks if they are an owner or moderator, then if so, checks to see if > they can bind successfully to the given ldap, and if so, logs them in > with their owner or moderator permissions. Has anyone implemented or > worked on anything like this? In general, there is no "official" way to do this sort of centralized authentication. I did some work on our local install of Mailman to allow regular network login for list moderation and administration, but it is dependent on both our Single-Sign-On system (Cosign) and particular LDAP setup. I have spoken with people at a number of other institutions that were interested in similar single-sign-on support for the Mailman web interface, and there has been extensive discussion on the -developers list about making it a part of the Mailman core. However, it's unlikely they will be making any changes that significant until after Mailman 2.2, which is the next planned major release. Basically, the answer right now is "roll your own," though I might be able to dig through our patches and find some starting points if you were going to begin work towards such a goal. Hope that helps, Lennon Day-Reynolds System Support Specialist Reed College -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFW0lyRtirLnfvQskRAuSdAJ4ve7RLG2SjAIdW/jT7FPhCJxOa7gCeKBqM jXvghoSRhwnRbrhvsoa/Qqo= =ee9V -----END PGP SIGNATURE----- From barry at python.org Fri Nov 17 05:49:52 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 16 Nov 2006 23:49:52 -0500 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman In-Reply-To: <45586AE0.7000902@is.kochi-u.ac.jp> References: <91C9C926-0BB3-45CC-95E8-80D33ED0CCE3@python.org> <45568940.9010201@is.kochi-u.ac.jp> <8A17B4D8-6AE2-41B7-B71C-9C2BAB8E0362@python.org> <45586AE0.7000902@is.kochi-u.ac.jp> Message-ID: <79CB634A-C2E1-43BB-B933-D9525D28E14F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 13, 2006, at 7:53 AM, Tokio Kikuchi wrote: > I was wrong in writing wsgi_app.py at SCRIPT_NAME CGI environment > variable. It was not merely the name of the script but the script > path. > > Now the script can be accessed by /listinfo, /mailman/listinfo, or > even > /mailman/blah/listinfo etc. etc. You can now write httpd.conf like > so: > ProxyPass /mailman/ http://localhost:2580/mailman/ > > By this, we can use the same SCRIPT_NAME (or script path) for both > wsgi > backend and apache frontend. We might be able to get rid of the > HTTP_REFERER and '../' things from our code but I've only checked in > thus far. > > Please check and test it. I haven't tested getting rid of HTTP_REFERER either, but what you checked in appears to work great from both wsgi and ScriptAlias. Thanks! - -barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRV0/cHEjvBPtnXfVAQIj2QP/dwES+GVgSqotSlL9ewnfm9IP/tl9QGH2 kbSOFrUVVJTo0MI410xtl0bHyv+ZL5ykZeuVKtRghBtRQPe5eXOEv39fs6AEEQRO /qgdbumJhzkkrY+L00JFKwxi/j5UmdKNYTnECuKKLpKzIL4UTRoN/BOyhh4t/rzN rx8RH/X6+OY= =jlWc -----END PGP SIGNATURE----- From barry at python.org Thu Nov 23 19:34:13 2006 From: barry at python.org (Barry Warsaw) Date: Thu, 23 Nov 2006 13:34:13 -0500 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8100] trunk/mailman/Mailman/MTA/Postfix.py In-Reply-To: References: Message-ID: <0ED25574-BB22-402C-8F06-A8D6DB842CF7@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 23, 2006, at 7:32 AM, tkikuchi at users.sourceforge.net wrote: > Revision: 8100 > http://svn.sourceforge.net/mailman/?rev=8100&view=rev > Author: tkikuchi > Date: 2006-11-23 04:32:56 -0800 (Thu, 23 Nov 2006) > > Log Message: > ----------- > Some cleanups of code. > - if config.USE_LMTP immediately after ALIASFILE add/remove; we need > to keep alias settings because postfix rejects as unknown if > not present. I haven't tried this diff yet, but are you sure that you need the alias settings if you've got a transport_maps setting? I thought that I tested using fully qualified alias names in the transport map and not needing alias file entries unless you wanted site-wide or across-all-domain aliases, e.g. noreply at . I'll have to test this again, but it would be great that if you're using LMTP via transport maps, you don't also need alias file settings. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWXppXEjvBPtnXfVAQKtSQP+LZJj+k/tRGznbOUP93I6ShSgHIbWoyy7 O9Bf6Y8a4gw4ru31MDDfNeYU3/0PRr+LLEqD5oAD1iTNPwojdUOSwOuzNkvAwyZy MIyIkH8LRX/Xj91ye8+JHqdin9ZV3Wh5j0DjXPTM5iBihK7rYrk+7qkyYsgOBm7j Qt9OAUitS0s= =kEaT -----END PGP SIGNATURE----- From tkikuchi at is.kochi-u.ac.jp Fri Nov 24 02:25:28 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 24 Nov 2006 10:25:28 +0900 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8100] trunk/mailman/Mailman/MTA/Postfix.py In-Reply-To: <0ED25574-BB22-402C-8F06-A8D6DB842CF7@python.org> References: <0ED25574-BB22-402C-8F06-A8D6DB842CF7@python.org> Message-ID: <45664A08.9070404@is.kochi-u.ac.jp> >> - if config.USE_LMTP immediately after ALIASFILE add/remove; we need >> to keep alias settings because postfix rejects as unknown if >> not present. > > I haven't tried this diff yet, but are you sure that you need the > alias settings if you've got a transport_maps setting? I thought > that I tested using fully qualified alias names in the transport map > and not needing alias file entries unless you wanted site-wide or > across-all-domain aliases, e.g. noreply at . Well, I'm testing on debian/postfix-2.1.5, which may be old, but the postfix returns 550 if I set up with transport map only. But, additional test on my site revealed that using virtual map resulted in pipe command and not lmtp. :-( I'll test it more on this weekend. -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Sun Nov 26 03:28:58 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 26 Nov 2006 11:28:58 +0900 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8100] trunk/mailman/Mailman/MTA/Postfix.py In-Reply-To: <45664A08.9070404@is.kochi-u.ac.jp> References: <0ED25574-BB22-402C-8F06-A8D6DB842CF7@python.org> <45664A08.9070404@is.kochi-u.ac.jp> Message-ID: <4568FBEA.2070703@is.kochi-u.ac.jp> Hi, After all, you are right, Barry. Tokio Kikuchi wrote: >>> - if config.USE_LMTP immediately after ALIASFILE add/remove; we need >>> to keep alias settings because postfix rejects as unknown if >>> not present. >> I haven't tried this diff yet, but are you sure that you need the >> alias settings if you've got a transport_maps setting? I thought >> that I tested using fully qualified alias names in the transport map >> and not needing alias file entries unless you wanted site-wide or >> across-all-domain aliases, e.g. noreply at . > > Well, I'm testing on debian/postfix-2.1.5, which may be old, but the > postfix returns 550 if I set up with transport map only. But, > additional test on my site revealed that using virtual map resulted in > pipe command and not lmtp. :-( I'll test it more on this weekend. > I've committed in trunk and here is the basic configuration for Postfix virtual host environment. We need no indivual entries for transport file. You may have to run bin/genaliases if LMTP_ONLY_DOMAINS is updated though. Postfix configuration main.cf +------------------------------------------------- |# dom1 is the main hostname. |# dom2 is not here |mydestination = dom1.example.com |# You need aliases for noreply address |alias_maps = hash:/etc/aliases | hash:/usr/local/mailman/data/aliases |# for persons in dom2 domain |virtual_alias_maps = hash:/etc/postfix/virtual |# everything else is in transport |transport_maps = hash:/usr/local/mailman/data/transport +------------------------------------------------- /etc/postfix/virtual +------------------------------------------------- |# if you want to deliver to a real person in dom2 |user at dom2.example.com dom2user +------------------------------------------------- /usr/local/mailman/data/aliases +------------------------------------------------- |noreply: /usr/local/mailman/data/owner-bounces.mbox +------------------------------------------------- /usr/local/mailman/data/transport +------------------------------------------------- |# This file is automatically generated |noreply at dom1.example.com local:noreply |... etc. |# dom2 is for mailman only (except in /etc/postfix/virtual) |dom2.example.com lmtp:localhost:8025 |# list transports follow. |list at dom1.example.com lmtp:localhost:8025 |... etc. +------------------------------------------------- etc/mailman.cfg (Defaults.py) +------------------------------------------------- |USE_LMTP = Yes |add_runner('LMTPRunner') |add_domain('dom2.example.com', 'www2.example.com') |LMTP_ONLY_DOMAINS = ['dom2.example.com'] |# Use this domain only for mailman mailing list. |# You should write postfix 'virtual' file for other persons |# in this domain. +------------------------------------------------- -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Tue Nov 28 04:57:06 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 27 Nov 2006 22:57:06 -0500 Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8100] trunk/mailman/Mailman/MTA/Postfix.py In-Reply-To: <4568FBEA.2070703@is.kochi-u.ac.jp> References: <0ED25574-BB22-402C-8F06-A8D6DB842CF7@python.org> <45664A08.9070404@is.kochi-u.ac.jp> <4568FBEA.2070703@is.kochi-u.ac.jp> Message-ID: <9F81D0A9-13F2-4E14-AD5B-640AC0BB5382@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 25, 2006, at 9:28 PM, Tokio Kikuchi wrote: > I've committed in trunk and here is the basic configuration for > Postfix > virtual host environment. We need no indivual entries for transport > file. You may have to run bin/genaliases if LMTP_ONLY_DOMAINS is > updated though. Hi Tokio, Yes, I think this is looking really good. I think I see what you're doing: you use a single transport entry to catch all aliases in a domain, and any overrides for that domain go in a virtual file. Correct? That seems nicer than having to write every alias in the transport file. I'm not quite ready to update to your revision though. I'm currently trying again to convert to SQLAlchemy for all list data and I'm in the middle of that process. I'd like to commit these changes to the trunk, but if it looks too radical then I might create a short lived branch for that work. I'm going to try to not completely break the trunk. ;) Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWuznXEjvBPtnXfVAQK4gAQAqtP1HPBAYwzECsyHQpuZt7YhAh9/yONX t0b0lFAlPcqnAYaIaI+UlLfPUPzebc93tJGyktuUSc7csAwn3TgZAR/ttn/wEqi/ ZNAVrYPEHMvm+5pSizURRgzlS/i9+UaEjgvINZaqr8DyRhVRp0BlugrIGDCTfUC8 Ve+fG2+wZUU= =aPCl -----END PGP SIGNATURE----- From mkabot at soarol.com Thu Nov 30 05:37:05 2006 From: mkabot at soarol.com (Michael Kabot) Date: Wed, 29 Nov 2006 23:37:05 -0500 Subject: [Mailman-Developers] The age old question - virtual domains Message-ID: <016801c71439$30b750c0$650aa8c0@office> Hi, I've searched quite a bit and found that virtual domains is still not supported in the current version of Mailmain (2.1.9). It sounds like it is around the corner in v2.2, whenever that is. I've also tried to use some of the "patches" that others have pointed to without success. I have a short term need for virtual domains in Mailman and believe I have a quick fix that I could use some brief expertise in implementing, thus why I am emailing this group. Here is my configuration - Dedicated Servers at GoDaddy.com - Fedora Core 4 (2.6.17 kernel) - Mailman 2.1.5 - Python 2.4.3 - Plesk 8.1 - Qmail 1.03 Here is my idea - create all mailman lists in the format - - This can be done right through Plesk - setup a mail alias for the virtual domain with the name that forwards to the -@ email address - Again, this can be done right through Plesk - Setup a regexp for the mailman list that looks for the - format - Presto, virtual domains working in mailman ! I will not be using ANY of the email admin functions, i.e. -request, -subscribe, -unsubscribe, etc.. I've got this all working well. The ONLY issue that I can see is that I need to have mailman munge two email addresses... - In the mail that is forwarded to the list members, the Reply-To and "on behalf of" of the person who sent the email needs to be put back in. Based on the forwarding, it is showing up as - - In that same email, change the --bounces email to just -bounces. Can someone help me with two things 1. I need a pointer to where in the code to do the munge above. 2. Any gotcha's you can think of to this idea? Thanks in advance, Michael Kabot President - SOAR Scouting Online Affordable & Reliable mkabot at soarol.com 585-388-0211 www.soarol.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1756 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20061129/d20ccacb/attachment.jpe