From mads at kiilerich.com  Tue Apr  1 03:11:17 2008
From: mads at kiilerich.com (Mads Kiilerich)
Date: Tue, 01 Apr 2008 03:11:17 +0200
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <PC1760200803310926080093578560e5@msapiro>
References: <PC1760200803310926080093578560e5@msapiro>
Message-ID: <47F18BB5.6050708@kiilerich.com>

Mark Sapiro wrote, On 03/31/2008 06:26 PM:
> So what do I do practically in this case. Calling out to verify the
> recipient won't help because the recipient is valid.

I think that we - admins and developers - have to realize that times are 
changing.

Once upon a time when the RFCs were written then mail was asynchronous 
store-and-forward. MTAs accepted mails before being 100% certain that 
they could and would deliver them, and as soon as the mail had hit the 
disk then the receiving MTA took over delivery responsibility from the 
sending MTA.

In such a scenario Mailman "is just" a MTA with bouncing/holding 
filtering and dynamic alias expansion of envelope-rcpt and replacement 
of envelope-from with a robot address.

But now in modern times all mail handling has to be synchronous. Spam 
and virus and backscatter does that a MTA should never take 
responsibility for anything from an untrusted sender before the mail has 
actually been taken fully care of by someone - perhaps just by making it 
the problem of the next MTA/MDA. Yes, doing this all the way to the 
final mailboxes might be more expensive than the old way of doing it - 
but at the same time the same amount of work (or less?) has to be done, 
so it can't be that bad ... except for the number of live connections. I 
think that the RFCs allows fully synchronous mail handling, they just 
have to be used another way than they usually are today.

In Marks specific case in this scenario: The verification phase has been 
replaced by actually doing the delivery all the way to the final 
recipients, so the recipient ending up being invalid will be handled 
properly.

In this scenario Mailman is a MTA which decouples the synchronous chain. 
Mails are accepted and enqueued by Mailman iff responsibility is taken, 
either for immediate delivery or manual review - all other mails are 
rejected. All filtering thus has to be done synchronously. Delivery to 
list members is a separate process where target mail hosts probably will 
provide synchronous delivery status feedback (perhaps as DSN bounces 
from a trusting "real" MTA) (and if other mail hosts chooses to accept 
and then bounce later then they have a problem, but Mailman can still 
handle receiving bounces).

Lots of details are missing in this description. But do you agree that 
this is the direction we have to take as developers and admins?

/Mads

ps: This might be a bad description of trivial observation, but it 
suddenly made sense to me and I wanted to share it, even though I'm 
mostly a lurker on this list. Take it or leave it ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3422 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080401/c80a0173/attachment.bin 

From iane at sussex.ac.uk  Tue Apr  1 12:26:19 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 01 Apr 2008 10:26:19 +0000
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <PC1760200803310926080093578560e5@msapiro>
References: <PC1760200803310926080093578560e5@msapiro>
Message-ID: <D7719C1369785907A0761079@lewes.staff.uscs.susx.ac.uk>



--On 31 March 2008 09:26:08 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> Ian Eiloart wrote:
>> [snip]
>
> Here's the problem. I receive a message for board at example.net which is
> aliased to a few other addresses including user at example.com. The MTA
> (Postfix in my case) accepts the message to board and resends it to
> the aliased recipients. example.com has a very agressive content
> filter which rejects messages after receiving the DATA. so Postfix's
> delivery to user at example.com is sometimes not accepted by example.com
> so Postfix returns a DSN. Sometimes the sender was legitimate,
> sometimes (probably more often) not.
>
> So what do I do practically in this case. Calling out to verify the
> recipient won't help because the recipient is valid.

So, these are mail aliases that aren't managed by Mailman? Well, you could 
turn them into Mailman lists - albeit lists of one. Mailman would alter the 
return-path, and the rejection message would go to a list manager - perhaps 
the domain owner - instead of an innocent third party.

Also, you could perhaps arrange that Postfix only bounces into domains that 
publish SPF records, and only when you get an positive SPF response. 
Actually, I'm veering towards the notion that we should be creating a 
climate where the only sensible way to avoid collateral spam is to publish 
SPF records.

>  I can arrange for
> the DSN to pass through MailScanner on the way out and possibly create
> rules to conditionally drop it, but what should the rules be, and is
> it really a problem at all? Note for example, that yesterday I did not
> accept 29985 messages for unknown users and greylisted 5684 more and
> sent no DSNs. This is somewhat typical except I probably average 2 or
> 3 DSNs per day.

> Should I be worried?

That depends on the nature of your customers. But, you should also be 
concerned about the possibility of one day being flooded by DNS generating 
mail. At the current rate, it's a small problem [but a part of a larger 
problem], but what you have might be regarded as a vulnerability.



-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From iane at sussex.ac.uk  Tue Apr  1 12:52:55 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 01 Apr 2008 10:52:55 +0000
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <47F18BB5.6050708@kiilerich.com>
References: <PC1760200803310926080093578560e5@msapiro>
	<47F18BB5.6050708@kiilerich.com>
Message-ID: <D4D11BF926E944F7313B468E@lewes.staff.uscs.susx.ac.uk>



--On 1 April 2008 03:11:17 +0200 Mads Kiilerich <mads at kiilerich.com> wrote:

> Mark Sapiro wrote, On 03/31/2008 06:26 PM:
>> So what do I do practically in this case. Calling out to verify the
>> recipient won't help because the recipient is valid.
>
> I think that we - admins and developers - have to realize that times are
> changing.

agreed.

> Once upon a time when the RFCs were written then mail was asynchronous
> store-and-forward. MTAs accepted mails before being 100% certain that
> they could and would deliver them, and as soon as the mail had hit the
> disk then the receiving MTA took over delivery responsibility from the
> sending MTA.

true.

> In such a scenario Mailman "is just" a MTA with bouncing/holding
> filtering and dynamic alias expansion of envelope-rcpt and replacement of
> envelope-from with a robot address.

yes.

> But now in modern times all mail handling has to be synchronous.

that would be nice.

> Spam and
> virus and backscatter does that a MTA should never take responsibility
> for anything from an untrusted sender before the mail has actually been
> taken fully care of by someone - perhaps just by making it the problem of
> the next MTA/MDA. Yes, doing this all the way to the final mailboxes
> might be more expensive than the old way of doing it - but at the same
> time the same amount of work (or less?) has to be done, so it can't be
> that bad ... except for the number of live connections. I think that the
> RFCs allows fully synchronous mail handling, they just have to be used
> another way than they usually are today.

No, they don't allow fully synchronous mail handling. The problem is that 
much spam filtering depends on message content (headers and body). And, 
different recipients have different views on what is acceptable content. 
The RFCs don't allow us handle differences of opinion, because SMTP has no 
way of saying "foo at example.com" will accept this message, but 
"bar at example.net" will not.

In theory, this could be dealt with by adopting LMTP instead of SMTP. LMTP 
does allow us to reject or defer for individual recipients after we've seen 
the message content. But that's always going to be a slow process, and 
it'll be a brave sysadmin who first says "you can only deliver to us using 
LMTP".

The first step to this would be an extension to SMTP which allows a server 
to say "you may switch to LTMP" if you wish. MTA's might be configured to 
switch to single recipient deliveries when LMTP wasn't available. But, what 
spammer would use LMTP if SMTP were available?

It's nice to know that Mailman 3 is likely to have an LMTP engine, because 
it will be possible for lists to use different content-based rules, and 
reject (not bounce) messages to multiple lists depending on individual list 
rules. For example, one list might reject a message with attachments. Of 
course, this will only push the problem back to the local MTA, but that is 
at least some progress.

> In Marks specific case in this scenario: The verification phase has been
> replaced by actually doing the delivery all the way to the final
> recipients, so the recipient ending up being invalid will be handled
> properly.
>
> In this scenario Mailman is a MTA which decouples the synchronous chain.
> Mails are accepted and enqueued by Mailman iff responsibility is taken,
> either for immediate delivery or manual review - all other mails are
> rejected. All filtering thus has to be done synchronously. Delivery to
> list members is a separate process where target mail hosts probably will
> provide synchronous delivery status feedback (perhaps as DSN bounces from
> a trusting "real" MTA) (and if other mail hosts chooses to accept and
> then bounce later then they have a problem, but Mailman can still handle
> receiving bounces).
>
> Lots of details are missing in this description. But do you agree that
> this is the direction we have to take as developers and admins?

That would depend on whether we thought converting the world to LMTP is 
worth the effort. Perhaps it is, but not in my view simply so that we can 
fight spam. The real problem that we have to solve is trusting 
return-paths. At the moment, we can't trust or distrust anyone because it 
is so trivial to forge return-paths. SPF and DKIM offer solutions to 
authenticate senders, and hold domain owners accountable for email that's 
sent.

Once they're widely deployed, we will be able to make reasonable decisions 
about whether to trust the email sender based on the sending domain, or 
even on the individual sender.

At that point, we'll be able to synchronously chain callouts, without 
requiring to look at any message content. Sites will reliably be able to 
blacklist or whitelist based on Mail From.  We'll be able to build trust 
networks (like RBL lists, but with domains and email addresses, not IP 
addresses), and we won't need to scan content at all.

> /Mads
>
> ps: This might be a bad description of trivial observation, but it
> suddenly made sense to me and I wanted to share it, even though I'm
> mostly a lurker on this list. Take it or leave it ;-)
>



-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From Dale at Newfield.org  Tue Apr  1 19:15:42 2008
From: Dale at Newfield.org (Dale Newfield)
Date: Tue, 01 Apr 2008 13:15:42 -0400
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <D7719C1369785907A0761079@lewes.staff.uscs.susx.ac.uk>
References: <PC1760200803310926080093578560e5@msapiro>
	<D7719C1369785907A0761079@lewes.staff.uscs.susx.ac.uk>
Message-ID: <47F26DBE.3050601@Newfield.org>

Ian Eiloart wrote:
> Actually, I'm veering towards the notion that we should be creating a 
> climate where the only sensible way to avoid collateral spam is to publish 
> SPF records.

That's not always trivial.  I get plenty of back scatter, and I've tried 
to do this to reduce that, but I've been unable.  My domain is for my 
family, so each person is in a different part of the country using 
numerous paths to send out mail (local ISP, gmail, web-mail through my 
server, a roaming SMTP service, various cell phones, blackberries, 
etc.), so I've not been able to come up with a complete list of what 
machines can send valid mail from my domain.

-Dale

From iane at sussex.ac.uk  Wed Apr  2 12:52:05 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 02 Apr 2008 10:52:05 +0000
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <47F26DBE.3050601@Newfield.org>
References: <PC1760200803310926080093578560e5@msapiro>
	<D7719C1369785907A0761079@lewes.staff.uscs.susx.ac.uk>
	<47F26DBE.3050601@Newfield.org>
Message-ID: <A25A24030929517B3AF50BB0@lewes.staff.uscs.susx.ac.uk>



--On 1 April 2008 13:15:42 -0400 Dale Newfield <Dale at Newfield.org> wrote:

> Ian Eiloart wrote:
>> Actually, I'm veering towards the notion that we should be creating a
>> climate where the only sensible way to avoid collateral spam is to
>> publish  SPF records.
>
> That's not always trivial.  I get plenty of back scatter, and I've tried
> to do this to reduce that, but I've been unable.  My domain is for my
> family, so each person is in a different part of the country using
> numerous paths to send out mail (local ISP, gmail, web-mail through my
> server, a roaming SMTP service, various cell phones, blackberries,
> etc.), so I've not been able to come up with a complete list of what
> machines can send valid mail from my domain.
>
> -Dale

The long and the short of it is this: as long as you permit email with 
return-paths in your domain to be injected into the mail system without 
authentication and authorisation, then you'll suffer backscatter, 
blacklisting, content scanning and all sorts of other problems.

Ultimately, you'll HAVE to find a way that your domain users can submit 
messages through a server (or virtual server) that YOU manage. Your 
family's ISPs might be able to authenticate their customers, but they 
probably can't know that your family members are authorised to use your 
email domain.

I had a similar problem with my private domain: eiloart.com

First, I rented a virtual server. That turned out to have a pretty cruddy 
qmail installation (which would lose mail if it ran out of RAM during 
delivery!), so I got the domain's email service provided by Google apps. 
<http://www.google.com/a/help/intl/en/index.html> It provides authenticated 
SMTP submission, including on port 587, POP and IMAP. Works nicely on my 
iPhone, with Apple Mail, etc. One issue: I don't seem to be able to use 
both my personal accounts at the same time on my iPhone, but it's OK with 
Apple Mail.

Sorry, this is only vaguely on topic. Mailman doesn't really suffer the 
message submission problem in a big way.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From barry at list.org  Wed Apr  2 13:29:10 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 07:29:10 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47EBBCA5.1000305@gmx.de>
References: <47EBBCA5.1000305@gmx.de>
Message-ID: <39939D5A-3593-466C-800E-B8937EA7A400@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 27, 2008, at 11:26 AM, Timo Wingender wrote:

> I like to participate in Google Summer of Code this year. One possible
> Project for me is to implement some Spam Defense in Mailman. I think
> development for Mailman should be possible through Python Software
> Foundation. Am I right with this?

Hi Timo,

I think you could do this through either the PSF or the GNU project.   
It's a good project to pursue, and either organization seems  
appropriate.

> I administrate a Mailman installation with about 100 lists and  
> thousands
> of users and I moderate most of the Lists. I think the biggest Problem
> of Mailman is the lack in spam defense. Discard messages from  
> nonmembers
> is no option on most lists.
>
> Some time ago I began some modification of Mailman. But I never  
> finished
> it. The first action is to integrate support for SpamAssassin in
> Mailman. Therefor I wrote a python class spamc which connects to  
> spamd.
> This gives the possibility to scan all incoming Mail.
> Further ideas for spam defense are:
> - - Add the possibility to scan all messages form nonmembers half an
> hour later again before mark them as hold. This is because most of the
> mails which are not recognized as spam are to new. The servers are not
> in any blacklist at time of incoming.
> - - Train the bayes filter from Mailman. Forward all accepted Messages
> to SpamAssassin to learn them as ham. The autolearn feature of SA
> doesn't work for me. It learns to much false negatives.

A couple of thoughts, and then I'm going to try to respond to other  
messages in this thread.  While I agree that it's generally much  
better to do spam detection upstream of Mailman, i.e. in the MTA, I  
think there is still some benefit to developing several hooks in  
Mailman to something like SpamAssassin.  One of course would be a  
fairly simple handler to recognize SA headers and do the appropriate  
thing.  Your idea of having a call out to SA to scan the message is  
valid too though, because I don't think everybody is able to hook it  
into their MTA, for whatever reason.  This wouldn't be on by default,  
but it should be an option.

Several years ago, myself and a few others worked on some code to hook  
Mailman's approval mechanism into Spambayes training.  It worked  
moderately well, but not good enough to ever add to Mailman proper.   
I'm sure the patches are still on SourceForge and might even still  
apply to MM 2.1.  It's an interesting idea that you might like to dust  
off and see if you can get working for SA.

> This are my ideas so far. Is this welcome in Mailman and is it enough
> for an GSoC Project? Where would it be best? 2.1.11? 2.2.0? 3.0.0?

I wouldn't do it for 2.1 since I'd like to be very strict about "no  
new features" for 2.1.  It would probably be most useful for people in  
2.2, but I hope that you'll also consider looking at 3.0 because I  
think the architecture will be more amenable to these ideas.  E.g.  
you'd be able to reject spammy messages during the LMTP phase.

I'm planning on releasing Mailman 3 alpha 1 in the next day or so.   
It's basically ready, but I have to fix an annoying setuptools problem.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfzbgcACgkQ2YZpQepbvXFAMQCfTQZ/Ef6XCHGHUjMu9vVPgqoZ
7l8An3FotgRC+CeKbCcu3tjk6oxuvbyu
=/Oay
-----END PGP SIGNATURE-----

From barry at list.org  Wed Apr  2 13:32:30 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 07:32:30 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47EBCB61.30702@netconsonance.com>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
Message-ID: <E29CF802-668D-4CA5-BA3F-B079BD2579BD@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 27, 2008, at 12:29 PM, Jo Rhett wrote:

> For example, the sites I am aware of run amavisd+SA in front of  
> mailman.
>  They aren't going to disable amavis to have mailman run SA directly.
> Nor are sites with barrucudas likely to do so, etc etc.  My opinion
> entirely, but I think it would be better to make mailman aware of the
> headers inserted by these solutions.

There should definitely be a handler to do this recognition.  It's  
easy to do and as you say, if the site is already running SA in the  
MTA, this would be a useful addition to Mailman.

However, not all sites run thing this way, and I think it would be  
helpful if people could run SA scanning in Mailman, though we should  
not recommend it or enable it by default.

One other place to scan, which an MTA-embedded SA doesn't cover, is  
gating messages from NNTP.  I know that it's not a common use case  
these days, but many sites still pull messages from NNTP to their  
mailing list, and in this case, there is currently /no/ scanning for  
spam.  It's a pretty common vector that would be useful to close off.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfzbs8ACgkQ2YZpQepbvXEkfgCdFcOdyursgpmIR4b2Cec2kVeu
0voAoJKRaUVj6u+Ynuz+6YknDWbbBgVU
=OWHn
-----END PGP SIGNATURE-----

From timowi.lists at gmx.de  Wed Apr  2 15:50:23 2008
From: timowi.lists at gmx.de (Timo Wingender)
Date: Wed, 02 Apr 2008 15:50:23 +0200
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47EBBCA5.1000305@gmx.de>
References: <47EBBCA5.1000305@gmx.de>
Message-ID: <47F38F1F.3020105@gmx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As the deadline was on March 31th I submitted a application to the 
Python Software foundation.
A copy of my application can be found here:

http://kybs.de/~wingender/gsoc2008/mailman/application.html

It's not good because I had to less time. But luckily Google extended 
the deadline until April 7th. So I am able to improve my application and 
correct some errors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH848eakDbqHKnrh8RAlwrAJ9t+EaeSY65U3MpcoKQMvRHqSQk0QCgzCWq
+Z7A0vWF9Re5Hcf9zK7Du74=
=rdix
-----END PGP SIGNATURE-----


From stephen at xemacs.org  Wed Apr  2 19:02:48 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 03 Apr 2008 02:02:48 +0900
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <39939D5A-3593-466C-800E-B8937EA7A400@list.org>
References: <47EBBCA5.1000305@gmx.de>
	<39939D5A-3593-466C-800E-B8937EA7A400@list.org>
Message-ID: <87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:
 > Mailman to something like SpamAssassin.  One of course would be a  
 > fairly simple handler to recognize SA headers and do the appropriate  
 > thing.

Why have a Handler when you can already use header scanning in the
privacy filters?  Ie, isn't this a documentation or UI problem rather
than a Handler problem?

 > Your idea of having a call out to SA to scan the message is valid
 > too though, because I don't think everybody is able to hook it into
 > their MTA, for whatever reason.  This wouldn't be on by default,
 > but it should be an option.

Even if you can't hook it into the MTA, it's certainly possible to do
this via procmail, etc.  There are so many ways to do this already.
Why doesn't TOOWTDI apply here?


From eino at utu.fi  Wed Apr  2 19:07:56 2008
From: eino at utu.fi (Eino Tuominen)
Date: Wed, 02 Apr 2008 20:07:56 +0300
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de>
	<39939D5A-3593-466C-800E-B8937EA7A400@list.org>
	<87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <47F3BD6C.8020700@utu.fi>

Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>  > Mailman to something like SpamAssassin.  One of course would be a  
>  > fairly simple handler to recognize SA headers and do the appropriate  
>  > thing.
> 
> Why have a Handler when you can already use header scanning in the
> privacy filters?  Ie, isn't this a documentation or UI problem rather
> than a Handler problem?

I agree, it's a UI problem. What I'd like is that privacy/spam 
administration page had two checkboxes for "Filter obvious spam" and 
"Filter propable spam" (or smthng like that). These would be handled 
internally like spam filter regexp, only difference would be that those 
regexps would be configured in mm_cfg.py. And there shouldn't be Reject 
as a possible action for these rules.

In mm_cfg.py site admin could enable/disable/hide these and set default 
actions for these rules.

That way list admins could easily e.g. discard obvious spam messages and 
hold probable ones.

-- 
   Eino Tuominen

From stephen at xemacs.org  Wed Apr  2 22:20:47 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 03 Apr 2008 05:20:47 +0900
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47F3BD6C.8020700@utu.fi>
References: <47EBBCA5.1000305@gmx.de>
	<39939D5A-3593-466C-800E-B8937EA7A400@list.org>
	<87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
	<47F3BD6C.8020700@utu.fi>
Message-ID: <87d4p8xb34.fsf@uwakimon.sk.tsukuba.ac.jp>

Eino Tuominen writes:

 > I agree, it's a UI problem. What I'd like is that privacy/spam 
 > administration page had two checkboxes for "Filter obvious spam" and 
 > "Filter propable spam" (or smthng like that).

Do you mean "Filter SpamAssassin score >15" and "Filter SpamAssassin >5",
or equivalent for other filter applications?

The problem is that on "watch-lovers at rich-folks.net" discussion of
Rolex watches is likely not spam, but on "xemacs-commits at xemacs.org"
it sure is!  So "obvious" is not a good word to use.

I think if that's what you mean, a numerical entry documented with

    For most lists, >5 is an aggressive setting that will permit very
    little spam but may throw out legitimate posts.  >15 is a very
    relaxed setting that will almost never throw out a legitimate post
    but will let in a fair amount of spam.  Adjust the setting
    according to your preferences and the results.

I think I would do the UI this way:

------------------------------------------------------------------------
SpamAssassin filters:

If your site uses SpamAssassin to tag messages, then you can set the
following filters based on the SpamAssassin score of each post.  If
SpamAssassin is not installed, or not configured to tag the message
with a score[1], these settings will have no effect.

On/Off  Action                              Score
 (o)    HOLD posts with score over         [  5.0]
 ( )    DISCARD posts with score over      [ 15.0]
------------------------------------------------------------------------

The settings in the prototype will NEVER discard a post, and will hold
posts with a score over 5.0.  I prefer this style because we can
provide visible defaults for the scores.

Footnotes: 
[1]  This should mention the exact SA header we're looking for, of
course.

From barry at list.org  Thu Apr  3 03:07:38 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 21:07:38 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <877ifnten9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de>
	<877ifnten9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <E67003C7-D2EE-4D11-B41A-7B2BBDC7C2AA@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 28, 2008, at 4:51 AM, Stephen J. Turnbull wrote:
>
>  - The big hole in the current architecture is that there is no way  
> for
>    spam filters in the MTA to get information from Mailman's member
>    lists.  That seems to be the crucial defect at present.

This ties into the work that we sprinted on at Pycon, which would  
expose a REST interface to Mailman's internal data structures.  I  
don't know if Maki, Andrew and Richard have made much progress on this  
since then though.  The intent is to make this available in both MM2.2  
and 3.0.

- -Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf0LdsACgkQ2YZpQepbvXEWSgCfcScee9wn7auWu3VIvK3IV7j1
UV4An0kOPqAjOpzmghjNvTO2vrD3u0V5
=mmHM
-----END PGP SIGNATURE-----

From barry at list.org  Thu Apr  3 04:12:42 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 22:12:42 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote:

> For this reason I am looking forward to a way to issue SMTP rejects
> based on content.  Eg, for sendmail and postfix, this could be
> implemented via a Mailman-provided milter.

What about the Mailman 3 LMTP server?  I plan on backporting this to  
2.2.

>> I'd like to hear some arguments before I change that view,
>> though. My current solution has the advantage that for any
>> complaining list admin, I can point that administrator to her/his
>> own admin panel and say, "Play with these settings."
>
> Unfortunately, tuning list settings that have to do with filtering is
> not and never really was something that you want people who have never
> even set up an MTA to do.  Understanding what happens is quite  
> complex.

The solution in Mailman 3 will be to allow for defining named styles.   
A style is simply a collection of some subset of all the configuration  
variables on a mailing list.  So you could imagine a site that cans a  
few common styles for spam filtering and lets their list admins choose  
which they want.  If they really want to let them have full control,  
they could do that through an 'advanced' tab.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf0PRwACgkQ2YZpQepbvXHy3wCaAn5rGVTS9YsAqkq+amt3mVDP
3e4AoKYj71ShABwIJm13rlYy+jtzpPRR
=Wrix
-----END PGP SIGNATURE-----

