From mark at msapiro.net  Tue Jul  1 20:04:44 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 01 Jul 2008 11:04:44 -0700
Subject: [Mailman-Developers] Mailman 2.1.11 final has been released.
In-Reply-To: <486930DE.6050202@msapiro.net>
References: <486930DE.6050202@msapiro.net>
Message-ID: <486A71BC.3060105@msapiro.net>

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

The release notes and NEWS file for Mailman 2.1.11 contains the
following innocuous looking item.

~    - Improved bounce loop detection and handling in BounceRunner.py.

This actually first appeared in 2.1.11rc2. It turns out this had an
unintended consequence, but I actually think it is a good thing.

The change involved bounces returned to the site list (mailman list)
- -bounces address. There was always code in BounceRunner.py to look at
bounces returned to the site list -bounces address to try to detect if
the bounce was a bounce of a notice to a list owner, and if so, to send
the bounce to the site list instead of processing it. This code never
worked right.

The main problem, is I don't in general know how to tell to what address
the bounced message was originally sent. If I did, there would never be
an unrecognized bounce. So part of the change in 2.1.11 rc2 and final is
to just forward to the site list owner any message that arrives to the
site list -bounces address so the owner can handle the bounce.

The unintended consequence is that bounces of password reminders will
also now go to the site list owner whereas before they were probably
just ignored or processed as unrecognized bounces to the site list.

Most of these bounces will probably be for dead addresses where the user
disabled delivery and forgot about the list and the address died and the
password reminders have been bouncing for a long time.

In the longer term, plain text passwords and reminders are going away,
but in the short term, the site list owner may get a lot of bounced
password reminders (possibly a whole lot in a large site) on the first
of the month following installation of this release.

I think the best way to deal with these is to remove the dead addresses
from the lists. Once this is done, the number of bounces on an ongoing
basis should be small.

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

iD8DBQFIanG8VVuXXpU7hpMRAg9UAKDa8+K8krlwftCWex/9HuGPV/yq8ACgkX0H
/lXKKlzIU/aP2xOhE9K3H5k=
=lOmt
-----END PGP SIGNATURE-----

From barry at list.org  Tue Jul  1 20:57:38 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 14:57:38 -0400
Subject: [Mailman-Developers] [Mailman-Users] Mailman 2.1.11 final has
	been released.
In-Reply-To: <200807011840.m61IeRKV022201@julie.lostwells.net>
References: <200807011840.m61IeRKV022201@julie.lostwells.net>
Message-ID: <F32CB58B-B7E7-4193-8516-58D0E57E4610@list.org>

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

On Jul 1, 2008, at 2:40 PM, Hank van Cleef wrote:

> I'm also concerned about this proposed scheme to discontinue montnly
> mailings.  It most definitely needs some mechanism whereby a user can
> reset or re-obtain their password without moderator intervention.  Our
> user base is just plain not password-savvy, and I'm concerned about
> the increase in moderator workload if the recovery method is similar
> to password resetting by root (the Unix method).

Don't worry, going forward we'll have a fairly typical password reset  
feature instead of the monthly reminder.  The other advantage of this  
is that we won't have to keep user passwords in our database  
unencrypted.

- -Barry

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

iEYEARECAAYFAkhqfiIACgkQ2YZpQepbvXGgOACgphaPDxMRZ1E3bSO+NVVTqHxM
8ogAoKD9V1hQ18ZkTlHsAb0X7Ky5YVEr
=cYvr
-----END PGP SIGNATURE-----

