From mark at msapiro.net  Sun Feb  3 01:33:24 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 02 Feb 2008 16:33:24 -0800
Subject: [Mailman-Developers] Mailman 2.1.10b1 Released
In-Reply-To: <475638CF.2090105@msapiro.net>
References: <475638CF.2090105@msapiro.net>
Message-ID: <47A50BD4.9080305@msapiro.net>

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

I am happy to announce the second beta release of Mailman 2.1.10. For
technical reasons, there was no 'b2' release.

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 two new language translations, 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.

Changes since 2.1.10b1 include:

~  - Fixed cron/disabled to test if bounce info is stale before disabling a
~    member when the threshold has been reduced.

~  - Improved processing of backup/recovery of queue files.

~  - Updated mmdsr script.

~  - Updated Vietnamese and Danish translations.

And here are the major changes from 2.1.9 that were included in 2.1.10b1:

~  Security

~    - The 2.1.9 fixes for CVE-2006-3636 have been enhanced.  In particular,
~      many potential cross-site scripting attacks have are now detected in
~      editing templates and updating the list's info attribute via the web
~      admin interface.  Thanks again to Moritz Naumann for assistance with
~      this.

~  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.


- --
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)

iD8DBQFHpQvUVVuXXpU7hpMRAsfsAKDUXE72UxVAFi7RfqGvnBtVQp6IygCff6Rr
+Zo1cUxAKRMJOfg0wJMPMqw=
=ib/a
-----END PGP SIGNATURE-----

From mark at msapiro.net  Sun Feb  3 01:44:01 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 02 Feb 2008 16:44:01 -0800
Subject: [Mailman-Developers] Mailman 2.1.10b3 Released (was: Re: Mailman
	2.1.10b1 Released)
In-Reply-To: <47A50BD4.9080305@msapiro.net>
References: <475638CF.2090105@msapiro.net> <47A50BD4.9080305@msapiro.net>
Message-ID: <47A50E51.1090609@msapiro.net>

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

Ihe subject of my previous post quoted below should have been "Mailman
2.1.10b3 Released". Sorry for the confusion.

Mark Sapiro wrote:
| I am happy to announce the second beta release of Mailman 2.1.10. For
| technical reasons, there was no 'b2' release.
|
| 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 two new language translations, 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.
|
| Changes since 2.1.10b1 include:
|
| ~  - Fixed cron/disabled to test if bounce info is stale before disabling a
| ~    member when the threshold has been reduced.
|
| ~  - Improved processing of backup/recovery of queue files.
|
| ~  - Updated mmdsr script.
|
| ~  - Updated Vietnamese and Danish translations.
|
| And here are the major changes from 2.1.9 that were included in 2.1.10b1:
|
| ~  Security
|
| ~    - The 2.1.9 fixes for CVE-2006-3636 have been enhanced.  In
| particular,
| ~      many potential cross-site scripting attacks have are now detected in
| ~      editing templates and updating the list's info attribute via the web
| ~      admin interface.  Thanks again to Moritz Naumann for assistance with
| ~      this.
|
| ~  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.
|
|

- --
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)

iD8DBQFHpQ5RVVuXXpU7hpMRAlWtAJ9aQaIQXQVfNCcRuMG8ZYp5V0HfSwCfegGP
EC+QXwqhVYqDcK5FFoekZoU=
=IbiN
-----END PGP SIGNATURE-----

From barry at list.org  Sun Feb  3 04:33:24 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 2 Feb 2008 22:33:24 -0500
Subject: [Mailman-Developers] [Mailman-Announce] Mailman 2.1.10b1
	Released
In-Reply-To: <47A50BD4.9080305@msapiro.net>
References: <475638CF.2090105@msapiro.net> <47A50BD4.9080305@msapiro.net>
Message-ID: <B041E985-A08A-4C92-A103-A963D9FBD4D9@list.org>

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

On Feb 2, 2008, at 7:33 PM, Mark Sapiro wrote:
>
> I am happy to announce the second beta release of Mailman 2.1.10. For
> technical reasons, there was no 'b2' release.

Awesome!  Thanks, and congratulations Mark.

- -Barry

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

iD8DBQFHpTYE2YZpQepbvXERAlSbAJ9MQatnxST/LWENA4E1+x/qq9fBjQCdHOi8
6/nKDh0bhR2y/NDzJlyUlwE=
=Q/bo
-----END PGP SIGNATURE-----

From adrian at tasmaniaconsulting.com  Tue Feb  5 22:07:58 2008
From: adrian at tasmaniaconsulting.com (Adrian Bye)
Date: Tue, 5 Feb 2008 17:07:58 -0400
Subject: [Mailman-Developers] Feedback for mailman developers
Message-ID: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>

Hi guys (and RMS, copied),

About 3 years ago I made this post:

http://mail.python.org/pipermail/mailman
-developers/2005-February/017850.html

As a result, I get an email every 1-2 months from people asking for an
updated patch.

I felt at the time it was an important project.  I was told it was not, so I
made it myself.  And, it was refused to be added to the main fork of mailman
which was quite frustrating.

Given the volume of email requests I get about it, my opinion seems to be
confirmed.  I wanted to bring it to your attention, and hope something will
be done about it.  These are just people who are figuring out my email
address on the web and contacting me.  There must be many more who don't
actually ask me about it.

If another group wants to step up and improve mailman, it might be a good
time to do so.  This is a critical project which could become the
centerpiece of a lot of important software if it was improved.

Best regards,

Adrian

From stephen at xemacs.org  Thu Feb  7 04:52:07 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 07 Feb 2008 12:52:07 +0900
Subject: [Mailman-Developers]  Feedback for mailman developers
In-Reply-To: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
Message-ID: <87odatiftk.fsf@uwakimon.sk.tsukuba.ac.jp>

Adrian Bye writes:

 > I felt at the time it was an important project.  I was told it was
 > not, so I made it myself.  And, it was refused to be added to the
 > main fork of mailman which was quite frustrating.

Actually, in the thread in the archives you were not told it was
"unimportant", you were told it was a bad idea, that shouldn't be
added to the Mailman mainline, and one prominent developer's bad
experiences with a very similar system (which was implied to be more
robust than yours is) were described.  You didn't respond, so as far
as I can see it was left out by default, not actually refused.  There
is a difference.

I see no reason why the reasons for not adding the proposed feature
given in that thread have been invalidated.  If you have significant
experience with successes with your system, and are willing to
describe it, and are willing to address the perceived defects in the
light of your experience, I'm sure your patch will be reconsidered.

If you don't, declaring your patch to be "often requested" and "a
necessary precondition for the resources needed to turn Mailman into a
system capable of handling millions of messages a day" is not going to
help your case.

Another way to put it is the Mailman developers all have a lot of
successful experience with the policy of implementing standards and
best practices.  There's no standard here so experience is crucial to
demonstrating best practice.  Please report yours!



From amk at amk.ca  Thu Feb  7 12:25:40 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Thu, 7 Feb 2008 06:25:40 -0500
Subject: [Mailman-Developers] Feedback for mailman developers
In-Reply-To: <87odatiftk.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
	<87odatiftk.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20080207112540.GA12163@amk.local>

On Thu, Feb 07, 2008 at 12:52:07PM +0900, Stephen J. Turnbull wrote:
> I see no reason why the reasons for not adding the proposed feature
> given in that thread have been invalidated.  If you have significant

This patch includes two things, though: HTML headers and footers, and
the 1-click unsubscribe.  The HTML headers don't seem as
controversial, beyond one incorrect help message, and could go in even
if 1-click doesn't.  I was thinking of adding HTML headers and
footers, so I'm happy to shepherd that portion of the patch.