From barry at list.org  Thu Apr  3 04:14:35 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 22:14:35 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47F38F1F.3020105@gmx.de>
References: <47EBBCA5.1000305@gmx.de> <47F38F1F.3020105@gmx.de>
Message-ID: <3CDC04FD-68BE-42F6-BAC5-000397C7D0E2@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2008, at 9:50 AM, Timo Wingender wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As the deadline was on March 31th I submitted a application to the
> Python Software foundation.
> A copy of my application can be found here:
>
> http://kybs.de/~wingender/gsoc2008/mailman/application.html
>
> It's not good because I had to less time. But luckily Google extended
> the deadline until April 7th. So I am able to improve my application  
> and
> correct some errors.

Does the extension mean you could file with the FSF as well?  I don't  
know what the procedure is for the organizations to get in touch with  
the projects, but I'll try to look into this.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf0PYsACgkQ2YZpQepbvXE+XgCglWak616HyloS4qzJWVhIp+r6
yqUAoIRcI6h9Q0sF+6WYGK0T4ux/UiiI
=vWg1
-----END PGP SIGNATURE-----

From barry at list.org  Thu Apr  3 04:17:58 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 22:17:58 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de>
	<39939D5A-3593-466C-800E-B8937EA7A400@list.org>
	<87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <A4BD7619-9CF8-4A34-8B77-4CB3489E682B@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2008, at 1:02 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>> Mailman to something like SpamAssassin.  One of course would be a
>> fairly simple handler to recognize SA headers and do the appropriate
>> thing.
>
> Why have a Handler when you can already use header scanning in the
> privacy filters?  Ie, isn't this a documentation or UI problem rather
> than a Handler problem?

I'm really thinking about Mailman 3's rule architecture.  I think it's  
going to be much better to have narrower rules for specific purposes,  
as they can be packaged in plugins, enabled separately etc.  A generic  
header regexp matcher could be used, but would probably be a bit more  
difficult to use.

>> Your idea of having a call out to SA to scan the message is valid
>> too though, because I don't think everybody is able to hook it into
>> their MTA, for whatever reason.  This wouldn't be on by default,
>> but it should be an option.
>
> Even if you can't hook it into the MTA, it's certainly possible to do
> this via procmail, etc.  There are so many ways to do this already.
> Why doesn't TOOWTDI apply here?

Because I think you're talking about different sites having different  
administrative domains.  In some, it will make sense to do it as far  
upstream as possible, but in others, it's going to be left to the list  
admin, so they should at least have the ability to enable such filters  
if nobody else will.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf0PlYACgkQ2YZpQepbvXE7GQCfZQfB5JzwxtoomyXSkraMuO7r
FYAAoJ5/FD294hMx2s0/QLDkJD9XNec1
=VHlH
-----END PGP SIGNATURE-----

From barry at list.org  Thu Apr  3 04:19:01 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Apr 2008 22:19:01 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <47F3BD6C.8020700@utu.fi>
References: <47EBBCA5.1000305@gmx.de>
	<39939D5A-3593-466C-800E-B8937EA7A400@list.org>
	<87fxu4xk93.fsf@uwakimon.sk.tsukuba.ac.jp>
	<47F3BD6C.8020700@utu.fi>
Message-ID: <29BD1797-F568-4076-9A37-36DB93051C61@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2008, at 1:07 PM, Eino Tuominen wrote:
> Stephen J. Turnbull wrote:
>> Barry Warsaw writes:
>> > Mailman to something like SpamAssassin.  One of course would be  
>> a   > fairly simple handler to recognize SA headers and do the  
>> appropriate   > thing.
>> Why have a Handler when you can already use header scanning in the
>> privacy filters?  Ie, isn't this a documentation or UI problem rather
>> than a Handler problem?
>
> I agree, it's a UI problem. What I'd like is that privacy/spam  
> administration page had two checkboxes for "Filter obvious spam" and  
> "Filter propable spam" (or smthng like that). These would be handled  
> internally like spam filter regexp, only difference would be that  
> those regexps would be configured in mm_cfg.py. And there shouldn't  
> be Reject as a possible action for these rules.
>
> In mm_cfg.py site admin could enable/disable/hide these and set  
> default actions for these rules.
>
> That way list admins could easily e.g. discard obvious spam messages  
> and hold probable ones.

When I translate that to Mailman 3-speak, I agree. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf0PpcACgkQ2YZpQepbvXFurQCeP9rTjasS08Zq6WyWyzoVAJAt
R+wAoJj+B6+wFMAcEtMGXOaEDMxu1YiX
=GMcO
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Thu Apr  3 07:28:55 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 03 Apr 2008 14:28:55 +0900
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
Message-ID: <874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote:
 > 
 > > For this reason I am looking forward to a way to issue SMTP rejects
 > > based on content.  Eg, for sendmail and postfix, this could be
 > > implemented via a Mailman-provided milter.
 > 
 > What about the Mailman 3 LMTP server?  I plan on backporting this to  
 > 2.2.

I don't see how that works.  Do SMTP MTAs typically initiate an LMTP
session before accepting mail from remote hosts?  If they don't, then
you don't get any extra leverage on the backscatter problem.

 > > Unfortunately, tuning list settings that have to do with filtering is
 > > not and never really was something that you want people who have never
 > > even set up an MTA to do.  Understanding what happens is quite  
 > > complex.
 > 
 > The solution in Mailman 3 will be to allow for defining named styles.

That's half the solution.  The other half is providing means and
encouragement for good ones to end up in a contrib directory. :-)

 > A style is simply a collection of some subset of all the configuration  
 > variables on a mailing list.

And these cascade, right?


From eino at utu.fi  Thu Apr  3 07:38:45 2008
From: eino at utu.fi (Eino Tuominen)
Date: Thu, 03 Apr 2008 08:38:45 +0300
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
	<874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <47F46D65.4080707@utu.fi>

Stephen J. Turnbull wrote:
> Barry Warsaw writes:
> 
>  > On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote:
>  > 
>  > > For this reason I am looking forward to a way to issue SMTP rejects
>  > > based on content.  Eg, for sendmail and postfix, this could be
>  > > implemented via a Mailman-provided milter.
>  > 
>  > What about the Mailman 3 LMTP server?  I plan on backporting this to  
>  > 2.2.
> 
> I don't see how that works.  Do SMTP MTAs typically initiate an LMTP
> session before accepting mail from remote hosts?  If they don't, then

No, they don't. Mailman-milter has potential. That way most of privacy 
rules could be checked in SMTP conversation phase, and "Reject" would be 
once again a useful action.

-- 
   Eino Tuominen

From iane at sussex.ac.uk  Thu Apr  3 12:19:08 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 03 Apr 2008 10:19:08 +0000
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
	<874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <0A15F4BE7CDCB8E14074DD03@lewes.staff.uscs.susx.ac.uk>



--On 3 April 2008 14:28:55 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> 
wrote:

> Barry Warsaw writes:
>
>  > On Mar 29, 2008, at 11:17 PM, Stephen J. Turnbull wrote:
>  >
>  > > For this reason I am looking forward to a way to issue SMTP rejects
>  > > based on content.  Eg, for sendmail and postfix, this could be
>  > > implemented via a Mailman-provided milter.
>  >
>  > What about the Mailman 3 LMTP server?  I plan on backporting this to
>  > 2.2.
>
> I don't see how that works.  Do SMTP MTAs typically initiate an LMTP
> session before accepting mail from remote hosts?  If they don't, then
> you don't get any extra leverage on the backscatter problem.

Exim could do that. It has Access Controls that can be implemented at any 
stage of the SMTP process. They're capable of running arbitrary perl code. 
That's not trivial.

What would be easy and useful though, would be LMTP call forwards, which 
are run after each RCPT TO command. We already use these to determine quota 
status on our Cyrus mailstores. Mailman would need to reject mail after 
RCPT TO if the sender isn't permitted to post to the list, or if the 
recipient address doesn't refer to a list.

It would be nice if RFC1893/2034 enhanced error codes were used. These seem 
relevant:

X.1.1   Bad destination mailbox address
X.2.4   Mailing list expansion problem
X.5.3   Too many recipients
X.7.2   Mailing list expansion prohibited
    The sender is not authorized to send a message to the intended mailing 
list.

X is 4 for a temporary error, 5 for a permanent error.


>  > > Unfortunately, tuning list settings that have to do with filtering is
>  > > not and never really was something that you want people who have
> never  > > even set up an MTA to do.  Understanding what happens is quite
>   > > complex.
>  >
>  > The solution in Mailman 3 will be to allow for defining named styles.
>
> That's half the solution.  The other half is providing means and
> encouragement for good ones to end up in a contrib directory. :-)
>
>  > A style is simply a collection of some subset of all the configuration
>   > variables on a mailing list.
>
> And these cascade, right?
>
> _______________________________________________
> 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/iane%40sussex.a
> c.uk
>
> Security Policy:
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp



-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From Dale at Newfield.org  Thu Apr  3 18:29:06 2008
From: Dale at Newfield.org (Dale Newfield)
Date: Thu, 03 Apr 2008 12:29:06 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <0A15F4BE7CDCB8E14074DD03@lewes.staff.uscs.susx.ac.uk>
References: <47EBBCA5.1000305@gmx.de>
	<47EBCB61.30702@netconsonance.com>	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>	<47EBE969.4000108@mschuette.name>	<20080328161401.GF22290@garp.metalab.unc.edu>	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>	<20080329175011.GO22290@garp.metalab.unc.edu>	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>	<874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
	<0A15F4BE7CDCB8E14074DD03@lewes.staff.uscs.susx.ac.uk>
Message-ID: <47F505D2.9070606@Newfield.org>

Ian Eiloart wrote:
> Mailman would need to reject mail after RCPT TO if the sender isn't
> permitted to post to the list, or if the recipient address doesn't
> refer to a list.

Or a list owner, etc.

-Dale

From timowi.lists at gmx.de  Thu Apr  3 19:12:37 2008
From: timowi.lists at gmx.de (Timo Wingender)
Date: Thu, 03 Apr 2008 19:12:37 +0200
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <3CDC04FD-68BE-42F6-BAC5-000397C7D0E2@list.org>
References: <47EBBCA5.1000305@gmx.de> <47F38F1F.3020105@gmx.de>
	<3CDC04FD-68BE-42F6-BAC5-000397C7D0E2@list.org>
Message-ID: <47F51005.2010609@gmx.de>

Barry Warsaw schrieb:
>
> On Apr 2, 2008, at 9:50 AM, Timo Wingender wrote:
>>
>> As the deadline was on March 31th I submitted a application to the
>> Python Software foundation.
>> A copy of my application can be found here:
>>
>> http://kybs.de/~wingender/gsoc2008/mailman/application.html
>>
>> It's not good because I had to less time. But luckily Google extended
>> the deadline until April 7th. So I am able to improve my application and
>> correct some errors.
>
> Does the extension mean you could file with the FSF as well?  I don't 
> know what the procedure is for the organizations to get in touch with 
> the projects, but I'll try to look into this.
Yes, it could also file a new application. I thought PSF would be the 
best here. I think it's better to contact the Organization 
Administrators and ask them what they think.

From mark at msapiro.net  Sat Apr  5 19:10:32 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 05 Apr 2008 10:10:32 -0700
Subject: [Mailman-Developers] Mailman 2.1.10 final release schedule.
In-Reply-To: <47D9E26E.4040708@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>
Message-ID: <47F7B288.6020801@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For translators who haven't yet updated their translations for 2.1.10
and for other interested parties, I plan to release a 2.1.10 release
candidate on April 14, 2008 and barring any issues with the RC, the
2.1.10 final on April 21, 2008.

Note to translators - the latest mailman.pot for the 2.1 branch is at
<https://code.launchpad.net/~mailman-coders/mailman/2.1>. The SVN
repository on sourceforge is no longer maintained and is out of date.

One way to get your updated translation to me is to register on
launchpad and make your own private branch off the 2.1 branch, update
your branch and publish it and send me a note when it's ready. Then I
can just merge your branch back into the 2.1 branch.

Of course, if you prefer, you can just send me your updated message
catalog and templates if any or make them available anywhere on the web
and tell me where to find them.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFH97KHVVuXXpU7hpMRAoSnAKCb9kN0WV7EVJ2KVqUX0yhPQjlkkQCgwfLx
UjpxqBDIR8yLPin2faeMr7M=
=yLBQ
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr  5 20:50:51 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 5 Apr 2008 14:50:51 -0400
Subject: [Mailman-Developers] [Mailman-Announce] Mailman 2.1.10 final
	release schedule.
In-Reply-To: <47F7B288.6020801@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
Message-ID: <5EC9708A-A3D7-4AE2-A2EE-23E1DBE074B7@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 5, 2008, at 1:10 PM, Mark Sapiro wrote:
>
> For translators who haven't yet updated their translations for 2.1.10
> and for other interested parties, I plan to release a 2.1.10 release
> candidate on April 14, 2008 and barring any issues with the RC, the
> 2.1.10 final on April 21, 2008.

Sounds great, Mark.  Thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf3ygwACgkQ2YZpQepbvXFxGACgpa03tySXUxgGL8yuQCzD7zub
QeoAmwbL7R3SKQ+1K5aF9EiS8d3z5YiM
=t5NW
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Sat Apr  5 22:04:21 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 06 Apr 2008 05:04:21 +0900
Subject: [Mailman-Developers] Configurable options in Mailman 3
In-Reply-To: <PC176020080404100554023408e56980@msapiro>
References: <659D5E8D-4D9B-4487-BDE9-6965D68B3007@uci.edu>
	<PC176020080404100554023408e56980@msapiro>
Message-ID: <87prt41322.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Sapiro writes:

 > What are you asking, and what is the issue?
 > 
 > Upon rereading, I think your question is "is it possible to have
 > OLD_STYLE_PREFIXING = No in mm_cfg.py, but use the old style for
 > selected lists through some list setting". Unfortunately, the answer
 > to that is no.

I don't understand why it should ever be the case that a configuration
option that makes sense to configure per-list should be not
configurable per-list.

How is Mailman 3 handling this?


From barry at list.org  Wed Apr  9 03:43:48 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Apr 2008 21:43:48 -0400
Subject: [Mailman-Developers] Configurable options in Mailman 3
In-Reply-To: <87prt41322.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <659D5E8D-4D9B-4487-BDE9-6965D68B3007@uci.edu>
	<PC176020080404100554023408e56980@msapiro>
	<87prt41322.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <8330BC30-D32E-49DC-9A40-2DE324A2C7FA@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 5, 2008, at 4:04 PM, Stephen J. Turnbull wrote:
> Mark Sapiro writes:
>
>> What are you asking, and what is the issue?
>>
>> Upon rereading, I think your question is "is it possible to have
>> OLD_STYLE_PREFIXING = No in mm_cfg.py, but use the old style for
>> selected lists through some list setting". Unfortunately, the answer
>> to that is no.
>
> I don't understand why it should ever be the case that a configuration
> option that makes sense to configure per-list should be not
> configurable per-list.

Agreed.

> How is Mailman 3 handling this?

On several levels I think.  The style system is basically a way to  
organize the settings of MailingList attributes.  These attributes are  
defined in an interface and in the default storage backend, as columns  
on the MailingList table.  There is a default style that basically  
maps Defaults.py values (i.e the old mm_cfg.py/Defaults.py.in stuff)  
to attribute settings.  Ultimately I'd like to be able to get rid of  
Defaults.py entirely for per-list configuration defaults and use it  
just for site-wide settings.  Then the style system would be /the/ way  
to set values per-list.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf8H1QACgkQ2YZpQepbvXGPkQCgpelMjuCgUA1iFUZIEBXJseiS
89AAoKiMWJa46FnwmxoN2Rv30J9zEY3O
=WOw6
-----END PGP SIGNATURE-----

From barry at list.org  Wed Apr  9 04:10:58 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Apr 2008 22:10:58 -0400
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That Thing
	Alone)
Message-ID: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After far too long, I'm finally happy to announce the availability of  
GNU Mailman version 3.0 alpha 1, code name "Leave That Thing Alone".

Hopefully, I needn't point out that this version is not suitable for  
production.  Instead, I'm making it available to provide an early  
snapshot of where Mailman 3 is going, and to give interested  
developers, users and integrators something real to play with.  I am  
looking forward to your feedback and contributions, and I hope you  
will at least download the package and give what works a try.

For now, I would prefer if all discussion about 3.0a1 were held on the  
mailman-developers mailing list.  Please don't submit bug reports to  
SourceForge; it's far too early for that.  Ideally, you'll be  
interested enough to create your own branches and push them to  
Launchpad for all of us to look at.

For detailed information on 3.0a1, please read docs/ALPHA.txt.  This  
will explain what works and what doesn't, how to run the test suite  
and how to actually create, populate, and deliver to some mailing  
lists.  Much does not yet work, but everything that does work is very  
well documented using Python's doctest framework.

Please note that Python 2.5 is required, but a C compiler is no longer  
needed.  You will need some third party packages, but everything you  
need is available in the Python Cheeseshop.

You can download both the tarball and egg file for 3.0a1 from the  
Cheeseshop as well:

     http://pypi.python.org/pypi/mailman/3.0.0a1

You'll probably want the source tarball.

I hope you will find this first snapshot useful and encouraging.   
Please participate!

Enjoy,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf8JbMACgkQ2YZpQepbvXGtxgCguOrVEuZ61VnCe86nwkWHXGBm
b7sAoLn2fUbRLDmRdWusYxfsAu21FAxw
=eiPc
-----END PGP SIGNATURE-----

From barry at list.org  Wed Apr  9 04:53:51 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Apr 2008 22:53:51 -0400
Subject: [Mailman-Developers] Has Mailman lost its way?
In-Reply-To: <Pine.GSO.4.58.0803200924510.17281@arachne.dur.ac.uk>
References: <Pine.GSO.4.58.0803200924510.17281@arachne.dur.ac.uk>
Message-ID: <899DF576-AAB9-44D3-B068-03BE87630C74@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

Thanks for the post.  As I hope you will soon see, I believe the  
Mailman projects is very much alive and kicking, and it is moving  
forward with a fairly clear plan.  Ultimately of course, that roadmap  
is subject to the constraints that many open source projects are also  
subject to, grand designs implemented between diaper changes, trading  
today's new feature or fix for falling ever farther behind in email,   
and convincing yourself that sleep is a Corportist plot.

On Mar 20, 2008, at 6:41 AM, David Lee wrote:

> Could I suggest that serious consideration be given to:
>
> 1. Freeze 2.1 now.  No new features. The only exception would be  
> security
> bug-fixes.  Nothing else.

This is happening.  When Mark releases 2.1.10, there will be no 2.1  
releases except for security or other serious bug fixes.

> 2. Freeze "new idea" development now.  Concentrate solely on  
> bugfixing the
> already implemented ideas.

Hmm.  Probably not realistic.  There's a huge backlog of good ideas  
waiting to get in.  Now is actually exactly the time to evaluate those  
and decide whether and where to implement them.

> 3. Decide whether 2.2 or 3.0 is the way of the near future.  The  
> reality
> is that neither of these has delivered anything to the real-world  
> end-user
> during two or more years.  Choose only one.  Freeze the other for  
> the time
> being, until the "chosen one" has been properly post-beta released.

I don't think this is going to happen.  Almost all new code for  
Mailman is today written by either Mark or myself.  This is not to  
dismiss all the fantastic contributions of other sorts by other  
people, nor to dismiss the huge number of patches available out on the  
'net.  But some of the things I've pushed for recently is specifically  
geared to getting more involvement from the community.  That's why I  
chose Bazaar as our dvcs.  I don't want patches, I want live branches  
that I can merge and review.

Both 2.2 and 3.0 are the future, but for different audiences.  I  
recognize that this means our limited resources are stretched even  
thinner, but I think it's justified.  Mailman 2.2 will be for those  
users who are happy (enough) with the 2.1 data model, and just want a  
few new features, a spruced up web u/i, and other modest but important  
improvements.  I consider Mailman 2.2 a critical project, and I am  
delighted that Mark will lead this effort.

While I will be involved in 2.2, and plan to be engaged in its design,  
I personally am spending my limited hacking time on 3.0.  Mailman 3 is  
the long promised solution to several architectural limitations in the  
MM2 series, and improving those aspects requires a bump to version 3.   
Mailman 3 also has a different focus.  It's trying to be at its core a  
mailing list delivery library, usable and easily integrated with a  
wide variety of applications and web frameworks.  Ultimately, Mailman  
3 will be usable just like 2 is, as a standalone turn-key system, but  
I think it's real power will be in its use as a component for more  
interesting systems.

Will 2.2 or 3.0 be released first?  I have no idea.

> 4. Whichever of the above is chosen, aim to start delivering betas  
> fast.
> Get something out there that you (the main developers) and we (some
> real-world end-users who can help bug-hunt) can get to work on,  
> knowing
> that our work will be productive in a foreseeable timescale.  Set the
> goal. Drive towards it, ignoring distractions.

Well, there is nothing stopping you from participating today.  I just  
released Mailman 3.0 alpha 1.  You can pull the code down, or branch  
from the Bazaar repository, start fixing bugs, implementing ideas and  
helping out.  You can push branches, request reviews, strive toward  
adoption in the core.  Soon, I expect we'll see some Mailman 2.2  
branches and alphas, and then you can do the same there.

This is a volunteer effort, on my and your part.  I've put my stake in  
the ground.  Where are you interesting in contributing?

> 5. For a few months, change the mindset away from development (yes,  
> I know
> we coders love it) and towards a firm, decisively-directed "release
> management" (to use ITIL-speak).
>
> Mailman used to be a leading product.  But it is slipping behind.
>
> We, the end-users, need some of that new code that's being lying  
> dormant,
> and (to an end-user) unuseable, during the last two years or so.
>
> Many of us, the enthusiastic real-world end-users, cannot  
> realistically
> commit to developing something for which there is no clear strategy.
> Give us a strategy, a roadmap with real, near-future dates on it,  
> then we
> can at least make local business cases to our local managements for  
> our
> taking part in beta trials.
>
> Let's get some new code out now as beta. There may be a sizeable  
> "TODO";
> there may be a sizeable "Known Problems".  But let's start releasing  
> betas
> soon, and concentrate all our limited efforts on that one common task.

It doesn't quite work that way.  Once you reach beta, features are  
frozen, and I think we're too early for that.  But we can have a  
vibrant alpha ecosystem right now, and if you're willing to  
participate, you can make a difference.  If that means you can't make  
a business case to your manager right now, then hack on it in your  
spare time.  Help us get to a point this year where we /can/ feature  
freeze and start releasing betas.  I would like nothing more than  
that, so that both you and I can begin to convince our managers to let  
us spend Real Work Time polishing and releasing.

> Otherwise, are we not in danger of following Majordomo into oblivion?

It's always possible, but I think unlikely.  You have it in your power  
to help avoid that fate.

> (Oh, and #1 on my own list is proper "virtual domains": the Jul/2005  
> paper
> mentioned that the code substantially existed.  But sadly it's never  
> come
> anywhere near a release schedule.  If we have a realistic beta-release
> schedule, then I can locally justify actively investing in bug- 
> hunting.)
>
> Sorry if that sounds harsh.  It is meant to be constructive.   
> (Honest!)

Proper virtual domains exist today, in Mailman 3.0a1.  Try it.  If  
there is anything stopping folks from participating, please let me  
know.  I'm very keen on helping remove barriers to participation.  But  
remember that Mark and I have jobs and families, other hobbies and  
lives.  Occasionally we like to eat and sleep too, so we develop the  
software when we can.  But I think we'd both welcome anybody who's  
interested getting more involved, in whatever way they want (it does  
not /have/ to be as a coder, as great contributions from Terri, Clytie  
and many others has proven).

I guess I need to sleep now.  Damn those Corportists!

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf8L78ACgkQ2YZpQepbvXF8QwCfT7KXPXPUoK+5XEJDCYpFdwqb
FdMAmgM/6JxIZZxerpUurZzrOdbz89/h
=1Jlg
-----END PGP SIGNATURE-----

From barry at list.org  Wed Apr  9 05:08:57 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Apr 2008 23:08:57 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
Message-ID: <901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 10, 2008, at 11:10 PM, Satoshi Tanabe wrote:
>
> Currently I'm creating an unofficial site of GNU Mailman. It's not
> done yet, but the goal is to make the current official site more
> accessible and usable. The content is almost the same.

Satoshi, this is very cool.  I'm sorry for not responding sooner, but  
I think it would be great to flesh these ideas out more, probably with  
Terri's help.