From barry at list.org  Wed Jul  2 18:03:42 2008
From: barry at list.org (Barry Warsaw)
Date: Wed, 2 Jul 2008 12:03:42 -0400
Subject: [Mailman-Developers] [Mailman-Users] Python process size grows
	30x in 8 hours (memory
In-Reply-To: <PC187020080702081517028138c4a06a@msapiro>
References: <PC187020080702081517028138c4a06a@msapiro>
Message-ID: <89C35AC9-B253-46B5-B230-15A9C2070F46@list.org>

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

On Jul 2, 2008, at 11:15 AM, Mark Sapiro wrote:

> At some point in the next day or so, I'm going to make a modified
> scripts/post script which will queue incoming messages in qfiles/bad
> and then move them to qfiles/in only if they are under a certain size.
> I'm really curious to see if that will help.

This should be moved to mailman-developers, but in general it's an  
interesting idea. In MM3 I've split the incoming queue into two  
separate queues.  The incoming queue now solely determines the  
disposition of the message, i.e. held, rejected, discarded or  
accepted.  If accepted, the message is moved to a pipeline queue where  
it's munged for delivery (i.e. headers and footers added, etc.).

MM3 also has an LMTP queue runner, which I'd like to make the default  
delivery mechanism for 3.0 and possibly 2.2 (yes, I still have a todo  
to back port MM3's new process architecture to 2.2).  Although it's  
not there right now, it would be trivial to add a check on the raw  
size of the message before it's parsed.  If it's too large then it can  
be rejected before the email package attempts to parse it, and that  
would give the upstream LTMP client (i.e. your MTA) a better diagnostic.

It still makes sense to put a size limit in your MTA so it never hits  
the LMTP server because the string will still be in the Python  
process's memory.  But at least you won't pay the penalty for parsing  
such a huge message just to reject it later.

>> Trying to find a way to look at the contents of the heap or at  
>> least limit
>> its growth.
>> Or is there not a way expire & restart mailman processes analogous  
>> to the
>> apache httpd process expiration (designed to mitigate this kind of  
>> resource
>> growth over time)?
>
>
> bin/mailmanctl could be modified to do this automatically, but
> currently only does it on command (restart) or signal (SIGINT), but I
> gather you're already running a cron that does a periodic restart.

This is a good idea.  It might be better to do this in  
Runner._doperiodic().

- -Barry

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

iEYEARECAAYFAkhrpt4ACgkQ2YZpQepbvXHAtgCgj0E1IJjf4kkv4TNKkzcB+RFF
VxAAn1k01dLfPeKPcOgMxDneSyEB/5Ro
=qiO5
-----END PGP SIGNATURE-----

From barry at list.org  Thu Jul  3 06:57:06 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 3 Jul 2008 00:57:06 -0400
Subject: [Mailman-Developers] RFC 5064 Archived-At header
Message-ID: <378856DB-FC4F-4432-AAF7-2A8B955A02FD@list.org>

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

Hello MHonArc and Mailman developers.

RFC 5064 describes the Archived-At header, which is used to point  
directly to the archived version of a mailing list mail message.  The  
value of this header could also be used in a message body footer, such  
as the type that Mailman typically adds to its list copy of the  
message.  Supporting this would be a big improvement in usability for  
mailing lists and is an often requested feature of Mailman.

We have been having some off-list discussions recently between Jeff  
Marshall and Jeff Breidenbach of the Mail-Archive.com, Earl Hood of  
the MHonArc project and myself on approaches that would provide for  
support of RFC 5064 Archived-At headers.  The RFC itself is agnostic  
on how to calculate the value of this header, but it does provide some  
suggestions.  On the mailman-developers mailing list a while ago we  
discussed several ways of calculating this header, and in our private  
discussions, we've refined our thoughts.  We're now at something of an  
impasse, where the specific approach requires us to make some trade- 
offs between implementation choices and usability.  It's now time to  
get your feedback.

I've just updated the current proposal on the Mailman wiki:

http://wiki.list.org/x/yQAM

See specifically the Open Issues section.  The most straight-forward  
way to implement this leads to long, unusable (in our opinion) urls.   
Shortening the urls would require quite a bit of additional  
implementation complexity.  What to do?

It's time to open this up to your ideas, but let me say that from  
Mailman(3)'s perspective, the exact algorithm probably doesn't matter  
much.  I have a bzr branch that implements the interfaces and  
infrastructure for archiver plugins, so if MHonArc, Pipermail, and  
Mail-Archive.com all chose different algorithms, we can fairly easily  
write a different plugin for each.  Still, it would be good to  
standardize on a usable, implementable approach.

I invite you to read the wiki page, and comment either there or as a  
follow up to this message.  I am not on the mhonarc-dev mailing list.

Cheers,
- -Barry
P.S. mhonarc-devs: I apologize in advance for the replybot on my email  
address.

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

iEYEARECAAYFAkhsXCIACgkQ2YZpQepbvXFvNwCgg6jS/6NgmwYMa1W+9786Qd63
d00AoLJ99UEbKmvoBRUGbVi+B+PHJZEk
=Lzo8
-----END PGP SIGNATURE-----

From jeff at jab.org  Thu Jul  3 08:44:56 2008
From: jeff at jab.org (Jeff Breidenbach)
Date: Wed, 2 Jul 2008 23:44:56 -0700
Subject: [Mailman-Developers] RFC 5064 Archived-At header
In-Reply-To: <200807030611.m636BN8x025598@gator.earlhood.com>
References: <378856DB-FC4F-4432-AAF7-2A8B955A02FD@list.org>
	<200807030611.m636BN8x025598@gator.earlhood.com>
Message-ID: <e03b90ae0807022344h4361501w11e36ca69421e2a@mail.gmail.com>

>Will someone provide some real use case scenarios of how the
>archived-at URL gets used by a message receipient.  If I have
>the message locally, do I care where it is archived?

It's handy if you are writing a blog. For example, Linux Weekly
News reports on the Linux Kernel mailing list. They quote
particular messages, and provide an archival link. This lets readers
examine the (possibly active) thread.

http://lwn.net/Articles/286910/
http://lwn.net/Articles/287490/

From william.multimedia at gmail.com  Thu Jul  3 13:59:59 2008
From: william.multimedia at gmail.com (William Mead)
Date: Thu, 3 Jul 2008 12:59:59 +0100
Subject: [Mailman-Developers] Mailman 3 lmtp queue runners
Message-ID: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>

Hello fellow Mailman developers,

My name is William Mead, I'm a new Mailman developer and currently as
an intern for Ian Elioart at the university of Sussex.

We have started working on Mailman 3.0. At the moment we are looking
at the lmtp part of Mailman, however we have come up against a few
problems. We are able to get all the queue runners started except for
the lmtp queue runner. We have set lmtp to be used in the Defaults.py
file, but this doesn't start the lmtp queue runner.

We are currently looking at the lmtp.txt file in
3.0/Mailman/queue/docs. To start a lmtp queue runner we need to be
able to run these 3 lines of code :

>>> from mailman.tests import helper
>>> master = helpers.TestableMaster()
>>> master.start('lmtp')

However the second line of code gives us an error and prevents us from
starting the lmtp runner.

The python code contained in this file produces errors when trying to
doctest it. Once we've run the doctest :

>>> import doctest
>>> doctest.testfile("lmtp.txt")

here is the first error :

**********************************************************************
File "./lmtp.txt", line 14, in lmtp.txt
Failed example:
    master = helpers.TestableMaster()
Exception raised:
    Traceback (most recent call last):
      File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py",
line 1212, in __run
      File "<doctest lmtp.txt[1]>", line 1, in <module>
        master = helpers.TestableMaster()
      File "/Library/Python/2.5/site-packages/mailman-3.0.0a1_-py2.5.egg/mailman/tests/helpers.py",
line 114, in __init__
        restartable=False, config_file=config.filename)
    AttributeError: 'Configuration' object has no attribute 'filename'
**********************************************************************

which correctly corresponds to the second line of code needed, we saw earlier.

Do we have to import any other files or set any specific variables ?

William Mead.

From barry at list.org  Thu Jul  3 16:52:22 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 3 Jul 2008 10:52:22 -0400
Subject: [Mailman-Developers] RFC 5064 Archived-At header
In-Reply-To: <200807030611.m636BN8x025598@gator.earlhood.com>
References: <378856DB-FC4F-4432-AAF7-2A8B955A02FD@list.org>
	<200807030611.m636BN8x025598@gator.earlhood.com>
Message-ID: <5E9E17E5-4270-4D9D-BBB0-C2DAA1DF1151@list.org>

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

On Jul 3, 2008, at 2:11 AM, Earl Hood wrote:

> On July 3, 2008 at 00:57, Barry Warsaw wrote:
>
>> I've just updated the current proposal on the Mailman wiki:
>>
>> http://wiki.list.org/x/yQAM
>>
>> See specifically the Open Issues section.  The most straight-forward
>> way to implement this leads to long, unusable (in our opinion) urls.
>> Shortening the urls would require quite a bit of additional
>> implementation complexity.  What to do?
>
> Quick editorial comment: in the "Open issues" section, you write:
>
>  "... Mail-Archive.com uses MHonArc which requires the use of the
>  list name in the url."
>
> This is misleading wrt mhonarc.  Mhonarc imposes no requirement on
> how an archive is structured on the file system from a pathname
> perspective.  The convention is something imposed by the user.

Thanks Earl.  Fixed.

> As for "readable URLs", I still think it may be a bogus concern.
> Usability testing would have to be done to verify if this concern
> is real.

I've clarified that this claim hasn't been tested.

> Wrt this context, it seems most will "click" on the URL in the mail
> message, or copy-n-paste it.
>
> And even then, I wonder how much the link will actually get used.
> Will someone provide some real use case scenarios of how the
> archived-at URL gets used by a message receipient.  If I have
> the message locally, do I care where it is archived?

Yes.  Archived messages are referenced all over the place, in forum  
posts and wiki pages to name a few.  Another use case is referring to  
the message in other mailing list discussions.  E.g. I'd like to point  
mhonarc-devs at the start of the original thread months ago on mailman- 
developers.

Right now, if I have a message in one of my folders, it is often quite  
difficult to find the url that the message is archived.

> One reasonable case I can think of is if a receipient wants
> to tell others about the message, and instead of forwarding
> the message they got, they just send a URL to it, which would
> allows others to following subsequent follow-ups if they are
> not subscribed to the list.

One thing I've dreamed about in an archiver is a "mail this to me"  
link in the archived message.  This would allow me for example, to  
jump start the thread in my mail reader.  So if you were to send me  
the archived-at url for a message in mhonarc-dev, I'd follow that in  
my browser, click the "mail this to me" link and it would show up in  
my inbox, where I can use all my MUA goodness on it.

> Or, they bookmark the link so they can always go back to the
> message w/o having to archive in their local MUA.
>
> Either scenario implies the user can either do a couple of clicks
> or just copy-n-paste the URL to their bookmark manager.
>
> This implies the archive-at URL is mainly for bookmarking purposes.   
> I.e.
> I go to the archive and read some messages (or got their via a  
> search).
> I see a message of interest, and want to bookmark it so I can go back
> to it directly.

You may be right that the readability argument is specious.  It may be  
that cut-n-paste is the overwhelming use case for archived-at.  Does  
that mean you'd argue for the slightly shorter base64 encoding of the  
hash?

> P.S. When time permits, I will look into mhonarc to see if it can
> be changed so the filenames it uses for messages can be based on
> Stable URL since stable filenames has been a problem for mhonarc.

That would be awesome.  Stable URLs on archive regeneration are really  
the core impetus for all this, though the discussion has (rightly)  
diverged a bit since then.

- -Barry

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

iEYEARECAAYFAkhs56YACgkQ2YZpQepbvXHv9gCgki7rMxxaddJLUQIegCtuKV0c
wmQAoIzo5IKZqVC9cAc1Qq3WITcF0IHe
=jAX3
-----END PGP SIGNATURE-----

From joostvb-mailman-developers at mdcc.cx  Thu Jul  3 16:54:55 2008
From: joostvb-mailman-developers at mdcc.cx (Joost van Baal)
Date: Thu, 3 Jul 2008 16:54:55 +0200
Subject: [Mailman-Developers] Mailman,
	PGP and S/MIME (was: Re: [...] Encrypted mailing lists)
In-Reply-To: <C00B68FC-0A85-48B8-8EC0-599DE37A224B@list.org>
Message-ID: <20080703145455.GQ12960@bruhat.mdcc.cx>

Hi,

Op Thu 10 Apr 2008 om 06:40:32 -0400 schreef Barry Warsaw:
>
<snip>
>
> 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.

Some good news: with help from others, I have taken up work on
mailman-ssls again.  It's now called mailman-pgp-smime, and kept in a
Bazaar branch at
https://code.launchpad.net/~joostvb/mailman/2.1-pgp-smime .  The
project's homepage is at http://non-gnu.uvt.nl/mailman-pgp-smime/.

A patch for mailman 2.1.11 is available from
http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.11-pgp-smime_2008-07-03.patch.gz
.

This patch is mostly the same as the 2.1.7 one from Jan 2006.  In the
coming months, the patch will greatly improve though.  See the file
TODO.PGP-SMIME in the patch.

Comments on the code are welcome (but you guessed that :)

Bye,

Joost

-- 
http://mdcc.cx/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20080703/c4041ac8/attachment.pgp>

From barry at list.org  Thu Jul  3 17:43:47 2008
From: barry at list.org (Barry Warsaw)
Date: Thu, 3 Jul 2008 11:43:47 -0400
Subject: [Mailman-Developers] Mailman 3 lmtp queue runners
In-Reply-To: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>
References: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>
Message-ID: <7ECFC09D-1AFC-45C1-B8C5-C886FE16A491@list.org>

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

On Jul 3, 2008, at 7:59 AM, William Mead wrote:

> Hello fellow Mailman developers,
>
> My name is William Mead, I'm a new Mailman developer and currently as
> an intern for Ian Elioart at the university of Sussex.
>
> We have started working on Mailman 3.0. At the moment we are looking
> at the lmtp part of Mailman, however we have come up against a few
> problems. We are able to get all the queue runners started except for
> the lmtp queue runner. We have set lmtp to be used in the Defaults.py
> file, but this doesn't start the lmtp queue runner.
>
> We are currently looking at the lmtp.txt file in
> 3.0/Mailman/queue/docs. To start a lmtp queue runner we need to be
> able to run these 3 lines of code :
>
>>>> from mailman.tests import helper
>>>> master = helpers.TestableMaster()
>>>> master.start('lmtp')
>
> However the second line of code gives us an error and prevents us from
> starting the lmtp runner.
>
> The python code contained in this file produces errors when trying to
> doctest it. Once we've run the doctest :
>
>>>> import doctest
>>>> doctest.testfile("lmtp.txt")
>
> here is the first error :
>
> **********************************************************************
> File "./lmtp.txt", line 14, in lmtp.txt
> Failed example:
>    master = helpers.TestableMaster()
> Exception raised:
>    Traceback (most recent call last):
>      File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
> lib/python2.5/doctest.py",
> line 1212, in __run
>      File "<doctest lmtp.txt[1]>", line 1, in <module>
>        master = helpers.TestableMaster()
>      File "/Library/Python/2.5/site-packages/mailman-3.0.0a1_- 
> py2.5.egg/mailman/tests/helpers.py",
> line 114, in __init__
>        restartable=False, config_file=config.filename)
>    AttributeError: 'Configuration' object has no attribute 'filename'
> **********************************************************************
>
> which correctly corresponds to the second line of code needed, we  
> saw earlier.
>
> Do we have to import any other files or set any specific variables ?