--amk

From barry at list.org  Thu Feb  7 13:31:40 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 7 Feb 2008 07:31:40 -0500
Subject: [Mailman-Developers] Feedback for mailman developers
In-Reply-To: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
Message-ID: <2153CA14-918C-4AEA-A3DC-973C3242FDC9@list.org>

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

On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:

> Hi guys (and RMS, copied),
>
> About 3 years ago I made this post:
>
> http://mail.python.org/pipermail/mailman
> -developers/2005-February/017850.html
>
> As a result, I get an email every 1-2 months from people asking for an
> updated patch.

It looks to me like there are really two separate unrelated features  
here.  Distributing them in the same patch would make it difficult to  
review, discuss, test and integrate, regardless of whether they are  
good ideas or not.

I would like to encourage you to develop your patches in a different  
way.  I'm not making any promises about whether they would be  
integrated if you do this, but it would make it easier for us to look  
at, and I believe easier for your to maintain separately if you decide  
to continue to do so.

I would highly recommend creating two separate Bazaar branches of the  
Mailman 2.1 code.  Each would implement just one of your features.   
You could create a third branch with the whole thing if you wanted,  
but I don't think it would be necessary.  You should then register on  
Launchpad and push these branches, publishing them in a live source  
code repository for all to see.

I'm really trying to encourage this style of development.  To me,  
patches living in a tracker is dead code.  With a published, public  
branch, the entire process is more transparent, we can easily do a  
merge and test if we wanted to look at it.  We can even find these  
branches easily via Launchpad.  And you will have an easier time  
maintaining them, because as new revisions get pushed to Mailman 2.1  
trunk, you can just merge, commit, and push to update your own branch.

If you -- or anybody else -- has questions about this workflow, please  
ping me on #mailman on irc.freenode.net.  I will happily walk you  
through it.

Cheers,
- -Barry

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

iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3
pcP+bzgjF1D1dIv89m8VLCY=
=BC8W
-----END PGP SIGNATURE-----

From barry at list.org  Thu Feb  7 13:36:30 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 7 Feb 2008 07:36:30 -0500
Subject: [Mailman-Developers] Feedback for mailman developers
In-Reply-To: <20080207112540.GA12163@amk.local>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
	<87odatiftk.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080207112540.GA12163@amk.local>
Message-ID: <4BE16CA0-7575-46DB-A0C1-EA7E727AF448@list.org>

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

On Feb 7, 2008, at 6:25 AM, A.M. Kuchling wrote:

> On Thu, Feb 07, 2008 at 12:52:07PM +0900, Stephen J. Turnbull wrote:
>> I see no reason why the reasons for not adding the proposed feature
>> given in that thread have been invalidated.  If you have significant
>
> This patch includes two things, though: HTML headers and footers, and
> the 1-click unsubscribe.  The HTML headers don't seem as
> controversial, beyond one incorrect help message, and could go in even
> if 1-click doesn't.  I was thinking of adding HTML headers and
> footers, so I'm happy to shepherd that portion of the patch.

When Mark releases Mailman 2.1.10, I'd like to reopen the discussion  
about Mailman 2.2.  I'd like for us to consider moving all new  
development over to that branch, which will allow us to be more  
liberal about accepting new features, within the constraints of  
Mailman 2's architecture of course.

I am planning on releasing an alpha of Mailman 3 by PyCon next month,  
but it will still be lacking a web u/i so I think it still makes sense  
to think about moving almost all current Mailman 2.1 work over to the  
2.2 branch, while still maintaining Mailman 2.1 for security and  
severe performance bugs.

Cheers,
- -Barry

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

iD8DBQFHqvtO2YZpQepbvXERAvbpAJ9VbgT8Su7WOmYdlTpf3DEF76iVxgCfdp8o
RQfh9pggeOBAjkCK7CUFtfE=
=rflQ
-----END PGP SIGNATURE-----

From barry at list.org  Thu Feb  7 21:18:50 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 7 Feb 2008 15:18:50 -0500
Subject: [Mailman-Developers] Feedback for mailman developers
In-Reply-To: <a893002e0802071008v7d861e5ey27314e15225e5a2a@mail.gmail.com>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
	<2153CA14-918C-4AEA-A3DC-973C3242FDC9@list.org>
	<a893002e0802071008v7d861e5ey27314e15225e5a2a@mail.gmail.com>
Message-ID: <9E81F732-0806-46F5-94E9-6454C7A5D1ED@list.org>

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

On Feb 7, 2008, at 1:08 PM, Adrian Bye wrote:

> The one-click unsubscribe is a critical feature for mailman and will  
> open up a much larger interest base.  I am not proposing 1-click  
> unsubscribe for discussion mailing lists such as this one - that  
> would obviously cause problems with people unsubscribing each other  
> by mistake.  However a lot of organizations use mailing list  
> software to broadcast newsletters to their membership.  If users  
> cannot unsubscribe via some kind of (simple) 1-click interface then  
> it limits the people who can use the system and may not be CANSPAM  
> compliant.

I can see that there is some merit to the idea for newsletter type  
mailing lists.  I think there's still the possibility of abuse because  
such messages tend to be forwarded and those forwards will have the 1- 
click unsub link.  The only way I see of limiting that would be to  
require a log-in to confirm the unsub, but then I guess you're in no  
better shape.

I really wish more mail readers would support the RFC 2369 headers  
directly.  I think that would go a long way to making unsub as easy as  
possible.

Having said all that, this is clearly not a feature for Mailman 2.1.   
If some of the details can be worked out, it might be an option for  
Mailman 3 where I think 'list styles' will help make configuration of  
newsletter vs. discussion mailing lists much simpler.

Adrian, are you interested in creating the Bazaar branches as I  
outlined previously?

Cheers,
- -Barry

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

iD8DBQFHq2eq2YZpQepbvXERAhRJAKCPGr9poibsagXH0MglKZFb+j8howCgkFhm
h2GkWKJK1cZbhPOeQsl1kVg=
=D2fp
-----END PGP SIGNATURE-----

From barry at list.org  Fri Feb  8 00:11:59 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 7 Feb 2008 18:11:59 -0500
Subject: [Mailman-Developers] Fwd:  Feedback for mailman developers
References: <a893002e0802071453m67ed5f61s69b66f799b63566c@mail.gmail.com>
Message-ID: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org>

Begin forwarded message:

> From: "Adrian Bye" <adrian at tasmaniaconsulting.com>
> Date: February 7, 2008 5:53:21 PM EST
> To: barry at list.org
> Subject: Fwd: [Mailman-Developers] Feedback for mailman developers
>
> Barry,
>
> Could you do me a huge favor and make sure this gets to the list.   
> It doesn't show up in the archives.
>
> Warm regards,
>
> Adrian
>
> ---------- Forwarded message ----------
> From: Adrian Bye <adrian at tasmaniaconsulting.com>
> Date: Feb 7, 2008 2:08 PM
> Subject: Re: [Mailman-Developers] Feedback for mailman developers
> To: Barry Warsaw <barry at list.org>
> Cc: mailman-developers at python.org, rms at gnu.org, bmurdoch at lwb.org.au, tmihalicek at mihainside.com 
> , techsupport at meridian-ds.com, Peter Brown <peterb at fsf.org>
>
>
> Hi guys,
>
> I've copied 3 people who emailed me since May 2007 about this  
> issue.  I don't know any of them, they just found my post from 3  
> years ago on the web and wrote to me.  Clearly its important to them  
> since they emailed me about it.
>
> Guys:  I encourage you to subscribe to the mailman-developers list  
> so you can communicate your needs directly with the mailman  
> development team.
>
> The one-click unsubscribe is a critical feature for mailman and will  
> open up a much larger interest base.  I am not proposing 1-click  
> unsubscribe for discussion mailing lists such as this one - that  
> would obviously cause problems with people unsubscribing each other  
> by mistake.  However a lot of organizations use mailing list  
> software to broadcast newsletters to their membership.  If users  
> cannot unsubscribe via some kind of (simple) 1-click interface then  
> it limits the people who can use the system and may not be CANSPAM  
> compliant.  The FSF is one organization that has been running a  
> newsletter for a while and they have had to manually handle  
> unsubscribe requests.  Peter Brown is copied as well as RMS and may  
> be able to respond if necessary.
>
> When many users cannot unsubscribe from an announcement list (as the  
> FSF used mailman for) they often don't bother, instead they just hit  
> the "this is spam" button.  Neither the sender or receiver notices  
> anything when this happens.  For the receiver, future emails from  
> the list go into the trash, so hitting the "this is spam" button  
> accomplished their purpose.  The sender doesn't realise there was a  
> problem because they never heard from the recipient.  But the mail  
> services know (eg hotmail/gmail/yahoo/aol) and they begin to mark  
> the IP address/domain of the sender as a spam sender.  This causes  
> future WANTED mail from that sender to go into the trash.
>
> When we were experimenting with mailman 3 years ago, we found that  
> in fact mailman already has a bad reputation for email.  We found  
> our mail was directly going into the trash when it included mailman  
> headers.  When we modified mailman to send but hide the mailman  
> headers, we got directly into the inbox.  This testing is 3 years  
> old, and I don't remember the specific services we were testing to,  
> but it included one of hotmail or yahoo.
>
> While mailman continues not to support easy unsubscribe in the  
> footers, it will continue to hamper the growth of free software, as  
> free software organizations will not have a reliable product to mail  
> to broadcast to interested users.  This demand is evidenced by the  
> emails I get every 2 months from people asking me for this patch due  
> to my emails in the archives from 3 years ago.
>
> I'm not here to get into a debate - I only joined the list again to  
> ask to have that post removed because I'm tired of responding to  
> these requests which I cannot help with.
>
> I hope this explains my point of view.  Best of luck,
>
> Adrian
>
>
> On 2/7/08, Barry Warsaw <barry at list.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:
>
> > Hi guys (and RMS, copied),
> >
> > About 3 years ago I made this post:
> >
> > http://mail.python.org/pipermail/mailman
> > -developers/2005-February/017850.html
> >
> > As a result, I get an email every 1-2 months from people asking  
> for an
> > updated patch.
>
> It looks to me like there are really two separate unrelated features
> here.  Distributing them in the same patch would make it difficult to
> review, discuss, test and integrate, regardless of whether they are
> good ideas or not.
>
> I would like to encourage you to develop your patches in a different
> way.  I'm not making any promises about whether they would be
> integrated if you do this, but it would make it easier for us to look
> at, and I believe easier for your to maintain separately if you decide
> to continue to do so.
>
> I would highly recommend creating two separate Bazaar branches of the
> Mailman 2.1 code.  Each would implement just one of your features.
> You could create a third branch with the whole thing if you wanted,
> but I don't think it would be necessary.  You should then register on
> Launchpad and push these branches, publishing them in a live source
> code repository for all to see.
>
> I'm really trying to encourage this style of development.  To me,
> patches living in a tracker is dead code.  With a published, public
> branch, the entire process is more transparent, we can easily do a
> merge and test if we wanted to look at it.  We can even find these
> branches easily via Launchpad.  And you will have an easier time
> maintaining them, because as new revisions get pushed to Mailman 2.1
> trunk, you can just merge, commit, and push to update your own branch.
>
> If you -- or anybody else -- has questions about this workflow, please
> ping me on #mailman on irc.freenode.net.  I will happily walk you
> through it.
>
> Cheers,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3
> pcP+bzgjF1D1dIv89m8VLCY=
> =BC8W
> -----END PGP SIGNATURE-----
>
>
>
> -- 
> Adrian Bye
> Tasmania Consulting Group
> http://TasmaniaConsulting.com
> adrian.bye at tasmaniaconsulting.com
> Phone: 305-433-8188 Fax: 305-428-2665
>
> Mailing address:
> 8260 NW 14th St, EPS-Y12457
> Doral, FL, 33126-1502
>
>
> -- 
> Adrian Bye
> Tasmania Consulting Group
> http://TasmaniaConsulting.com
> adrian.bye at tasmaniaconsulting.com
> Phone: 305-433-8188 Fax: 305-428-2665
>
> Mailing address:
> 8260 NW 14th St, EPS-Y12457
> Doral, FL, 33126-1502

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20080207/ca8369cd/attachment.pgp 

From stephen at xemacs.org  Fri Feb  8 03:17:01 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 08 Feb 2008 11:17:01 +0900
Subject: [Mailman-Developers]  Fwd:  Feedback for mailman developers
In-Reply-To: <3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org>
References: <a893002e0802071453m67ed5f61s69b66f799b63566c@mail.gmail.com>
	<3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org>
Message-ID: <87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:
 > Begin forwarded message:
 > > From: "Adrian Bye" <adrian at tasmaniaconsulting.com>

 > > We found our mail was directly going into the trash when it
 > > included mailman headers.  When we modified mailman to send but
 > > hide the mailman headers, we got directly into the inbox.

What do you mean by "Mailman headers"?  The RFC 2369 headers
(List-Id, List-Post, and friends)?


From stephen at xemacs.org  Sat Feb  9 05:20:19 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 09 Feb 2008 13:20:19 +0900
Subject: [Mailman-Developers] Fwd: Feedback for mailman developers
In-Reply-To: <a893002e0802080715t2c9506ddtd723ebe79d9bf3a2@mail.gmail.com>
References: <a893002e0802071453m67ed5f61s69b66f799b63566c@mail.gmail.com>
	<3E27E105-5319-49F0-9554-63BCCA96E0BC@list.org>
	<87wspggpk2.fsf@uwakimon.sk.tsukuba.ac.jp>
	<a893002e0802080715t2c9506ddtd723ebe79d9bf3a2@mail.gmail.com>
Message-ID: <873as2oj5o.fsf@uwakimon.sk.tsukuba.ac.jp>

Adrian Bye writes:

 > I don't know the specifics.  I just told the developer to remove
 > all headers which identified mailman as mailman.

Well, could you ask him which they were?  It matters.

BTW, a look at the patch suggests it's incomplete; I couldn't find any
templates for headers and footers, nor documentation for how to
generate the 1-click unsubscribe button.

 > When we did this, mail got into the inbox.  We tested this
 > definitively and the mailman headers was the difference.

Sure, but that doesn't necessarily mean that Mailman or Mailman lists
have bad reputations per se.  The big email providers are known to
have screwed up MTAs and filters that do not conform to the relevant
standards in ways that "just happen" to misidentify legitimate use of
certain headers by Mailman as spammer spoor.


From adrian at tasmaniaconsulting.com  Thu Feb  7 19:08:03 2008
From: adrian at tasmaniaconsulting.com (Adrian Bye)
Date: Thu, 7 Feb 2008 14:08:03 -0400
Subject: [Mailman-Developers] Feedback for mailman developers
In-Reply-To: <2153CA14-918C-4AEA-A3DC-973C3242FDC9@list.org>
References: <a893002e0802051307p1588ce22r39f6d27dfd4679a5@mail.gmail.com>
	<2153CA14-918C-4AEA-A3DC-973C3242FDC9@list.org>
Message-ID: <a893002e0802071008v7d861e5ey27314e15225e5a2a@mail.gmail.com>