I think you've accurately identified some of the problems with the  
current web site. It's also true that we're building it with 1996  
technology and web design sensibility (not unlike Mailman's web u/i ;).

I do think it's important to consider that the tools used to build the  
site be free software.  I'd like people to be able to hack the web  
building tools just like they can hack the software.

It's also important to consider what information is better suited for  
the wiki and what is better suited for the static main site.  I agree  
that there's a lot of duplication of information, and I tend to think  
that a large amount of that belongs on the wiki instead.  Relying  
heavily on the wiki[1] allows the entire community to participate, and  
as Terri has shown, even the documentation written on the wiki can be  
exported to other formats that are more easily printed.

I would like to keep some of the same color schemes and logos we  
currently use, unless there is a strong desire to update them.  I  
still like the logo though. :)

One other question you raise: I would like to move the bug trackers  
off of SourceForge at some point.  I think Jira is no longer a viable  
option, so we should consider alternatives.  Once again, Launchpad  
seems a natural, but I'm open to suggestions, given our constraints  
(we don't currently have the resources to maintain our own tracker  
instances).

- -Barry

[1] Admittedly the wiki is not running on free software.  As much as I  
like Confluence, this is an issue for a GNU project like Mailman.   
However, again I don't think we yet have the resources to maintain our  
own wiki, let alone import the existing content into a free wiki.   
IMO, having a non-free wiki is more useful to the community than not  
having a wiki at all, but I'm open to volunteers coming forward to  
help rectify the situation.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf8M0kACgkQ2YZpQepbvXF+KgCdHj+qTjuKUif76FlgcJ+kMKZQ
wP4AnRlb3Fesrv7YU2Ekqy95x8nDlDOO
=vtTq
-----END PGP SIGNATURE-----

From barry at list.org  Wed Apr  9 05:14:12 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Apr 2008 23:14:12 -0400
Subject: [Mailman-Developers] [Mailman-i18n] [Mailman-Users]
	[Mailman-Announce] Updated message catalogs needed for
	Mailman 2.1.10
In-Reply-To: <90B310F8-E15B-46ED-AE64-DA2A67637B70@riverland.net.au>
References: <47D31C99.10103@msapiro.net>
	<Pine.A41.4.58.0803100949150.782356@beluga.user.services.metu.edu.tr>
	<p06240800c3fb93a0f72f@[192.168.1.199]>
	<90B310F8-E15B-46ED-AE64-DA2A67637B70@riverland.net.au>
Message-ID: <98D2BAD2-4EC1-4495-ACB9-DA305EC99E47@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 12, 2008, at 5:07 AM, Clytie Siddall wrote:
>
> On 11/03/2008, at 12:11 PM, Brad Knowles wrote:
>
>> On 3/10/08, liste yoneticisi wrote:
>>
>>> (An explanation to all: I just asked if there is anyone who
>>> responsible for Turkish translation of Mailman, attended to these
>>> lists
>>> from Turkiye.)
>>
>> This is a question that is better asked on the mailman-i18n mailing
>> list.  That's where all the Internationalization folks should be
>> hanging out.
>
> I'd definitely vote for Pootle. It's free software, and gives you
> complete control of access, plus syncing with source control
> (including bzr, AFAIK). Its developers are extremely responsive to
> admin or user needs.

Clytie,

I would like to set this up for Mailman 2.2 and 3.0.  Could you or  
another volunteer outline what it would take to get a Pootle instance  
running for us?  Is there some service that we can piggyback on?   
Would anybody out there be willing and able to run a reliable Pootle  
server for us?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf8NIQACgkQ2YZpQepbvXGAvQCggd1jTxioWaLKXR++uVoY3WFL
6okAn0VoffXIKTRGi++BqVSIDMYiFkGw
=CRFK
-----END PGP SIGNATURE-----

From cmpalmer at metalab.unc.edu  Wed Apr  9 05:55:10 2008
From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer)
Date: Tue, 8 Apr 2008 23:55:10 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
Message-ID: <20080409035510.GC9880@garp.metalab.unc.edu>

On Tue, Apr 08, 2008 at 11:08:57PM -0400, Barry Warsaw wrote:
> 
> One other question you raise: I would like to move the bug trackers  
> off of SourceForge at some point.  I think Jira is no longer a viable  
> option, so we should consider alternatives.  Once again, Launchpad  
> seems a natural

Launchpad++

Slowness aside, that platform looks like a perfect fit.

If people reeeaaaally don't like that idea, I know a certain .org that
might host other tracking software for the mailman team....

Cheers,
-- 
Crist?bal Palmer
ibiblio.org systems administrator

From cmpalmer at metalab.unc.edu  Wed Apr  9 06:03:48 2008
From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer)
Date: Wed, 9 Apr 2008 00:03:48 -0400
Subject: [Mailman-Developers] [Mailman-i18n]
	[Mailman-Users]	[Mailman-Announce] Updated message catalogs
	needed for Mailman	2.1.10
In-Reply-To: <98D2BAD2-4EC1-4495-ACB9-DA305EC99E47@list.org>
References: <47D31C99.10103@msapiro.net>
	<Pine.A41.4.58.0803100949150.782356@beluga.user.services.metu.edu.tr>
	<p06240800c3fb93a0f72f@[192.168.1.199]>
	<90B310F8-E15B-46ED-AE64-DA2A67637B70@riverland.net.au>
	<98D2BAD2-4EC1-4495-ACB9-DA305EC99E47@list.org>
Message-ID: <20080409040348.GD9880@garp.metalab.unc.edu>

On Tue, Apr 08, 2008 at 11:14:12PM -0400, Barry Warsaw wrote:
>
> Would anybody out there be willing and able to run a reliable Pootle  
> server for us?

ibiblio can very likely host it. Please contact me off-list.

Cheers,
-- 
Crist?bal Palmer
ibiblio.org systems administrator

From stanabe at uwo.ca  Wed Apr  9 06:28:04 2008
From: stanabe at uwo.ca (Satoshi Tanabe)
Date: Wed, 9 Apr 2008 13:28:04 +0900
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
Message-ID: <42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>

Thanks Barry for your comments and thoughts. I waited for your reply :-)

Several comments on what you said:

* I used gedit to create all the html files, so "pages being build
using non-free software" is not an issue at least with my part.

* As you pointed out, which Wiki to use, whether to use a non-free
wiki service, and which content should be placed in the wiki site all
remain an issue.

* All color scheme is defined in the CSS file, so changing the color
scheme should be trivial. (And no, I'm not insisting using green
instead of the current color scheme :-) It just happened to be.)

* Thanks for the comment on the Jira no longer being an option. I'll
update that part.

- Satoshi


2008/4/9, Barry Warsaw <barry at list.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On Mar 10, 2008, at 11:10 PM, Satoshi Tanabe wrote:
>
> >
> > Currently I'm creating an unofficial site of GNU Mailman. It's not
> > done yet, but the goal is to make the current official site more
> > accessible and usable. The content is almost the same.
> >
>
>  Satoshi, this is very cool.  I'm sorry for not responding sooner, but I
> think it would be great to flesh these ideas out more, probably with Terri's
> help.
>
>  I think you've accurately identified some of the problems with the current
> web site. It's also true that we're building it with 1996 technology and web
> design sensibility (not unlike Mailman's web u/i ;).
>
>  I do think it's important to consider that the tools used to build the site
> be free software.  I'd like people to be able to hack the web building tools
> just like they can hack the software.
>
>  It's also important to consider what information is better suited for the
> wiki and what is better suited for the static main site.  I agree that
> there's a lot of duplication of information, and I tend to think that a
> large amount of that belongs on the wiki instead.  Relying heavily on the
> wiki[1] allows the entire community to participate, and as Terri has shown,
> even the documentation written on the wiki can be exported to other formats
> that are more easily printed.
>
>  I would like to keep some of the same color schemes and logos we currently
> use, unless there is a strong desire to update them.  I still like the logo
> though. :)
>
>  One other question you raise: I would like to move the bug trackers off of
> SourceForge at some point.  I think Jira is no longer a viable option, so we
> should consider alternatives.  Once again, Launchpad seems a natural, but
> I'm open to suggestions, given our constraints (we don't currently have the
> resources to maintain our own tracker instances).
>
>  - -Barry
>
>  [1] Admittedly the wiki is not running on free software.  As much as I like
> Confluence, this is an issue for a GNU project like Mailman.  However, again
> I don't think we yet have the resources to maintain our own wiki, let alone
> import the existing content into a free wiki.  IMO, having a non-free wiki
> is more useful to the community than not having a wiki at all, but I'm open
> to volunteers coming forward to help rectify the situation.
>
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkf8M0kACgkQ2YZpQepbvXF+KgCdHj+qTjuKUif76FlgcJ+kMKZQ
>  wP4AnRlb3Fesrv7YU2Ekqy95x8nDlDOO
>  =vtTq
>  -----END PGP SIGNATURE-----
>

From amk at amk.ca  Wed Apr  9 13:59:57 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 9 Apr 2008 07:59:57 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
Message-ID: <20080409115957.GA5988@amk-desktop.matrixgroup.net>

On Tue, Apr 08, 2008 at 11:08:57PM -0400, Barry Warsaw wrote:
> [1] Admittedly the wiki is not running on free software.  As much as I  
> like Confluence, this is an issue for a GNU project like Mailman.   
> However, again I don't think we yet have the resources to maintain our  
> own wiki, let alone import the existing content into a free wiki.   

wiki.python.org could certainly host another wiki.  About importing
the existing content: is it possible to obtain a dump of all the
existing wiki pages from Confluence, or would we need to crawl it?

--amk


From iane at sussex.ac.uk  Wed Apr  9 20:42:17 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 09 Apr 2008 19:42:17 +0100
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That
 Thing	Alone)
In-Reply-To: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
Message-ID: <317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>



--On 8 April 2008 22:10:58 -0400 Barry Warsaw <barry at list.org> wrote:

> After far too long, I'm finally happy to announce the availability of
> GNU Mailman version 3.0 alpha 1, code name "Leave That Thing Alone".

This is great news.

I've downloaded the code, and had a look at the LMTP server code, which I'm 
looking forward to. I'm hoping that it will permit integration with Exim in 
a way (LMTP call forwards) that gives us something sensible to do with 
messages from forbidden posters.

Unfortunately, it doesn't. But, if the following seems sensible, then I'm 
willing to implement it:

The LMTP server is implemented as a subclass of Python's built in 
SMTPServer, which seems to have only one method: process_message. That must 
be run too late to give any useful information to a callforward. However, 
on closer inspection, there's a "channel" class which inherits from 
smtpd.SMTPChannel. This seems to override some useful looking methods:

    def smtp_LHLO(self, arg):
    def smtp_HELO(self, arg):

Ah, and the source suggests to me that overriding smtp_RCPT is feasible. 
That's the place to check whether the list exists (and whether the sender 
is permitted to post - but let's do one thing at a time).

Validating the recipient
------------------------

All that's required is that the code which checks the existence of a list 
is moved from process_message to smtp_RCPT, and it's modified to 
"self.__rcpttos.append(address)" when the address is valid, but not 
otherwise. Thus, we build rcpttos instead of reading from it. LMTP requires 
a reply after DATA for only those addresses that haven't been rejected at 
RCPT. If I'm reading the code correctly, then a 550 error would be 
generated if the queue disappeared between RCTP and DATA (by virtue of the 
exception being thrown by queue.enqueue().

Validating the sender
---------------------

Now, as to the question of determining whether the message sender is 
permitted to post to a list, that's a bit more complicated. As far as I can 
see, all the logic for this is in moderate.py - in the "process" function. 
But, the decision is all tangled up with with the actions.

I propose an additional function, to be called from process, or by the lmtp 
server in smtp_RCPT: perhaps post_action(list, sender) which returns the 
name of the action to take when "sender" posts to the list "list". I guess 
it will return one of "accept", "discard", "reject", or "hold", and the 
lmtp server should reject (not bounce) the message if "reject" or "discard" 
is returned. It might be nice to introduce a distinction between bounce and 
reject. For example, a site admin might decide to permit bounce messages to 
be generated for local mail domains.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From justinlong at gmail.com  Wed Apr  9 05:16:35 2008
From: justinlong at gmail.com (Justin Long)
Date: Wed, 9 Apr 2008 11:16:35 +0800
Subject: [Mailman-Developers] Feature Request: an improvement to
	approve-by-email
Message-ID: <876ecebe0804082016x2d3e59b8t9fd10dc262350cde@mail.gmail.com>

Greetings,

My name is Justin Long, and I manage the website www.strategicnetwork.org.
We recently migrated to postfix/mailman from qmail/ezmlm because postfix had
better anti-spam features and qmail/ezmlm simply hadn't been updated in a
long while. We have about 400+ lists with about 160,000 subscribers. I've
been very pleased so far with mailman's performance and utility (although
admittedly the web interface leaves much to be desired--grin)

One thing I have noticed that I would like to suggest for a fix. When a post
comes into a moderated list, the bounce goes to the -owner address. It comes
with an email attachment that contains a confirmation code in the subject
line. This works great in an email client like Outlook. I, however, use
gmail as my primary email source, and the confirmation code comes in a
message buried in the message, not in the subject line.

Of course, if I hit "reply" it doesn't go to -requests. I think it either
goes to -bounce or -owner. In any event, it's not a simply reply-and-send
like it was in ezmlm.

So some suggestions:

1. Have the bounce message come to the owner from the -response address, for
easy reply

2. Don't require the confirmation code to be in the subject line

3. Why is the password required? I can sort of see this, and I don't mind it
too much, but wouldn't it be better to have perhaps an -approve and -reject
email address that can be clicked as a link? (not a web address but an email
address?) or something simple that doesn't require my remembering or typing
in the password?

I wouldn't mind #3 so much if #1 and #2 were fixed, so that all I have to do
is hit REPLY and type in "Approved: " and the password. As it is, in gmail,
I have to forward the email to the -response address, find-cut-paste the
confirmation code, and then type the address line.

This is a big deal for many of our members who are in significantly low
bandwidth situations or in places where they do not have web access, and
must moderate everything by email...

Cordially,
Justin Long

-- 
Never retreat. Never surrender. Never cut a deal with a dragon.
-------
Justin Long / justinlong at gmail.com
http://www.strategicnetwork.org - 120,000 subscribers, 16,000 articles
http://www.momentum-mag.org - bi-monthly magazine on unreached peoples
http://www.momentum-mag.org/wiki - Missiopedia of Christian missions
MSNIM justinlong at strategicnetwork.org / Skype nsmjustinlong
-------
We help people build 6 things: Drive, Energy, Effort, Inspiration, Power,
Strength
-------
No armor? Unclean life? Then do not mess in the affairs of dragons,
for you are crunchy and taste good with ketchup.

From barry at list.org  Thu Apr 10 23:27:18 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 10 Apr 2008 17:27:18 -0400
Subject: [Mailman-Developers] Sibling list terminology (was Re: Mailman
	2.1.10b4 Released)
In-Reply-To: <47EBFEDF.2070805@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>	<36898B72F6D4423EF51C29C3@lewes.staff.uscs.susx.ac.uk>
	<7FE7A0C5-4EDF-441F-B01E-5F286A74BAEA@list.org>
	<47EBFEDF.2070805@msapiro.net>
Message-ID: <3C5ED03F-4591-49FB-9C06-8386E5D9CAC8@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 27, 2008, at 4:09 PM, Mark Sapiro wrote:

> The actual word "sibling" appears in a few places. It is in the  
> title of
> the subsection for configuring regular_(in|ex)clude_lists, and is
> mentioned in the detailed help for these settings in the phrase "site
> administrator may prohibit cross domain siblings". It is also in the
> configuration variable ALLOW_CROSS_DOMAIN_SIBLING.
>
> I would be reluctant to change this for 2.1.10 because the existing
> strings have been translated in a few updates, and I have been  
> actively
> trying to keep from making any further changes to i18n strings.
>
> As far as whether the 'sibling' relationship is symmetric or
> antisymmetric, this is a question that can only be answered if the
> definition of the relationship is precise enough. There are at least  
> two
> possible definitions that make sense to me.
>
> 1) List A is a sibling of list B iff list A appears in one of list B's
> regular_(in|ex)clude_lists attributes.
>
> 2) List A is a sibling of List B iff list A appears in one of list B's
> regular_(in|ex)clude_lists attributes or list B appears in one of list
> A's regular_(in|ex)clude_lists attributes.
>
> Under definition 1), the 'sibling' relationship is neither symmetric  
> nor
> antisymmetric. Under definition 2), the 'sibling' relationship is
> symmetric and not antisymmetric.

I agree that it's too late to change this in 2.1.10, which probably  
means it's too late to change for 2.1.  I think you're follow up  
rationale indicates that "sibling" is probably an acceptable term for  
the feature given one way of looking at it, and because we have  
nothing better. ;)

> As far as a list being in it's own regular_(in|ex)clude_lists, as a
> result of Ian's original post, I changed the GUI to not allow it and
> changed the handler to ignore it, but log it.

Great, thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf+hjkACgkQ2YZpQepbvXEvFgCeJ3DPzLz+O46yRAxIZ4AVDJ/R
3KUAn34PSpL3WLrW6NaidzRFRgOJR7yP
=B80W
-----END PGP SIGNATURE-----

From barry at list.org  Thu Apr 10 23:45:23 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 10 Apr 2008 17:45:23 -0400
Subject: [Mailman-Developers] Done.
In-Reply-To: <47EBD57F.3070204@netconsonance.com>
References: <47EBD57F.3070204@netconsonance.com>
Message-ID: <6D36B091-4CC1-4DF1-AD05-7F837200A426@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 27, 2008, at 1:12 PM, Jo Rhett wrote:
> I've been incredibly tolerant of being abused on this issue for 3  
> weeks
> now, but the now-constant flood of people coming forward to say that  
> I'm
> not respecting the mailman community is too funny.  It breaks the  
> bounds
> of reality.
>
> *I* did one thing.  I pointed out an issue that *EVERYONE* knows  
> about,
> even the non-technical news media.  I asked that something be done  
> soon.
>  I wrote my post clearly and politely.
>
> http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html
>
> Did I receive a respectful response addressing these issues from  
> anyone
> who writes code for the project?
>
> Yes: Mark Sapiro wrote me a respectful reply on March 5.

I'd have been shocked if that wasn't the case.

> I had a nice dinner with a number of people last night on this topic,
> and not a single person (all of whom witnessed this thread) felt that
> trying to address this issue here was producing any results.
>
> So I am done.  Keep your derision to yourself, and keep wasting time
> telling people how they should respect you rather than solve the  
> problem.
>
> I am right now updating our AUP documentation to mention that  
> Mailman is
> explicitly banned unless the person provides documentation of the
> configuration/patches they have applied to prevent backscatter.  I am
> notifying the known mailman sites within our network.  We are done  
> with
> this issue.

I'm sorry that it had to come to this for you, but suffice to say that  
the issue /will/ be addressed, though maybe not as timely or in the  
manner that you would like to see.  I think our position is entirely  
consistent with overall good project management principles, which have  
to weigh conflicting requirements and make reasoned compromises.

Such is the nature of all-volunteer open source projects, and of  
course forks are always possible.  Today, they can be as constructive  
and collaborative as Bazaar branches make possible.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf+incACgkQ2YZpQepbvXH5kwCeNc2OWEEzjkeGGhWFDBvNZxiz
D68Anjci56WNCjseTByw6Thx1oLJa+kQ
=8SpO
-----END PGP SIGNATURE-----

From barry at list.org  Fri Apr 11 00:40:32 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 10 Apr 2008 18:40:32 -0400
Subject: [Mailman-Developers] [Mailman-Users] Encrypted mailing lists
In-Reply-To: <47EFDE48.8010504@indymedia.org>
References: <47EFDE48.8010504@indymedia.org>
Message-ID: <C00B68FC-0A85-48B8-8EC0-599DE37A224B@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm moving this discussion to mailman-developers.

On Mar 30, 2008, at 2:39 PM, Alster wrote:
>
> I have been repeatedly tempted to sum up options of setting up  
> encrypted
> mailing lists, with or without using GNU Mailman.
>
> As such, only these options listed in my previous summary remain:
>
> * mailman-ssls, a Mailman-Patch which has recently been updated for
>  Mailman 2.1.9 compatibility:
>  http://non-gnu.uvt.nl/mailman-ssls/
>
> * firma, a standalone encrypted mailinglist server (written in bash):
>  http://codecoop.org/projects/firma/
>
>
> Additionally, there are these options which had not been part of the
> last overview:
>
> * MMReencrypt, another Mailman patch
> https://sourceforge.net/projects/mmreencrypt/
> no longer maintained
>
> * Schleuder, a standalone 'crypto mailinglist'
> http://codecoop.org/projects/schleuder/
> still maintained (according to their versioning system), but last
> release dates back to 2006

I don't have time right now to look at these, however I would really  
like to support some form of encrypted mailing lists for Mailman 3, if  
not also 2.2.  It isn't possible to add this feature to Mailman 2.1.

If you're interested in working on this, it would be good to capture  
some requirements and use cases in the wiki.  If you wanted to do a  
survey of the approaches and implementations that have gone before,  
that would also help.  Ideally, some folks would be motivated enough  
to start developing some branches in Bazaar so that we can take a  
look, with an eye toward supporting the feature officially in a future  
release.

Feel free to discuss further on this mailing list.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf+l2EACgkQ2YZpQepbvXFFBQCdFY+07fgyROIVGUVInd1+Zhph
HBkAnjuh78SV2DzvEtchN0CAFLeoXkjE
=iaw1
-----END PGP SIGNATURE-----

From barry at list.org  Fri Apr 11 04:52:49 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 10 Apr 2008 22:52:49 -0400
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That
	Thing	Alone)
In-Reply-To: <317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
Message-ID: <898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 9, 2008, at 2:42 PM, Ian Eiloart wrote:
> --On 8 April 2008 22:10:58 -0400 Barry Warsaw <barry at list.org> wrote:
>
>> After far too long, I'm finally happy to announce the availability of
>> GNU Mailman version 3.0 alpha 1, code name "Leave That Thing Alone".
>
> This is great news.
>
> I've downloaded the code, and had a look at the LMTP server code,  
> which I'm looking forward to. I'm hoping that it will permit  
> integration with Exim in a way (LMTP call forwards) that gives us  
> something sensible to do with messages from forbidden posters.
>
> Unfortunately, it doesn't. But, if the following seems sensible,  
> then I'm willing to implement it:

Hi Ian, I'm really psyched that you've taken a look and are interested  
in fleshing this part of LMTP out.  I didn't have time for it before  
getting 3.0a1 out, but I did think about it, so let me outline how I  
was thinking of doing it.  I'm definitely open to other approaches if  
it makes the feature work better.

> The LMTP server is implemented as a subclass of Python's built in  
> SMTPServer, which seems to have only one method: process_message.  
> That must be run too late to give any useful information to a  
> callforward.

IIRC, this is going to be called when the "\r\n.\r\n" terminator to  
the DATA command is seen.  That might be an interesting place to hook  
in content filtering.