Hi William.

First, I just want to be sure you're running the test suite the way  
it's (currently) intended.  Here's what I do in a pristine branch:

% mkdir staging
% pushd staging
% export PYTHONPATH=`pwd`:$PYTHONPATH
% popd
% python setup.py develop -d staging
% staging/bin/testall lmtp

You might want to run testall with -v and/or -e.  The former produces  
a bit more verbosity, such as the config file its loading.  The latter  
propagates any exceptions in the child process to the console.

- -Barry

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

iEYEARECAAYFAkhs87MACgkQ2YZpQepbvXHprQCfXMV5OuFF8dGtUNlSxQtfI33Y
LhoAoJVaI0fa4ZY6jNB47g09QEfzocCH
=eK9s
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jul  3 17:45:12 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Jul 2008 11:45:12 -0400
Subject: [Mailman-Developers] Mailman,
	PGP and S/MIME (was: Re: [...] Encrypted mailing lists)
In-Reply-To: <20080703145455.GQ12960@bruhat.mdcc.cx>
References: <20080703145455.GQ12960@bruhat.mdcc.cx>
Message-ID: <BC33F916-1FA8-4AF4-A543-10E1B0578963@python.org>

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

On Jul 3, 2008, at 10:54 AM, Joost van Baal wrote:
> Op Thu 10 Apr 2008 om 06:40:32 -0400 schreef Barry Warsaw:
>>
> <snip>
>>
>> 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.
>
> Some good news: with help from others, I have taken up work on
> mailman-ssls again.  It's now called mailman-pgp-smime, and kept in a
> Bazaar branch at
> https://code.launchpad.net/~joostvb/mailman/2.1-pgp-smime .  The
> project's homepage is at http://non-gnu.uvt.nl/mailman-pgp-smime/.
>
> A patch for mailman 2.1.11 is available from
> http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.11-pgp-smime_2008-07-03.patch.gz
> .
>
> This patch is mostly the same as the 2.1.7 one from Jan 2006.  In the
> coming months, the patch will greatly improve though.  See the file
> TODO.PGP-SMIME in the patch.
>
> Comments on the code are welcome (but you guessed that :)

Very cool.  Don't forget to add your branch to the list of unofficial  
ones:

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

- -Barry

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

iQCVAwUBSGz0CHEjvBPtnXfVAQKgMQP8CfdO88Ih6RFa08AVCJjmtqb3E8bJAvSm
n2vQIqfLNGaHRVoUdCxfficEWGCBa5ZC8jdTqCuYCscC0f1MEqGNhuVqdRz17gAk
7zjcnHeR6c6FeNIeAzHb6MrGMqocqstL88TsVlWGH/2caBTaklyGHRQBrIGFD6eo
JmqQm8ztGC0=
=WZly
-----END PGP SIGNATURE-----

From barry at list.org  Sun Jul  6 17:52:45 2008
From: barry at list.org (Barry Warsaw)
Date: Sun, 6 Jul 2008 11:52:45 -0400
Subject: [Mailman-Developers] Donate to GNU Mailman!
Message-ID: <1890C687-2335-408B-84E2-602571A19A3D@list.org>

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

I'm very pleased to announce that you can now donate to the GNU  
Mailman project!

https://www.fsf.org/donate/directed-donations/gnumailman/

The Free Software Foundation has established a directed donation fund  
for GNU Mailman.  Most of your donation goes directly to GNU Mailman,  
with a small percentage going to help the FSF.  You can now support  
both great organizations with one donation.

As quoted on the donation page:

"Your donation will be used to obtain equipment, services, development  
resources and other support for the GNU Mailman project.  All  
expenditures will be approved by a committee chosen from core GNU  
Mailman maintainers, and will be fully disclosed on the main GNU  
Mailman website."

Currently myself, Mark Sapiro and Terri Oda are serving as members of  
the informal Mailman Steering Committee.

I'd like to thank Peter Brown at the FSF for help getting this set up  
over there. I'd also like to thank Jeff Marshall and Jeff Breidenbach  
from the Mail-Archive.com for their initial generous donation.  As  
part of this kick-start, Mailman 3 will make it possible to easily  
archive your public mailing lists at www.mail-archive.com, including a  
permalink in the footer of all messages.

More details on the donation program are available on the wiki:

http://wiki.list.org/x/R4BJ

Feel free to comment on that page with any questions, and we'll make  
sure to update the page with any additional information.

Please consider supporting both GNU Mailman and the FSF with your  
donation.  We thank you.

- -Barry

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

iEYEARECAAYFAkhw6k0ACgkQ2YZpQepbvXEo8ACffJq3QNTmNIDIR8Fa6x8e+sjT
2egAnArei7fdCEsIjNjcW7utRs6KHHCc
=6VAj
-----END PGP SIGNATURE-----

From mark at msapiro.net  Sun Jul  6 18:48:19 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 06 Jul 2008 09:48:19 -0700
Subject: [Mailman-Developers] [Mailman-checkins]
 [Branch	~mailman-administrivia/mailman-administrivia/admin] Rev 25:	updates
In-Reply-To: <20080706153809.9706.91303.launchpad@canonical@forster.canonical.com>
References: <20080706153809.9706.91303.launchpad@canonical@forster.canonical.com>
Message-ID: <4870F753.1060807@msapiro.net>

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


| +    <li>the
| +    <a
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mailman/mailman/ACKNOWLEDGMENTS?rev=HEAD&content-type=text/vnd.viewcvs-markup"
| +    >list of contributors</a>, bug hunters, big idea people, and others
| +    who have helped immensely with Mailman's development