Hi guys,

I've copied 3 people who emailed me since May 2007 about this issue.  I
don't know any of them, they just found my post from 3 years ago on the web
and wrote to me.  Clearly its important to them since they emailed me about
it.

Guys:  I encourage you to subscribe to the mailman-developers list so you
can communicate your needs directly with the mailman development team.

The one-click unsubscribe is a critical feature for mailman and will open up
a much larger interest base.  I am not proposing 1-click unsubscribe for
discussion mailing lists such as this one - that would obviously cause
problems with people unsubscribing each other by mistake.  However a lot of
organizations use mailing list software to broadcast newsletters to their
membership.  If users cannot unsubscribe via some kind of (simple) 1-click
interface then it limits the people who can use the system and may not be
CANSPAM compliant.  The FSF is one organization that has been running a
newsletter for a while and they have had to manually handle unsubscribe
requests.  Peter Brown is copied as well as RMS and may be able to respond
if necessary.

When many users cannot unsubscribe from an announcement list (as the FSF
used mailman for) they often don't bother, instead they just hit the "this
is spam" button.  Neither the sender or receiver notices anything when this
happens.  For the receiver, future emails from the list go into the trash,
so hitting the "this is spam" button accomplished their purpose.  The sender
doesn't realise there was a problem because they never heard from the
recipient.  But the mail services know (eg hotmail/gmail/yahoo/aol) and they
begin to mark the IP address/domain of the sender as a spam sender.  This
causes future WANTED mail from that sender to go into the trash.

When we were experimenting with mailman 3 years ago, we found that in fact
mailman already has a bad reputation for email.  We found our mail was
directly going into the trash when it included mailman headers.  When we
modified mailman to send but hide the mailman headers, we got directly into
the inbox.  This testing is 3 years old, and I don't remember the specific
services we were testing to, but it included one of hotmail or yahoo.

While mailman continues not to support easy unsubscribe in the footers, it
will continue to hamper the growth of free software, as free software
organizations will not have a reliable product to mail to broadcast to
interested users.  This demand is evidenced by the emails I get every 2
months from people asking me for this patch due to my emails in the archives
from 3 years ago.

I'm not here to get into a debate - I only joined the list again to ask to
have that post removed because I'm tired of responding to these requests
which I cannot help with.

I hope this explains my point of view.  Best of luck,

Adrian


On 2/7/08, Barry Warsaw <barry at list.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote:
>
> > Hi guys (and RMS, copied),
> >
> > About 3 years ago I made this post:
> >
> > http://mail.python.org/pipermail/mailman
> > -developers/2005-February/017850.html
> >
> > As a result, I get an email every 1-2 months from people asking for an
> > updated patch.
>
> It looks to me like there are really two separate unrelated features
> here.  Distributing them in the same patch would make it difficult to
> review, discuss, test and integrate, regardless of whether they are
> good ideas or not.
>
> I would like to encourage you to develop your patches in a different
> way.  I'm not making any promises about whether they would be
> integrated if you do this, but it would make it easier for us to look
> at, and I believe easier for your to maintain separately if you decide
> to continue to do so.
>
> I would highly recommend creating two separate Bazaar branches of the
> Mailman 2.1 code.  Each would implement just one of your features.
> You could create a third branch with the whole thing if you wanted,
> but I don't think it would be necessary.  You should then register on
> Launchpad and push these branches, publishing them in a live source
> code repository for all to see.
>
> I'm really trying to encourage this style of development.  To me,
> patches living in a tracker is dead code.  With a published, public
> branch, the entire process is more transparent, we can easily do a
> merge and test if we wanted to look at it.  We can even find these
> branches easily via Launchpad.  And you will have an easier time
> maintaining them, because as new revisions get pushed to Mailman 2.1
> trunk, you can just merge, commit, and push to update your own branch.
>
> If you -- or anybody else -- has questions about this workflow, please
> ping me on #mailman on irc.freenode.net.  I will happily walk you
> through it.
>
> Cheers,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3
> pcP+bzgjF1D1dIv89m8VLCY=
> =BC8W
> -----END PGP SIGNATURE-----
>



-- 
Adrian Bye
Tasmania Consulting Group
http://TasmaniaConsulting.com
adrian.bye at tasmaniaconsulting.com
Phone: 305-433-8188 Fax: 305-428-2665

Mailing address:
8260 NW 14th St, EPS-Y12457
Doral, FL, 33126-1502

From stephen at xemacs.org  Tue Feb 12 21:35:21 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 13 Feb 2008 05:35:21 +0900
Subject: [Mailman-Developers] Logging lossage
In-Reply-To: <PC1760200802120910220421986b899b@msapiro>
References: <f9467540802120515l2fe4e7d2l86db689302bf7d9c@mail.gmail.com>
	<PC1760200802120910220421986b899b@msapiro>
Message-ID: <8763wt6hh2.fsf@uwakimon.sk.tsukuba.ac.jp>

Moved from mailman-users.

Mark Sapiro writes:

 > If this is the case, there will be 'Message discarded' entries in
 > Mailman's vette log, but they will only tell you the message was
 > discarded, not why.

I've long thought that this is a design bug.

This is one nice thing about SpamAssassin: it tells you which rules
were triggered.

Is this already improved in 3.0?  Would better logging be something to
target in 2.2?

From amk at amk.ca  Wed Feb 13 14:48:01 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 13 Feb 2008 08:48:01 -0500
Subject: [Mailman-Developers] Logging lossage
In-Reply-To: <8763wt6hh2.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <f9467540802120515l2fe4e7d2l86db689302bf7d9c@mail.gmail.com>
	<PC1760200802120910220421986b899b@msapiro>
	<8763wt6hh2.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20080213134801.GC6832@amk-desktop.matrixgroup.net>

On Wed, Feb 13, 2008 at 05:35:21AM +0900, Stephen J. Turnbull wrote:
> This is one nice thing about SpamAssassin: it tells you which rules
> were triggered.

This reminds me of Mailman's most annoying reason for holding a
message, the 'suspicious header' error/warning.  It doesn't say what
the header is, or what's suspicious about it; some regular posters to
lists I admin often get caught by this message, but I have no easy way
of telling why.

--amk

From barry at list.org  Wed Feb 13 15:15:24 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 13 Feb 2008 09:15:24 -0500
Subject: [Mailman-Developers] Logging lossage
In-Reply-To: <20080213134801.GC6832@amk-desktop.matrixgroup.net>
References: <f9467540802120515l2fe4e7d2l86db689302bf7d9c@mail.gmail.com>
	<PC1760200802120910220421986b899b@msapiro>
	<8763wt6hh2.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20080213134801.GC6832@amk-desktop.matrixgroup.net>
Message-ID: <20D844A3-7155-4E65-9498-C1A2BB176FC0@list.org>

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

On Feb 13, 2008, at 8:48 AM, A.M. Kuchling wrote:

> On Wed, Feb 13, 2008 at 05:35:21AM +0900, Stephen J. Turnbull wrote:
>> This is one nice thing about SpamAssassin: it tells you which rules
>> were triggered.
>
> This reminds me of Mailman's most annoying reason for holding a
> message, the 'suspicious header' error/warning.  It doesn't say what
> the header is, or what's suspicious about it; some regular posters to
> lists I admin often get caught by this message, but I have no easy way
> of telling why.

Agreed!  I really want to get rid of this for MM3.  Instead, I've  
implemented a fairly generic header matching rule which can be used to  
accept, hold, reject, or discard the message based on the match.   
These rules will be storable in the database or on file and the plan  
is to include exactly the match in any hold or rejection message.  The  
rule stuff is implemented and in the tree, the notification message  
stuff is not yet.