> However, on closer inspection, there's a "channel" class which  
> inherits from smtpd.SMTPChannel. This seems to override some useful  
> looking methods:
>
>   def smtp_LHLO(self, arg):
>   def smtp_HELO(self, arg):
>
> Ah, and the source suggests to me that overriding smtp_RCPT is  
> feasible. That's the place to check whether the list exists (and  
> whether the sender is permitted to post - but let's do one thing at  
> a time).
>
> Validating the recipient
> ------------------------
>
> All that's required is that the code which checks the existence of a  
> list is moved from process_message to smtp_RCPT, and it's modified  
> to "self.__rcpttos.append(address)" when the address is valid, but  
> not otherwise. Thus, we build rcpttos instead of reading from it.  
> LMTP requires a reply after DATA for only those addresses that  
> haven't been rejected at RCPT. If I'm reading the code correctly,  
> then a 550 error would be generated if the queue disappeared between  
> RCTP and DATA (by virtue of the exception being thrown by  
> queue.enqueue().

We probably want to refactor the code that splits the recipient  
address into a separate method, this would validate the fqdn list name  
and subaddress, but it wouldn't instantiate a Switchboard object.   
Might as well skip that if the message isn't going to get delivered.   
If everything looks good, store the fqdn listname and subaddress in  
self._rcpttos (no need for double underscore) and then  
process_message() can iterate over that and create the Switchboard  
instance.  If the recipient is not valid, store a marker object  
instead so that it can be compared against in the self._rcpttos loop  
in process_message().  When that loop sees the marker object, it  
appends an ERR_550 without bothering to create the Switchboard instance.

> Validating the sender
> ---------------------
>
> Now, as to the question of determining whether the message sender is  
> permitted to post to a list, that's a bit more complicated. As far  
> as I can see, all the logic for this is in moderate.py - in the  
> "process" function. But, the decision is all tangled up with with  
> the actions.
>
> I propose an additional function, to be called from process, or by  
> the lmtp server in smtp_RCPT: perhaps post_action(list, sender)  
> which returns the name of the action to take when "sender" posts to  
> the list "list". I guess it will return one of "accept", "discard",  
> "reject", or "hold", and the lmtp server should reject (not bounce)  
> the message if "reject" or "discard" is returned. It might be nice  
> to introduce a distinction between bounce and reject. For example, a  
> site admin might decide to permit bounce messages to be generated  
> for local mail domains.

That's not the way I was thinking about doing it.  Although you can't  
really tell, pipeline/moderate.py is obsolete and will likely go  
away.  It doesn't fit the current model where moderation occurs by  
rule-chain processing in the incoming queue, and the pipeline queue  
runs handlers which only modify already accepted messages.  I really  
should have moved moderate.,py to an attic because there are bits I  
still want to convert, but just haven't gotten to yet.

Originally, I was thinking we could just define an IChain which could  
be used in the lmtp runner.  This new chain would be specifically  
defined to run a smaller set of rules that would validate the sender,  
or do other early filtering.  But there's a problem with that because  
the interface to IChain and IRule takes three arguments, the mailing  
list, the message, and the message metadata dictionary.

One problem is that until you get to process_message() -- i.e. you've  
seen the DATA terminating dot), you won't have a message object, and  
many of the rules you're going to want require a message object.  You  
could get around that by defining some custom rules that ignored the  
'msg' argument, and you could put everything you know so far in the  
msgdata dictionary.  These rules would only work then in the lmtp  
runner.

For the mlist argument, you probably need to run the rule-chain for  
each RCPT TO.  Because you've already determined that it's a valid  
mailing list above, you get the mailing list object and use that in  
the rule chain.  It would therefore be possible to reject the message  
for list A but accept it for list B.  I think you want to return a 553  
if you're going to reject the recipient.

Upshot is that in thinking about this, I think it's doable using the  
rule-chain architecture during the smpt_RCPT call.

Does the above make sense?  If you decide to work on it, I'd be happy  
to help answer ore specific questions, and of course review the code.   
I'm not opposed to making some architectural changes to suit this  
better, but I'd want to think about them carefully, and would prefer  
to fit it into the current model.  We'd also need doctest for the  
feature and any other changes you make.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkf+0oEACgkQ2YZpQepbvXH8SwCeL86BhmoIrur6Kbbapt8pMkJt
gsoAn0v95kRIfMczhTJb9qu+Ighbha+K
=JNvC
-----END PGP SIGNATURE-----

From justinlong at gmail.com  Fri Apr 11 10:29:45 2008
From: justinlong at gmail.com (Justin Long)
Date: Fri, 11 Apr 2008 16:29:45 +0800
Subject: [Mailman-Developers] Question on pulling list variables
Message-ID: <876ecebe0804110129g352f6e14y8e1c98fdccfba487@mail.gmail.com>

Greetings,

this may be entirely the wrong place to ask this question, and if so I
apologize.

While integrating mailman with our website, I am trying to integrate
in our browse mode. When browsing lists, we generally try to show
users the following pieces of data:

Mailing List 	Subscriptions 	Postings 	Publicity 	Access
(listname)     (moderated/open)     (moderated/open)
(advertised/not)    (person's access to the list)

The only way I can see to pull this data is by using config_list. I've
actually recoded this (my_config) to drop the comment fields since all
I need is the variables and the values. But really, I only need very
specific variables and values.

Has anyone come up with a simple way to either (a) directly access the
configuration files for a given list from PHP or (b) used withlist
(I'm not a Python programmer, so I'm hitting my brain against a wall
right now... for anything advanced) to pull specific variables?

Is there a patch or some little piece of open source code somewhere
that can help me with this problem?

Config_list seems to work ok but it is taking a lot of compute cycles
to run it against 20 lists in a row on a browse screen...

Cordially,
Justin Long

-- 
Never retreat. Never surrender. Never cut a deal with a dragon.
-------
Justin Long / justinlong at gmail.com
http://www.strategicnetwork.org - 120,000 subscribers, 16,000 articles
http://www.momentum-mag.org - bi-monthly magazine on unreached peoples
http://www.momentum-mag.org/wiki - Missiopedia of Christian missions
MSNIM justinlong at strategicnetwork.org / Skype nsmjustinlong
-------
We help people build 6 things: Drive, Energy, Effort, Inspiration,
Power, Strength
-------
No armor? Unclean life? Then do not mess in the affairs of dragons,
for you are crunchy and taste good with ketchup.

From iane at sussex.ac.uk  Fri Apr 11 15:30:26 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 11 Apr 2008 14:30:26 +0100
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That
 Thing	Alone)
In-Reply-To: <898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
Message-ID: <614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>



--On 10 April 2008 22:52:49 -0400 Barry Warsaw <barry at list.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Apr 9, 2008, at 2:42 PM, Ian Eiloart wrote:
>> --On 8 April 2008 22:10:58 -0400 Barry Warsaw <barry at list.org> wrote:
>>
>>> After far too long, I'm finally happy to announce the availability of
>>> GNU Mailman version 3.0 alpha 1, code name "Leave That Thing Alone".
>>
>> This is great news.
>>
>> I've downloaded the code, and had a look at the LMTP server code,
>> which I'm looking forward to. I'm hoping that it will permit
>> integration with Exim in a way (LMTP call forwards) that gives us
>> something sensible to do with messages from forbidden posters.
>>
>> Unfortunately, it doesn't. But, if the following seems sensible,
>> then I'm willing to implement it:
>
> Hi Ian, I'm really psyched that you've taken a look and are interested in
> fleshing this part of LMTP out.  I didn't have time for it before getting
> 3.0a1 out, but I did think about it, so let me outline how I was thinking
> of doing it.  I'm definitely open to other approaches if it makes the
> feature work better.
>
>> The LMTP server is implemented as a subclass of Python's built in
>> SMTPServer, which seems to have only one method: process_message.
>> That must be run too late to give any useful information to a
>> callforward.
>
> IIRC, this is going to be called when the "\r\n.\r\n" terminator to the
> DATA command is seen.  That might be an interesting place to hook in
> content filtering.

Yes, that's the earliest opportunity to filter content. It also allows the 
LTMP server to accept the message for some lists, but not others. It 
doesn't help the local SMTP server, though, since it's too late for an SMTP 
server to selectively reject.

Some admins may prefer this though. For example, I monitor my SMTP server 
queues more closely than my Mailman queues.

>> However, on closer inspection, there's a "channel" class which
>> inherits from smtpd.SMTPChannel. This seems to override some useful
>> looking methods:
>>
>>   def smtp_LHLO(self, arg):
>>   def smtp_HELO(self, arg):
>>
>> Ah, and the source suggests to me that overriding smtp_RCPT is
>> feasible. That's the place to check whether the list exists (and
>> whether the sender is permitted to post - but let's do one thing at
>> a time).
>>
>> Validating the recipient
>> ------------------------
>>
>> All that's required is that the code which checks the existence of a
>> list is moved from process_message to smtp_RCPT, and it's modified
>> to "self.__rcpttos.append(address)" when the address is valid, but
>> not otherwise. Thus, we build rcpttos instead of reading from it.
>> LMTP requires a reply after DATA for only those addresses that
>> haven't been rejected at RCPT. If I'm reading the code correctly,
>> then a 550 error would be generated if the queue disappeared between
>> RCTP and DATA (by virtue of the exception being thrown by
>> queue.enqueue().
>
> We probably want to refactor the code that splits the recipient address
> into a separate method, this would validate the fqdn list name and
> subaddress, but it wouldn't instantiate a Switchboard object.

Hmm, I don't know what a Switchboard object is.

> Might as well skip that if the message isn't going to get delivered.  If
> everything looks good, store the fqdn listname and subaddress in
> self._rcpttos (no need for double underscore) and then process_message()
> can iterate over that and create the Switchboard instance.

> If the  recipient is not valid, store a marker object instead so that it 
can be
> compared against in the self._rcpttos loop in process_message().

No, I don't think that's necessary. If we don't like the argument to RCPT 
we should say so with a 4xx or 5xx error, and then add NOTHING to 
self._rcpttos. The RFC only wants us to give a reply for addresses that 
made it past RCPT. It's crucial to get this right, because the returned 
list of codes isn't indexed, and therefore has to be matched up with the 
list of RCTP commands that didn't get a rejection.

If you look at the example here: 
<http://www.apps.ietf.org/rfc/rfc2033.html#sec-4.2>, there are three RCPT 
commands, but only two post-DATA responses.

Of course, we could say yes to everything at RCTP, but then our SMTP server 
callouts are pointless.

>  When that loop sees the marker object, it appends an ERR_550 without 
bothering
> to create the Switchboard instance.
>
>> Validating the sender
>> ---------------------
>>
>> Now, as to the question of determining whether the message sender is
>> permitted to post to a list, that's a bit more complicated. As far
>> as I can see, all the logic for this is in moderate.py - in the
>> "process" function. But, the decision is all tangled up with with
>> the actions.
>>
>> I propose an additional function, to be called from process, or by
>> the lmtp server in smtp_RCPT: perhaps post_action(list, sender)
>> which returns the name of the action to take when "sender" posts to
>> the list "list". I guess it will return one of "accept", "discard",
>> "reject", or "hold", and the lmtp server should reject (not bounce)
>> the message if "reject" or "discard" is returned. It might be nice
>> to introduce a distinction between bounce and reject. For example, a
>> site admin might decide to permit bounce messages to be generated
>> for local mail domains.
>
> That's not the way I was thinking about doing it.  Although you can't
> really tell, pipeline/moderate.py is obsolete and will likely go away.
> It doesn't fit the current model where moderation occurs by rule-chain
> processing in the incoming queue, and the pipeline queue runs handlers
> which only modify already accepted messages.  I really should have moved
> moderate.,py to an attic because there are bits I still want to convert,
> but just haven't gotten to yet.
>
> Originally, I was thinking we could just define an IChain which could be
> used in the lmtp runner.  This new chain would be specifically defined to
> run a smaller set of rules that would validate the sender, or do other
> early filtering.  But there's a problem with that because the interface
> to IChain and IRule takes three arguments, the mailing list, the message,
> and the message metadata dictionary.
>
> One problem is that until you get to process_message() -- i.e. you've
> seen the DATA terminating dot), you won't have a message object, and many
> of the rules you're going to want require a message object.  You could
> get around that by defining some custom rules that ignored the 'msg'
> argument, and you could put everything you know so far in the msgdata
> dictionary.  These rules would only work then in the lmtp runner.

Or, could you pass an empty message? I guess not if a list is configured to 
reject implicit recipients, for example.

> For the mlist argument, you probably need to run the rule-chain for each
> RCPT TO.  Because you've already determined that it's a valid mailing
> list above, you get the mailing list object and use that in the rule
> chain.  It would therefore be possible to reject the message for list A
> but accept it for list B.  I think you want to return a 553 if you're
> going to reject the recipient.
>
> Upshot is that in thinking about this, I think it's doable using the
> rule-chain architecture during the smpt_RCPT call.

That's good news.

> Does the above make sense?

To an extent. I know now that I was wise to ask before ploughing on!

The first part seems quite easy to do, and has the significant gain for me 
that it allows me to put my Mailman server on a different host from my MTA. 
Currently, my MTA is looking for the existence of the Mailman files for 
routing purposes. Calling out to the LMTP server is a much more flexible 
solution.

The second part - screening senders seems harder at the moment, because I 
don't understand how the chains work. I'll take another look, but a brief 
explanation of the concept, and how they're called would be useful.

>  If you decide to work on it, I'd be happy to
> help answer ore specific questions, and of course review the code.  I'm
> not opposed to making some architectural changes to suit this better,

Hmm, well if we can't do stuff at RCPT time, then I think the architecture 
is flawed. Whether its reasonably easy to fix, I can't tell.

I think it's really important to separate out the code for determining 
whether a sender can post to a list. In my experience, it's the only test 
that (a) users really understand and (b) is really useful.

It's also important to because it helps us to decide whether we are safe to 
generate a bounce message, in the event that the message content is bad. 
I'd argue that it usually is safe when the sender is a member of the list, 
but usually not otherwise. That still leaves us with a problem for open 
lists, but no worse a problem than we already have.

> but I'd want to think about them carefully, and would prefer to fit it 
into
> the current model.  We'd also need doctest for the feature and any other
> changes you make.

Oh, I guess I'll have to do some proper learning, then!

>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkf+0oEACgkQ2YZpQepbvXH8SwCeL86BhmoIrur6Kbbapt8pMkJt
> gsoAn0v95kRIfMczhTJb9qu+Ighbha+K
> =JNvC
> -----END PGP SIGNATURE-----



-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From mark at msapiro.net  Fri Apr 11 18:58:26 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 11 Apr 2008 09:58:26 -0700
Subject: [Mailman-Developers] Question on pulling list variables
In-Reply-To: <876ecebe0804110129g352f6e14y8e1c98fdccfba487@mail.gmail.com>
Message-ID: <PC17602008041109582602506f1aef74@msapiro>

Justin Long wrote:
>
>While integrating mailman with our website, I am trying to integrate
>in our browse mode. When browsing lists, we generally try to show
>users the following pieces of data:
>
>Mailing List 	Subscriptions 	Postings 	Publicity 	Access
>(listname)     (moderated/open)     (moderated/open)
>(advertised/not)    (person's access to the list)
>
>The only way I can see to pull this data is by using config_list. I've
>actually recoded this (my_config) to drop the comment fields since all
>I need is the variables and the values. But really, I only need very
>specific variables and values.
>
>Has anyone come up with a simple way to either (a) directly access the
>configuration files for a given list from PHP or (b) used withlist
>(I'm not a Python programmer, so I'm hitting my brain against a wall
>right now... for anything advanced) to pull specific variables?
>
>Is there a patch or some little piece of open source code somewhere
>that can help me with this problem?
>
>Config_list seems to work ok but it is taking a lot of compute cycles
>to run it against 20 lists in a row on a browse screen...


You could try using

bin/dumpdb lists/listname/config.pck

instead of config_list. That should be a little quicker; possibly
quicker even than a withlist script.

Although, if you were to use bin/withlist -a rather than invoking
bin/dumpdb separately for each list, that might be better.

Consider get_data.py as follows:

def get_data(mlist, user):
    print "Mailing List: %s" % mlist.real_name
    print "Subscribe Policy: %d" % mlist.subscribe_policy
    print "Default Moderation: %s" % mlist.default_member_moderation
    print "Advertised: %s" % mlist.advertised
    print "%s is member: %s" % (user, mlist.isMember(user))

and run by

bin/withlist -a -r get_data -- user at example.com

That's probably not really what you want as I had to guess what you
meant by "Postings" and "Access" and my guesses gave some things that
aren't available from config_list.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From barry at list.org  Sat Apr 12 17:18:09 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 11:18:09 -0400
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That
	Thing	Alone)
In-Reply-To: <614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
Message-ID: <73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 11, 2008, at 9:30 AM, Ian Eiloart wrote:

>> IIRC, this is going to be called when the "\r\n.\r\n" terminator to  
>> the
>> DATA command is seen.  That might be an interesting place to hook in
>> content filtering.
>
> Yes, that's the earliest opportunity to filter content. It also  
> allows the LTMP server to accept the message for some lists, but not  
> others. It doesn't help the local SMTP server, though, since it's  
> too late for an SMTP server to selectively reject.
>
> Some admins may prefer this though. For example, I monitor my SMTP  
> server queues more closely than my Mailman queues.

So you mean that most SMTPd's will have accepted the message by they  
time they issue the DATA to the LMTP?  If that's the case, then does  
it even make sense to do content filtering at that step in LMTP, given  
that we'll still be doing the full-blown rule matching in the incoming  
runner?

>>> However, on closer inspection, there's a "channel" class which
>>> inherits from smtpd.SMTPChannel. This seems to override some useful
>>> looking methods:
>>>
>>>  def smtp_LHLO(self, arg):
>>>  def smtp_HELO(self, arg):
>>>
>>> Ah, and the source suggests to me that overriding smtp_RCPT is
>>> feasible. That's the place to check whether the list exists (and
>>> whether the sender is permitted to post - but let's do one thing at
>>> a time).
>>>
>>> Validating the recipient
>>> ------------------------
>>>
>>> All that's required is that the code which checks the existence of a
>>> list is moved from process_message to smtp_RCPT, and it's modified
>>> to "self.__rcpttos.append(address)" when the address is valid, but
>>> not otherwise. Thus, we build rcpttos instead of reading from it.
>>> LMTP requires a reply after DATA for only those addresses that
>>> haven't been rejected at RCPT. If I'm reading the code correctly,
>>> then a 550 error would be generated if the queue disappeared between
>>> RCTP and DATA (by virtue of the exception being thrown by
>>> queue.enqueue().
>>
>> We probably want to refactor the code that splits the recipient  
>> address
>> into a separate method, this would validate the fqdn list name and
>> subaddress, but it wouldn't instantiate a Switchboard object.
>
> Hmm, I don't know what a Switchboard object is.

The Switchboard object represents a queue's directory.  It's the class  
that handles enqueuing and dequeuing message pickles from that  
directory.

>> Might as well skip that if the message isn't going to get  
>> delivered.  If
>> everything looks good, store the fqdn listname and subaddress in
>> self._rcpttos (no need for double underscore) and then  
>> process_message()
>> can iterate over that and create the Switchboard instance.
>
>> If the  recipient is not valid, store a marker object instead so  
>> that it
> can be
>> compared against in the self._rcpttos loop in process_message().
>
> No, I don't think that's necessary. If we don't like the argument to  
> RCPT we should say so with a 4xx or 5xx error, and then add NOTHING  
> to self._rcpttos.

Yep.  I wasn't thinking clearly when I wrote the above.  You're  
absolutely right.

> The RFC only wants us to give a reply for addresses that made it  
> past RCPT. It's crucial to get this right, because the returned list  
> of codes isn't indexed, and therefore has to be matched up with the  
> list of RCTP commands that didn't get a rejection.
>
> If you look at the example here: <http://www.apps.ietf.org/rfc/rfc2033.html#sec-4.2 
> >, there are three RCPT commands, but only two post-DATA responses.
>
> Of course, we could say yes to everything at RCTP, but then our SMTP  
> server callouts are pointless.
>> One problem is that until you get to process_message() -- i.e. you've
>> seen the DATA terminating dot), you won't have a message object,  
>> and many
>> of the rules you're going to want require a message object.  You  
>> could
>> get around that by defining some custom rules that ignored the 'msg'
>> argument, and you could put everything you know so far in the msgdata
>> dictionary.  These rules would only work then in the lmtp runner.
>
> Or, could you pass an empty message? I guess not if a list is  
> configured to reject implicit recipients, for example.

Actually, this occurred to me to, and I do think it would work.  You  
have limited information at that point, but enough to create a bare- 
bones Message instance that can satisfy the interface.  You just have  
to be careful not to put any rules into that chain that require  
information you don't have at that point, but that should be fairly  
easy to do.

>> For the mlist argument, you probably need to run the rule-chain for  
>> each
>> RCPT TO.  Because you've already determined that it's a valid mailing
>> list above, you get the mailing list object and use that in the rule
>> chain.  It would therefore be possible to reject the message for  
>> list A
>> but accept it for list B.  I think you want to return a 553 if you're
>> going to reject the recipient.
>>
>> Upshot is that in thinking about this, I think it's doable using the
>> rule-chain architecture during the smpt_RCPT call.
>
> That's good news.
>
>> Does the above make sense?
>
> To an extent. I know now that I was wise to ask before ploughing on!
>
> The first part seems quite easy to do, and has the significant gain  
> for me that it allows me to put my Mailman server on a different  
> host from my MTA. Currently, my MTA is looking for the existence of  
> the Mailman files for routing purposes. Calling out to the LMTP  
> server is a much more flexible solution.
>
> The second part - screening senders seems harder at the moment,  
> because I don't understand how the chains work. I'll take another  
> look, but a brief explanation of the concept, and how they're called  
> would be useful.

All this is in the doctests (that's the beauty of testable  
documentation! :), but briefly:

You have rules, which have a check() method.  This method takes a  
mailing list, a message, and a metadata dictionary and it returns a  
boolean specifying whether the rule matched or not.  Rules are  
organized into chains, where each element of the chain is actually a  
"chain link".  The chain link ties a rule with an action.

Processing a chain is then just iterating over all the chain links,  
executing the rule in the link, and if the rule returns True,  
processing the action.  The actions are things like "jump to another  
chain", "take a detour through another chain", "stop processing this  
chain", "run some function".

So the idea is that we'll define a rule (or rules -- they should be as  
narrow as possible) that implements the "verify if this RCPT TO is  
acceptable", and an action that has a callable that says "set the RCPT  
TO return code", which is probably stored in the metadata dictionary   
There's probably a built-in such chain, and it may be YAGNI to allow  
per-list overrides.

So, you get the RCPT TO, you process the chain, grab the return code  
out of the metadata dictionary.  If it's a 250, you remember the  
recipient for later, and if not, you chuck it.

>> If you decide to work on it, I'd be happy to
>> help answer ore specific questions, and of course review the code.   
>> I'm
>> not opposed to making some architectural changes to suit this better,
>
> Hmm, well if we can't do stuff at RCPT time, then I think the  
> architecture is flawed. Whether its reasonably easy to fix, I can't  
> tell.

See above, I think we can.

> I think it's really important to separate out the code for  
> determining whether a sender can post to a list. In my experience,  
> it's the only test that (a) users really understand and (b) is  
> really useful.

It probably does make sense to refactor this out.  I can imagine the  
REST interface is going to want to ask the same question.

> It's also important to because it helps us to decide whether we are  
> safe to generate a bounce message, in the event that the message  
> content is bad. I'd argue that it usually is safe when the sender is  
> a member of the list, but usually not otherwise. That still leaves  
> us with a problem for open lists, but no worse a problem than we  
> already have.

There's something else that Mailman 3 allows us to do.  We can ask  
whether we know anything about the sender or not.  So she may not be a  
member of List A, but maybe she's a member of List B.  So when she  
posts to List A, we at least know that the sender is a real person.   
Maybe we send her a bounce, maybe we don't, but I think knowing that  
the site has a relationship with the sender can come in handy.

>> but I'd want to think about them carefully, and would prefer to fit  
>> it
> into
>> the current model.  We'd also need doctest for the feature and any  
>> other
>> changes you make.
>
> Oh, I guess I'll have to do some proper learning, then!

I hope the above helps!  Let me know if any the doctests don't make  
sense as documentation.

Good luck!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA0rQACgkQ2YZpQepbvXEbPQCeNBockJ6jmb9nugeGxT3t6017
Oo0An0SnGNW8Sn4+O9yfbZ9NGPO/sRFh
=ljz2
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:02:45 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:02:45 -0400
Subject: [Mailman-Developers] before next release: disable backscatterin
	default installation
In-Reply-To: <B164C61C31A5CD642DE0C048@lewes.staff.uscs.susx.ac.uk>
References: <PC17602008032509075602502bb10012@msapiro>
	<47E930FD.2000800@utu.fi>	<87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk>
	<87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk>
	<87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp>
	<6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk>
	<87r6duqtl1.fsf@uwakimon.sk.tsukuba.ac.jp>
	<B164C61C31A5CD642DE0C048@lewes.staff.uscs.susx.ac.uk>
Message-ID: <B991EA86-F816-44E2-ABC6-0F7CEEF40A76@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 31, 2008, at 6:15 AM, Ian Eiloart wrote:

> As far as DKIM is concerned, I think Mailman already can re-sign  
> messages.
> I don't remember the details, though. Anyway, I think re-signing is  
> the
> correct thing for a list to do. Again, Mailman is a winner here  
> because
> it's capable of doing such things.

IIRC, I think we decided that it was best to leave re-signing up to  
the local MTA that Mailman delivers to, and not have Mailman itself do  
the signing.  Or am I misremembering that?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA3SoACgkQ2YZpQepbvXGPtQCdE6ylXidmle/UkWVDjTWhp8Io
7nUAnjyVrFmWHSPUo0xDxaPINDZfgujS
=xCar
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:16:53 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:16:53 -0400
Subject: [Mailman-Developers] before next release: disable backscatter
	in default installation