The above link is dead. The current link to that version is
<http://mailman.cvs.sourceforge.net/mailman/mailman/ACKNOWLEDGMENTS?view=markup>,
but a somewhat more current link is
<http://mailman.svn.sourceforge.net/viewvc/mailman/trunk/mailman/docs/ACKNOWLEDGMENTS.txt?view=markup>
or perhaps
<http://mailman.svn.sourceforge.net/viewvc/*checkout*/mailman/trunk/mailman/docs/ACKNOWLEDGMENTS.txt>.

Better still, would be a link to the current head revision of the
lp:mailman branch, but I don't know what that would be. I can browse to
the file at
<http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/annotate/6635?file_id=docsacknowledgments.-20070507165525-0o0kligrooe34vyc-2763>
(<http://tinyurl.com/57jp73>), but that is the specific revision, not
the generic latest revision.

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

iD8DBQFIcPdTVVuXXpU7hpMRAuBaAJ466jmQZ4NEswPaq8do5Y2Std1dkwCeKHYE
9FO1kfvLDpS+d/p0FYbBFkQ=
=K/WD
-----END PGP SIGNATURE-----

From mk2s at digitalcommute.com  Mon Jul  7 04:52:33 2008
From: mk2s at digitalcommute.com (Maki Kato)
Date: Sun, 06 Jul 2008 22:52:33 -0400
Subject: [Mailman-Developers] updated wiki page on how to setup an
	environment to run the restserver
Message-ID: <487184F1.3070103@digitalcommute.com>

Since I figured the setting up of a running dev environment is not 
exactly trivial, I've gone through the steps again myself and recorded 
them on the wiki at:
http://wiki.list.org/display/DEV/restserver-branch

....maki....



From iane at sussex.ac.uk  Mon Jul  7 17:13:10 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 07 Jul 2008 16:13:10 +0100
Subject: [Mailman-Developers] Mailman 3 lmtp queue runners
In-Reply-To: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>
References: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>
Message-ID: <FB2709403C110066E3D034EA@lewes.staff.uscs.susx.ac.uk>



--On 3 July 2008 12:59:59 +0100 William Mead <william.multimedia at gmail.com> 
wrote:

>
> My name is William Mead, I'm a new Mailman developer and currently as
> an intern for Ian Eiloart at the university of Sussex.

We're up and running now, and working on the LMTP qrunner, which is based 
on a subclass ("Channel") of the class smtpd.SMTPChannel - part of Python's 
Library.

We're having to use name mangling to access some private attributes of 
smtpd.SMTPChannel. It seems that virtually everything in SMTPChannel is 
private, making it quite hard to override any of its methods.

It seems to me natural that an smtp/lmtp daemon will wish to access all the 
information available to it from its s/lmtp session at any time, and 
therefore the arguments to all the session commands should be available at 
any time - up to an RSET.

For example, you really should not reject an email before RCPT TO:, in case 
it's addressed to "postmaster" at a local domain. Exceptions might be made 
for really hopeless syntactical errors, though.

So, I think these attributes should be public - so that we have easy access 
to them at RCTP TO: and at DATA.

argument to EHLO/HELO
argument to MAIL FROM
number or rejected recipients




-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From barry at list.org  Mon Jul  7 17:28:03 2008
From: barry at list.org (Barry Warsaw)
Date: Mon, 7 Jul 2008 11:28:03 -0400
Subject: [Mailman-Developers] Mailman 3 lmtp queue runners
In-Reply-To: <FB2709403C110066E3D034EA@lewes.staff.uscs.susx.ac.uk>
References: <774a9a470807030459p24665b7djf1eccaf0f6a3a9c4@mail.gmail.com>
	<FB2709403C110066E3D034EA@lewes.staff.uscs.susx.ac.uk>
Message-ID: <9A3E1FAD-48CE-4128-8FED-FE6E36FB5DD3@list.org>

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

On Jul 7, 2008, at 11:13 AM, Ian Eiloart wrote:

> We're having to use name mangling to access some private attributes  
> of smtpd.SMTPChannel. It seems that virtually everything in  
> SMTPChannel is private, making it quite hard to override any of its  
> methods.

Yep, this sucks.  The code was written back when we thought this was a  
good idea.  Fixing it requires changes in Python, and it's probably  
too late to get this into Python 2.6 and 3.0.

The best thing I can suggest is to make them public in the LMTP  
subclass, probably using properties that do the name mangling.

- -Barry

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

iEYEARECAAYFAkhyNgMACgkQ2YZpQepbvXGlzQCgpxBZQrYtbxKs74yWyT0Nx489
o1YAoLW6AwXlcLXy6mqy4xutX3hekeIC
=9b1/
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Tue Jul  8 16:52:13 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 08 Jul 2008 15:52:13 +0100
Subject: [Mailman-Developers] bug report
Message-ID: <0B3089F4BF61D1B214FF1A49@lewes.staff.uscs.susx.ac.uk>

Hi,

I'm trying to work out how to report a bug in Mailman 3.0

None seem to be listed at <https://bugs.launchpad.net/mailman>

The bug seems to be in the lmtp queue runner. If I try to create a new list 
while the queue runner is handling a connection, mailman.db gets 
permanently locked.

So, if I telnet to the lmtp server, and say:

    220 quant.staff.uscs.susx.ac.uk Python LMTP queue runner 1.0
    lhlo me
    250 quant.staff.uscs.susx.ac.uk
    mail from:<>
    250 Ok
    rcpt to:<foo at example.com>

then, I switch to another shell, and try to create a list with create_list:

    quant:mailman-3.0.0a1 its$ staging/bin/create_list -l baz at example.com 
-q -o wam221 at sussex.ac.uk
    Traceback (most recent call last):
      File "staging/bin/create_list", line 8, in <module>
        load_entry_point('mailman==3.0.0a1', 'console_scripts', 
'bin/create_list')()
      File 
"/Users/wam22/mailmantesting/test4/mailman-3.0.0a1/mailman/bin/create_list.py",
    line 110, in main        config.db.commit()
      File 
"/Users/wam22/mailmantesting/test4/mailman-3.0.0a1/mailman/database/__init__.py",
    line 79, in commit        self.store.commit()
      File 
"/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/storm/store.py",
    line 107, in commit        self._connection.commit()
      File 
"/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/storm/databases/sqlite.py",
    line 125, in commit        self.raw_execute("COMMIT", _end=True)
      File 
"/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/storm/databases/sqlite.py",
    line 153, in raw_execute        return Connection.raw_execute(self, 
statement, params)
      File 
"/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/storm/database.py",
    line 278, in raw_execute        raw_cursor.execute(statement)
    sqlite3.OperationalError: database is locked

And, it stays locked like that for eternity, or until I remove 
var/data/mailman.db-journal (whichever comes sooner ;)

The question is, why would the lmtp server need a write lock on the 
database?
-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From barry at list.org  Tue Jul  8 17:53:18 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Jul 2008 11:53:18 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>
	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
Message-ID: <A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>

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

On Jun 25, 2008, at 4:17 PM, Terri Oda wrote:
> On 25-Jun-08, at 3:44 PM, Terri Oda wrote:
>> Back in April,
>
> Err, my bad, it was actually March.  Clearly we're overdue for some  
> action on this. ;)

Clearly, I still suck. :(

A couple of quick thoughts.  I don't mind the beige, but what if the  
color scheme were a little closer to the logo?  That might be  
unreadable though.  If so, the gray looks nice.

I wonder if we should consider using this system to write the new site  
in:

http://sphinx.pocoo.org/

It's Python (yay!) and avoids us having to write pure HTML (yay, yay!)  
which I really hate. ;).  I know Andrew is familiar with Sphinx  
because it's what we use to build the python.org site.  Ours would be  
much simpler.

It took me a little bit of work to get Sphinx running on my Mac, but  
it's not too bad.  What do you think?

- -Barry

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

iEYEARECAAYFAkhzjW4ACgkQ2YZpQepbvXGF9QCdHpPFT6gjCV7WbRXqF71uCUEo
bg0AoJqBHhgPGZfVr5A+jeEAuYO2J65p
=88eW
-----END PGP SIGNATURE-----

From barry at python.org  Tue Jul  8 18:15:27 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 8 Jul 2008 12:15:27 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>
	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
Message-ID: <5513E3FB-94E7-4B49-B231-05B5A15EC784@python.org>

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