- -Barry

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

iD8DBQFHsvt82YZpQepbvXERAvf3AKCR5rov3kxffNGi0QLoz7WXSOCTLwCbBo08
x+aJ/d2i21ONNxlEqtHlINI=
=HcwJ
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Wed Feb 13 19:59:39 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 14 Feb 2008 03:59:39 +0900
Subject: [Mailman-Developers] [Mailman-Users] RFC: X-Archive header
	fields
In-Reply-To: <7E20E34E-E220-46FB-BC7F-238404E323B9@list.org>
References: <2d460de70802130400j1fc79627qa1e1dce298cbca34@mail.gmail.com>
	<7E20E34E-E220-46FB-BC7F-238404E323B9@list.org>
Message-ID: <87zlu47kdg.fsf@uwakimon.sk.tsukuba.ac.jp>

Moving to Mailman-Developers per BAW.  CC to -Users; Reply-To set to
-Developers only.

Barry Warsaw writes:

 > Hi Richard,
 > 
 > Please see RFC 5064: http://www.ietf.org/rfc/rfc5064.txt

Argh.  You'd think they'd get in touch with the maintainers and users
of the most popular mailing list software before approving it.  It
doesn't even mention the word "thread".

If somebody knows offhand how to find the archived discussions for the
RFC, please post an URL.  It's hard to imagine these guys didn't
already cover a lot of the ground that we'll want to (especially the
point that X-Archived-Thread may be a YAGNI).

Richard Hartman writes:

 > I was wondering if anyone would think X-Archive-Thread and
 > X-Archive-Mail would make sense.

A couple of minutes' reflection suggests to me that this distinction
may be artificial.  Specifically,

(1) It's not obvious to me how many such distinctions make sense.  For
example, User A may wish to jump to head of thread to see the whole
thing, while User B may wish to jump to most recent to see if there's
been a resolution (or maybe the list is infested with top-posters so
reading the most recent in last-line-first mode is the most efficient
way to get the whole thread!)  Some users may want to see an index,
which might be by-date or by-author or by-subject.

(2) This URL "works" in the sense that you get the specified document,
and the query part is ignored.  I don't know if this is an artifact of
the server daemon or if it's part of the specification of the query
part.

    http://www.ietf.org/rfc/rfc2822.txt?bogusquery=doesnotmatter

(3) In current best practice (heck, even pipermail does it) each
message contains "up" pointers to one or more relevant indicies.  This
means that you're at most three clicks from where you want to be
(archive link in current message, thread index, thread-head message).

Given those three points, I suggest that a better way to do this is to
provide some standard queries *relative to an archived message* that
dynamic archive servers can support, while with a static server the
user is not very far from where she wants to be in any case.

Some additional comments: (1) suggests that "archived thread" is
premature in the RFC tradition; there's no practice to support it yet
AFAIK.  We could support it, but use of URLs with derived queries
generated by MUAs is somewhat more flexible (there's no backward
compatibility problem with archaic X-Headers).


From Dale at Newfield.org  Wed Feb 13 20:49:39 2008
From: Dale at Newfield.org (Dale Newfield)
Date: Wed, 13 Feb 2008 14:49:39 -0500
Subject: [Mailman-Developers] [Mailman-Users] RFC: X-Archive
	header	fields
In-Reply-To: <87zlu47kdg.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <2d460de70802130400j1fc79627qa1e1dce298cbca34@mail.gmail.com>	<7E20E34E-E220-46FB-BC7F-238404E323B9@list.org>
	<87zlu47kdg.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <47B349D3.5020309@Newfield.org>

Stephen J. Turnbull wrote:
> If somebody knows offhand how to find the archived discussions for the
> RFC, please post an URL.

The RFC says it was discussed on the ietf-822 at imc.org mailing list.

http://www.imc.org/ietf-822/mail-archive/msg05940.html  Seems to be the 
thread root for the last discussion about it.

-Dale

From richih.mailinglist at gmail.com  Wed Feb 13 22:55:26 2008
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Wed, 13 Feb 2008 22:55:26 +0100
Subject: [Mailman-Developers] [Mailman-Users] RFC: X-Archive header
	fields
In-Reply-To: <87zlu47kdg.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <2d460de70802130400j1fc79627qa1e1dce298cbca34@mail.gmail.com>
	<7E20E34E-E220-46FB-BC7F-238404E323B9@list.org>
	<87zlu47kdg.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <2d460de70802131355gd71ac91r94582ed86df596cd@mail.gmail.com>

On Feb 13, 2008 7:59 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> Moving to Mailman-Developers per BAW.  CC to -Users; Reply-To set to
> -Developers only.

I love being in an atmosphere where people know what they do. Proper
mail & list handling is not too much of a surprise on these lists I guess,
though.


> Argh.  You'd think they'd get in touch with the maintainers and users
> of the most popular mailing list software before approving it.  It
> doesn't even mention the word "thread".

Indeed.


> A couple of minutes' reflection suggests to me that this distinction
> may be artificial.  Specifically,

In the same sense that both a directory and a file are both files ;)


> (1) It's not obvious to me how many such distinctions make sense.  For
> example, User A may wish to jump to head of thread to see the whole
> thing, while User B may wish to jump to most recent to see if there's
> been a resolution (or maybe the list is infested with top-posters so
> reading the most recent in last-line-first mode is the most efficient
> way to get the whole thread!)  Some users may want to see an index,
> which might be by-date or by-author or by-subject.

In theory, several options could be offered. In the scheme I had in mind,
as it is what a thread basically is, is a tree view of the discussion, sorted
by thread. Of course, this can be debated, but I feel this what a 'thread'
actually is.


> (2) This URL "works" in the sense that you get the specified document,
> and the query part is ignored.  I don't know if this is an artifact of
> the server daemon or if it's part of the specification of the query
> part.
>
>     http://www.ietf.org/rfc/rfc2822.txt?bogusquery=doesnotmatter

That is implementation-specific. As the list software could handle &
generate the URI itself, this would solve itself.


> (3) In current best practice (heck, even pipermail does it) each
> message contains "up" pointers to one or more relevant indicies.  This
> means that you're at most three clicks from where you want to be
> (archive link in current message, thread index, thread-head message).

No reason to enhance this with a better, more general standard, though.


> Given those three points, I suggest that a better way to do this is to
> provide some standard queries *relative to an archived message* that
> dynamic archive servers can support, while with a static server the
> user is not very far from where she wants to be in any case.

Now _that_ is something I can fully agree with. Perhaps inject some
other X fields that allow the MUA to build their own URIs more or less
freely in reaction to whatever was supplied in the mail.

I do not think you will be able to specify standard modifiers that all list
software can agree to, so an implicit URI generation is not viable.

Which of the two options is better is up for debate, please join in :)


> Some additional comments: (1) suggests that "archived thread" is
> premature in the RFC tradition; there's no practice to support it yet
> AFAIK.  We could support it, but use of URLs with derived queries
> generated by MUAs is somewhat more flexible (there's no backward
> compatibility problem with archaic X-Headers).

As the RFC was released Dec 2007, changes should be relatively
painless to make in a new RFC.


Richard

From stephen at xemacs.org  Fri Feb 15 17:55:03 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 16 Feb 2008 01:55:03 +0900
Subject: [Mailman-Developers] [Bug] 2x decode_header? [was: No subscription
	is made ...]
