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