On Jul 8, 2008, at 11:53 AM, Barry Warsaw wrote:

> I wonder if we should consider using this system to write the new  
> site in:
>
> http://sphinx.pocoo.org/

Okay, I'm an idiot too.  docs.python.org is built with Sphinx, not the  
main web site.

- -Barry

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

iQCVAwUBSHOSoHEjvBPtnXfVAQK3DAP9ElTgdtn+cqQkE4ZBmz1Vl46TpU4+CPV5
B9uKKO9kbWANcr06R0oIsAamvpOCm29Rrjbvry1W2Gai0ufJIs0XTb2zufmurwYr
9OiHgw0xeS+hEMIVWOMI9FVD2Ihu8uEtX72fJrXUx6d8rUeV1Du3r3ubh2lAjj5k
h/7BA+1ER+I=
=g93m
-----END PGP SIGNATURE-----

From terri at zone12.com  Tue Jul  8 18:35:33 2008
From: terri at zone12.com (Terri Oda)
Date: Tue, 8 Jul 2008 12:35:33 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>
	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
Message-ID: <AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>

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

On 8-Jul-08, at 11:53 AM, Barry Warsaw wrote:
> On Jun 25, 2008, at 4:17 PM, Terri Oda wrote:
>> On 25-Jun-08, at 3:44 PM, Terri Oda wrote:
>>> Back in April,
>> Err, my bad, it was actually March.  Clearly we're overdue for  
>> some action on this. ;)
> Clearly, I still suck. :(

I was cleaning up a mess some spammers made of a friend's server, and  
my time's just opened up again now.  So your timing is impeccable! ;)

> A couple of quick thoughts.  I don't mind the beige, but what if  
> the color scheme were a little closer to the logo?  That might be  
> unreadable though.  If so, the gray looks nice.

I'll experiment with some reds/pinks later this week and see if  
anything works.  One complaint about the gray is that the whole page  
is very cool then and it could use some warmth, but even those who  
commented on that didn't think that the beige was necessarily the  
right *source* of warmth as a solution.  One of the web designers who  
took a peek did suggest using the gray but with the pink/reds of the  
logo as link colours there, so I'll try that.

Do we have a higher res version of the logo anywhere?  One of the  
graphic designers who looked over the site pointed out that it's  
looking a little jpeg-artifact abused, beyond the intentional  
fuzzing.  I can probably bribe a graphic designer with cookies to try  
to get it cleaned up or remade, but it'd be exceptionally lovely if  
we had one hanging around already.

Also, the menu's going to need to have an extra donate link now. :)

> It took me a little bit of work to get Sphinx running on my Mac,  
> but it's not too bad.  What do you think?

I'm not picky -- I could probably write the menu-generating script in  
straight python if need be.  In fact, it's simple enough that that  
might not be a bad idea, now that I think about it.

  Terri

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

iD8DBQFIc5dVnB1cG1wafMARAv6/AJ4tl8lTvb1+XY8F7Bi2qKm95sDEtACeNLqO
atxJlkyzWlO3vN9iIQvZ/o4=
=bTCU
-----END PGP SIGNATURE-----

From barry at list.org  Tue Jul  8 20:49:06 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Jul 2008 14:49:06 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>
	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
Message-ID: <366E2591-2BE4-4934-B35F-CAA41DA908F5@list.org>

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

On Jul 8, 2008, at 12:35 PM, Terri Oda wrote:
>
> I was cleaning up a mess some spammers made of a friend's server,  
> and my time's just opened up again now.  So your timing is  
> impeccable! ;)

:)

>> A couple of quick thoughts.  I don't mind the beige, but what if  
>> the color scheme were a little closer to the logo?  That might be  
>> unreadable though.  If so, the gray looks nice.
>
> I'll experiment with some reds/pinks later this week and see if  
> anything works.  One complaint about the gray is that the whole page  
> is very cool then and it could use some warmth, but even those who  
> commented on that didn't think that the beige was necessarily the  
> right *source* of warmth as a solution.  One of the web designers  
> who took a peek did suggest using the gray but with the pink/reds of  
> the logo as link colours there, so I'll try that.

Yes, a warmer site would definitely be nice.

> Do we have a higher res version of the logo anywhere?  One of the  
> graphic designers who looked over the site pointed out that it's  
> looking a little jpeg-artifact abused, beyond the intentional  
> fuzzing.  I can probably bribe a graphic designer with cookies to  
> try to get it cleaned up or remade, but it'd be exceptionally lovely  
> if we had one hanging around already.

What's on the web page is all that I know of.  Those were the logos  
donated to the FSF.  I'm graphic designers love cookies though!

> Also, the menu's going to need to have an extra donate link now. :)

Indeed!

>> It took me a little bit of work to get Sphinx running on my Mac,  
>> but it's not too bad.  What do you think?
>
> I'm not picky -- I could probably write the menu-generating script  
> in straight python if need be.  In fact, it's simple enough that  
> that might not be a bad idea, now that I think about it.

I think it would be nice if we could use reST to generate the pages.   
It's a fairly easy markup language.  But feel free to experiment and  
see what you come up with!

- -Barry

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

iEYEARECAAYFAkhztqMACgkQ2YZpQepbvXF0rgCgvM9HyEDRIWL7oh3ZrVyHPfge
aUAAn0jJhJigoEEPed7MGIl+2U7xJJyP
=8XzS
-----END PGP SIGNATURE-----

From mark at msapiro.net  Tue Jul  8 22:37:28 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 08 Jul 2008 13:37:28 -0700
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
Message-ID: <4873D008.5060303@msapiro.net>

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

Terri Oda wrote:
|
| Do we have a higher res version of the logo anywhere?  One of the
| graphic designers who looked over the site pointed out that it's looking
| a little jpeg-artifact abused, beyond the intentional fuzzing.  I can
| probably bribe a graphic designer with cookies to try to get it cleaned
| up or remade, but it'd be exceptionally lovely if we had one hanging
| around already.

Are you looking at the 247x93 one at
<http://www.gnu.org/software/mailman/otherstuff.html>? AFAIK that's as
good as we have. I did find links to some gifs on The Dragon De
Monsyne's web site <http://transform.to/~dragondm/>, but the links are
broken.

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

iD8DBQFIc9AHVVuXXpU7hpMRAslZAJwJ2bmRayf73OqswGlRCrB5fcSNCACfUbGC
2ni7ZubsC0BjH5LHXPhZEDk=
=Yb7R
-----END PGP SIGNATURE-----

From barry at list.org  Wed Jul  9 00:11:57 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 8 Jul 2008 18:11:57 -0400
Subject: [Mailman-Developers] bug report
In-Reply-To: <0B3089F4BF61D1B214FF1A49@lewes.staff.uscs.susx.ac.uk>
References: <0B3089F4BF61D1B214FF1A49@lewes.staff.uscs.susx.ac.uk>
Message-ID: <8FDBAB23-83F2-4AE6-87AA-6008F9830E4C@list.org>

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

On Jul 8, 2008, at 10:52 AM, Ian Eiloart wrote:

> I'm trying to work out how to report a bug in Mailman 3.0
>
> None seem to be listed at <https://bugs.launchpad.net/mailman>

I've just set Launchpad up to accept bugs for Mailman.  At some point  
we will get the SourceForge bugs imported, but in the meantime, please  
use the above url for bugs in 2.2 and 3.0.

Please continue to use the SourceForge bug tracker for all Mailman 2.1  
bugs.