In-Reply-To: <78E3AAA50C11F0419C4C3F41707B6530048BE219@taipan.ad.adm.ku.dk>
References: <78E3AAA50C11F0419C4C3F41707B6530048BE1FE@taipan.ad.adm.ku.dk>
	<87ve4t4v65.fsf@uwakimon.sk.tsukuba.ac.jp>
	<78E3AAA50C11F0419C4C3F41707B6530048BE210@taipan.ad.adm.ku.dk>
	<87k5l770mq.fsf@uwakimon.sk.tsukuba.ac.jp>
	<78E3AAA50C11F0419C4C3F41707B6530048BE219@taipan.ad.adm.ku.dk>
Message-ID: <87wsp65fdk.fsf@uwakimon.sk.tsukuba.ac.jp>

Moving to -developers, reply-to set.  Please keep Henrik in the loop.

Seems to be the same as
http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=103&atid=100103

Henrik Rasmussen writes:

 > Stephen J. Turnbull wrote:
 > > Henrik Rasmussen writes:
 > > Of course it's possible that the MUA is just inserting those headers
 > > but it's a lie (the MUA thinks that's enough to let it get away with
 > > just putting UTF-8 *anywhere*).  But note that 0xF8 is illegal in
 > > UTF-8 (for several reasons), so most likely that is intended as an ISO
 > > 8-bit character.
 > > Do you agree that the interpretation of 0xF8 as "?" is likely here?
 > 
 > I'm not sure. The mail body contains a signature "N?rregaard" in
 > the plain text section and "N=C3=B8rregaard" in the HTML section,
 > but there is no "?" in the header (and thus nor the e-mail address
 > of the subscriber).

This sounds like a bug in Mailman; if the headers do not contain any
characters outside of ASCII, then for some reason Mailman (or the
email module that it calls) is trying to decode the headers twice.