In-Reply-To: <200803250933.13236.julian@mehnle.net>
References: <PC1760200803241845220812981736e2@msapiro>
	<6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com>
	<200803250933.13236.julian@mehnle.net>
Message-ID: <55F85FD3-4F7D-41A5-A076-99D1329919DC@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 25, 2008, at 5:33 AM, Julian Mehnle wrote:
> Jo Rhett wrote:
>> On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote:
>>> I still don't get what you mean by "properly deal with DSNs". Are  
>>> you
>>> saying that an MTA should never return a DSN? It should either  
>>> reject
>>> the mail during the incoming SMTP transaction or forever hold its
>>> piece?
>>
>> Yes.  And not just me, but a dozen different blacklists.  RTFM
>> "backscatter"
>
> You can however safely send a DSN if an SPF[1] check for the incoming
> message passes.
>
> 1. http://www.openspf.org

I've added this to http://wiki.list.org/display/DEV/Mailman+3.0

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA4HUACgkQ2YZpQepbvXEZzACfW4rQ+IZfnZL5i/JzqLLzhF9h
7Y4An1n+GCDzGKo4xuM/Ix5YJ9RWPgMv
=CoOu
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:18:58 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:18:58 -0400
Subject: [Mailman-Developers] before next release:	disable	backscatter
	indefault installation
In-Reply-To: <47E9CD2C.2060401@Newfield.org>
References: <E6C70824-2AD0-45B0-B8CB-7B146D1FFD07@netconsonance.com>	<PC1760200803041528220796684c8ad2@msapiro>	<20080305011346.GD5749@garp.metalab.unc.edu>	<87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp>	<A6E88D20-028F-4706-A2FB-FB5BC7EC93EA@netconsonance.com>	<87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp>
	<63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com>
	<47E9CD2C.2060401@Newfield.org>
Message-ID: <F3F396F3-C8C2-475F-BAB3-C3FC5C3A4845@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 12:12 AM, Dale Newfield wrote:
>>
> This is an open source project.  You are welcome to use it as is or
> modify it to your liking.  (I believe--someone confirm, please) you  
> even
> have the right to distribute your modified version.

Absolutely.  GNU Mailman is licensed under the GPLv2, which gives you  
this right as long as you preserve this right for anybody who receives  
your modified version.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA4PMACgkQ2YZpQepbvXEAsACeJnLA6tZM7KXSkawFw4UZWyTV
XA4An28f1nfZI0Ni9Tp1PkRkCV9nXCPJ
=VbXA
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:33:38 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:33:38 -0400
Subject: [Mailman-Developers] before next release: disable
	backscatter	in default installation
In-Reply-To: <2E24C30EA2CAFD42BCF9DC9A@lewes.staff.uscs.susx.ac.uk>
References: <PC1760200803241845220812981736e2@msapiro>
	<6C848D55-A86A-4E76-8510-D47CF866CB78@netconsonance.com>
	<D0DAD6B3-B1CE-42F0-9750-9A89531904B2@python.org>
	<2E24C30EA2CAFD42BCF9DC9A@lewes.staff.uscs.susx.ac.uk>
Message-ID: <D7CD04C5-7369-482B-8453-2609424F7B14@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 7:27 AM, Ian Eiloart wrote:
>
>>
>> I think you will be happier with what is possible in Mailman 3.  In
>> mm3 we have a working LMTP server, those it's based on asyncore and
>> its scalability is questionable.  Although I have not yet done  
>> this, I
>> plan to tie the rule chain checker into LMTP so that if your MTA
>> supports LMTP delivery the following can happen:
>>
>> worldwildwonderland -> SMTP -> MM's LMTP -> rule checks
>>
>> The rule checks then could tell LTMP to reject the message right
>> there, which would return 5xx to SMTP and /it/ would return 5xx to
>> whatever upstream SMTP its talking to.
>>
>> Now, I wouldn't want to do a lot of work at that point, but some
>> simple checks would definitely be possible.  You can reject messages
>> as early in the process as possible and do it at the SMTP layer.
>
> It needs to be done after RCPT TO.  LMTP allows you to sensibly do  
> this
> later, and get return codes for individual recipients. However, it  
> we're
> doing this with call forwards from an MTA which is receiving email  
> over
> SMTP, then the MTA will have to check the sender/recipient pair at  
> RCPT TO
> time.
>
> on connect:
> accept the connection
> HELO/EHLO:
> reject if the sending MTA isn't known
> MAIL FROM:
> accept (perhaps unless the sender address is forbidden to post to all
> lists).
> RCPT TO:
> accept if the sender has permissions to post to the list, otherwise  
> reject.
> This is the last chance to give a list specific response to an MTA  
> that is
> engaged in a callout.
> DATA:
> reject null senders here if appropriate. Rejecting a null sender at  
> RCPT TO
> or earlier might break callouts.
> .............
> .
> Check the data, reject if inappropriate for a specific list (but  
> this is
> likely to cause a bounce from our MTA). Because we've decided to  
> trust the
> sender, we should be OK to bounce a message here, unless the list is  
> an
> open list.

This is great.  I've captured it on the wiki: http://wiki.list.org/display/DEV/LMTP+process

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA5GYACgkQ2YZpQepbvXGfyACdGdsEJtyQgevZWggi1kviroHr
GiEAoLQoEhQ+TV8CRr5NF9cKk6IkIddp
=WjHS
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:35:10 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:35:10 -0400
Subject: [Mailman-Developers] before next release:	disable	backscatter
	indefault installation
In-Reply-To: <2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com>
References: <E6C70824-2AD0-45B0-B8CB-7B146D1FFD07@netconsonance.com>	<PC1760200803041528220796684c8ad2@msapiro>	<20080305011346.GD5749@garp.metalab.unc.edu>	<87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp>	<A6E88D20-028F-4706-A2FB-FB5BC7EC93EA@netconsonance.com>	<87r6dze334.fsf@uwakimon.sk.tsukuba.ac.jp>
	<63F122FC-9CEA-4587-AE86-D393E3B22C75@netconsonance.com>
	<47E9CD2C.2060401@Newfield.org>
	<2928.64.13.143.30.1206558170.squirrel@mail.netconsonance.com>
Message-ID: <1D6FDE69-8DC8-455B-B974-EAD9EEF84BCD@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 26, 2008, at 3:02 PM, Jo Rhett wrote:

> You're missing the point.  I'm an Abuse Admin.  This isn't my  
> problem, nor
> is it my bidding.  If you run Mailman, this is *YOUR* problem.

Ah, Abuse is down the hall.  This is Getting Hit On The Head lessons  
in here.

pythonic-ly y'rs,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA5L4ACgkQ2YZpQepbvXESlgCghHqwW53Z528Efn2Yo7eA5rTd
H4EAnjRv/c+wtVkYc8wvAvQh7dmA827w
=7cMR
-----END PGP SIGNATURE-----

From barry at list.org  Sat Apr 12 18:44:49 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 12:44:49 -0400
Subject: [Mailman-Developers] before next release: disable	backscatter
	indefault installation
In-Reply-To: <5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk>
References: <E6C70824-2AD0-45B0-B8CB-7B146D1FFD07@netconsonance.com>
	<PC1760200803041528220796684c8ad2@msapiro>
	<20080305011346.GD5749@garp.metalab.unc.edu>
	<87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp>
	<A6E88D20-028F-4706-A2FB-FB5BC7EC93EA@netconsonance.com>
	<46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk>
	<1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com>
	<20080327001842.GN22377@garp.metalab.unc.edu>
	<47EBC9D8.3000403@netconsonance.com>
	<878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk>
Message-ID: <A77281AC-574C-4AA0-B7AF-E02AF4DAEA76@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 28, 2008, at 8:09 AM, Ian Eiloart wrote:
> How To Do Autoreplies Without The World Hating You
> <http://wiki.exim.org/EximAutoReply>
>
>
> UK Joint Academic Network provides network connectivity and services  
> for UK
> HE institutions, here's their guidance to victims of backscatter:
> <http://www.ja.net/services/csirt/advice/policies/collateral- 
> spam.html>
>
>
> A talk given at a UK Unix User Group meeting. Look for the 5th  
> abstract on
> this page:
> <http://www.ukuug.org/events/winter2005/programme.shtml>
>
>
> <http://www.dontbouncespam.org/>
> <http://spamlinks.net/prevent-secure-backscatter.htm>
>
> The inevitable "...considered harmful" article:
> <http://mayfirst.org/?q=node/180>

Thanks!  Capture here in the "best practices" section:

http://wiki.list.org/display/DEV/Home

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgA5wMACgkQ2YZpQepbvXFtWgCgorh/wuw9ASf7rTeSM1ouUXKE
WmkAnAlde9Y6Bg68vAbkjUx2cXKHJDnd
=d+qT
-----END PGP SIGNATURE-----

From mark at msapiro.net  Sat Apr 12 21:06:06 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 12 Apr 2008 12:06:06 -0700
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave
	ThatThing	Alone)
In-Reply-To: <73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
Message-ID: <PC1760200804121206060328b854afae@msapiro>

Barry Warsaw wrote:
>On Apr 11, 2008, at 9:30 AM, Ian Eiloart wrote:
>
>>> IIRC, this is going to be called when the "\r\n.\r\n" terminator to  
>>> the
>>> DATA command is seen.  That might be an interesting place to hook in
>>> content filtering.
>>
>> Yes, that's the earliest opportunity to filter content. It also  
>> allows the LTMP server to accept the message for some lists, but not  
>> others. It doesn't help the local SMTP server, though, since it's  
>> too late for an SMTP server to selectively reject.
>>
>> Some admins may prefer this though. For example, I monitor my SMTP  
>> server queues more closely than my Mailman queues.
>
>So you mean that most SMTPd's will have accepted the message by they  
>time they issue the DATA to the LMTP?  If that's the case, then does  
>it even make sense to do content filtering at that step in LMTP, given  
>that we'll still be doing the full-blown rule matching in the incoming  
>runner?


I don't think that's what Ian is saying. The key word is 'selectively'.
I.e. the SMTP server can still reject the incoming message, but once
it has seen the DATA, it can only reject the entire message; it can't
reject a subset of RCPTs.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Sat Apr 12 21:07:42 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 12 Apr 2008 12:07:42 -0700
Subject: [Mailman-Developers] before next release: disable
	backscatterindefault installation
In-Reply-To: <B991EA86-F816-44E2-ABC6-0F7CEEF40A76@list.org>
Message-ID: <PC1760200804121207420859b854b1e5@msapiro>

Barry Warsaw wrote:
>
>On Mar 31, 2008, at 6:15 AM, Ian Eiloart wrote:
>
>> As far as DKIM is concerned, I think Mailman already can re-sign  
>> messages.
>> I don't remember the details, though. Anyway, I think re-signing is  
>> the
>> correct thing for a list to do. Again, Mailman is a winner here  
>> because
>> it's capable of doing such things.
>
>IIRC, I think we decided that it was best to leave re-signing up to  
>the local MTA that Mailman delivers to, and not have Mailman itself do  
>the signing.  Or am I misremembering that?


That's my recollection too.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From barry at list.org  Sat Apr 12 21:21:55 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Apr 2008 15:21:55 -0400
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave
	ThatThing	Alone)
In-Reply-To: <PC1760200804121206060328b854afae@msapiro>
References: <PC1760200804121206060328b854afae@msapiro>
Message-ID: <643D6F81-47E4-4B77-A0CE-A21C136D8258@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 12, 2008, at 3:06 PM, Mark Sapiro wrote:
> Barry Warsaw wrote:
>> On Apr 11, 2008, at 9:30 AM, Ian Eiloart wrote:
>>
>>>> IIRC, this is going to be called when the "\r\n.\r\n" terminator to
>>>> the
>>>> DATA command is seen.  That might be an interesting place to hook  
>>>> in
>>>> content filtering.
>>>
>>> Yes, that's the earliest opportunity to filter content. It also
>>> allows the LTMP server to accept the message for some lists, but not
>>> others. It doesn't help the local SMTP server, though, since it's
>>> too late for an SMTP server to selectively reject.
>>>
>>> Some admins may prefer this though. For example, I monitor my SMTP
>>> server queues more closely than my Mailman queues.
>>
>> So you mean that most SMTPd's will have accepted the message by they
>> time they issue the DATA to the LMTP?  If that's the case, then does
>> it even make sense to do content filtering at that step in LMTP,  
>> given
>> that we'll still be doing the full-blown rule matching in the  
>> incoming
>> runner?
>
> I don't think that's what Ian is saying. The key word is  
> 'selectively'.
> I.e. the SMTP server can still reject the incoming message, but once
> it has seen the DATA, it can only reject the entire message; it can't
> reject a subset of RCPTs.


Ah, right, on the SMTP side.  LMTP can reject individual RCPTs, but  
the SMTP upstream of it can't.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgBC9cACgkQ2YZpQepbvXGxpwCgnIYYZNTyI0JGRyJ6xCbfCwxU
FJIAnju+uzmG6QKjPHbFRIvGM0Ol7vMH
=fPWI
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Mon Apr 14 13:52:33 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 14 Apr 2008 12:52:33 +0100
Subject: [Mailman-Developers] before next release: disable backscatterin
 default installation
In-Reply-To: <B991EA86-F816-44E2-ABC6-0F7CEEF40A76@list.org>
References: <PC17602008032509075602502bb10012@msapiro>
	<47E930FD.2000800@utu.fi>	<87bq52eevv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<6409CCAB96BF893D5A596FCA@lewes.staff.uscs.susx.ac.uk>
	<87tzitdoop.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20A8FB7AF06FCD481A760372@lewes.staff.uscs.susx.ac.uk>
	<87abkjtj5q.fsf@uwakimon.sk.tsukuba.ac.jp>
	<6448A7726836C8302EE824C3@lewes.staff.uscs.susx.ac.uk>
	<87r6duqtl1.fsf@uwakimon.sk.tsukuba.ac.jp>
	<B164C61C31A5CD642DE0C048@lewes.staff.uscs.susx.ac.uk>
	<B991EA86-F816-44E2-ABC6-0F7CEEF40A76@list.org>
Message-ID: <0950CC7533DD4C4882F1AD71@lewes.staff.uscs.susx.ac.uk>



--On 12 April 2008 12:02:45 -0400 Barry Warsaw <barry at list.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mar 31, 2008, at 6:15 AM, Ian Eiloart wrote:
>
>> As far as DKIM is concerned, I think Mailman already can re-sign
>> messages.
>> I don't remember the details, though. Anyway, I think re-signing is
>> the
>> correct thing for a list to do. Again, Mailman is a winner here
>> because
>> it's capable of doing such things.
>
> IIRC, I think we decided that it was best to leave re-signing up to the
> local MTA that Mailman delivers to, and not have Mailman itself do the
> signing.  Or am I misremembering that?

I think you're right.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From iane at sussex.ac.uk  Mon Apr 14 14:07:00 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 14 Apr 2008 13:07:00 +0100
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave That
 Thing	Alone)
In-Reply-To: <73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
Message-ID: <B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>



--On 12 April 2008 11:18:09 -0400 Barry Warsaw <barry at list.org> wrote:

>>> IIRC, this is going to be called when the "\r\n.\r\n" terminator to
>>> the
>>> DATA command is seen.  That might be an interesting place to hook in
>>> content filtering.
>>
>> Yes, that's the earliest opportunity to filter content. It also
>> allows the LTMP server to accept the message for some lists, but not
>> others. It doesn't help the local SMTP server, though, since it's
>> too late for an SMTP server to selectively reject.
>>
>> Some admins may prefer this though. For example, I monitor my SMTP
>> server queues more closely than my Mailman queues.
>
> So you mean that most SMTPd's will have accepted the message by they time
> they issue the DATA to the LMTP?

Exim will have, almost certainly. Although it's  possible for Exim to run 
any perl script before sending the response to DATA, or even call any 
external program, there are three reasons why it probably won't:

1. It requires some coding to create the script.
2. The script would have to substantially replicate Exim's routing and 
delivery code.
3. It's relatively expensive to run such scripts.
4. It's already too late to selectively reject the message when there is 
more than one recipient, because we've passed the SMTP RCTP stage. If only 
email were all done by LMTP!

I don't know about other MTAs.

>  If that's the case, then does it even
> make sense to do content filtering at that step in LMTP, given that we'll
> still be doing the full-blown rule matching in the incoming runner?

It's of very limited use. I'm not convinced that my users use it at all. If 
a message passes the sender filter, then it's probably OK to generate a 
bounce message. The exception would be for an open list, but an open list 
that gets lots of spam probably isn't going to last very long.

My view is that content filtering for spam belongs in the MTA, which is 
much better equipped to deal with it. Rejecting spam at SMTP time has the 
huge advantage that spambots can learn to leave you alone. I don't know if 
they do, though. Otherwise, you can teergrube them (add delays to the smtp 
replies, to slow them down).

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From iane at sussex.ac.uk  Mon Apr 14 14:08:59 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 14 Apr 2008 13:08:59 +0100
Subject: [Mailman-Developers] ANNOUNCE: GNU Mailman 3.0a1 (Leave
 ThatThing	Alone)
In-Reply-To: <PC1760200804121206060328b854afae@msapiro>
References: <PC1760200804121206060328b854afae@msapiro>
Message-ID: <2766E0B337459D4D7636AE66@lewes.staff.uscs.susx.ac.uk>



--On 12 April 2008 12:06:06 -0700 Mark Sapiro <mark at msapiro.net> wrote:

>
> I don't think that's what Ian is saying. The key word is 'selectively'.
> I.e. the SMTP server can still reject the incoming message, but once
> it has seen the DATA, it can only reject the entire message; it can't
> reject a subset of RCPTs.

Yes, that much is true in theory. In practice, it's even worse than that. 
Exim really has accepted the email before it attempts delivery. That's 
going to be true for any MTA that has a queueing mechanism (qmail, for 
example), and perhaps others, too.


-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From julian at mehnle.net  Mon Apr 14 14:59:17 2008
From: julian at mehnle.net (Julian Mehnle)
Date: Mon, 14 Apr 2008 12:59:17 +0000
Subject: [Mailman-Developers]
	=?utf-8?q?ANNOUNCE=3A_GNU_Mailman_3=2E0a1_?=
	=?utf-8?q?=28Leave_ThatThing=09Alone_=29?=
In-Reply-To: <PC1760200804121206060328b854afae@msapiro>
References: <PC1760200804121206060328b854afae@msapiro>
Message-ID: <200804141259.22746.julian@mehnle.net>

Mark Sapiro wrote:
> I don't think that's what Ian is saying. The key word is 'selectively'.
> I.e. the SMTP server can still reject the incoming message, but once
> it has seen the DATA, it can only reject the entire message; it can't
> reject a subset of RCPTs.

There is http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt .

Not very widely implemented, though, AFAICT. :-(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080414/6717d642/attachment.pgp 

From barry at list.org  Mon Apr 14 15:20:43 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Apr 2008 09:20:43 -0400
Subject: [Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU Mailman
	3.0a1 (Leave That Thing	Alone))
In-Reply-To: <B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
	<B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
Message-ID: <727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 14, 2008, at 8:07 AM, Ian Eiloart wrote:
> --On 12 April 2008 11:18:09 -0400 Barry Warsaw <barry at list.org> wrote:
>>
>> So you mean that most SMTPd's will have accepted the message by  
>> they time
>> they issue the DATA to the LMTP?
>
> Exim will have, almost certainly.

Okay.  BTW, wouldn't you think that the majority of messages sent to a  
Mailman list will have exactly one RCPT?  Cross-posting is relatively  
rare for most sites, isn't it?
>
>> If that's the case, then does it even
>> make sense to do content filtering at that step in LMTP, given that  
>> we'll
>> still be doing the full-blown rule matching in the incoming runner?
>
> It's of very limited use. I'm not convinced that my users use it at  
> all. If a message passes the sender filter, then it's probably OK to  
> generate a bounce message. The exception would be for an open list,  
> but an open list that gets lots of spam probably isn't going to last  
> very long.
>
> My view is that content filtering for spam belongs in the MTA, which  
> is much better equipped to deal with it. Rejecting spam at SMTP time  
> has the huge advantage that spambots can learn to leave you alone. I  
> don't know if they do, though. Otherwise, you can teergrube them  
> (add delays to the smtp replies, to slow them down).

I agree.  Okay, let's code for the common/useful case and leave the  
rest for YAGNI.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgDWiwACgkQ2YZpQepbvXEerQCgh7XTEkUaTfUz6HiApyqkvWIo
7e4AnRY1Sj/LH46xPeompxWL4WqF7HJc
=xpgz
-----END PGP SIGNATURE-----

From barry at list.org  Mon Apr 14 15:26:07 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Apr 2008 09:26:07 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
	<874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <70815DD1-3194-4EB1-A1BD-FAA8DE2AB4C9@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 3, 2008, at 1:28 AM, Stephen J. Turnbull wrote:
>
>>> Unfortunately, tuning list settings that have to do with filtering  
>>> is
>>> not and never really was something that you want people who have  
>>> never
>>> even set up an MTA to do.  Understanding what happens is quite
>>> complex.
>>
>> The solution in Mailman 3 will be to allow for defining named styles.
>
> That's half the solution.  The other half is providing means and
> encouragement for good ones to end up in a contrib directory. :-)

Or the Cheeseshop.  At least the /intent/ is that third party packages/ 
eggs could be installed that provide entry points for the plugins that  
Mailman defines.  If that doesn't work in practice then we need to bug  
the distutils folks or find another solution.  I really want to  
encourage a rich ecosystem of add-ons that don't need to be officially  
supported or even acknowledged by the core team.  The core should be  
concentrating on the core functionality and providing a robust  
framework with useful plug points.

>> A style is simply a collection of some subset of all the  
>> configuration
>> variables on a mailing list.
>
> And these cascade, right?

They can, other than that I haven't written the code yet. ;)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgDW28ACgkQ2YZpQepbvXGe3gCfQ5ZwND9HWHVxFnMOrEzqiFDg
tNgAoJr/P3p6tNs7V2g5YLeBCSevIYey
=0FGj
-----END PGP SIGNATURE-----

From barry at list.org  Mon Apr 14 15:35:33 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Apr 2008 09:35:33 -0400
Subject: [Mailman-Developers] Google Summer of Code - Spam Defense
In-Reply-To: <0A15F4BE7CDCB8E14074DD03@lewes.staff.uscs.susx.ac.uk>
References: <47EBBCA5.1000305@gmx.de> <47EBCB61.30702@netconsonance.com>
	<AD1AA6BA-7A7C-4E7A-BD96-64532754E471@raoset.com>
	<53240295-0A86-4940-91C5-29FD85FBFE52@zone12.com>
	<47EBE969.4000108@mschuette.name>
	<20080328161401.GF22290@garp.metalab.unc.edu>
	<87od8yqij5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080329175011.GO22290@garp.metalab.unc.edu>
	<87bq4wrjdb.fsf@uwakimon.sk.tsukuba.ac.jp>
	<577DE81E-1489-4E66-9556-A104FD1DA8F9@list.org>
	<874pajy0a0.fsf@uwakimon.sk.tsukuba.ac.jp>
	<0A15F4BE7CDCB8E14074DD03@lewes.staff.uscs.susx.ac.uk>
Message-ID: <FC81AC65-B161-4432-BA86-EDD694DCFCD6@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 3, 2008, at 6:19 AM, Ian Eiloart wrote:
> X.1.1   Bad destination mailbox address
> X.2.4   Mailing list expansion problem
> X.5.3   Too many recipients
> X.7.2   Mailing list expansion prohibited
>   The sender is not authorized to send a message to the intended  
> mailing list.
>
> X is 4 for a temporary error, 5 for a permanent error.

Thanks, wiki updated.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgDXaYACgkQ2YZpQepbvXEJBwCfemogkxdUEtsbDxeHgjUuxmdV
5yMAn3aQ/1bfMgqiR/vEmvXgsClTxNjm
=xQxj
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Mon Apr 14 16:44:40 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 14 Apr 2008 15:44:40 +0100
Subject: [Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU
 Mailman 3.0a1 (Leave That Thing	Alone))
In-Reply-To: <727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
	<B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
	<727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
Message-ID: <0E485C2873861A84228B22AC@lewes.staff.uscs.susx.ac.uk>