> The bug seems to be in the lmtp queue runner. If I try to create a  
> new list while the queue runner is handling a connection, mailman.db  
> gets permanently locked.
>
> So, if I telnet to the lmtp server, and say:
>
>   220 quant.staff.uscs.susx.ac.uk Python LMTP queue runner 1.0
>   lhlo me
>   250 quant.staff.uscs.susx.ac.uk
>   mail from:<>
>   250 Ok
>   rcpt to:<foo at example.com>
>
> then, I switch to another shell, and try to create a list with  
> create_list:
>
>   quant:mailman-3.0.0a1 its$ staging/bin/create_list -l baz at example.com 
>  -q -o wam221 at sussex.ac.uk
>   Traceback (most recent call last):
>     File "staging/bin/create_list", line 8, in <module>
>       load_entry_point('mailman==3.0.0a1', 'console_scripts', 'bin/ 
> create_list')()
>     File "/Users/wam22/mailmantesting/test4/mailman-3.0.0a1/mailman/ 
> bin/create_list.py",
>   line 110, in main        config.db.commit()
>     File "/Users/wam22/mailmantesting/test4/mailman-3.0.0a1/mailman/ 
> database/__init__.py",
>   line 79, in commit        self.store.commit()
>     File "/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/ 
> storm/store.py",
>   line 107, in commit        self._connection.commit()
>     File "/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/ 
> storm/databases/sqlite.py",
>   line 125, in commit        self.raw_execute("COMMIT", _end=True)
>     File "/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/ 
> storm/databases/sqlite.py",
>   line 153, in raw_execute        return  
> Connection.raw_execute(self, statement, params)
>     File "/Library/Python/2.5/site-packages/storm-0.12-py2.5.egg/ 
> storm/database.py",
>   line 278, in raw_execute        raw_cursor.execute(statement)
>   sqlite3.OperationalError: database is locked
>
> And, it stays locked like that for eternity, or until I remove var/ 
> data/mailman.db-journal (whichever comes sooner ;)
>
> The question is, why would the lmtp server need a write lock on the  
> database?

I'm betting the LMTPRunner needs a config.db.commit() right before the  
successful return path in process_message().

- -Barry

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

iEYEARECAAYFAkhz5i8ACgkQ2YZpQepbvXE04ACeOyg+z3Qoouf9lyfg0sVYzP7u
odkAniqdTV9EkVoepPZvda4w10UM8eci
=GFKI
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Wed Jul  9 11:36:44 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 09 Jul 2008 10:36:44 +0100
Subject: [Mailman-Developers] bug report
In-Reply-To: <8FDBAB23-83F2-4AE6-87AA-6008F9830E4C@list.org>
References: <0B3089F4BF61D1B214FF1A49@lewes.staff.uscs.susx.ac.uk>
	<8FDBAB23-83F2-4AE6-87AA-6008F9830E4C@list.org>
Message-ID: <5AF134B7E8057FE988B72DBA@lewes.staff.uscs.susx.ac.uk>



--On 8 July 2008 18:11:57 -0400 Barry Warsaw <barry at list.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 8, 2008, at 10:52 AM, Ian Eiloart wrote:
>
>> I'm trying to work out how to report a bug in Mailman 3.0
>>
>> None seem to be listed at <https://bugs.launchpad.net/mailman>
>
> I've just set Launchpad up to accept bugs for Mailman.  At some point we
> will get the SourceForge bugs imported, but in the meantime, please use
> the above url for bugs in 2.2 and 3.0.

Thanks. I've reported the bug there.


> Please continue to use the SourceForge bug tracker for all Mailman 2.1
> bugs.
>
>> The bug seems to be in the lmtp queue runner. If I try to create a
>> new list while the queue runner is handling a connection, mailman.db
>> gets permanently locked.

 .....
>
> I'm betting the LMTPRunner needs a config.db.commit() right before the
> successful return path in process_message().
>

Yes, perhaps. We'll probably have a go at resolving the bug, then!
-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From william.multimedia at gmail.com  Mon Jul 14 12:03:51 2008
From: william.multimedia at gmail.com (William Mead)
Date: Mon, 14 Jul 2008 11:03:51 +0100
Subject: [Mailman-Developers] New unofficial LMTP branch
Message-ID: <774a9a470807140303n80edf06oa2ca535188d5be11@mail.gmail.com>

Hi,

A new Mailman 3 branch can now be found at
https://code.launchpad.net/~wilunix/mailman/lmtp
The wiki at http://wiki.list.org/display/DEV/MailmanBranches has been
updated with this branch in the unofficial section.

This branch has enhanced LMTP code for Mailman, found in
mailman/queue/lmtp.py.
The LMTP server will reject mail RCPT TO if: (a) the list doesn't exist, or
(b) generic_nonmember_action is set to "reject", and the sender is not a
list member. Emails to sub-addresses of known lists will pass this point.

This code still needs enhancing. We would like your views on how emails
should be processed, depending on the sender's status (member/non-member),
the sub-address in the list address and the non-member filters.


Depending on which sub-addresses are used and if the sender is a known
member or not, emails should be accepted or rejected at RCPT TO.

Should emails from unknown senders with the sub-addresses -leave and
-unsubscribe not pass RCPT TO, seeing as these senders aren't members of any
lists ?

Should emails from unknown senders with the sub-addresses -join and
-subscribe be able to pass RCPT TO so that people can join and subscribe to
mailing lists ?

What should be done with emails from unknown senders with the sub-addresses
-bounces, -owner, -confirm and -request ?

Should all the sub-addresses be accessible by all known members ?


At the moment our code will reject mail from senders who aren't members
if generic_nonmember_action is set to "reject".

Seeing as this code is enhancing the LMTP server how should we handle the
non-member filters ?

Should we keep the current filters ? or would a new mechanism for handling
emails from non members be the best solution ?



William Mead.

From iane at sussex.ac.uk  Thu Jul 17 11:58:26 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 17 Jul 2008 10:58:26 +0100
Subject: [Mailman-Developers] Mailman 3.0 config_list
Message-ID: <6A5D8120E1EAA15151E815A3@lewes.staff.uscs.susx.ac.uk>

Hi,

It looks like config_list isn't working yet in Mailman 3.0, and there seems 
to be quite a lot of work to do to get it working.

In the meantime, how can I configure accept_these_nonmembers for a list? I 
need to  test LMTP qrunner code that uses this value.

I can do an SQL update, which is probably the easiest way to create a 
value, but I'm not sure what the value of the field should be.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From barry at python.org  Fri Jul 18 15:06:37 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 18 Jul 2008 09:06:37 -0400
Subject: [Mailman-Developers] Mailman 3.0 config_list
In-Reply-To: <6A5D8120E1EAA15151E815A3@lewes.staff.uscs.susx.ac.uk>
References: <6A5D8120E1EAA15151E815A3@lewes.staff.uscs.susx.ac.uk>
Message-ID: <D64A66E2-A992-48CC-950E-0108EA40E06A@python.org>

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

On Jul 17, 2008, at 5:58 AM, Ian Eiloart wrote:

> It looks like config_list isn't working yet in Mailman 3.0, and  
> there seems to be quite a lot of work to do to get it working.
>
> In the meantime, how can I configure accept_these_nonmembers for a  
> list? I need to  test LMTP qrunner code that uses this value.
>
> I can do an SQL update, which is probably the easiest way to create  
> a value, but I'm not sure what the value of the field should be.

Hi Ian,

I'll look into config_list, but in the meantime with_list should  
work.  You should be able to fire that up, change the value, then do  
config.db.commit() to save your changes.

- -Barry

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

iQCVAwUBSICVXnEjvBPtnXfVAQLGPgP9HvEoqYikobzWNp3hYRINZuvqWTNErvKC
1xbCy/zcM2HtGx6CIfMLqrWnCxWg+M5CsFYAYxulaseLI+df+ozMzZ3JFeDJ/fH7
7Gb+pCCMhru4kukqSXpxEZ5ZPOMH2f9NPsqpOUh8Lqp6KD9sOHAtHdyaTgPtKiEk
Jc9Rrb8mbrg=
=GSNK
-----END PGP SIGNATURE-----

From barry at list.org  Fri Jul 18 15:37:37 2008
From: barry at list.org (Barry Warsaw)
Date: Fri, 18 Jul 2008 09:37:37 -0400
Subject: [Mailman-Developers] Mailman 3.0 config_list
In-Reply-To: <D64A66E2-A992-48CC-950E-0108EA40E06A@python.org>
References: <6A5D8120E1EAA15151E815A3@lewes.staff.uscs.susx.ac.uk>
	<D64A66E2-A992-48CC-950E-0108EA40E06A@python.org>
Message-ID: <27DD54F4-994F-4A11-B55C-FE9CCCDC2224@list.org>

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

On Jul 18, 2008, at 9:06 AM, Barry Warsaw wrote:

> On Jul 17, 2008, at 5:58 AM, Ian Eiloart wrote:
>
>> It looks like config_list isn't working yet in Mailman 3.0, and  
>> there seems to be quite a lot of work to do to get it working.
>>
>> In the meantime, how can I configure accept_these_nonmembers for a  
>> list? I need to  test LMTP qrunner code that uses this value.
>>
>> I can do an SQL update, which is probably the easiest way to create  
>> a value, but I'm not sure what the value of the field should be.
>
> I'll look into config_list, but in the meantime with_list should  
> work.  You should be able to fire that up, change the value, then do  
> config.db.commit() to save your changes.

BTW, I opened bug 249855 on this.

https://bugs.launchpad.net/bugs/249855

- -Barry

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

iEYEARECAAYFAkiAnKEACgkQ2YZpQepbvXE+zQCfX/Nni9w9dkCSu1LUvfqEU4Iw
kb4AmwQuy/tW/dw6yyy8BvzZBITSLgd7
=O6lo
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Tue Jul 22 15:12:09 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 22 Jul 2008 14:12:09 +0100
Subject: [Mailman-Developers] New unofficial LMTP branch
In-Reply-To: <774a9a470807140303n80edf06oa2ca535188d5be11@mail.gmail.com>
References: <774a9a470807140303n80edf06oa2ca535188d5be11@mail.gmail.com>
Message-ID: <03E613168C75901FD04BF049@lewes.staff.uscs.susx.ac.uk>



--On 14 July 2008 11:03:51 +0100 William Mead 
<william.multimedia at gmail.com> wrote:

> Hi,
>
> A new Mailman 3 branch can now be found at
> https://code.launchpad.net/~wilunix/mailman/lmtp
> The wiki at http://wiki.list.org/display/DEV/MailmanBranches has been
> updated with this branch in the unofficial section.
>

We're in Willam's final week here, and he's made good progress. He's 
uploaded an unofficial branch of Mailman 3.0 with an enhanced LMTP 
interface - supporting ENHANCEDSTATUSCODES, and rejecting mail as early as 
possible when it isn't wanted.

He's also backported the code to version 2.2.

I've documented this in a comment at http://snipurl.com/33196


William Mead has been working on LMTP code for me. He's produced 
implementations for version 3.0 and for version 2.2, with these tests 
applied after RCPT TO in the LMTP conversation:

1. message will be rejected if the list name is not known.
2. message will be accepted if the sender matches "accept_these_nonmembers".
3. message will be accepted if "generic_nonmember_action" is not reject.
4. message will be accepted if the sender is a list member.
5. if we get this far, the message will be rejected - the sender is a 
non-member of a closed list.

We could also reject other members if they're moderated, for example. 
However, we've adopted the view that it is relatively safe to generate a 
bounce message for someone who is a member of the list.

William has completely reimplemented the SMTPD code in Python, to support 
ENHANCEDSTATUSCODES, because the LMTP RFC requires that - even though the 
examples in the RFC don't show them being used! However, the code doesn't 
implement PIPELINING - also required by LMTP - because the underlying 
ASYNCHAT/ASYNCORE architecture doesn't seem to support it. We discovered 
that advertising PIPELINING causes the test smtp client to fail, but we've 
not even thought about how to fix that - LMTP clients which are 
re-implementations of SMTP clients might just live with the fact that 
PIPELINING isn't advertised.

William's code is at https://code.launchpad.net/~wilunix

The LMTP queue runner allows us to run Mailman on a server that's unrelated 
to the main MTA. With an Exim MTA, you could use a recipient callout  to 
verify that the sender is permitted to post to the list, before accepting 
the message for deliver. This means that rejecting an unwanted message 
should not create collateral spam.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From iane at sussex.ac.uk  Tue Jul 22 16:28:04 2008
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 22 Jul 2008 15:28:04 +0100
Subject: [Mailman-Developers] New unofficial LMTP branch
In-Reply-To: <03E613168C75901FD04BF049@lewes.staff.uscs.susx.ac.uk>
References: <774a9a470807140303n80edf06oa2ca535188d5be11@mail.gmail.com>
	<03E613168C75901FD04BF049@lewes.staff.uscs.susx.ac.uk>
Message-ID: <692B451D6AFC556D8104C954@lewes.staff.uscs.susx.ac.uk>



--On 22 July 2008 14:12:09 +0100 Ian Eiloart <iane at sussex.ac.uk> wrote:

> We discovered that advertising PIPELINING causes the test smtp client to
> fail, but we've not even thought about how to fix that - LMTP clients
> which are re-implementations of SMTP clients might just live with the
> fact that PIPELINING isn't advertised.

Actually, it looks like this isn't a real problem. The LMTP Channel raises 
an error if the client disconnects before getting all the Channel's output. 
But, once the client has gone away, the Channel has no purpose anyway. 
Hopefully, it will discard any message that it has to avoid message 
duplication - this remains to be tested. The LMTP listener survives all 
this, and so I think we are in fact safe to advertise PIPELINING. Hooray!

-- 
Ian Eiloart
IT Services, University of Sussex
x3148

From terri at zone12.com  Wed Jul 23 19:01:29 2008
From: terri at zone12.com (Terri Oda)
Date: Wed, 23 Jul 2008 13:01:29 -0400
Subject: [Mailman-Developers] GNU Mailman Site Redesign
In-Reply-To: <4873D008.5060303@msapiro.net>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
	<4873D008.5060303@msapiro.net>
Message-ID: <C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>

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

I've done a bit more work with the site redesign, and updated the  
working content I had.

The latest version is here:

http://terri.zone12.com/mm-website/

So, that's using some red/pink from the logo as link colours as  
someone suggested to me.  It looks fine to me on this macbook, but  
I'm at the Ottawa Linux Symposium and don't have my usual array of  
desktops to test from, so someone please let me know if it's  
unreadable.  (I've cc'ed mailman-users to get more eyes.)

Here's one wit the same idea, using darker reds:
http://terri.zone12.com/mm-website/?css=mailman-dark

And the original two, both beige and gray are here:
http://terri.zone12.com/mm-website/?css=mailman-orig
http://terri.zone12.com/mm-website/?css=mailman-alt

More suggestions welcome!

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

iD8DBQFIh2PpnB1cG1wafMARAth3AJ9S3tMKRa7L6GkAE3RM5M5QOclC+gCdHocX
mDAbF8GrYVygAg6uzfUmooE=
=fz4P
-----END PGP SIGNATURE-----

From patrickstinson.lists at gmail.com  Wed Jul 23 18:40:14 2008
From: patrickstinson.lists at gmail.com (Patrick Stinson)
Date: Wed, 23 Jul 2008 10:40:14 -0600
Subject: [Mailman-Developers] rss feed
Message-ID: <6214d7a20807230940m6c4bd814pffee217ba4572312@mail.gmail.com>

Has there been any work on generating an rss feed from a mailman archive?

I got the HyperArchive.py patch to work but the body comes out wrong.
The perl scraper seems to have slightly better output but generates
some ugly html escaping.

The goal is to generate a blog-like activity summary using the tite,
author, date, and body of each mail sent to the list and slap it on
the main page. Some nice markup would be useful as well.

The site is here:

http://www.onlyinalaska.org/

From brad at python.org  Wed Jul 23 19:22:46 2008
From: brad at python.org (Brad Knowles)
Date: Wed, 23 Jul 2008 12:22:46 -0500
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
In-Reply-To: <C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>	<4873D008.5060303@msapiro.net>
	<C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>
Message-ID: <488768E6.3010109@python.org>

Terri Oda wrote:

> The latest version is here:
> 
> http://terri.zone12.com/mm-website/
> 
> So, that's using some red/pink from the logo as link colours as someone 
> suggested to me.

I really don't want anyone over-riding my own choices for link colors.

> More suggestions welcome!

Did you want to mention the official Mailman group on LinkedIn?  Of course, 
I can't figure out how to give you a link that will take you to their page 
for the group as opposed to the "home page" that I defined for the group 
(namely www.list.org), but that may be something we can resolve.

-- 
Brad Knowles <brad at python.org>
Member of the Python.org Postmaster Team & Co-Moderator of the
mailman-users and mailman-developers mailing lists

From jmhayes at speakeasy.net  Wed Jul 23 19:45:41 2008
From: jmhayes at speakeasy.net (Jordan Hayes)
Date: Wed, 23 Jul 2008 10:45:41 -0700
Subject: [Mailman-Developers] rss feed
References: <6214d7a20807230940m6c4bd814pffee217ba4572312@mail.gmail.com>
Message-ID: <CBF8DE6BE254468D89B427649D32A2EE@pavepaws>

> Has there been any work on generating an rss feed from
> a mailman archive?

I do this for some lists I run, but by using SWISH-E as a search engine. 
Once you're indexing the archive, it's simple to turn it into a feed 
that includes feeding on a search term ... or just a plain old 
"everything" feed.

http://infothecary.org/jordan/mailman.html

Is there any interest in the Mailman project for 'optional features' to 
be added?  I'd be happy to providing a cookbook or maybe even patches to 
configure et al.

/jordan 


From terri at zone12.com  Wed Jul 23 21:07:08 2008
From: terri at zone12.com (Terri Oda)
Date: Wed, 23 Jul 2008 15:07:08 -0400
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
In-Reply-To: <488768E6.3010109@python.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>	<4873D008.5060303@msapiro.net>
	<C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>
	<488768E6.3010109@python.org>
Message-ID: <610816DF-33F8-4409-8BDB-12B4B3B57456@zone12.com>

On 23-Jul-08, at 1:22 PM, Brad Knowles wrote:
>> The latest version is here:
>> http://terri.zone12.com/mm-website/
>> So, that's using some red/pink from the logo as link colours as  
>> someone suggested to me.
> I really don't want anyone over-riding my own choices for link colors.

The original version I had used the standard link colours (ie - it  
didn't set them), and comments ranged from just general malaise about  
the colour scheme of the links to several people who asserted it was  
nearly unreadable on their setups.  So I'll take the comment under  
advisement, but I suspect you're going to be in the minority.

Since I've since changed the original css, here's the current stuff  
with no link colours specified (so they default to your browser  
settings):

http://terri.zone12.com/mm-website/?css=mailman-nolink

> Did you want to mention the official Mailman group on LinkedIn?  Of  
> course, I can't figure out how to give you a link that will take  
> you to their page for the group as opposed to the "home page" that  
> I defined for the group (namely www.list.org), but that may be  
> something we can resolve.

Seems like a good fit for the "Participate" page!  I've put it just  
under the wiki entry.

Also, if I can convince launchpad and my laptop to get along, I'll  
share the code for this.  It's currently generating the pages using a  
little python script.  Although honestly, given that there's only 7  
pages here, I think we might as well generate them once and just  
serve up the straight HTML.

  Terri


From brad at shub-internet.org  Wed Jul 23 21:46:36 2008
From: brad at shub-internet.org (Brad Knowles)
Date: Wed, 23 Jul 2008 14:46:36 -0500
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
In-Reply-To: <610816DF-33F8-4409-8BDB-12B4B3B57456@zone12.com>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>	<4873D008.5060303@msapiro.net>	<C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>	<488768E6.3010109@python.org>
	<610816DF-33F8-4409-8BDB-12B4B3B57456@zone12.com>
Message-ID: <48878A9C.3090808@shub-internet.org>

Terri Oda wrote:

> The original version I had used the standard link colours (ie - it 
> didn't set them), and comments ranged from just general malaise about 
> the colour scheme of the links to several people who asserted it was 
> nearly unreadable on their setups.

That implies their client is misconfigured and that should be their problem 
and not ours.  Right?

>                                     So I'll take the comment under 
> advisement, but I suspect you're going to be in the minority.

I would urge caution about paying too much attention to a vocal minority, to 
the potential detriment of the majority who aren't complaining.

Now, if this was being driven by 508 compliance for accessibility and there 
simply were no other viable options, it would be more difficult for me to 
have grounds for a complaint.  But so far I haven't heard terms like that.

> Since I've since changed the original css, here's the current stuff with 
> no link colours specified (so they default to your browser settings):
> 
> http://terri.zone12.com/mm-website/?css=mailman-nolink

IMO, that looks much better.

>> Did you want to mention the official Mailman group on LinkedIn?  Of 
>> course, I can't figure out how to give you a link that will take you 
>> to their page for the group as opposed to the "home page" that I 
>> defined for the group (namely www.list.org), but that may be something 
>> we can resolve.
> 
> Seems like a good fit for the "Participate" page!  I've put it just 
> under the wiki entry.

Cool.  Thanks!

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

From turnbull at sk.tsukuba.ac.jp  Wed Jul 23 22:50:18 2008
From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Thu, 24 Jul 2008 05:50:18 +0900
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman Site Redesign
In-Reply-To: <48878A9C.3090808@shub-internet.org>
References: <42a95f60803102010i47ea00ft4af82f46b4cdf1e8@mail.gmail.com>
	<901387E0-D87B-427F-9C6A-1018D8B0F42B@list.org>
	<94C0A1E3-9222-4D6E-B0B5-10EA5157E81C@zone12.com>
	<CA6DB778-1771-46BC-8B0F-6271451E3378@zone12.com>
	<A43750FC-0F4D-4195-92A0-AB0F7B2E91BE@list.org>
	<AFDD1E43-3D6F-469F-ACD1-F7AB2603C736@zone12.com>
	<4873D008.5060303@msapiro.net>
	<C3256857-7BA6-42C9-A9A8-9537ABA0A5B7@zone12.com>
	<488768E6.3010109@python.org>
	<610816DF-33F8-4409-8BDB-12B4B3B57456@zone12.com>
	<48878A9C.3090808@shub-internet.org>
Message-ID: <87myk8fhpx.fsf@uwakimon.sk.tsukuba.ac.jp>

Brad Knowles writes:

 > That implies their client is misconfigured and that should be their problem 
 > and not ours.  Right?

Actually, all existing clients are pretty much broken, since they
don't allow you to enforce your own CSS.  But I guess they figure that
nearly all existing users are broken, 'cause they can't write their
own CSS ....  :-(  Grrr.


From carles at pina.cat  Sat Jul 26 02:39:02 2008
From: carles at pina.cat (Carles Pina i Estany)
Date: Sat, 26 Jul 2008 02:39:02 +0200
Subject: [Mailman-Developers] incorrect Catalan translation
Message-ID: <20080726003902.GA8657@pina.cat>


Hello,

I've sent a patch in Sourceforge for the Catalan translation:
https://sourceforge.net/tracker/index.php?func=detail&aid=2028370&group_id=103&atid=300103

In the webpage was said to send there and send ping here, so this is
what I'm doing.

Thank you,

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

From mark at msapiro.net  Sat Jul 26 17:31:09 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 26 Jul 2008 08:31:09 -0700
Subject: [Mailman-Developers] [Mailman-Users] moderation rejection
	notices, etc.
In-Reply-To: <20080725181216.533EDFA18F@friskymail-a5.g.dreamhost.com>
Message-ID: <PC1870200807260831090875df62c6f4@Notebook>

Michael Welch wrote:
> 
> 2. When I reject a moderated message with an explanation, the
> rejection note comes from listname-bounces@ . So when the member
> replies to that message, it sends me a note saying that it received
> an unrecognized bounce, and buried in the note is the member's
> response.
> 
> Shouldn't rejected & annotated messages come from listname-admin@
> instead? I bet there is a good reason for this that I do not know.


Brad has already responded to 1., 3. and 4. As far as 2. is concerned,
you raise a good point, although you mean the messages should be From:
listname-owner at .... listname-admin at ... is actually a deprecated
synonym for listname-bounces at ...

I don't think there is a good reason for the reject to come from
listname-bounces at .... 

This came about in the implementation of automated bounce processing in
Mailman 2.1. Prior to 2.1, the list owner address was
listname-admin at .... This address was also used as the envelope sender
of messages so bounces would return to the list owner for attention.
With automated bounce processing, the envelope sender was changed to
listname-bounces at ..., and the listname-admin at ..., was deprecated in
favor of listname-owner at ... and processed the same as
listname-bounces at ....


At that point, the processing of refusal messages was changed. The
intent was that replies go to the owner. In fact the log message for
the change says

  __refuse(): In the refuse.txt, use the -owner address as the
  %(adminaddr)s expansion so that when the human acts on this message,
  they'll contact a human without going through the bounce processor.

The actual change
<http://mailman.svn.sourceforge.net/viewvc/mailman?view=rev&revision=5019>
changed the address inserted into the text of the refusal to the
listname-owner at ... address, but it changed the From: to the
listname-bounces at ... address.

I think this was a mistake. I'm Ccing mailman-developers in case
someone remembers some reason for this, but barring objection, I'll
change it for the next release.

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