Can you provide a verbatim copy of the original message?  (If privacy
is a problem, send it to Mark Sapiro <mark at sapiro.net>.  Mark is the
likely person to actually do any fixing; I know how this stuff works
in principle but haven't yet actually hacked the core code.)  The
whole thing, with no changes at all, please (you never know what
matters in these things, even changing the .sig could make the bug go
away!)

 > But even so, the fact that Mailman issued a 'new' command, the user
 > should have been put on the list (i'm just speculating here, I'm
 > not that familiar with e-mail handeling and especially not Mailman
 > nor Python).

"Issue" a command and "complete" a command are two different things.
I've already archived the earlier posts so I can't evaluate your
conjecture offhand.



From mark at msapiro.net  Fri Feb 15 18:18:20 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 15 Feb 2008 09:18:20 -0800
Subject: [Mailman-Developers] [Bug] 2x decode_header? [was: No
	subscriptionis made ...]
In-Reply-To: <87wsp65fdk.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <PC17602008021509182005155e9b9397@msapiro>

Stephen J. Turnbull wrote:

>Moving to -developers, reply-to set.  Please keep Henrik in the loop.
>
>Seems to be the same as
>http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=103&atid=100103


I do not think it is the same bug. Note that bug 1186819 appears to be
due to non-ascii in the user's real name and occurs during processing
of a web subscribe request, although it may well also occur in
processing an email subscribe request too since it comes in
mlist.AddMember.

The current bug occurs in an email confirmation only and has to do with
non-ascii in the message body.

Here's my analysis of the current bug as posted in the mailman-users
thread:

<quote>
I looked more closely at the traceback, and I think we have a bug. What
happened here is the confirmation was received and processed and the
subscription was confirmed. Then there is a bit at the end of
cmd_confirm.py that 'eats up' the rest of the message and makes a list
of 'unprocessed' lines. It is in this loop that the exception occurs.
The loop goes through the lines skipping any that match the 'confirm
<token>' command just processed, since adding such a line to the
'unprocessed' lines would be confusing.

In this case, the processed confirm command was in the subject, and
because of the way we handle subjects, it was a Unicode string. Thus,
when we looped through the rest of the lines doing

    if line.lstrip() == match:

with match being a Unicode string, line.lstrip() was assumed ascii and
coerced to Unicode for the comparison. This threw the exception when
it got to the signature line with a non-ascii character, and even
though the subscription was confirmed, the exception caused the saving
of the updated list to be skipped and the new member was lost.
</quote>

I already have a fix for the current bug. I just haven't tested it yet.

--- test-mailman-2.1/Mailman/Commands/cmd_confirm.py
+++ test-mailman/Mailman/Commands/cmd_confirm.py
@@ -90,8 +90,11 @@
             match = 'confirm ' + cookie
             unprocessed = []
             for line in res.commands:
-                if line.lstrip() == match:
-                    continue
+                try:
+                    if line.lstrip() == match:
+                        continue
+                except UnicodeError:
+                    pass
                 unprocessed.append(line)
             res.commands = unprocessed
     # Process just one confirmation string per message

I will also look into bug 1186819.

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


From Jeff.Kunzelman at dhl.com  Mon Feb 18 22:27:30 2008
From: Jeff.Kunzelman at dhl.com (Jeff Kunzelman (DHL))
Date: Mon, 18 Feb 2008 14:27:30 -0700
Subject: [Mailman-Developers] Clustered mailman
In-Reply-To: <PC17602008021509182005155e9b9397@msapiro>
References: <87wsp65fdk.fsf@uwakimon.sk.tsukuba.ac.jp>
	<PC17602008021509182005155e9b9397@msapiro>
Message-ID: <F931C75C17BB4240AC7C268CDA674CCB0EF360@PHXDCEX200.phx-dc.dhl.com>


Sorry for posting this to the developers list but it's a little more
involved then a standard usability issue. 

We have 2 mailman servers that we run in a cluster sharing a san volume
for archives, data, lists, logs, qfiles. Orginally we didn't have it
sharing the data directory but we ran into problems with moderated lists
and having the web administration not seeing the moderated messages on
the other node.

So we shared the data directory and it solved this problem. But we are
running into issues with master-queuerunner.pid file being deleted when
mailman is stopped or restarted causing us to have to recreate this
file. Obviously we shouldn't be sharing the same pid file for 2 nodes.

My question is where in the configs can I change this filename so that
each node can have a unique pid file?


From mark at msapiro.net  Mon Feb 18 23:56:18 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 18 Feb 2008 14:56:18 -0800
Subject: [Mailman-Developers] Clustered mailman
In-Reply-To: <F931C75C17BB4240AC7C268CDA674CCB0EF360@PHXDCEX200.phx-dc.dhl.com>
Message-ID: <PC17602008021814561808902bf031ec@msapiro>

Jeff Kunzelman (DHL) wrote:
>
>So we shared the data directory and it solved this problem. But we are
>running into issues with master-queuerunner.pid file being deleted when
>mailman is stopped or restarted causing us to have to recreate this
>file. Obviously we shouldn't be sharing the same pid file for 2 nodes.
>
>My question is where in the configs can I change this filename so that
>each node can have a unique pid file?


The file is defined in Defaults.py and can be overridden in mm_cfg.py
just like anything else. The default is

PIDFILE = os.path.join(DATA_DIR, 'master-qrunner.pid')

You can redefine this in each mm_cfg.py to be a unique name for each
copy.

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


From stephen at xemacs.org  Sun Feb 24 00:40:16 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 24 Feb 2008 08:40:16 +0900
Subject: [Mailman-Developers] Mailboxes of various sorts (archive subthread)
In-Reply-To: <8835828F-6B51-47EB-BF35-79E8AD626AE1@list.org>
References: <PC1760200802210748510296930709fb@msapiro>
	<967AEBBB-BFAE-47A7-86E2-17598DB80661@list.org>
	<p06240803c3e3f5098509@[192.168.1.199]>
	<568B16A4-2555-4C3F-80DD-E0E0E4B6294A@list.org>
	<p0624080bc3e54cc7165e@[192.168.1.199]>
	<8835828F-6B51-47EB-BF35-79E8AD626AE1@list.org>
Message-ID: <87wsovfdi7.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > The archives is an entirely different subsystem, and without a  
 > volunteer stepping forward (for which I've been practically begging  
 > for years ;),

Are you able and willing to mentor said volunteer?

 > That's the unfortunate reality, but I do have thoughts about our  
 > archiver situation, which I'll outline at some future date.

Yes, please.  And sooner rather than later.

From mark at msapiro.net  Mon Feb 25 17:35:52 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 25 Feb 2008 08:35:52 -0800
Subject: [Mailman-Developers] [Bug] 2x decode_header? [was:
 No	subscriptionis made ...]
In-Reply-To: <PC17602008021509182005155e9b9397@msapiro>
References: <PC17602008021509182005155e9b9397@msapiro>
Message-ID: <47C2EE68.9040103@msapiro.net>

Mark Sapiro wrote:
> Stephen J. Turnbull wrote:
> 
>> Moving to -developers, reply-to set.  Please keep Henrik in the loop.
>>
>> Seems to be the same as
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=103&atid=100103
> 
> 
> I do not think it is the same bug. Note that bug 1186819 appears to be
> due to non-ascii in the user's real name and occurs during processing
> of a web subscribe request, although it may well also occur in
> processing an email subscribe request too since it comes in
> mlist.AddMember.
> 
> The current bug occurs in an email confirmation only and has to do with
> non-ascii in the message body.
> 
> Here's my analysis of the current bug as posted in the mailman-users
> thread:
> 
> <quote>
> I looked more closely at the traceback, and I think we have a bug. What
> happened here is the confirmation was received and processed and the
> subscription was confirmed. Then there is a bit at the end of
> cmd_confirm.py that 'eats up' the rest of the message and makes a list
> of 'unprocessed' lines. It is in this loop that the exception occurs.
> The loop goes through the lines skipping any that match the 'confirm
> <token>' command just processed, since adding such a line to the
> 'unprocessed' lines would be confusing.
> 
> In this case, the processed confirm command was in the subject, and
> because of the way we handle subjects, it was a Unicode string. Thus,
> when we looped through the rest of the lines doing
> 
>     if line.lstrip() == match:
> 
> with match being a Unicode string, line.lstrip() was assumed ascii and
> coerced to Unicode for the comparison. This threw the exception when
> it got to the signature line with a non-ascii character, and even
> though the subscription was confirmed, the exception caused the saving
> of the updated list to be skipped and the new member was lost.
> </quote>
> 
> I already have a fix for the current bug. I just haven't tested it yet.
> 
> --- test-mailman-2.1/Mailman/Commands/cmd_confirm.py
> +++ test-mailman/Mailman/Commands/cmd_confirm.py
> @@ -90,8 +90,11 @@
>              match = 'confirm ' + cookie
>              unprocessed = []
>              for line in res.commands:
> -                if line.lstrip() == match:
> -                    continue
> +                try:
> +                    if line.lstrip() == match:
> +                        continue
> +                except UnicodeError:
> +                    pass
>                  unprocessed.append(line)
>              res.commands = unprocessed
>      # Process just one confirmation string per message
> 
> I will also look into bug 1186819.
> 

I am unable to reproduce either bug in Mailman 2.1.10b3 with Python 
2.5.1, however I heard from Henrik that the above patch fixed his 
problem, and I have committed that patch to the 2.1 branch.

I added a note to 
<http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=103&atid=100103> 
saying I can't reproduce it and that it may have been fixed by 
<http://sourceforge.net/tracker/index.php?func=detail&aid=1235567&group_id=103&atid=300103> 
and asking for feedback if it is still a current problem.

-- 
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  Mon Feb 25 21:32:27 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 25 Feb 2008 15:32:27 -0500
Subject: [Mailman-Developers] Mailboxes of various sorts (archive
	subthread)
In-Reply-To: <87wsovfdi7.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <PC1760200802210748510296930709fb@msapiro>
	<967AEBBB-BFAE-47A7-86E2-17598DB80661@list.org>
	<p06240803c3e3f5098509@[192.168.1.199]>
	<568B16A4-2555-4C3F-80DD-E0E0E4B6294A@list.org>
	<p0624080bc3e54cc7165e@[192.168.1.199]>
	<8835828F-6B51-47EB-BF35-79E8AD626AE1@list.org>
	<87wsovfdi7.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <E4335131-639A-4014-B7A0-08F1AA448054@list.org>

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

On Feb 23, 2008, at 6:40 PM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> The archives is an entirely different subsystem, and without a
>> volunteer stepping forward (for which I've been practically begging
>> for years ;),
>
> Are you able and willing to mentor said volunteer?

Yes.  It's important enough that I would make time for it.

>> That's the unfortunate reality, but I do have thoughts about our
>> archiver situation, which I'll outline at some future date.
>
> Yes, please.  And sooner rather than later.

Okay.  I'm not /quite/ ready to do so, but should be soon.

Cheers,
- -Barry

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

iEYEARECAAYFAkfDJdsACgkQ2YZpQepbvXFdMgCfVsnUhtAjMorIeVXxRZk/Xv+L
QlMAoK7ZCaPBnpZ+Tqg2vitWQnyrRkcj
=i5Vx
-----END PGP SIGNATURE-----

From jenred at gmail.com  Thu Feb 28 22:40:45 2008
From: jenred at gmail.com (Jennifer Redman)
Date: Thu, 28 Feb 2008 13:40:45 -0800
Subject: [Mailman-Developers] Mailman Dynamic Sublists
Message-ID: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>

Hello!

The Systers (http://anitaborg.org/initiatives/systers/) community uses a
modified version of Mailman that extends functionality to include dynamic
sublists (a person can chose to unsubscribe to individual conversations if
they are not interested, without removing themselves from the main list).

The extension has been running well for the last 4+ years, but it's time to
sync to the current version of Mailman to remedy some problems with the
upgrade path, security concerns, and bugs that have appeared due to bit rot.

The original project is located here:

http://sourceforge.net/projects/dsub/

Ellen Spertus, the author of the extensions, posted previously many years
ago -- around 2002 if you'd like to search for the original threads.

My questions for the Mailman Development Community:

1) Is there any interest in helping us bring the code up to date?

2) Is the correct first step to create an unofficial branch and move the
project into Launchpad under the auspices of the Mailman project?

3) Has anyone developed something similar in the past few years which
provides similar functionality that may be an acceptable alternative?

4) What steps would we need to take to get the extensions included upstream?

Thanks for your help!

Jennifer

From barry at list.org  Thu Feb 28 23:33:43 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 17:33:43 -0500
Subject: [Mailman-Developers] Mailman Dynamic Sublists
In-Reply-To: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
References: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
Message-ID: <2FF0EAAF-87E7-4529-B277-6DDB4AE41B90@list.org>

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

On Feb 28, 2008, at 4:40 PM, Jennifer Redman wrote:

> Hello!

I Jennifer,

> The Systers (http://anitaborg.org/initiatives/systers/) community  
> uses a
> modified version of Mailman that extends functionality to include  
> dynamic
> sublists (a person can chose to unsubscribe to individual  
> conversations if
> they are not interested, without removing themselves from the main  
> list).

Very cool.  I remember talking with Ellen about this years ago.

> The extension has been running well for the last 4+ years, but it's  
> time to
> sync to the current version of Mailman to remedy some problems with  
> the
> upgrade path, security concerns, and bugs that have appeared due to  
> bit rot.
>
> The original project is located here:
>
> http://sourceforge.net/projects/dsub/
>
> Ellen Spertus, the author of the extensions, posted previously many  
> years
> ago -- around 2002 if you'd like to search for the original threads.
>
> My questions for the Mailman Development Community:
>
> 1) Is there any interest in helping us bring the code up to date?