--On 14 April 2008 09:20:43 -0400 Barry Warsaw <barry at list.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Apr 14, 2008, at 8:07 AM, Ian Eiloart wrote:
>> --On 12 April 2008 11:18:09 -0400 Barry Warsaw <barry at list.org> wrote:
>>>
>>> So you mean that most SMTPd's will have accepted the message by
>>> they time
>>> they issue the DATA to the LMTP?
>>
>> Exim will have, almost certainly.
>
> Okay.  BTW, wouldn't you think that the majority of messages sent to a
> Mailman list will have exactly one RCPT?  Cross-posting is relatively
> rare for most sites, isn't it?

Check the headers of this message! Two recipients.

OK, that might be OK if python.org and list.org are handled by different 
servers. On our site, though, we have thousands of users and hundreds of 
lists in the same domain. Most of our list members are in that same domain. 
So, replies to list messages will frequently have more than one RCPT.

Oh, and we make extensive use of umbrella lists, which might also make a 
difference. In fact, we have a complex heirarchy of lists which we'd like 
to develop further.


-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From barry at list.org  Mon Apr 14 17:44:36 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Apr 2008 11:44:36 -0400
Subject: [Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU
	Mailman 3.0a1 (Leave That Thing	Alone))
In-Reply-To: <0E485C2873861A84228B22AC@lewes.staff.uscs.susx.ac.uk>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
	<B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
	<727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
	<0E485C2873861A84228B22AC@lewes.staff.uscs.susx.ac.uk>
Message-ID: <969D2C39-D9EC-4EEC-97B5-B94CF744160B@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 14, 2008, at 10:44 AM, Ian Eiloart wrote:
>
>
> --On 14 April 2008 09:20:43 -0400 Barry Warsaw <barry at list.org> wrote:
>>
>> Okay.  BTW, wouldn't you think that the majority of messages sent  
>> to a
>> Mailman list will have exactly one RCPT?  Cross-posting is relatively
>> rare for most sites, isn't it?
>
> Check the headers of this message! Two recipients.
>
> OK, that might be OK if python.org and list.org are handled by  
> different servers.

They are ;)

> On our site, though, we have thousands of users and hundreds of  
> lists in the same domain. Most of our list members are in that same  
> domain. So, replies to list messages will frequently have more than  
> one RCPT.
>
> Oh, and we make extensive use of umbrella lists, which might also  
> make a difference. In fact, we have a complex heirarchy of lists  
> which we'd like to develop further.

Okay, that makes sense.  BTW, I'd love to get your feedback on the  
roster concept in MM3.  I /think/ it will make composable mailing list  
members much easier to deal with, but the ideas could probably still  
use some fleshing out.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgDe+QACgkQ2YZpQepbvXE/2QCdEDgvSaqiRe8B9lAtc7V+WPDN
YywAn0loB4ak20Oy2/qki/IwovCc39Fm
=1z35
-----END PGP SIGNATURE-----

From dgc at uchicago.edu  Mon Apr 14 19:19:17 2008
From: dgc at uchicago.edu (David Champion)
Date: Mon, 14 Apr 2008 12:19:17 -0500
Subject: [Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU
	Mailman 3.0a1 (Leave That	Thing Alone))
In-Reply-To: <727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
	<B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
	<727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
Message-ID: <20080414171917.GN10751@monkey.uchicago.edu>

> Okay.  BTW, wouldn't you think that the majority of messages sent to a  
> Mailman list will have exactly one RCPT?  Cross-posting is relatively  
> rare for most sites, isn't it?

Just another data point: I don't have experience at most sites, but here
cross-posting is extremely common.

For example, we have hundreds of lists just for different staff
cross-sections, and hundreds for student interest groups with some
common themes among them.  If someone wants to address people in two
different working groups who are collaborating on a short project, their
mail will quite likely go to each of those groups.  It's not worth
creating a new list for the few days that the project requires.

Another very common use case: one student group puts on an art show, and
they want to call the attention of other student groups who have an arty
focus.  That announcement might go to 20 lists.

-- 
 -D.    dgc at uchicago.edu    NSIT    University of Chicago

From stephen at xemacs.org  Mon Apr 14 21:10:39 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 15 Apr 2008 04:10:39 +0900
Subject: [Mailman-Developers] LMTP delivery (was Re: ANNOUNCE: GNU
	Mailman	3.0a1 (Leave That Thing	Alone))
In-Reply-To: <727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
References: <9F78B9C5-2B6A-409D-8120-D94D5B8D4F49@list.org>
	<317631BE54892DD124414ABE@lewes.staff.uscs.susx.ac.uk>
	<898713B6-9E7F-431D-8F4C-CDF55EDD992A@list.org>
	<614ABA2CB74A93C93C6C3C05@lewes.staff.uscs.susx.ac.uk>
	<73FF506F-0CA2-4829-B3E6-D16876FC4E9D@list.org>
	<B2EA0139656A6A76CBBCE64A@lewes.staff.uscs.susx.ac.uk>
	<727FC0B5-8477-4F91-ABDB-E8A802FF095F@list.org>
Message-ID: <87k5j0fe1c.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > Okay.  BTW, wouldn't you think that the majority of messages sent to a  
 > Mailman list will have exactly one RCPT?  Cross-posting is relatively  
 > rare for most sites, isn't it?

It's not just cross-posting, though.  Consider this message, except
assume that you posted from your Python address.  Open source lists
may be unusual, but (as one additional data point) the lists at my
work generally get lots of wide replies containing local users'
mailboxes.


From shiva at sewingwitch.com  Mon Apr 14 23:38:12 2008
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 14 Apr 2008 14:38:12 -0700
Subject: [Mailman-Developers] before next release: disable backscatter
 in default installation
In-Reply-To: <A77281AC-574C-4AA0-B7AF-E02AF4DAEA76@list.org>
References: <E6C70824-2AD0-45B0-B8CB-7B146D1FFD07@netconsonance.com>
	<PC1760200803041528220796684c8ad2@msapiro>
	<20080305011346.GD5749@garp.metalab.unc.edu>
	<87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp>
	<A6E88D20-028F-4706-A2FB-FB5BC7EC93EA@netconsonance.com>
	<46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk>
	<1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com>
	<20080327001842.GN22377@garp.metalab.unc.edu>
	<47EBC9D8.3000403@netconsonance.com>
	<878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk>
	<A77281AC-574C-4AA0-B7AF-E02AF4DAEA76@list.org>
Message-ID: <5078E62DC20006D6F67A57C1@[10.169.6.155]>

On Saturday, April 12, 2008 12:44 PM -0400 Barry Warsaw <barry at list.org> 
wrote:

> Thanks!  Capture here in the "best practices" section:
>
> http://wiki.list.org/display/DEV/Home

Note that there's already backscatter prevention info here:

<http://wiki.list.org/display/SEC/Controlling+spam>

One of these pages should be linking to the other. Or perhaps a new 
"backscatter resources" page should be created for both to point to.



From mark at msapiro.net  Tue Apr 15 00:47:53 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 14 Apr 2008 15:47:53 -0700
Subject: [Mailman-Developers] Mailman 2.1.10rc1 has been released
In-Reply-To: <47F7B288.6020801@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
Message-ID: <4803DF19.3030406@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am happy to announce the release of Mailman 2.1.10rc1.

This is a security and bug fix release and it is highly recommended
that all sites upgrade to this version. Mailman 2.1.10 also adds support
for three new language translations, Galician, Hebrew and Slovak and a
few new features.

Mailman is free software for managing email mailing lists and e-
newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, including download links, please see:

http://www.list.org
http://mailman.sf.net
http://www.gnu.org/software/mailman

Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding
and support, Moritz Naumann for help with security issues and Jim
Tittsler for a significant patch.

Here's a list of the major changes.

Note in particular, the second item under Security as this is new since
2.1.10b4 and requires an mm_cfg.py change to maintain current behavior.


Security

- - The 2.1.9 fixes for CVE-2006-3636 were not complete.  In particular,
~  some potential cross-site scripting attacks were not detected in
~  editing templates and updating the list's info attribute via the web
~  admin interface.  This has been assigned CVE-2008-0564 and has been
~  fixed.  Thanks again to Moritz Naumann for assistance with this.

- - There is a new mm_cfg.py/Defaults.py variable
~  OWNERS_CAN_CHANGE_MEMBER_PASSWORDS which controls whether the list
~  owner can change a member's password from the member's options page.
~  This defaults to No and should be changed to Yes only if list owners
~  are trusted to not change a member's password, log in as the member
~  and make global membership changes.

New Features

- - Changed cmd_who.py to list all members if authorization is with the
~  list's admin or moderator password and to accept the password if the
~  roster is public.  Also changed the web roster to show hidden members
~  when authorization is by site or list's admin or moderator password
~  (1587651).

- - Added the ability to put a list name in accept_these_nonmembers
~  to accept posts from members of that list (1220144).

- - Added a new 'sibling list' feature to exclude members of another list
~  from receiving a post from this list if the other list is in the To:
~  or Cc: of the post or to include members of the other list if that
~  list is  not in the To: or Cc: of the post (Patch ID 1347962).

- - Added the admin_member_chunksize attribute to the admin General
~  Options interface (Bug 1072002, Partial RFE 782436).

Internationalization

- - Added the Hebrew translation from Dov Zamir.  This includes addition
~  of a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table.  The
~  add_language() function defaults direction to 'ltr' to not break
~  existing mm_cfg.py files.

- - Added the Slovak translation from Martin Matuska.

- - Added the Galician translation from Frco. Javier Rial Rodr?guez.


Changes since 2.1.10b4 include the OWNERS_CAN_CHANGE_MEMBER_PASSWORDS
setting mentioned above plus

- - Changed cmd_subscribe.py to properly accept (no)digest without a
~  password and to recognize (no)digest and address= case insensitively.

- - An updated mm-handler (mm-handler-2.1.10) that can help reduce
~  backscatter has been added to the contrib directory.

and updates to the Italian and Polish translations.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIA98ZVVuXXpU7hpMRAm3uAKCngufNpjWZxTxIupg2X1dd5qSbLACgsAQX
xchWm2WMfDzXET53TeLxJcw=
=ZT1m
-----END PGP SIGNATURE-----

From justinlong at gmail.com  Sat Apr 19 05:07:36 2008
From: justinlong at gmail.com (Justin Long)
Date: Sat, 19 Apr 2008 11:07:36 +0800
Subject: [Mailman-Developers] Spammers forging addresses for
	subscribe/unsubscribe
Message-ID: <876ecebe0804182007g891f44eod053f10c0039a11e@mail.gmail.com>

Greetings,

we used to have a situation where a spammer would do the following with qmail:

(1) spammer send a message FROM someone (forging their address) TO an
invalid address on our server CONTAINING spam
(2) our server sees the address is invalid
(3) our server BOUNCES error message CONTAINING original message
(including spam) FROM us TO the forged address (which was the apparent
from address)
thus making us a spam source. (Ingenious.)

Since we have moved to postfix/mailman, we are now encountering a
different situation, also probably arising from spam

(1) spammer sends a message FROM someone (forged) TO a range of
addresses which include the -subscribe and/or -unsubscribe address
(2) mailman BOUNCES confirmation message TO forged address FOR
-subscribe/unsubscribe, this may include the spam (as part of the
notification)
(3) sometimes, if the address is invalid (dead address), we get a
bounce back saying the address is no good, which gets caught in the
"uncaught bounce" cycle.
(4) sometimes, if the address is valid and its to the -subscribe
address, the person gets spammed.

Is there a way in mailman to do the following - and if not, I'd like
to submit these ideas for implementation or adjustment
(1) bounces from subscribe requests should not include the original message
(2) unsubscribe requests should be dropped if they come from an
address which is not a member

You can't really tell if a subscribe request is valid or not, but at
least the attachments could be stripped out...

Cordially,
Justin Long

-- 
Never retreat. Never surrender. Never cut a deal with a dragon.
-------
Justin Long / justinlong at gmail.com
http://www.strategicnetwork.org - 120,000 subscribers, 16,000 articles
http://www.momentum-mag.org - bi-monthly magazine on unreached peoples
http://www.momentum-mag.org/wiki - Missiopedia of Christian missions
MSNIM justinlong at strategicnetwork.org / Skype nsmjustinlong
-------
We help people build 6 things: Drive, Energy, Effort, Inspiration,
Power, Strength
-------
No armor? Unclean life? Then do not mess in the affairs of dragons,
for you are crunchy and taste good with ketchup.

From mark at msapiro.net  Sat Apr 19 05:38:37 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 18 Apr 2008 20:38:37 -0700
Subject: [Mailman-Developers] Spammers forging addresses
	forsubscribe/unsubscribe
In-Reply-To: <876ecebe0804182007g891f44eod053f10c0039a11e@mail.gmail.com>
Message-ID: <PC1760200804182038370953d91ecede@msapiro>

Justin Long wrote:
>
>Is there a way in mailman to do the following - and if not, I'd like
>to submit these ideas for implementation or adjustment
>(1) bounces from subscribe requests should not include the original message


I can pretty much promise that this and other measures will be in the
initial Mailman 2.2 release, but it isn't in Mailman 2.1


>(2) unsubscribe requests should be dropped if they come from an
>address which is not a member


Interesting idea, but I can see some installations would want to send
some kind of response in case it is really from a subscribe who just
doesn't happen to know what their correct subscribed address is.


>You can't really tell if a subscribe request is valid or not, but at
>least the attachments could be stripped out...


Yes, we definitely plan to not echo the message body, at least by
default. However, many people feel there should be no response at all.
See for example the thread beginning at
<http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html>
and continuing into April.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From justinlong at gmail.com  Sat Apr 19 05:41:44 2008
From: justinlong at gmail.com (Justin Long)
Date: Sat, 19 Apr 2008 11:41:44 +0800
Subject: [Mailman-Developers] Spammers forging addresses
	forsubscribe/unsubscribe
In-Reply-To: <PC1760200804182038370953d91ecede@msapiro>
References: <876ecebe0804182007g891f44eod053f10c0039a11e@mail.gmail.com>
	<PC1760200804182038370953d91ecede@msapiro>
Message-ID: <876ecebe0804182041l20109286p977420057124df9e@mail.gmail.com>

Maybe some of these ideas should be controlled by configuration
options to give the most flexibility?

Unsubscribe from non-member address: (1) Reply (2) Bounce to moderator
(3) Discard

On Sat, Apr 19, 2008 at 11:38 AM, Mark Sapiro <mark at msapiro.net> wrote:
> Justin Long wrote:
>  >
>  >Is there a way in mailman to do the following - and if not, I'd like
>  >to submit these ideas for implementation or adjustment
>  >(1) bounces from subscribe requests should not include the original message
>
>
>  I can pretty much promise that this and other measures will be in the
>  initial Mailman 2.2 release, but it isn't in Mailman 2.1
>
>
>
>  >(2) unsubscribe requests should be dropped if they come from an
>  >address which is not a member
>
>
>  Interesting idea, but I can see some installations would want to send
>  some kind of response in case it is really from a subscribe who just
>  doesn't happen to know what their correct subscribed address is.
>
>
>
>  >You can't really tell if a subscribe request is valid or not, but at
>  >least the attachments could be stripped out...
>
>
>  Yes, we definitely plan to not echo the message body, at least by
>  default. However, many people feel there should be no response at all.
>  See for example the thread beginning at
>  <http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html>
>  and continuing into April.
>
>  --
>  Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
>  San Francisco Bay Area, California    better use your sense - B. Dylan
>
>



-- 
Never retreat. Never surrender. Never cut a deal with a dragon.
-------
Justin Long / justinlong at gmail.com
http://www.strategicnetwork.org - 120,000 subscribers, 16,000 articles
http://www.momentum-mag.org - bi-monthly magazine on unreached peoples
http://www.momentum-mag.org/wiki - Missiopedia of Christian missions
MSNIM justinlong at strategicnetwork.org / Skype nsmjustinlong
-------
We help people build 6 things: Drive, Energy, Effort, Inspiration,
Power, Strength
-------
No armor? Unclean life? Then do not mess in the affairs of dragons,
for you are crunchy and taste good with ketchup.

From barry at list.org  Sun Apr 20 22:27:32 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 16:27:32 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <20080409035510.GC9880@garp.metalab.unc.edu>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<20080409035510.GC9880@garp.metalab.unc.edu>
Message-ID: <85730DF3-90C9-4A40-85D2-23B14845321B@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 8, 2008, at 11:55 PM, Crist?bal Palmer wrote:
> On Tue, Apr 08, 2008 at 11:08:57PM -0400, Barry Warsaw wrote:
>>
>> One other question you raise: I would like to move the bug trackers
>> off of SourceForge at some point.  I think Jira is no longer a viable
>> option, so we should consider alternatives.  Once again, Launchpad
>> seems a natural
>
> Launchpad++
>
> Slowness aside, that platform looks like a perfect fit.
>
> If people reeeaaaally don't like that idea, I know a certain .org that
> might host other tracking software for the mailman team....

There doesn't seem to have been much debate on this, but I'm up for  
moving it.  I think the two options at this point are probably  
Launchpad or trying to get a Roundup instance up on python.org.  I  
think Martin just did something similar for setuptools so he might be  
open to helping us get one for Mailman.

I'd like to get Mark's feedback on this since he's been doing most of  
the bug closing these days (to my shame).

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgLpzQACgkQ2YZpQepbvXG9xgCdG3tQPmB6eVcvgmPJl1AwVwya
LhsAnivkXD+oxSf8Jaoy/Cb/bYdvsFsg
=6dz8
-----END PGP SIGNATURE-----

From barry at list.org  Sun Apr 20 22:35:59 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 16:35:59 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
Message-ID: <EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 9, 2008, at 12:28 AM, Satoshi Tanabe wrote:
> Thanks Barry for your comments and thoughts. I waited for your  
> reply :-)
>
> Several comments on what you said:
>
> * I used gedit to create all the html files, so "pages being build
> using non-free software" is not an issue at least with my part.

Ah, so you're not using any kind of general templating or site  
building software?  Just manually writing .html files?  Don't we need  
something to ensure consistent layout, links, etc?

Maybe not though.  Ideally, most of the www content really could live  
on the wiki.  We'd lose the mirrors, but I'm not really sure how much  
value there is in them anyway.  Radical thought: with a front page we  
can better design, and pages we can lock down from editing, can www be  
completely wiki?

> * As you pointed out, which Wiki to use, whether to use a non-free
> wiki service, and which content should be placed in the wiki site all
> remain an issue.
>
> * All color scheme is defined in the CSS file, so changing the color
> scheme should be trivial. (And no, I'm not insisting using green
> instead of the current color scheme :-) It just happened to be.)
>
> * Thanks for the comment on the Jira no longer being an option. I'll
> update that part.

Thanks again!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgLqTIACgkQ2YZpQepbvXG62ACfcqSDVabd/KoUaVeMSnIslH1q
fOwAoLlA8MtxAR3QapieltKyb/QteEbH
=RixL
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Mon Apr 21 00:01:09 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Apr 2008 07:01:09 +0900
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
	<EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
Message-ID: <87ve2cxk2i.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > Maybe not though.  Ideally, most of the www content really could live  
 > on the wiki.  We'd lose the mirrors, but I'm not really sure how much  
 > value there is in them anyway.  Radical thought: with a front page we  
 > can better design, and pages we can lock down from editing, can www be  
 > completely wiki?

Why not?  One thing that would be nice for this kind of thing would be
a wiki that lives on top of a VCS, with page sources on "official" and
"public-editable" branches.  The idea of the "official" manual is that
this is created by developers (preferably by merging from the public
branch :-), and is the source for the next distribution manual.

I don't think this wiki exists yet, though.

From stephen at xemacs.org  Mon Apr 21 00:04:56 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Apr 2008 07:04:56 +0900
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <85730DF3-90C9-4A40-85D2-23B14845321B@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<20080409035510.GC9880@garp.metalab.unc.edu>
	<85730DF3-90C9-4A40-85D2-23B14845321B@list.org>
Message-ID: <87tzhwxjw7.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > There doesn't seem to have been much debate on this, but I'm up for  
 > moving it.  I think the two options at this point are probably  
 > Launchpad or trying to get a Roundup instance up on python.org.  I  
 > think Martin just did something similar for setuptools so he might be  
 > open to helping us get one for Mailman.

I don't necessarily advocate this path for Mailman, but I'm doing a
Roundup tracker for XEmacs and would be able to help with it if that's
the way you want to go.

 > I'd like to get Mark's feedback on this since he's been doing most of  
 > the bug closing these days (to my shame).

Why waste time on being ashamed of yourself when you could be proud of
the job Mark's been doing instead?<wink>

From stanabe at uwo.ca  Mon Apr 21 00:27:41 2008
From: stanabe at uwo.ca (Satoshi Tanabe)
Date: Sun, 20 Apr 2008 18:27:41 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
	<EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
Message-ID: <42a95f60804201527j303f93b9hbac4a7b7da8f3efe@mail.gmail.com>

Hello,

2008/4/20, Barry Warsaw <barry at list.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On Apr 9, 2008, at 12:28 AM, Satoshi Tanabe wrote:
>
> > Thanks Barry for your comments and thoughts. I waited for your reply :-)
> >
> > Several comments on what you said:
> >
> > * I used gedit to create all the html files, so "pages being build
> > using non-free software" is not an issue at least with my part.
> >
>
>  Ah, so you're not using any kind of general templating or site building
> software?  Just manually writing .html files?  Don't we need something to
> ensure consistent layout, links, etc?

No, I didn't use any site building software, and yes, I created all
html files with gedit (with the help of the powerful snippet plugin).
CSS takes care of the consistent layout part.


>
>  Maybe not though.  Ideally, most of the www content really could live on
> the wiki.  We'd lose the mirrors, but I'm not really sure how much value
> there is in them anyway.  Radical thought: with a front page we can better
> design, and pages we can lock down from editing, can www be completely wiki?

I'm not really sure how much benefit we get by making the site 100%
wiki... (unless we create the Mailman Encyclopedia or something of
that sort.)  I see the benefit in the documentation and QandA part
(because people can constantly improve and add contents to them), but
other than that, wouldn't static HTML (plus links to those Wiki pages)
do the job? Wikis are nice, but at the same time it seems to create
otherwise unnecessary management issues (spamming, user accounts,
etc).

What do you think?

- Satoshi

From barry at list.org  Mon Apr 21 02:58:06 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 20:58:06 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <87ve2cxk2i.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
	<EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
	<87ve2cxk2i.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <F54349E1-1F4F-4D21-B6DF-4A7921C14074@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 20, 2008, at 6:01 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>> Maybe not though.  Ideally, most of the www content really could live
>> on the wiki.  We'd lose the mirrors, but I'm not really sure how much
>> value there is in them anyway.  Radical thought: with a front page we
>> can better design, and pages we can lock down from editing, can www  
>> be
>> completely wiki?
>
> Why not?  One thing that would be nice for this kind of thing would be
> a wiki that lives on top of a VCS, with page sources on "official" and
> "public-editable" branches.  The idea of the "official" manual is that
> this is created by developers (preferably by merging from the public
> branch :-), and is the source for the next distribution manual.
>
> I don't think this wiki exists yet, though.

I don't either, but it's a great idea.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgL5p4ACgkQ2YZpQepbvXHn+gCfVsgQrHsN2oFx5M7zUCa9NcS4
FYwAniTQ3nAm66N1q+b2FnordKw2wCed
=f3Cg
-----END PGP SIGNATURE-----

From barry at list.org  Mon Apr 21 02:58:43 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 20:58:43 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <87tzhwxjw7.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<20080409035510.GC9880@garp.metalab.unc.edu>
	<85730DF3-90C9-4A40-85D2-23B14845321B@list.org>
	<87tzhwxjw7.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <BC89E30E-FD77-4B10-8EBC-16E9351CBEEF@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 20, 2008, at 6:04 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
>
>> There doesn't seem to have been much debate on this, but I'm up for
>> moving it.  I think the two options at this point are probably
>> Launchpad or trying to get a Roundup instance up on python.org.  I
>> think Martin just did something similar for setuptools so he might be
>> open to helping us get one for Mailman.
>
> I don't necessarily advocate this path for Mailman, but I'm doing a
> Roundup tracker for XEmacs and would be able to help with it if that's
> the way you want to go.
>
>> I'd like to get Mark's feedback on this since he's been doing most of
>> the bug closing these days (to my shame).
>
> Why waste time on being ashamed of yourself when you could be proud of
> the job Mark's been doing instead?<wink>

Good point! :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgL5sQACgkQ2YZpQepbvXE8VQCeLFUPPaeinBUX7jdDQKhLCctD
McwAnj8Tvx93h8p89WNLkMXNIoUMlIkS
=ha+C
-----END PGP SIGNATURE-----

From barry at list.org  Mon Apr 21 03:01:38 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 21:01:38 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <20080409115957.GA5988@amk-desktop.matrixgroup.net>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<20080409115957.GA5988@amk-desktop.matrixgroup.net>
Message-ID: <ABA524F3-9489-4A69-A5F5-AFD385726F05@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 9, 2008, at 7:59 AM, A.M. Kuchling wrote:
> On Tue, Apr 08, 2008 at 11:08:57PM -0400, Barry Warsaw wrote:
>> [1] Admittedly the wiki is not running on free software.  As much  
>> as I
>> like Confluence, this is an issue for a GNU project like Mailman.
>> However, again I don't think we yet have the resources to maintain  
>> our
>> own wiki, let alone import the existing content into a free wiki.
>
> wiki.python.org could certainly host another wiki.  About importing
> the existing content: is it possible to obtain a dump of all the
> existing wiki pages from Confluence, or would we need to crawl it?

Confluence does support getting a dump of its pages in XML format,  
which I've done.  I'm leery of publishing the url widely though  
because I haven't had a chance to look through it, so I don't know if  
there is any sensitive information in there.  Andrew, I'll send you  
the url if you want to take a look.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgL53IACgkQ2YZpQepbvXEUpQCfUN37lXkqWB8n2/zL7pCGl4Io
aT0An3SC4vKECqVYgFn5znMiwrpYGGxq
=BGD+
-----END PGP SIGNATURE-----

From barry at list.org  Mon Apr 21 03:07:03 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 20 Apr 2008 21:07:03 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <42a95f60804201527j303f93b9hbac4a7b7da8f3efe@mail.gmail.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<42a95f60804082128p72637a3sdd23c4ac42635ef1@mail.gmail.com>
	<EA7F6F84-E687-4E7D-8C2E-9F6D93423B14@list.org>
	<42a95f60804201527j303f93b9hbac4a7b7da8f3efe@mail.gmail.com>
Message-ID: <FE204D47-888A-4A3A-9388-A385653AED81@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 20, 2008, at 6:27 PM, Satoshi Tanabe wrote:
>>
>> Maybe not though.  Ideally, most of the www content really could  
>> live on
>> the wiki.  We'd lose the mirrors, but I'm not really sure how much  
>> value
>> there is in them anyway.  Radical thought: with a front page we can  
>> better
>> design, and pages we can lock down from editing, can www be  
>> completely wiki?
>
> I'm not really sure how much benefit we get by making the site 100%
> wiki... (unless we create the Mailman Encyclopedia or something of
> that sort.)  I see the benefit in the documentation and QandA part
> (because people can constantly improve and add contents to them), but
> other than that, wouldn't static HTML (plus links to those Wiki pages)
> do the job? Wikis are nice, but at the same time it seems to create
> otherwise unnecessary management issues (spamming, user accounts,
> etc).
>
> What do you think?

The real benefit of a wiki is that the community can really  
participate in its improvement and upkeep.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgL6LkACgkQ2YZpQepbvXFb5wCgkmEO2D3JrSfoYtlCTQ8pktcr
zw0AniTu4q12lq8hDTUfdCAAiMUC8bvq
=AwpZ
-----END PGP SIGNATURE-----

From mark at msapiro.net  Mon Apr 21 04:56:08 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 20 Apr 2008 19:56:08 -0700
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <BC89E30E-FD77-4B10-8EBC-16E9351CBEEF@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<20080409035510.GC9880@garp.metalab.unc.edu>	<85730DF3-90C9-4A40-85D2-23B14845321B@list.org>	<87tzhwxjw7.fsf@uwakimon.sk.tsukuba.ac.jp>
	<BC89E30E-FD77-4B10-8EBC-16E9351CBEEF@list.org>
Message-ID: <480C0248.1090507@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw wrote:
| On Apr 20, 2008, at 6:04 PM, Stephen J. Turnbull wrote:
|> Barry Warsaw writes:
|
|>> I'd like to get Mark's feedback on this since he's been doing most of
|>> the bug closing these days (to my shame).
|> Why waste time on being ashamed of yourself when you could be proud of
|> the job Mark's been doing instead?<wink>
|
| Good point! :)


Thanks guys.

As far as trackers are concerned, I'm pretty much agnostic. I like the
idea of Launchpad because it keeps the code and the tracker together,
but I'm not really familiar with the features of either Roundup or the
Launchpad tracker, so I'd defer to those who know more about them for a
decision.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIDAJIVVuXXpU7hpMRAuSHAJ9v2m4R57LCLXjuXTN3O9fm01hu7wCglhtM
lBLQXXRELgPK7y/ZwKt9Gyo=
=v/ss
-----END PGP SIGNATURE-----

From amk at amk.ca  Mon Apr 21 14:47:35 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Mon, 21 Apr 2008 08:47:35 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <ABA524F3-9489-4A69-A5F5-AFD385726F05@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<20080409115957.GA5988@amk-desktop.matrixgroup.net>
	<ABA524F3-9489-4A69-A5F5-AFD385726F05@list.org>
Message-ID: <20080421124735.GA6803@amk-desktop.matrixgroup.net>

On Sun, Apr 20, 2008 at 09:01:38PM -0400, Barry Warsaw wrote:
> Confluence does support getting a dump of its pages in XML format,  
> which I've done.  I'm leery of publishing the url widely though  
> because I haven't had a chance to look through it, so I don't know if  
> there is any sensitive information in there.  Andrew, I'll send you  
> the url if you want to take a look.

I've looked through it and it's straightforward to pull out the text
of wiki pages; the complicated task would be converting them from
Confluence's wiki markup to MoinMoin.  The dump does include a list of
users, their e-mail addresses, and hashed versions of their passwords,
so you shouldn't post it publicly.

Do you want me to actually start working on this conversion, or are
you still deciding whether to use some alternative?  It would be a
good impetus to make me upgrade python.org to MoinMoin 1.6.  (No rush
here; it would probably be a few weeks before the upgrade can be
completed because I can't work on it this week.)

--amk


From barry at list.org  Mon Apr 21 15:20:51 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 09:20:51 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <480C0248.1090507@msapiro.net>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<20080409035510.GC9880@garp.metalab.unc.edu>	<85730DF3-90C9-4A40-85D2-23B14845321B@list.org>	<87tzhwxjw7.fsf@uwakimon.sk.tsukuba.ac.jp>
	<BC89E30E-FD77-4B10-8EBC-16E9351CBEEF@list.org>
	<480C0248.1090507@msapiro.net>
Message-ID: <DD96B40C-BCA4-40D4-9D50-7DEC060144F4@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 20, 2008, at 10:56 PM, Mark Sapiro wrote:
>
> As far as trackers are concerned, I'm pretty much agnostic. I like the
> idea of Launchpad because it keeps the code and the tracker together,
> but I'm not really familiar with the features of either Roundup or the
> Launchpad tracker, so I'd defer to those who know more about them  
> for a
> decision.

I'll make a request to get the import into Launchpad going.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgMlLQACgkQ2YZpQepbvXEeOACdHRVYiOhjDp8LdoRNyKqPtCZg
wzUAnRij+h7NUu9dl1RmCZv21uZBFI3g
=xkZR
-----END PGP SIGNATURE-----

From mark at msapiro.net  Mon Apr 21 21:50:01 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Apr 2008 12:50:01 -0700
Subject: [Mailman-Developers] Mailman 2.1.10 has been released
In-Reply-To: <4803DF19.3030406@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
	<4803DF19.3030406@msapiro.net>
Message-ID: <480CEFE9.5000008@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am happy to announce the release of Mailman 2.1.10.

This is a security and bug fix release and it is highly recommended
that all sites upgrade to this version. Mailman 2.1.10 also adds support
for three new language translations, Galician, Hebrew and Slovak and a
few new features.

Mailman is free software for managing email mailing lists and e-
newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, including download links, please see:

http://www.list.org
http://mailman.sf.net
http://www.gnu.org/software/mailman

Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding
and support, Moritz Naumann for help with security issues and Jim Tittsler
for a significant patch.

Here's a list of the major changes.

Security

- - The 2.1.9 fixes for CVE-2006-3636 were not complete.  In particular,
some potential cross-site scripting attacks were not detected in
editing templates and updating the list's info attribute via the web
admin interface.  This has been assigned CVE-2008-0564 and has been
fixed.  Thanks again to Moritz Naumann for assistance with this.

- - There is a new mm_cfg.py/Defaults.py variable
OWNERS_CAN_CHANGE_MEMBER_PASSWORDS which controls whether the list
owner can change a member's password from the member's options page.
This defaults to No and should be changed to Yes only if list owners
are trusted to not change a member's password, log in as the member
and make global membership changes.

Note: If you are not ready to upgrade, patches for these two issues
are available at
http://sourceforge.net/project/showfiles.php?group_id=103
in the 2.1.9 file list.

New Features

- - Changed cmd_who.py to list all members if authorization is with the
list's admin or moderator password and to accept the password if the
roster is public. Also changed the web roster to show hidden members
when authorization is by site or list's admin or moderator password
(1587651).

- - Added the ability to put a list name in accept_these_nonmembers
to accept posts from members of that list (1220144).

- - Added a new 'sibling list' feature to exclude members of another list
from receiving a post from this list if the other list is in the To: or
Cc: of the post or to include members of the other list if that list is
not in the To: or Cc: of the post (Patch ID 1347962).

- - Added the admin_member_chunksize attribute to the admin General Options
interface (Bug 1072002, Partial RFE 782436).

Internationalization

- - Added the Hebrew translation from Dov Zamir. This includes addition of
a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The
add_language() function defaults direction to 'ltr' to not break
existing mm_cfg.py files.

- - Added the Slovak translation from Martin Matuska.

- - Added the Galician translation from Frco. Javier Rial Rodr?guez.


- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIDO/oVVuXXpU7hpMRAngiAKCwIOhSJJrCaY3afhGJQN339/dKuACeMckR
SI7DwCHcYONnIj3LoNYueC0=
=DO/d
-----END PGP SIGNATURE-----

From mark at msapiro.net  Mon Apr 21 21:50:01 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Apr 2008 12:50:01 -0700
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <4803DF19.3030406@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
	<4803DF19.3030406@msapiro.net>
Message-ID: <480CEFE9.5000008@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am happy to announce the release of Mailman 2.1.10.

This is a security and bug fix release and it is highly recommended
that all sites upgrade to this version. Mailman 2.1.10 also adds support
for three new language translations, Galician, Hebrew and Slovak and a
few new features.

Mailman is free software for managing email mailing lists and e-
newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, including download links, please see:

http://www.list.org
http://mailman.sf.net
http://www.gnu.org/software/mailman

Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding
and support, Moritz Naumann for help with security issues and Jim Tittsler
for a significant patch.

Here's a list of the major changes.

Security

- - The 2.1.9 fixes for CVE-2006-3636 were not complete.  In particular,
some potential cross-site scripting attacks were not detected in
editing templates and updating the list's info attribute via the web
admin interface.  This has been assigned CVE-2008-0564 and has been
fixed.  Thanks again to Moritz Naumann for assistance with this.

- - There is a new mm_cfg.py/Defaults.py variable
OWNERS_CAN_CHANGE_MEMBER_PASSWORDS which controls whether the list
owner can change a member's password from the member's options page.
This defaults to No and should be changed to Yes only if list owners
are trusted to not change a member's password, log in as the member
and make global membership changes.

Note: If you are not ready to upgrade, patches for these two issues
are available at
http://sourceforge.net/project/showfiles.php?group_id=103
in the 2.1.9 file list.

New Features

- - Changed cmd_who.py to list all members if authorization is with the
list's admin or moderator password and to accept the password if the
roster is public. Also changed the web roster to show hidden members
when authorization is by site or list's admin or moderator password
(1587651).

- - Added the ability to put a list name in accept_these_nonmembers
to accept posts from members of that list (1220144).

- - Added a new 'sibling list' feature to exclude members of another list
from receiving a post from this list if the other list is in the To: or
Cc: of the post or to include members of the other list if that list is
not in the To: or Cc: of the post (Patch ID 1347962).

- - Added the admin_member_chunksize attribute to the admin General Options
interface (Bug 1072002, Partial RFE 782436).

Internationalization

- - Added the Hebrew translation from Dov Zamir. This includes addition of
a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The
add_language() function defaults direction to 'ltr' to not break
existing mm_cfg.py files.

- - Added the Slovak translation from Martin Matuska.

- - Added the Galician translation from Frco. Javier Rial Rodr?guez.


- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIDO/oVVuXXpU7hpMRAngiAKCwIOhSJJrCaY3afhGJQN339/dKuACeMckR
SI7DwCHcYONnIj3LoNYueC0=
=DO/d
-----END PGP SIGNATURE-----
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: http://mail.python.org/mailman/options/mailman-users/spyropolymiadis%40kromestudios.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp


From brad at shub-internet.org  Mon Apr 21 23:28:16 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 16:28:16 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net>
Message-ID: <480D06F0.5020009@shub-internet.org>

Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.

Now running on mail.python.org.  Please let us know if there are any problems.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From brad at shub-internet.org  Mon Apr 21 23:28:16 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 16:28:16 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net>
Message-ID: <480D06F0.5020009@shub-internet.org>

Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.

Now running on mail.python.org.  Please let us know if there are any problems.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: http://mail.python.org/mailman/options/mailman-users/spyropolymiadis%40kromestudios.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp


From brad at shub-internet.org  Tue Apr 22 00:24:38 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 17:24:38 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net>
Message-ID: <480D1426.1040000@shub-internet.org>

Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.
> 
> This is a security and bug fix release and it is highly recommended
> that all sites upgrade to this version. Mailman 2.1.10 also adds support
> for three new language translations, Galician, Hebrew and Slovak and a
> few new features.

Remind me next time that we *MUST* upgrade to the betas and RCs on 
python.org once you've made them available.  The changes made to the code 
which supports skipping unparseable messages means that mmdsr has to be 
changed to suit, otherwise you could wind up with a daily report that is 
800MB in size, depending on how many "unparseable messages" you might have.

We'll need to coordinate the updates to mmdsr and get the official version 
with all code contributions from all parties out there on the SourceForge page.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From brad at shub-internet.org  Tue Apr 22 00:24:38 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 17:24:38 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net>
Message-ID: <480D1426.1040000@shub-internet.org>

Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.
> 
> This is a security and bug fix release and it is highly recommended
> that all sites upgrade to this version. Mailman 2.1.10 also adds support
> for three new language translations, Galician, Hebrew and Slovak and a
> few new features.

Remind me next time that we *MUST* upgrade to the betas and RCs on 
python.org once you've made them available.  The changes made to the code 
which supports skipping unparseable messages means that mmdsr has to be 
changed to suit, otherwise you could wind up with a daily report that is 
800MB in size, depending on how many "unparseable messages" you might have.

We'll need to coordinate the updates to mmdsr and get the official version 
with all code contributions from all parties out there on the SourceForge page.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: http://mail.python.org/mailman/options/mailman-users/spyropolymiadis%40kromestudios.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp


From barry at list.org  Tue Apr 22 00:31:41 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 18:31:41 -0400
Subject: [Mailman-Developers] Mailman 2.1.10 has been released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
	<4803DF19.3030406@msapiro.net> <480CEFE9.5000008@msapiro.net>
Message-ID: <4AD99A70-A16F-4E0B-8F06-D1F00FAD3257@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 21, 2008, at 3:50 PM, Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.

Congratulations Mark!  Long live Mailman 2.2. :)

I will update the web sites.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNFc0ACgkQ2YZpQepbvXEQ0wCePrsNZ1cyXStsBpjMHR94o20H
HoEAn3Fv8D3WC3NCSkkjg9qIS5I5CzzP
=1UG9
-----END PGP SIGNATURE-----

From barry at list.org  Tue Apr 22 00:33:17 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 18:33:17 -0400
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480D06F0.5020009@shub-internet.org>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net> <480D06F0.5020009@shub-internet.org>
Message-ID: <AD4DE780-E3CE-4311-ABA0-06FAF90A106C@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 21, 2008, at 5:28 PM, Brad Knowles wrote:

> Mark Sapiro wrote:
>
>> I am happy to announce the release of Mailman 2.1.10.
>
> Now running on mail.python.org.  Please let us know if there are any  
> problems.

Wow, awesome Brad.  Thanks!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNFi4ACgkQ2YZpQepbvXG4+wCgp+P2SypS4dBTbAdP4LBpShDu
VCoAoKn0Xvqlt0x72zOWgsvlQA1cJLMv
=4M3O
-----END PGP SIGNATURE-----

From barry at list.org  Tue Apr 22 00:31:41 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 18:31:41 -0400
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has
	been	released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
	<4803DF19.3030406@msapiro.net> <480CEFE9.5000008@msapiro.net>
Message-ID: <4AD99A70-A16F-4E0B-8F06-D1F00FAD3257@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 21, 2008, at 3:50 PM, Mark Sapiro wrote:

> I am happy to announce the release of Mailman 2.1.10.

Congratulations Mark!  Long live Mailman 2.2. :)

I will update the web sites.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNFc0ACgkQ2YZpQepbvXEQ0wCePrsNZ1cyXStsBpjMHR94o20H
HoEAn3Fv8D3WC3NCSkkjg9qIS5I5CzzP
=1UG9
-----END PGP SIGNATURE-----
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: http://mail.python.org/mailman/options/mailman-users/spyropolymiadis%40kromestudios.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp


From barry at list.org  Tue Apr 22 00:33:17 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 18:33:17 -0400
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480D06F0.5020009@shub-internet.org>
References: <47D9E26E.4040708@msapiro.net>
	<47F7B288.6020801@msapiro.net>	<4803DF19.3030406@msapiro.net>
	<480CEFE9.5000008@msapiro.net> <480D06F0.5020009@shub-internet.org>
Message-ID: <AD4DE780-E3CE-4311-ABA0-06FAF90A106C@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 21, 2008, at 5:28 PM, Brad Knowles wrote:

> Mark Sapiro wrote:
>
>> I am happy to announce the release of Mailman 2.1.10.
>
> Now running on mail.python.org.  Please let us know if there are any  
> problems.

Wow, awesome Brad.  Thanks!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNFi4ACgkQ2YZpQepbvXG4+wCgp+P2SypS4dBTbAdP4LBpShDu
VCoAoKn0Xvqlt0x72zOWgsvlQA1cJLMv
=4M3O
-----END PGP SIGNATURE-----
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: http://mail.python.org/mailman/options/mailman-users/spyropolymiadis%40kromestudios.com

Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp


From barry at list.org  Tue Apr 22 00:50:14 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 18:50:14 -0400
Subject: [Mailman-Developers] before next release: disable backscatter
	in default installation
In-Reply-To: <5078E62DC20006D6F67A57C1@[10.169.6.155]>
References: <E6C70824-2AD0-45B0-B8CB-7B146D1FFD07@netconsonance.com>
	<PC1760200803041528220796684c8ad2@msapiro>
	<20080305011346.GD5749@garp.metalab.unc.edu>
	<87abldwxjp.fsf@uwakimon.sk.tsukuba.ac.jp>
	<A6E88D20-028F-4706-A2FB-FB5BC7EC93EA@netconsonance.com>
	<46AFF679D4EFB29F57698A4B@lewes.staff.uscs.susx.ac.uk>
	<1369.64.13.143.30.1206558898.squirrel@mail.netconsonance.com>
	<20080327001842.GN22377@garp.metalab.unc.edu>
	<47EBC9D8.3000403@netconsonance.com>
	<878x03tfs6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5FB84C0DFC17D736C4D7E6B1@lewes.staff.uscs.susx.ac.uk>
	<A77281AC-574C-4AA0-B7AF-E02AF4DAEA76@list.org>
	<5078E62DC20006D6F67A57C1@[10.169.6.155]>
Message-ID: <2D8D7D28-2BDE-4C06-B719-B8CC6E852660@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 14, 2008, at 5:38 PM, Kenneth Porter wrote:

> On Saturday, April 12, 2008 12:44 PM -0400 Barry Warsaw <barry at list.org 
> > wrote:
>
>> Thanks!  Capture here in the "best practices" section:
>>
>> http://wiki.list.org/display/DEV/Home
>
> Note that there's already backscatter prevention info here:
>
> <http://wiki.list.org/display/SEC/Controlling+spam>
>
> One of these pages should be linking to the other. Or perhaps a new  
> "backscatter resources" page should be created for both to point to.

I linked them.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNGikACgkQ2YZpQepbvXFFTQCfWNrs1pRZ3i0gEVn7N+xJJRQf
uM8An1It4pTyXig43ewLOlhSpjMi7G8M
=2UFn
-----END PGP SIGNATURE-----

From mark at msapiro.net  Tue Apr 22 01:19:24 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Apr 2008 16:19:24 -0700
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480D1426.1040000@shub-internet.org>
Message-ID: <PC1760200804211619240015a9a406a7@msapiro>

Brad Knowles wrote:
>
>Remind me next time that we *MUST* upgrade to the betas and RCs on 
>python.org once you've made them available.  The changes made to the code 
>which supports skipping unparseable messages means that mmdsr has to be 
>changed to suit, otherwise you could wind up with a daily report that is 
>800MB in size, depending on how many "unparseable messages" you might have.
>
>We'll need to coordinate the updates to mmdsr and get the official version 
>with all code contributions from all parties out there on the SourceForge page.


OK, I'll try to remember.

FYI, I've been running all the 2.1.10 beta and rc releases and mmdsr
and haven't seen an issue, but I think in my case Postgrey/MailScanner
must be getting rid of all the unparseable messages before they reach
Mailman.

Note that in addition to the logging change for unparseable messages,
they will now be saved in the shunt queue, so if you have a lot,
you'll have to deal with that too.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From brad at shub-internet.org  Tue Apr 22 02:52:22 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 19:52:22 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <PC1760200804211619240015a9a406a7@msapiro>
References: <PC1760200804211619240015a9a406a7@msapiro>
Message-ID: <480D36C6.20209@shub-internet.org>

Mark Sapiro wrote:

> Note that in addition to the logging change for unparseable messages,
> they will now be saved in the shunt queue, so if you have a lot,
> you'll have to deal with that too.

These are the *.psv files?  Yeah, we've got almost 8000 of them on 
python.org.  Do you have any documentation on what should be done with them?

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From mark at msapiro.net  Tue Apr 22 03:30:40 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Apr 2008 18:30:40 -0700
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480D36C6.20209@shub-internet.org>
Message-ID: <PC1760200804211830400093f07b6ee5@msapiro>

Brad Knowles wrote:

>Mark Sapiro wrote:
>
>> Note that in addition to the logging change for unparseable messages,
>> they will now be saved in the shunt queue, so if you have a lot,
>> you'll have to deal with that too.
>
>These are the *.psv files?  Yeah, we've got almost 8000 of them on 
>python.org.  Do you have any documentation on what should be done with them?


Wow! I never thought there would be anything like this.

Here's the situation. Pre 2.1.9, when Mailman dequeued an incoming
message and then the Python email library couldn't parse the MIME
structure  the message was just lost. There wasn't anything that could
be done other than log the fact. This is not a big deal as the
message's MIME structure was defective and the message was almost
certainly spam.

Beginning in 2.1.9, we implemented the .bak files to back up an in
process message so the message could be recovered if something died
horribly (e.g. power failure) while it was in process. Nothing was
done at that time about the unparseable messages.

I then realized that the unparseable message had an intact .bak file in
the queue, so for 2.1.10, I decided to preserve this file (thus the
.psv in the shunt queue) in case some human wanted to look at it with
bin/dumpdb or whatever. Obviously, if you get 8000+ in a few hours, no
one is going to look at them all or even much of a sample.