Without looking at the code, I think this should be done as part of  
Mailman 2.2's development.  But you could start by merging the code  
with the head of the Mailman 2.1 branch.  Once it applies cleanly to  
2.1 it should be pretty easy to apply to 2.2 once the latter is  
brought current.

It can't go into 2.1 because it's a new feature.  I'm really hoping  
that 2.1.10 will be one of the last 2.1 releases and that we'll start  
focussing on 2.2 and 3.0 from then on.

It would be neat to see how the same ideas could be applied to 3.0,  
but I suspect the implementation would be fairly significantly  
different.

> 2) Is the correct first step to create an unofficial branch and move  
> the
> project into Launchpad under the auspices of the Mailman project?

You don't need official Mailman project blessing to do the first  
steps.  I think it would be enough to create a team and project on  
Launchpad, bzr branch the Mailman 2.1 tree, port your code to the  
branch, then push the branch into the team's code area.  Mailman's  
code pillar should notice that the branches are related and show up  
automatically under its Code tab.

Be sure to edit this page though: http://wiki.list.org/display/DEV/MailmanBranches

I'm happy to chat with you on irc (#mailman on freenode) if you have  
any questions getting this set up!

> 3) Has anyone developed something similar in the past few years which
> provides similar functionality that may be an acceptable alternative?

I think Tokio's sibling lists might be in the same ballpark.

> 4) What steps would we need to take to get the extensions included  
> upstream?

First let's get a working branch on Launchpad, then we can review the  
code.  Ultimately, we'll need FSF assignment papers for any  
significant patch (which it sounds like this is) from all copyright  
owners.  Other than that, if it's a cool feature then I think 100k  
euros (sorry, US dollar <snif>) to each of Mark, Tokio and I in bags  
of small, unmarked coins should do it. :)

just-kidding-about-the-bribe-ly y'rs,
- -Barry

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

iEYEARECAAYFAkfHNscACgkQ2YZpQepbvXEBRwCfRNukcp8odQFg/ud5Xvnism7j
ZqIAnRcJjO1KoVemsjorL0kOUCqAzBpL
=4j5m
-----END PGP SIGNATURE-----

From terri at zone12.com  Thu Feb 28 23:17:35 2008
From: terri at zone12.com (Terri Oda)
Date: Thu, 28 Feb 2008 17:17:35 -0500
Subject: [Mailman-Developers] Mailman Dynamic Sublists
In-Reply-To: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
References: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
Message-ID: <1DB97A6B-6E8A-44B4-8C30-392861256CEC@zone12.com>

On 28-Feb-08, at 4:40 PM, Jennifer Redman wrote:
> 3) Has anyone developed something similar in the past few years which
> provides similar functionality that may be an acceptable alternative?

How similar is this to the Topic functionality that's around now?   
(all messages matching a topic regex can be subscribed to/ 
unsubscribed from.)  I'm guessing the big difference is that your  
dynamic sublists are generated, well, dynamically?  Would it be  
possible to just put in some code to generate the topics  
automatically and have that meet your needs?

  Terri


From jenred at gmail.com  Thu Feb 28 23:52:43 2008
From: jenred at gmail.com (Jennifer Redman)
Date: Thu, 28 Feb 2008 14:52:43 -0800
Subject: [Mailman-Developers] Mailman Dynamic Sublists
In-Reply-To: <1DB97A6B-6E8A-44B4-8C30-392861256CEC@zone12.com>
References: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
	<1DB97A6B-6E8A-44B4-8C30-392861256CEC@zone12.com>
Message-ID: <93f118f0802281452m3fd182d9vb2bbcf0d3a13986d@mail.gmail.com>

On Thu, Feb 28, 2008 at 2:17 PM, Terri Oda <terri at zone12.com> wrote:

>
> How similar is this to the Topic functionality that's around now?
> (all messages matching a topic regex can be subscribed to/
> unsubscribed from.)  I'm guessing the big difference is that your
> dynamic sublists are generated, well, dynamically?  Would it be
> possible to just put in some code to generate the topics
> automatically and have that meet your needs?
>

At first glance, this sounds like an excellent alternative, and possibly
easier to implement then bringing the legacy code up to date.  I'm still
sorting through all of the extra features that seem to be bundled in the
extension.

There is also a database dependency -- Systers is using Postgres -- which is
an added level of complexity and difference from the main Mailman branch
that would be nice to eliminate if we could do so without losing any major
functionality.

Would you mind pointing me in the direction of documentation on the topics
functionality -- I found the excellent entries in the handbook ;>, but would
like to take a look at some release notes or additional doc if it's around.
Is the Mailman Developer Resources home page on the wiki the best place to
start?

Thanks!

From jenred at gmail.com  Thu Feb 28 23:57:27 2008
From: jenred at gmail.com (Jennifer Redman)
Date: Thu, 28 Feb 2008 14:57:27 -0800
Subject: [Mailman-Developers] Mailman Dynamic Sublists
In-Reply-To: <2FF0EAAF-87E7-4529-B277-6DDB4AE41B90@list.org>
References: <93f118f0802281340x38577975k59927be504042de7@mail.gmail.com>
	<2FF0EAAF-87E7-4529-B277-6DDB4AE41B90@list.org>
Message-ID: <93f118f0802281457v6a924eafma03a2001f5a417cd@mail.gmail.com>

Hi Barry!

On Thu, Feb 28, 2008 at 2:33 PM, Barry Warsaw <barry at list.org> wrote:


> > 2) Is the correct first step to create an unofficial branch and move
> > the
> > project into Launchpad under the auspices of the Mailman project?
>
>
> You don't need official Mailman project blessing to do the first
> steps.  I think it would be enough to create a team and project on
> Launchpad, bzr branch the Mailman 2.1 tree, port your code to the
> branch, then push the branch into the team's code area.  Mailman's
> code pillar should notice that the branches are related and show up
> automatically under its Code tab.
>
> Be sure to edit this page though:
> http://wiki.list.org/display/DEV/MailmanBranches
>
> I'm happy to chat with you on irc (#mailman on freenode) if you have
> any questions getting this set up!


Thank you, I'll proceed following the above instructions.


>
>
> > 3) Has anyone developed something similar in the past few years which
> > provides similar functionality that may be an acceptable alternative?
>
> I think Tokio's sibling lists might be in the same ballpark.


Would you please point me to some information about the sibling lists or is
this the topic functionality Terri mentioned?


>
>
> > 4) What steps would we need to take to get the extensions included
> > upstream?
>
> First let's get a working branch on Launchpad, then we can review the
> code.  Ultimately, we'll need FSF assignment papers for any
> significant patch (which it sounds like this is) from all copyright
> owners.


I'll start working on this.


> Other than that, if it's a cool feature then I think 100k
> euros (sorry, US dollar <snif>) to each of Mark, Tokio and I in bags
> of small, unmarked coins should do it. :)


heh.

Thank you!

Jennifer

From mark at msapiro.net  Fri Feb 29 03:09:33 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 28 Feb 2008 18:09:33 -0800
Subject: [Mailman-Developers] Mailman Dynamic Sublists
In-Reply-To: <93f118f0802281457v6a924eafma03a2001f5a417cd@mail.gmail.com>
Message-ID: <PC1760200802281809330281b58d4b3a@msapiro>

Jennifer Redman wrote:
>
>Would you please point me to some information about the sibling lists or is
>this the topic functionality Terri mentioned?


Sibling lists are not related to Topics. I think Topics are closer to
what you want.

Probably the best information about sibling lists is at
<https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103>.

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