You could set up a cron to run every hour or some other interval to
efectively do

  rm $var_prefix/qfiles/shunt/*.psv

The problem with that is there can occasionally be queue entries
preserved for other conditions which are hopefully much rarer, but you
might actually want to look at those.

I think the best solution is to turn off the preservation of
unparseable messages, and add an mm_cfg.py setting to turn it on. I
can work up a patch.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Tue Apr 22 04:40:33 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Apr 2008 19:40:33 -0700
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <PC1760200804211830400093f07b6ee5@msapiro>
References: <PC1760200804211830400093f07b6ee5@msapiro>
Message-ID: <480D5021.10405@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Sapiro wrote:
|
| I think the best solution is to turn off the preservation of
| unparseable messages, and add an mm_cfg.py setting to turn it on. I
| can work up a patch.
|


A patch is attached. It doesn't turn off preservation by default because
it piggybacks on an existing Defaults.py/mm_cfg.py setting which was
lately used only by bin/update. The Defaults.py setting is

QRUNNER_SAVE_BAD_MESSAGES = Yes

Setting

QRUNNER_SAVE_BAD_MESSAGES = No

in mm_cfg.py will stop preserving the unparseable messages, but certain
other problem qfiles will still be preserved. Additionally, preserved
files will be stored in qfiles/bad and not qfiles/shunt. Finally, if
QRUNNER_SAVE_BAD_MESSAGES = No, the log message will revert to the old
"Ignoring unparseable message:".

Brad,

If you could apply this patch (you can apply it directly to the
installation directory, by e.g.

cd /usr/local/mailman
patch -p0 < path/to/2.1.10.patch.txt

and set

QRUNNER_SAVE_BAD_MESSAGES = No

in mm_cfg.py and restart Mailman, things should be back more or less the
way they were in 2.1.9.

I have applied the patch to my installation and I'm sure it's good, but
I haven't seen any unparseable messages.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIDVAhVVuXXpU7hpMRAqHBAKCFODqF84UhBYnRvblS00eX4roxdQCeNOXl
amZX+XRwrdd9RpIE80eOFKM=
=vi+P
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.1.10.patch.txt
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20080421/dceffdf2/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.1.10.patch.txt.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20080421/dceffdf2/attachment.obj>

From barry at list.org  Tue Apr 22 04:50:02 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 21 Apr 2008 22:50:02 -0400
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <PC1760200804211830400093f07b6ee5@msapiro>
References: <PC1760200804211830400093f07b6ee5@msapiro>
Message-ID: <42F93661-9DB1-4021-B29D-6863712F6203@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 21, 2008, at 9:30 PM, Mark Sapiro wrote:

> You could set up a cron to run every hour or some other interval to
> efectively do
>
>  rm $var_prefix/qfiles/shunt/*.psv
>
> The problem with that is there can occasionally be queue entries
> preserved for other conditions which are hopefully much rarer, but you
> might actually want to look at those.
>
> I think the best solution is to turn off the preservation of
> unparseable messages, and add an mm_cfg.py setting to turn it on. I
> can work up a patch.

We should probably have some kind of shunt queue culler cron script in  
place, either that archives and deletes those files, or just expires  
them after a certain amount of time.  What to people generally do with  
their shunt files?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgNUlsACgkQ2YZpQepbvXFI8gCgpF+Z1ROdfrEQa4ACrUnDBkJT
DWIAn0qyRtYt4/1UCCpKSmImyLAWhkZO
=WmVk
-----END PGP SIGNATURE-----

From brad at shub-internet.org  Tue Apr 22 06:18:06 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 23:18:06 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
 released
In-Reply-To: <42F93661-9DB1-4021-B29D-6863712F6203@list.org>
References: <PC1760200804211830400093f07b6ee5@msapiro>
	<42F93661-9DB1-4021-B29D-6863712F6203@list.org>
Message-ID: <p06240800c4331722669c@[192.168.1.199]>

On 4/21/08, Barry Warsaw wrote:

>  We should probably have some kind of shunt queue culler cron script in
>  place, either that archives and deletes those files, or just expires
>  them after a certain amount of time.

That's easy enough to do with cron and find.  You tell me what you 
want, and I'll be glad to set that up.

>                                        What to people generally do with
>  their shunt files?

Leave them untouched for months or years?  ;-)

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From brad at shub-internet.org  Tue Apr 22 06:31:32 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 21 Apr 2008 23:31:32 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <480D5021.10405@msapiro.net>
References: <PC1760200804211830400093f07b6ee5@msapiro>
	<480D5021.10405@msapiro.net>
Message-ID: <p06240803c4331a381fd7@[192.168.1.199]>

On 4/21/08, Mark Sapiro wrote:

>  If you could apply this patch (you can apply it directly to the
>  installation directory, by e.g.
>
>  cd /usr/local/mailman
>  patch -p0 < path/to/2.1.10.patch.txt

Patch applied fine, no complaints.

>  and set
>
>  QRUNNER_SAVE_BAD_MESSAGES = No

Done.

>  in mm_cfg.py and restart Mailman, things should be back more or less the
>  way they were in 2.1.9.
>
>  I have applied the patch to my installation and I'm sure it's good, but
>  I haven't seen any unparseable messages.

I haven't seen any more unparseable messages in the last few minutes, 
but let's see how things go.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From brad at shub-internet.org  Tue Apr 22 07:36:39 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Tue, 22 Apr 2008 00:36:39 -0500
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <p06240803c4331a381fd7@[192.168.1.199]>
References: <PC1760200804211830400093f07b6ee5@msapiro>
	<480D5021.10405@msapiro.net> <p06240803c4331a381fd7@[192.168.1.199]>
Message-ID: <p06240801c43327172405@[192.168.1.199]>

On 4/21/08, Brad Knowles wrote:

>>   I have applied the patch to my installation and I'm sure it's good, but
>>   I haven't seen any unparseable messages.
>
>  I haven't seen any more unparseable messages in the last few minutes,
>  but let's see how things go.

We've now had a couple of unparseable messages since applying the 
patch, and it seems to be working as expected.


Going back to Jun 12 23:48:51 2007, it looks like we've had a total 
of about 378,989 unparseable messages, although we only have just 
over 8000 messages in the mailman/qfiles/shunt and 
mailman/qfiles/shunt.old directories (7759 .psv files, and 312 .pck 
files).

That works out to about 37,900 unparseable messages per month, or 
something like about 125 unparseable messages per day.

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

From mark at msapiro.net  Tue Apr 22 15:52:23 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 22 Apr 2008 06:52:23 -0700
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.10 has been
	released
In-Reply-To: <p06240801c43327172405@[192.168.1.199]>
Message-ID: <PC176020080422065223079647453653@msapiro>

Brad Knowles wrote:

>On 4/21/08, Brad Knowles wrote:
>
>>>   I have applied the patch to my installation and I'm sure it's good, but
>>>   I haven't seen any unparseable messages.
>>
>>  I haven't seen any more unparseable messages in the last few minutes,
>>  but let's see how things go.
>
>We've now had a couple of unparseable messages since applying the 
>patch, and it seems to be working as expected.
>
>
>Going back to Jun 12 23:48:51 2007, it looks like we've had a total 
>of about 378,989 unparseable messages, although we only have just 
>over 8000 messages in the mailman/qfiles/shunt and 
>mailman/qfiles/shunt.old directories (7759 .psv files, and 312 .pck 
>files).
>
>That works out to about 37,900 unparseable messages per month, or 
>something like about 125 unparseable messages per day.


The light dawns! (thanks to the post at
<http://mail.python.org/pipermail/mailman-users/2008-April/061365.html>).

There was an error in 2.1.9 that didn't delete (or move aside) the .bak
file in qfiles/in from an unparseable message. Thus, there were 7500+
unparseable message qfiles/in/*.bak files when you restarted mailman.
These were all 'recovered' and reprocessed, reproducing the
unparseable message error, and this time moved to qfiles/shunt/*.psv
(so it wouldn't happen again).

This explains why there were over 7500 of these at once, when the
normal rate is /only/ 125 per day.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Tue Apr 22 17:13:52 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 22 Apr 2008 08:13:52 -0700
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10 upgrade note.
Message-ID: <480E00B0.1010808@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, this note really applies to just restarting mailman a Mailman
2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in
installations that just 'run' without intervention, this restart may not
occur until an upgrade.

There is an error in Mailman 2.1.9. In the introduction of the backup
and recovery of queue entries, we neglected to remove the backup queue
entry for an unparseable message. Thus, if you sometimes receive
unparseable messages which are ignored, you may have an accumulation of
.bak files in qfiles/in from these messages. When you restart Mailman,
these will all be reprocessed, resulting in a flood of error log entries.

There is no real harm done, but it would be a good idea when upgrading
to stop Mailman and remove any qfiles/in/*.bak files.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIDgCwVVuXXpU7hpMRAlOyAJ4/VpFnCL9JHoEBSl4PmZIBowTbigCgjjRr
Bh8FoeuGZDAXonphAnvqwMA=
=qt1K
-----END PGP SIGNATURE-----

From mark at msapiro.net  Tue Apr 22 17:44:03 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 22 Apr 2008 08:44:03 -0700
Subject: [Mailman-Developers] Mailman 2.1.10 has been released
In-Reply-To: <p06240801c43327172405@[192.168.1.199]>
Message-ID: <PC176020080422084403006298e57a61@msapiro>

Brad Knowles wrote:
>
>Going back to Jun 12 23:48:51 2007, it looks like we've had a total 
>of about 378,989 unparseable messages, although we only have just 
>over 8000 messages in the mailman/qfiles/shunt and 
>mailman/qfiles/shunt.old directories (7759 .psv files, and 312 .pck 
>files).


There are two reasons why you've had 378,989 unparseable messages, but
only have 7759 .psv files.

First, some of the unparseable .bak files that 2.1.9 left behind in
qfiles/in may have been removed or moved aside.

Second, whenever Mailman was restarted, any qfiles/in/*.bak files would
have been reprocessed resulting in a flood of unparseable message
errors and leaving just one new .bak file per message. Thus a single
message and .bak file could have been responsible for several logged
unparseable message errors if Mailman had been restarted several times.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From t.d.lee at durham.ac.uk  Tue Apr 22 18:14:46 2008
From: t.d.lee at durham.ac.uk (David Lee)
Date: Tue, 22 Apr 2008 17:14:46 +0100 (BST)
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10 upgrade
 note.
In-Reply-To: <480E00B0.1010808@msapiro.net>
References: <480E00B0.1010808@msapiro.net>
Message-ID: <Pine.GSO.4.58.0804221707080.28623@arachne.dur.ac.uk>

On Tue, 22 Apr 2008, Mark Sapiro wrote:

> Actually, this note really applies to just restarting mailman a Mailman
> 2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in
> installations that just 'run' without intervention, this restart may not
> occur until an upgrade.
>
> There is an error in Mailman 2.1.9. In the introduction of the backup
> and recovery of queue entries, we neglected to remove the backup queue
> entry for an unparseable message. Thus, if you sometimes receive
> unparseable messages which are ignored, you may have an accumulation of
> .bak files in qfiles/in from these messages. When you restart Mailman,
> these will all be reprocessed, resulting in a flood of error log entries.
>
> There is no real harm done, but it would be a good idea when upgrading
> to stop Mailman and remove any qfiles/in/*.bak files.

Just a thought, Mark, for consideration...

If this is deemed "Important" (for anyone upgrading over the next year or
more), and if this cleaning process is well-defined and capable of
mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a"
(or 2.1.11 or whatever nomeclature is appropriate) that automatically does
this cleaning?

(I realise that 2.1.x was intended to be frozen at 2.1.10, but wasn't
there allowance for significant security fixes and bug fixes?)


(Only sending this to -developers list.)

-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:  UNIX Team Leader                         Durham University     :
:                                           South Road            :
:  http://www.dur.ac.uk/t.d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :

From bob at nleaudio.com  Tue Apr 22 18:44:33 2008
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Tue, 22 Apr 2008 12:44:33 -0400
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10 upgrade
 note.
In-Reply-To: <Pine.GSO.4.58.0804221707080.28623@arachne.dur.ac.uk>
References: <480E00B0.1010808@msapiro.net>
	<Pine.GSO.4.58.0804221707080.28623@arachne.dur.ac.uk>
Message-ID: <480E15F1.50200@nleaudio.com>

+1 on the auto-delete.  I have a lot of boxes running Mailman that I periodically have to go into to 
clean out stuff, and having more junk pile up, while helpful for debugging, isn't great for production.

Bob

David Lee wrote:
> On Tue, 22 Apr 2008, Mark Sapiro wrote:
> 
>> Actually, this note really applies to just restarting mailman a Mailman
>> 2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in
>> installations that just 'run' without intervention, this restart may not
>> occur until an upgrade.
>>
>> There is an error in Mailman 2.1.9. In the introduction of the backup
>> and recovery of queue entries, we neglected to remove the backup queue
>> entry for an unparseable message. Thus, if you sometimes receive
>> unparseable messages which are ignored, you may have an accumulation of
>> .bak files in qfiles/in from these messages. When you restart Mailman,
>> these will all be reprocessed, resulting in a flood of error log entries.
>>
>> There is no real harm done, but it would be a good idea when upgrading
>> to stop Mailman and remove any qfiles/in/*.bak files.
> 
> Just a thought, Mark, for consideration...
> 
> If this is deemed "Important" (for anyone upgrading over the next year or
> more), and if this cleaning process is well-defined and capable of
> mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a"
> (or 2.1.11 or whatever nomeclature is appropriate) that automatically does
> this cleaning?
> 
> (I realise that 2.1.x was intended to be frozen at 2.1.10, but wasn't
> there allowance for significant security fixes and bug fixes?)
> 
> 
> (Only sending this to -developers list.)
> 

From mark at msapiro.net  Tue Apr 22 20:44:05 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 22 Apr 2008 11:44:05 -0700
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10
	upgradenote.
In-Reply-To: <480E15F1.50200@nleaudio.com>
Message-ID: <PC1760200804221144050468c671b4f9@msapiro>

Bob Puff at NLE wrote:

>+1 on the auto-delete.  I have a lot of boxes running Mailman that I periodically have to go into to 
>clean out stuff, and having more junk pile up, while helpful for debugging, isn't great for production.

>David Lee wrote:
>> 
>> If this is deemed "Important" (for anyone upgrading over the next year or
>> more), and if this cleaning process is well-defined and capable of
>> mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a"
>> (or 2.1.11 or whatever nomeclature is appropriate) that automatically does
>> this cleaning?


I think this is a good idea. If I had remembered about the unparseable
.bak files, and thought it through, I could have added code to
bin/update to remove them, and I still can for a fix-up release.

Also, In another thread, Barry asked for feedback on "some kind of
shunt queue culler cron script". I think this is a good idea, either
for a separate cron, or incorporated into one of the existing crons.

How about something like a couple of Default config settings like

BAD_SHUNT_ARCHIVE_DIRECTORY = None
BAD_SHUNT_STALE_AFTER = days(7)

With the idea being anything in the 'bad' or 'shunt' queues older than
BAD_SHUNT_STALE_AFTER would be discarded or moved to
BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.

Do people like this idea?

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From eino at utu.fi  Tue Apr 22 20:57:28 2008
From: eino at utu.fi (Eino Tuominen)
Date: Tue, 22 Apr 2008 21:57:28 +0300
Subject: [Mailman-Developers] Important Mailman 2.1.9 to
	2.1.10	upgradenote.
In-Reply-To: <PC1760200804221144050468c671b4f9@msapiro>
References: <PC1760200804221144050468c671b4f9@msapiro>
Message-ID: <480E3518.2090901@utu.fi>

Mark Sapiro wrote:
>
> How about something like a couple of Default config settings like
> 
> BAD_SHUNT_ARCHIVE_DIRECTORY = None
> BAD_SHUNT_STALE_AFTER = days(7)
> 
> With the idea being anything in the 'bad' or 'shunt' queues older than
> BAD_SHUNT_STALE_AFTER would be discarded or moved to
> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
> 
> Do people like this idea?

Seems like a good plan.

-- 
   Eino Tuominen

From bob at nleaudio.com  Tue Apr 22 21:46:01 2008
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Tue, 22 Apr 2008 15:46:01 -0400
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10
	upgradenote.
In-Reply-To: <PC1760200804221144050468c671b4f9@msapiro>
References: <PC1760200804221144050468c671b4f9@msapiro>
Message-ID: <480E4079.90207@nleaudio.com>

Sounds good to me!

Bob

Mark Sapiro wrote:

> How about something like a couple of Default config settings like
> 
> BAD_SHUNT_ARCHIVE_DIRECTORY = None
> BAD_SHUNT_STALE_AFTER = days(7)
> 
> With the idea being anything in the 'bad' or 'shunt' queues older than
> BAD_SHUNT_STALE_AFTER would be discarded or moved to
> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
> 
> Do people like this idea?
> 

From cmpalmer at metalab.unc.edu  Wed Apr 23 08:07:20 2008
From: cmpalmer at metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer)
Date: Wed, 23 Apr 2008 02:07:20 -0400
Subject: [Mailman-Developers] Important Mailman 2.1.9 to
	2.1.10	upgradenote.
In-Reply-To: <PC1760200804221144050468c671b4f9@msapiro>
References: <480E15F1.50200@nleaudio.com>
	<PC1760200804221144050468c671b4f9@msapiro>
Message-ID: <20080423060720.GD22091@garp.metalab.unc.edu>

On Tue, Apr 22, 2008 at 11:44:05AM -0700, Mark Sapiro wrote:
> 
> How about something like a couple of Default config settings like
> 
> BAD_SHUNT_ARCHIVE_DIRECTORY = None
> BAD_SHUNT_STALE_AFTER = days(7)
> 
> With the idea being anything in the 'bad' or 'shunt' queues older than
> BAD_SHUNT_STALE_AFTER would be discarded or moved to
> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
> 
> Do people like this idea?

+1

-- 
Crist?bal Palmer
ibiblio.org systems administrator

From mark at msapiro.net  Wed Apr 23 17:12:47 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 23 Apr 2008 08:12:47 -0700
Subject: [Mailman-Developers] Mailman 2.1.10 has been released
In-Reply-To: <480CEFE9.5000008@msapiro.net>
References: <47D9E26E.4040708@msapiro.net> <47F7B288.6020801@msapiro.net>
	<4803DF19.3030406@msapiro.net> <480CEFE9.5000008@msapiro.net>
Message-ID: <480F51EF.6040702@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Sapiro wrote:
| I am happy to announce the release of Mailman 2.1.10.


I have discovered a few problems with the release. None is a major show
stopper, but the most significant so far is that I broke cmd_subscribe
so that email subscribe to the -subscribe or -join address or the
- -request address with a bare 'subscribe' command results in the message
being shunted. A patch for this is attached, but I plan to make a patch
release probably next week.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFID1HvVVuXXpU7hpMRAm+3AKD2otRNTXWYSRjguJEYVc0HRVflhACZAVXf
Kao5NWvpiRQ9U9keKT2Jbj8=
=1NSl
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.1.10.patch2.txt
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20080423/2d6995cd/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.1.10.patch2.txt.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20080423/2d6995cd/attachment.obj>

From barry at python.org  Wed Apr 23 22:32:09 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Apr 2008 16:32:09 -0400
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10
	upgradenote.
In-Reply-To: <PC1760200804221144050468c671b4f9@msapiro>
References: <PC1760200804221144050468c671b4f9@msapiro>
Message-ID: <C5C4A17B-EF8A-4EC9-9F6C-5A43F2B48D49@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 22, 2008, at 2:44 PM, Mark Sapiro wrote:

> Bob Puff at NLE wrote:
>
>> +1 on the auto-delete.  I have a lot of boxes running Mailman that  
>> I periodically have to go into to
>> clean out stuff, and having more junk pile up, while helpful for  
>> debugging, isn't great for production.
>
>> David Lee wrote:
>>>
>>> If this is deemed "Important" (for anyone upgrading over the next  
>>> year or
>>> more), and if this cleaning process is well-defined and capable of
>>> mechanisation, then might it be worth superseding 2.1.10 with a  
>>> "2.1.10a"
>>> (or 2.1.11 or whatever nomeclature is appropriate) that  
>>> automatically does
>>> this cleaning?
>
>
> I think this is a good idea. If I had remembered about the unparseable
> .bak files, and thought it through, I could have added code to
> bin/update to remove them, and I still can for a fix-up release.
>
> Also, In another thread, Barry asked for feedback on "some kind of
> shunt queue culler cron script". I think this is a good idea, either
> for a separate cron, or incorporated into one of the existing crons.
>
> How about something like a couple of Default config settings like
>
> BAD_SHUNT_ARCHIVE_DIRECTORY = None
> BAD_SHUNT_STALE_AFTER = days(7)
>
> With the idea being anything in the 'bad' or 'shunt' queues older than
> BAD_SHUNT_STALE_AFTER would be discarded or moved to
> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
>
> Do people like this idea?

+1, but I think it should be a separate cron script.  Keep 'em small  
and simple!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSA+cznEjvBPtnXfVAQIzwAQAqGE8xQ+fFoZb7Y1kEEQv/y+BpVRdmTYm
qQeCrMR6V4/nO9xFhavaDE38VWywh7u8U0zMvdAQA6nUVv5z2QVTHEMfIvEzIevV
AUBDSWuckoWh4T1dGENPn8O32ni65JiuIeUFZHwekZtqSXu5qJlQGul0HeGhezpr
RaNfE77wO88=
=QpNE
-----END PGP SIGNATURE-----

From vaquino at dystrick.com  Wed Apr 23 22:27:29 2008
From: vaquino at dystrick.com (Victor Aquino)
Date: Wed, 23 Apr 2008 13:27:29 -0700
Subject: [Mailman-Developers] request for Mailman dev consultant
Message-ID: <480F9BB1.1010800@dystrick.com>

Hello.

We are in search a Mailman application developer to help with one of our 
clients.

Our client's site is tightly integrated with Mailman list software and the server
environment has been highly customized to enable Apache processes to execute
high-level mail configuration commands both within Mailman and Sendmail. This 
custom integration has been problematic to support for us.

Our client does not want to automatically reject messages if addresses are not
in their list servers because they want it to be 'user-friendly' to their client?le. 
Our client also only moderates when an attachment is too large or something
else is out of whack. Of course, spam is a huge problem that has crippled this
workflow and we basically cannot even go in and delete.

We're looking for help and guidance and would like to contract this out.

Thank

-- 

<http://www.dystrick.com>

*Victor Aquino*
Project Manager

dystrick design, Inc.
675 North First St., Suite 280
San Jose, CA 95112

*office:* 408.286.6952 ext. 314
*fax:* 408.904.5019

vaquino at dystrick.com <mailto:vaquino at dystrick.com>
http://www.dystrick.com


From mark at msapiro.net  Sun Apr 27 20:47:07 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 27 Apr 2008 11:47:07 -0700
Subject: [Mailman-Developers] Important Mailman 2.1.9 to 2.1.10 upgrade
 note.
In-Reply-To: <C5C4A17B-EF8A-4EC9-9F6C-5A43F2B48D49@python.org>
References: <PC1760200804221144050468c671b4f9@msapiro>
	<C5C4A17B-EF8A-4EC9-9F6C-5A43F2B48D49@python.org>
Message-ID: <4814CA2B.7050203@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw wrote:
| On Apr 22, 2008, at 2:44 PM, Mark Sapiro wrote:
|
|> Bob Puff at NLE wrote:
|
|>> +1 on the auto-delete.
[...]
|
|>> David Lee wrote:
|>>>
|>>> If this is deemed "Important" (for anyone upgrading over the next
|>>> year or
|>>> more), and if this cleaning process is well-defined and capable of
|>>> mechanisation, then might it be worth superseding 2.1.10 with a
|>>> "2.1.10a"
|>>> (or 2.1.11 or whatever nomeclature is appropriate) that
|>>> automatically does
|>>> this cleaning?
|
|
|> I think this is a good idea. If I had remembered about the unparseable
|> .bak files, and thought it through, I could have added code to
|> bin/update to remove them, and I still can for a fix-up release.
|
|> Also, In another thread, Barry asked for feedback on "some kind of
|> shunt queue culler cron script". I think this is a good idea, either
|> for a separate cron, or incorporated into one of the existing crons.
|
|> How about something like a couple of Default config settings like
|
|> BAD_SHUNT_ARCHIVE_DIRECTORY = None
|> BAD_SHUNT_STALE_AFTER = days(7)
|
|> With the idea being anything in the 'bad' or 'shunt' queues older than
|> BAD_SHUNT_STALE_AFTER would be discarded or moved to
|> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
|
|> Do people like this idea?
|
| +1, but I think it should be a separate cron script.  Keep 'em small and
| simple!


I have implemented a cull_bad_shunt cron and a small change to
bin/update to remove any .bak files from qfiles/ on an upgrade.

These changes are revisions 1074 and 1075 in the branch at
<https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt>.

Revision 1071 is the 2.1.10 release. Revisions 1072 and 1073 have been
committed to the 2.1 branch and a patch for these changes is on the
sourceforge and GNU download sites.

I would appreciate feedback on the 1074 and 1075 revisions from those
interested.

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIFMoqVVuXXpU7hpMRAkP8AJ44h0xk1sBBNLTrrIpcMsta0FR5sACfcVln
A9tSvvHb1ZwuU397YEY0wfY=
=Bh2q
-----END PGP SIGNATURE-----