From gmccaughan at synaptics-uk.com  Thu Jun  1 13:01:11 2006
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Thu, 1 Jun 2006 12:01:11 +0100
Subject: [Mailman-Developers] Hooks for external archivers
Message-ID: <200606011201.11957.gmccaughan@synaptics-uk.com>

Suppose you're using Mailman with a separate archiving system
such as Lurker or mod_mbox or something. Then there are a few
points at which the external archiver needs to be informed of
what Mailman is up to, including at least these:

  - Creation of a new list
  - Some changes to config of an existing list
  - Arrival of a new message
  - Removal of a list (maybe)

At the moment (I'm using 2.1.8) I think the only such notification
is for the arrival of a new message, at which point PUBLIC_EXTERNAL_ARCHIVER
or PRIVATE_EXTERNAL_ARCHIVER gets invoked.

In my local setup, I've tentatively added a new hook that I've
equally tentatively called LIST_INFO_UPDATE_COMMAND; if it's not
None, it gets invoked whenever a list object's Save method is
called (after %-formatting using the list's configvars plus an
extra entry for the list's canonical name). That works well
for my needs, but I'm under no delusion that it's clearly optimal.

Is there a Right Thing that I should have done instead? If not,
should Mailman grow some more hooks for interaction with external
archivers?

(Here's a possibly tempting Wrong Thing: don't have separate hooks,
just check everything whenever a new message arrives. But this is
inefficient, and more importantly it means that changes to list
information won't be noticed until the next message is sent, which
for low-traffic lists might be some time after the change.)

-- 
g


From barry at python.org  Fri Jun  2 00:05:24 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 1 Jun 2006 18:05:24 -0400
Subject: [Mailman-Developers] Hooks for external archivers
In-Reply-To: <200606011201.11957.gmccaughan@synaptics-uk.com>
References: <200606011201.11957.gmccaughan@synaptics-uk.com>
Message-ID: <20060601180524.1c766726@resist.wooz.org>

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

On Thu, 1 Jun 2006 12:01:11 +0100
Gareth McCaughan <gmccaughan at synaptics-uk.com> wrote:

> Suppose you're using Mailman with a separate archiving system
> such as Lurker or mod_mbox or something. Then there are a few
> points at which the external archiver needs to be informed of
> what Mailman is up to, including at least these:
> 
>   - Creation of a new list
>   - Some changes to config of an existing list
>   - Arrival of a new message
>   - Removal of a list (maybe)
> 
> At the moment (I'm using 2.1.8) I think the only such notification
> is for the arrival of a new message, at which point
> PUBLIC_EXTERNAL_ARCHIVER or PRIVATE_EXTERNAL_ARCHIVER gets invoked.
> 
> In my local setup, I've tentatively added a new hook that I've
> equally tentatively called LIST_INFO_UPDATE_COMMAND; if it's not
> None, it gets invoked whenever a list object's Save method is
> called (after %-formatting using the list's configvars plus an
> extra entry for the list's canonical name). That works well
> for my needs, but I'm under no delusion that it's clearly optimal.
> 
> Is there a Right Thing that I should have done instead? If not,
> should Mailman grow some more hooks for interaction with external
> archivers?

I think Mailman should definitely grow more hooks.  In fact, it really
should grow a framework for extensions as well, so that your extensions
can live outside the Mailman source code (a good thing for many
reasons).  Obviously something like this can't go in Mailman 2.1, but
it could go into Mailman 2.2.

Off the top of my head, the general idea is that you'd define a file
system location for your extension to live, and Mailman would map that
into its Mailman.extension package.  There it would look for modules to
load that provided an interface for getting notifications of certain
events.  I think designing the framework is fairly straight-forward.
The real issue is what kinds of hooks you'd like to see, and what kind
of information should get passed to each hook.

Maybe you'd like to outline your thoughts on that in the wiki
<wiki.list.org>? If we can come up with a decent list of hooks and hook
information, then it probably wouldn't be a difficult feaure to add,
and I think it could be rather powerful for sites that want lots of
special customization.

> (Here's a possibly tempting Wrong Thing: don't have separate hooks,
> just check everything whenever a new message arrives. But this is
> inefficient, and more importantly it means that changes to list
> information won't be noticed until the next message is sent, which
> for low-traffic lists might be some time after the change.)

Yeah, I wouldn't do that! :)

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRH9kp3EjvBPtnXfVAQLxFgP/TB0oiONf3308+FoJEc8P2ami1quwqe5s
DwuNh/ZEtdcxRYEQcbab9DHF5rEFerfXjIUjAz+ezex9So8U6HuDDhqUhYPlNa3h
9HZ5KAPSwHQCAINMrtzsZGiljUeryP2iUAJmzZ89kECODm7tfP+gvmBPH8nx1+nw
TWV4ylTXLYM=
=ybK0
-----END PGP SIGNATURE-----

From fil at rezo.net  Fri Jun  2 00:08:31 2006
From: fil at rezo.net (Fil)
Date: Fri, 2 Jun 2006 00:08:31 +0200
Subject: [Mailman-Developers] Hooks for external archivers
In-Reply-To: <200606011201.11957.gmccaughan@synaptics-uk.com>
References: <200606011201.11957.gmccaughan@synaptics-uk.com>
Message-ID: <20060601220831.GD3410@rezo.net>

@ Gareth McCaughan <gmccaughan at synaptics-uk.com> :
> Suppose you're using Mailman with a separate archiving system
> such as Lurker or mod_mbox or something. Then there are a few

Is there some kind of tutorial on mod_mbox somewhere? I had never heard
about this project and find the example lists no less than excellent

-- Fil


From gmccaughan at synaptics-uk.com  Fri Jun  2 10:59:01 2006
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Fri, 2 Jun 2006 09:59:01 +0100
Subject: [Mailman-Developers] Hooks for external archivers
In-Reply-To: <20060601220831.GD3410@rezo.net>
References: <200606011201.11957.gmccaughan@synaptics-uk.com>
	<20060601220831.GD3410@rezo.net>
Message-ID: <200606020959.01924.gmccaughan@synaptics-uk.com>

On Thursday 2006-06-01 23:08, "Fil" wrote:

> @ Gareth McCaughan <gmccaughan at synaptics-uk.com> :
> > Suppose you're using Mailman with a separate archiving system
> > such as Lurker or mod_mbox or something. Then there are a few
> 
> Is there some kind of tutorial on mod_mbox somewhere? I had never heard
> about this project and find the example lists no less than excellent

I'm not aware of one. I agree that mod_mbox is beautiful, much nicer
than Lurker. The things that worry me a bit about it:

  - The AJAX-y stuff basically only works on Gecko-based browsers.
    That would be Firefox, Mozilla, and their less common relations.
    It doesn't work, for instance, on IE or Opera or Safari or
    Konqueror.

  - I've found one situation where it simply breaks and refuses
    to show you an e-mail. (If you have an attachment whose name
    is a quoted string containing spaces, the parsing is wrong
    and it produces broken XML and everything goes pear-shaped.)
    I have a quick-and-dirty patch for this bug, but the presence
    of a bug like this doesn't inspire me with confidence.

  - It makes more assumptions than I'm happy with about the mboxen
    it reads. They have to contain a List-Post header somewhere;
    they have to be named in a certain way. Again, these aren't
    major problems but I worry that they may be symptoms of a
    deeper pathology, namely a general preference for writing code
    that works in one particular context and not worrying if it
    doesn't work right in general.

  - (I may be misremembering this one.) I don't think there's any
    way to process messages incrementally as they arrive, so I'm
    not sure how you'd use mod_mbox for a busy mailing list. Now,
    the Apache project seems to use it for a whole lot of busy
    mailing lists, so maybe this is all fine, but I worry a bit,
    and I notice that the mail I sent yesterday to dev at httpd.apache.org
    reporting the aforementioned bug still hasn't appeared in the
    mod_mbox-based archives, so maybe they handle it by just not
    running the updater very often.

Also, there's some sign of support for searching, but it's not
clear how much it can do or how to make it work and it requires
this separate Lucene4c thing, and I'm lazy.

But, still, it's awfully shiny and I'd love to love it. Perhaps
when it's matured a little more. :-)

-- 
g


From gmccaughan at synaptics-uk.com  Fri Jun  2 16:06:49 2006
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Fri, 2 Jun 2006 15:06:49 +0100
Subject: [Mailman-Developers] Hooks for external archivers
In-Reply-To: <200606020959.01924.gmccaughan@synaptics-uk.com>
References: <200606011201.11957.gmccaughan@synaptics-uk.com>
	<20060601220831.GD3410@rezo.net>
	<200606020959.01924.gmccaughan@synaptics-uk.com>
Message-ID: <200606021506.50162.gmccaughan@synaptics-uk.com>

>   - (I may be misremembering this one.) I don't think there's any
>     way to process messages incrementally as they arrive, so I'm
>     not sure how you'd use mod_mbox for a busy mailing list. Now,
>     the Apache project seems to use it for a whole lot of busy
>     mailing lists, so maybe this is all fine, but I worry a bit,
>     and I notice that the mail I sent yesterday to dev at httpd.apache.org
>     reporting the aforementioned bug still hasn't appeared in the
>     mod_mbox-based archives, so maybe they handle it by just not
>     running the updater very often.

Actually, that last thing turns out to be at least partly because
dev@ just drops mail on the floor when it comes from unsubscribed
addresses. :-) But comparing with gmane, the mod_mbox-based archive
does seem to be some way behind...

-- 
g


From gmccaughan at synaptics-uk.com  Fri Jun  2 17:40:33 2006
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Fri, 2 Jun 2006 16:40:33 +0100
Subject: [Mailman-Developers] Hooks for external archivers
In-Reply-To: <20060601180524.1c766726@resist.wooz.org>
References: <200606011201.11957.gmccaughan@synaptics-uk.com>
	<20060601180524.1c766726@resist.wooz.org>
Message-ID: <200606021640.34052.gmccaughan@synaptics-uk.com>

On Thursday 2006-06-01 23:05, Barry Warsaw wrote:
> I think Mailman should definitely grow more hooks.  In fact, it really
> should grow a framework for extensions as well, so that your extensions
> can live outside the Mailman source code
[...]
> Maybe you'd like to outline your thoughts on that in the wiki
> <wiki.list.org>?

Sounds like a good plan, but unlikely to happen before the middle
of next week.

-- 
g


From msapiro at value.net  Sat Jun  3 05:18:51 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 2 Jun 2006 20:18:51 -0700
Subject: [Mailman-Developers] Topic regexps
In-Reply-To: <C09C7E12.CC07%jwblist3@olympus.net>
Message-ID: <PC17402006060220185102656f2df03c@msapiro>

John W. Baxter wrote:

>On 5/25/06 8:29 PM, "Mark Sapiro" <msapiro at value.net> wrote:
>
>> I've thought about this some more and what I'm currently thinking is if
>> the topic regexp is multiline, leave it as is in topics, but before
>> compiling it for use, split the lines and then rejoin them with "|",
>> and compile not in VERBOSE mode.
>
>I think you need to strip any trailing | characters from the strings in the
>resulting list before joining with |.
>
>Otherwise, you might build one||two||three
>Which clearly isn't what is wanted.
>
>Hmmm...I guess I mean "up to one trailing | character"...in case someone
>really wanted one||two for some really strange reason.


I actually don't think that's necessary. My reasoning is that the
descriptions imply that multiple lines are joined with "|" without
having to explicitly put "|" in the pattern.

The changes I intend to put in Mailman 2.2 will include code in
versions.py to convert all presumably working multi-line patterns
(verbose mode) into a single line equivalent, non-verbose pattern.
Thus, an existing topics regexp such as
'one|\ntwo|\nthree' will be converted during the 2.1.x to 2.2 upgrade
into 'one|two|three'. Thus the new code in Tagger.py will not see
multiple lines and won't change the pattern at all.

So the only future multi-line patterns will be new ones and presumably
the person creating them will not be motivated to put trailing "|" on
the lines and if he/she does anyway, testing should reveal that is
wrong.

This leads me to the next question. I have written
Mailman.Utils.strip_verbose_pattern() to strip comments and whitespace
from a verbose pattern and return a single-line, non-verbose
equivalent.

I think the thing to do with existing topics is the following:


--- versions.py	(revision 7905)
+++ versions.py	(working copy)
@@ -307,6 +307,16 @@
             pass
         else:
             l.digest_members[k] = 0
+    #
+    # Convert pre 2.2 topics regexps whice were compiled in verbose
mode
+    # to a single line, non-verbose equivalent.
+    #
+    if stored_state.data_version <= 97 and hasattr(stored_state,
'topics')\
+            and stored_state.topics:
+        l.topics = []
+        for name, pattern, description, emptyflag in
stored_state.topics:
+            pattern = Utils.strip_verbose_pattern(pattern)
+            l.topics.append((name, pattern, description, emptyflag))
 
 
 
I'm not 100% comfortable with this for two reasons. The first is that
this is apparently the only thing in versions.py which will reference
an actual data_version. It seems OK, but I wonder if there is a better
way.

The other discomfort is list admins may be confused by the fact that
their nicely commented, pretty, verbose topic regexp turned into an
uncommented, ugly, non-verbose regexp. I actually think this is the
least evil way to address this problem, but I'm still not 100%
comfortable with it.

Thoughts, comments, other ideas?

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


From msapiro at value.net  Sat Jun  3 06:43:00 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 2 Jun 2006 21:43:00 -0700
Subject: [Mailman-Developers] Topic regexps
In-Reply-To: <PC17402006060220185102656f2df03c@msapiro>
Message-ID: <PC17402006060221430002967b640668@msapiro>

Mark Sapiro wrote:
>
>I think the thing to do with existing topics is the following:
>
>
>--- versions.py	(revision 7905)
>+++ versions.py	(working copy)
>@@ -307,6 +307,16 @@
>             pass
>         else:
>             l.digest_members[k] = 0
>+    #
>+    # Convert pre 2.2 topics regexps whice were compiled in verbose mode
>+    # to a single line, non-verbose equivalent.
>+    #
>+    if stored_state.data_version <= 97 and hasattr(stored_state, 'topics')\
>+            and stored_state.topics:
>+        l.topics = []
>+        for name, pattern, description, emptyflag in stored_state.topics:
>+            pattern = Utils.strip_verbose_pattern(pattern)
>+            l.topics.append((name, pattern, description, emptyflag))


Testing reveals the above patch is not correct because stored_state is
a dictionary, not a list instance, but the logic is correct.

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


From fil at rezo.net  Mon Jun  5 22:39:31 2006
From: fil at rezo.net (Fil)
Date: Mon, 5 Jun 2006 22:39:31 +0200
Subject: [Mailman-Developers] update to MysqlMemberAdaptor
Message-ID: <20060605203931.GG29492@rezo.net>

Hi everybody,

there was a bug in "my" version of MysqlAdaptor, in the changeMemberAddress
method: it has been corrected @ http://trac.rezo.net/trac/rezo/changeset/75

-- Fil


From t.d.lee at durham.ac.uk  Tue Jun  6 18:23:08 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Tue, 6 Jun 2006 17:23:08 +0100 (BST)
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
Message-ID: <Pine.GSO.4.58.0606061711200.29049@arachne.dur.ac.uk>

(Background: new to Mailman.  Trialling 2.1.8 prior to wider roll-out.)

Minor mismatch in web interface terminology:


Whilst guiding a potential list-owner through the approval/moderation
procedure, I spotted an inconsistency.  A typical "http://.../admindb/..."
page ("Administrative requests for mailing list: ...") has a four way
radio button, with one being labelled "Accept".  But its "More detailed
instructions" link to "Detailed instructions for the administrative
database" then has this button described under the label "Approve".

This mixture of terminology seems to occur in other places also. You might
want to consider rationalising these to the same thing for the sake of
moderators who might be (say) secretarial staff.

Hope that helps.

-- 

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

From msapiro at value.net  Wed Jun  7 02:58:17 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 6 Jun 2006 17:58:17 -0700
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606061711200.29049@arachne.dur.ac.uk>
Message-ID: <PC17402006060617581701159e672f04@msapiro>

David Lee wrote:
>
>Whilst guiding a potential list-owner through the approval/moderation
>procedure, I spotted an inconsistency.  A typical "http://.../admindb/..."
>page ("Administrative requests for mailing list: ...") has a four way
>radio button, with one being labelled "Accept".  But its "More detailed
>instructions" link to "Detailed instructions for the administrative
>database" then has this button described under the label "Approve".
>
>This mixture of terminology seems to occur in other places also. You might
>want to consider rationalising these to the same thing for the sake of
>moderators who might be (say) secretarial staff.

Thanks for the report. I will update the template as follows unless you
have a better suggestion:

Index: admindbdetails.html
===================================================================
--- admindbdetails.html	(revision 7905)
+++ admindbdetails.html	(working copy)
@@ -14,7 +14,7 @@
     postings, you can still forward or preserve the message (see
     below).
 
-<li><b>Approve</b> -- Approve the message, sending it on to the list.
+<li><b>Accept/Approve</b> -- Accept the message, sending it on to the
list.
     For membership requests, approve the change in membership status.
 
 <li><b>Reject</b> -- Reject the message, sending a rejection notice to


Since it is a template, you can fix your own and store the fixed
version in templates/site/en/admindbdetails.html where it will survive
updates (the base is templates/en/admindbdetails.html). See
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.048.htp>.

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


From barry at python.org  Wed Jun  7 05:49:45 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 6 Jun 2006 23:49:45 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606061711200.29049@arachne.dur.ac.uk>
References: <Pine.GSO.4.58.0606061711200.29049@arachne.dur.ac.uk>
Message-ID: <20060606234945.0f135eb8@geddy.wooz.org>

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

On Tue, 6 Jun 2006 17:23:08 +0100 (BST)
David Lee <t.d.lee at durham.ac.uk> wrote:

> Whilst guiding a potential list-owner through the approval/moderation
> procedure, I spotted an inconsistency.  A typical
> "http://.../admindb/..." page ("Administrative requests for mailing
> list: ...") has a four way radio button, with one being labelled
> "Accept".  But its "More detailed instructions" link to "Detailed
> instructions for the administrative database" then has this button
> described under the label "Approve".
> 
> This mixture of terminology seems to occur in other places also. You
> might want to consider rationalising these to the same thing for the
> sake of moderators who might be (say) secretarial staff.

I agree, but which is the best term to use?  Reading the dictionary
entries for "approve" and "accept", I think I like the former:

ap_prove

   1. To consider right or good; think or speak favorably of.
   2. To consent to officially or formally; confirm or sanction: The
Senate approved the treaty.
   3. Obsolete. To prove or attest.

ac_cept

   1. To receive (something offered), especially with gladness or
approval: accepted a glass of water; accepted their contract. 
   2. To admit to a group, organization, or place: accepted me as a new
member of the club. 
   3.
         1. To regard as proper, usual, or right: Such customs are
widely accepted. 
         2. To regard as true; believe in: Scientists have accepted the
new theory. 
         3. To understand as having a specific meaning.
   4. To endure resignedly or patiently: accept one's fate.
   5.
         1. To answer affirmatively: accept an invitation.
         2. To agree to take (a duty or responsibility).
   6. To be able to hold (something applied or inserted): This wood
will not accept oil paints. 
   7. To receive officially: accept the committee's report.
   8. To consent to pay, as by a signed agreement.
   9. Medicine. To receive (a transplanted organ or tissue) without
      immunological rejection. 

Seems to me that definition #2 of "approve" is the closest to what a
list administrator does.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIZM3nEjvBPtnXfVAQKjawP/TD9T+jWShYHuz8jhEQ2jMRNBS8i5Kl6j
PXHICPW4a60QkuUPQMIhBHo9fNdDeU5zHSWA0+YBFT9g0q3PQ7//S2jDFsfEDf7M
Nx0oeOWiMIWelUTA8zZVInmoheFfv6RMPXOZ7GE0+hnMZ2j1katxXzyLTXYwkS7r
35lYgye3Iqo=
=cKGe
-----END PGP SIGNATURE-----

From jwblist3 at olympus.net  Tue Jun  6 21:56:51 2006
From: jwblist3 at olympus.net (John W. Baxter)
Date: Tue, 06 Jun 2006 12:56:51 -0700
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606061711200.29049@arachne.dur.ac.uk>
Message-ID: <C0AB2C13.CEB6%jwblist3@olympus.net>

On 6/6/06 9:23 AM, "David Lee" <t.d.lee at durham.ac.uk> wrote:

> This mixture of terminology seems to occur in other places also. You might
> want to consider rationalising these to the same thing for the sake of
> moderators who might be (say) secretarial staff.

Secretarial staff should have no problem with the example given.  The CEO,
on the other hand...

And yes, terminology should be consistent.

  --John



From msapiro at value.net  Wed Jun  7 07:02:44 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 6 Jun 2006 22:02:44 -0700
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060606234945.0f135eb8@geddy.wooz.org>
Message-ID: <PC1740200606062202440490b107c516@msapiro>

Barry Warsaw wrote:
>
>I agree, but which is the best term to use?  Reading the dictionary
>entries for "approve" and "accept", I think I like the former:

Actually, both terms are used on the radio buttons on the admindb page.
"Accept" is used for held posts, and "Approve" is used for
(un)subscription requests.

We could of course change the name of the held message radio button to
"Approve", but then we'd have an inconsistency with "Add
poster at example.com to one of these sender filters:", and if we changed
that, would we also want to change the name of accept_these_nonmembers?

It seemed simpler to me to just make the template change I indicated in
my prior reply.

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


From iane at sussex.ac.uk  Wed Jun  7 11:41:26 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 07 Jun 2006 10:41:26 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <PC1740200606062202440490b107c516@msapiro>
References: <PC1740200606062202440490b107c516@msapiro>
Message-ID: <1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>



--On 6 June 2006 22:02:44 -0700 Mark Sapiro <msapiro at value.net> wrote:

> Barry Warsaw wrote:
>>
>> I agree, but which is the best term to use?  Reading the dictionary
>> entries for "approve" and "accept", I think I like the former:
>
> Actually, both terms are used on the radio buttons on the admindb page.
> "Accept" is used for held posts, and "Approve" is used for
> (un)subscription requests.
>
> We could of course change the name of the held message radio button to
> "Approve", but then we'd have an inconsistency with "Add
> poster at example.com to one of these sender filters:", and if we changed
> that, would we also want to change the name of accept_these_nonmembers?
>
> It seemed simpler to me to just make the template change I indicated in
> my prior reply.

While we're here, can we change all instances of "reject" to "bounce". 
Mailman deals with queued messages, so it isn't capable of rejecting a 
message in the SMTP sense. All it can do is generate bounces - which are 
probably collateral spam.

Even better would be to integrate Mailman into MTA's better, so that the 
MTA can use Mailman data to reject spam.

-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Wed Jun  7 15:20:46 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 09:20:46 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <PC1740200606062202440490b107c516@msapiro>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
Message-ID: <20060607092046.54b2a0a0@geddy.wooz.org>

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

On Tue, 6 Jun 2006 22:02:44 -0700
Mark Sapiro <msapiro at value.net> wrote:

> >I agree, but which is the best term to use?  Reading the dictionary
> >entries for "approve" and "accept", I think I like the former:
> 
> Actually, both terms are used on the radio buttons on the admindb
> page. "Accept" is used for held posts, and "Approve" is used for
> (un)subscription requests.
> 
> We could of course change the name of the held message radio button to
> "Approve", but then we'd have an inconsistency with "Add
> poster at example.com to one of these sender filters:", and if we changed
> that, would we also want to change the name of
> accept_these_nonmembers?
> 
> It seemed simpler to me to just make the template change I indicated
> in my prior reply.

I don't disagree with that, so go for it.

It's just that we'll be redesigning the web u/i as part of the Google
SoC project (don't worry, it's not a forgone conclusion that that work
will be integrated into the mainline release).  As we redesign and
rewrite, I think we should standardize on "Approve" for actions to be
taken by the list administrator.

Ian mentioned that he thinks we should change "Reject" to "Bounce", but
I'm not sure I like that.  Rejecting a message or a subscription
request is the action that the admin takes.  Mailman's response to
that rejection is return the original message wrapped in a response.
The term "bounce" to me implies a more automatic return that happens at
a lower level in the mail stack, and it might be confused with
terminology in the bounce processing u/i.

So I think the following terms should be used consistently (I'm not
suggesting a mass rewrite to adhere to this):

Approve
Hold
Reject
Discard

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIbSsXEjvBPtnXfVAQKejwP/QPSup6mVwOezrMdYKly73z3QH3kbq3MN
pzUanylMlhZ9mVB1AYfLLnqI4/ziWmNjkPRj31VtrGKVnTBGHLGAYCnmFB8E4S/P
Zk5DvyG3fPj3VNCfFDN/UyKbaWMIe4tv7qHnS2C5xgE+pIBm00PPtmh9F0INElEi
DwxEI348tIU=
=b6Qu
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun  7 15:26:11 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 09:26:11 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060607092611.643e6744@geddy.wooz.org>

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

On Wed, 07 Jun 2006 10:41:26 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> Even better would be to integrate Mailman into MTA's better, so that
> the MTA can use Mailman data to reject spam.

I think that will be problematic, given the wide variety of MTA
extension frameworks.  A better approach would be to structure the
Mailman code in such a way that large parts of it can be used as a
library, which could serve as the basis for sites writing their own MTA
extension, or any other specialized Mailman-based application.

This is actually one of the main reasons why I've been moving the bulk
of the bin and cron scripts to inside the top-level Mailman package for
2.2.  Those scripts need to be refactored a bit better, but they do
provide some useful higher-level operations that other Python programs
can now get access to (e.g. by putting /usr/local/mailman on your
sys.path and doing good ol' imports).

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIbT93EjvBPtnXfVAQJVOAP/eS5fiGp/mWdoTmlp8p98t8fcMnpgbJ1m
ljwezQR+3G4FTPI6lymYqAN0xAqYKl4Nwfg6/n3XfUsteD5KaHKuXuTC/FYdMy8B
XEDjXpNaq0bF8uHQWyJM7LAEr8nuKOMMgAJyLKE/mk1KHGoyiXm6JXaJXu0VB8ib
rAGvZ5QUl+4=
=1Z8K
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Wed Jun  7 16:46:56 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 07 Jun 2006 15:46:56 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607092046.54b2a0a0@geddy.wooz.org>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
Message-ID: <FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>



--On 7 June 2006 09:20:46 -0400 Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 6 Jun 2006 22:02:44 -0700
> Mark Sapiro <msapiro at value.net> wrote:

>
> Ian mentioned that he thinks we should change "Reject" to "Bounce", but
> I'm not sure I like that.  Rejecting a message or a subscription
> request is the action that the admin takes.

OK, i'm talking about messages here, not subscription requests. As I 
understand the terms, a "reject" is an SMTP response to a remote server (or 
MTA) trying to send email. It means "I'm not accepting this email, you 
choose what to do with it". The sending MTA may choose to generate a DSN, 
and a DSN that reports a hard (5xx) rejection is often referred to as a 
bounce message.

With Mailman, rejection isn't possible. We've already accepted the message 
and queued it. When a Mailman list rule, or an administrator decides to 
"reject" a message, in fact they're choosing to send a DSN bounce message.

There's a REALLY REALLY REALLY important difference in the case of spam. 
Most spambots will ignore a reject and NOT generate a DSN bounce message. 
However, if you choose to bounce the message, then a DNS will be sent to an 
innocent third party. That's collateral spam, and it's a nightmare.

Unfortunately, RFC2821 says that you must generate such collateral spam, 
and that's why I want my MTA to be able to read Mailman's config - so that 
it can reject email properly at SMTP time.

> Mailman's response to
> that rejection is return the original message wrapped in a response.
> The term "bounce" to me implies a more automatic return that happens at
> a lower level in the mail stack, and it might be confused with
> terminology in the bounce processing u/i.

> So I think the following terms should be used consistently (I'm not
> suggesting a mass rewrite to adhere to this):
>
> Approve
> Hold
> Reject
> Discard
>
> - -Barry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iQCVAwUBRIbSsXEjvBPtnXfVAQKejwP/QPSup6mVwOezrMdYKly73z3QH3kbq3MN
> pzUanylMlhZ9mVB1AYfLLnqI4/ziWmNjkPRj31VtrGKVnTBGHLGAYCnmFB8E4S/P
> Zk5DvyG3fPj3VNCfFDN/UyKbaWMIe4tv7qHnS2C5xgE+pIBm00PPtmh9F0INElEi
> DwxEI348tIU=
> =b6Qu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe:
> http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a
> c.uk
>
> Security Policy:
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp



-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Wed Jun  7 16:51:54 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 07 Jun 2006 15:51:54 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607092611.643e6744@geddy.wooz.org>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
Message-ID: <E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>



--On 7 June 2006 09:26:11 -0400 Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 07 Jun 2006 10:41:26 +0100
> Ian Eiloart <iane at sussex.ac.uk> wrote:
>
>> Even better would be to integrate Mailman into MTA's better, so that
>> the MTA can use Mailman data to reject spam.
>
> I think that will be problematic, given the wide variety of MTA
> extension frameworks.

Yes, of course.

> A better approach would be to structure the
> Mailman code in such a way that large parts of it can be used as a
> library, which could serve as the basis for sites writing their own MTA
> extension, or any other specialized Mailman-based application.

Perhaps. Even better would be to hold rosters in open databases. Exim, for 
example, can read sql, ldap, flat files and so on. I don't think it's 
Mailman's job to examine the content of messages - that's the job of a spam 
or virus filter.

> This is actually one of the main reasons why I've been moving the bulk
> of the bin and cron scripts to inside the top-level Mailman package for
> 2.2.  Those scripts need to be refactored a bit better, but they do
> provide some useful higher-level operations that other Python programs
> can now get access to (e.g. by putting /usr/local/mailman on your
> sys.path and doing good ol' imports).
>
> - -Barry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iQCVAwUBRIbT93EjvBPtnXfVAQJVOAP/eS5fiGp/mWdoTmlp8p98t8fcMnpgbJ1m
> ljwezQR+3G4FTPI6lymYqAN0xAqYKl4Nwfg6/n3XfUsteD5KaHKuXuTC/FYdMy8B
> XEDjXpNaq0bF8uHQWyJM7LAEr8nuKOMMgAJyLKE/mk1KHGoyiXm6JXaJXu0VB8ib
> rAGvZ5QUl+4=
> =1Z8K
> -----END PGP SIGNATURE-----



-- 
Ian Eiloart
IT Services, University of Sussex

From brad at stop.mail-abuse.org  Wed Jun  7 19:28:55 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 12:28:55 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p0620071bc0acbc58a699@[10.0.1.210]>

At 3:46 PM +0100 2006-06-07, Ian Eiloart wrote:

>>  Ian mentioned that he thinks we should change "Reject" to "Bounce", but
>>  I'm not sure I like that.  Rejecting a message or a subscription
>>  request is the action that the admin takes.
>
>  OK, i'm talking about messages here, not subscription requests.

	List moderators deal mostly with messages, list administrators 
deal more frequently with things like subscription requests.

	We need to distinguish here what we call what, in what context.

>                                                                   As I
>  understand the terms, a "reject" is an SMTP response to a remote server (or
>  MTA) trying to send email. It means "I'm not accepting this email, you
>  choose what to do with it". The sending MTA may choose to generate a DSN,
>  and a DSN that reports a hard (5xx) rejection is often referred to as a
>  bounce message.

	Actually, no -- that would be a refusal.  A rejection would be 
something you would send after accepting the message initially, and 
then discovering that you could not deliver the message for some 
reason.

	So, when it comes to spam, you want to refuse it and not reject it.

>  There's a REALLY REALLY REALLY important difference in the case of spam.
>  Most spambots will ignore a reject and NOT generate a DSN bounce message.
>  However, if you choose to bounce the message, then a DNS will be sent to an
>  innocent third party. That's collateral spam, and it's a nightmare.

	Yes, blowback is a problem.  I'm not sure that anyone can resolve 
this problem any time soon, however.

>  Unfortunately, RFC2821 says that you must generate such collateral spam,
>  and that's why I want my MTA to be able to read Mailman's config - so that
>  it can reject email properly at SMTP time.

	See my previous responses.  We may be able to teach the MTAs how 
to read some of the databases that Mailman might be using when it 
would be making its decision to accept or reject the message, but I 
don't think it's going to be possible to teach the MTAs everything.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Wed Jun  7 19:24:26 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 12:24:26 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607092611.643e6744@geddy.wooz.org>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
Message-ID: <p0620071ac0acbbc383b4@[10.0.1.210]>

At 9:26 AM -0400 2006-06-07, Barry Warsaw wrote:

>  I think that will be problematic, given the wide variety of MTA
>  extension frameworks.

	It's not just the MTA extension frameworks, it's also the myriad 
of things that Mailman may choose to do or to look at when deciding 
what to do, based on content in the message.

	I don't think it's feasible to completely re-write Mailman, or to 
completely re-write the MTAs, so that each of them has a deep 
integral understanding of all the nuances and complexities of the 
work that is being done by the other.


	Short of doing a rewrite on that scale, I suspect that we're 
going to continue to have these kinds of problems for some time.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Wed Jun  7 19:36:23 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 12:36:23 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p0620071cc0acbd64e581@[10.0.1.210]>

At 3:51 PM +0100 2006-06-07, Ian Eiloart wrote:

>  Perhaps. Even better would be to hold rosters in open databases. Exim, for
>  example, can read sql, ldap, flat files and so on.

	That's just rosters.  That's a small part of the overall set of 
things that Mailman is going to be looking at when it comes to 
deciding whether or not to accept or reject a given message.

	Moreover, we've been trying to go to an integrated database model 
for all data regarding users, but what you're proposing here would be 
a push towards simplified, almost flat, databases with minimal 
specific information about users, so that the MTA could parse that 
information and understand who was subscribed to what list.

	Unless you've got some ideas of how to teach all MTAs how to 
reach deeply into our database and pull out subscription information 
for a given message, I don't see how these two goals are anything but 
diametrically opposed.


	We can't just be thinking of a single MTA here.  Just because it 
would be convenient to you to make all this magic happen in a way 
that would be perfectly fine for Exim, doesn't mean that we can 
ignore sendmail, postfix, and other programs.

	If you want to write up some Exim-specific ways that would result 
in a tighter integration between the MTA and Mailman, I think that 
would be fine so long as they don't cause architectural changes 
within Mailman that would result in a significantly worse integration 
with other MTAs.

>                                                      I don't think it's
>  Mailman's job to examine the content of messages - that's the job of a spam
>  or virus filter.

	But once the spam or virus filter has done their work, we need to 
look at that as part of the output in making our decisions.

	I don't think there's any way in the world that you're going to 
escape this.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Wed Jun  7 19:21:54 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 12:21:54 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p06200719c0acbb155aed@[10.0.1.210]>

At 10:41 AM +0100 2006-06-07, Ian Eiloart wrote:

>  Even better would be to integrate Mailman into MTA's better, so that the
>  MTA can use Mailman data to reject spam.

	I think we've had this debate in the past.  I don't think that's 
possible, given the sorts of things that Mailman may do with 
messages, including taking different actions on different messages 
with the exact same combination of envelope sender and recipient, 
based on the values of other things in the headers (such as placed 
there by anti-spam/anti-virus scanning systems).


	If you want to completely re-write your MTA so that it has a deep 
understanding of all the internal workings of Mailman, feel free to 
go ahead and do that.

	Otherwise, I suspect that we're going to continue to have this 
kind of problem for quite some time.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From barry at python.org  Wed Jun  7 20:18:52 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 14:18:52 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060607141852.41f12e4c@resist.wooz.org>

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

On Wed, 07 Jun 2006 15:46:56 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> OK, i'm talking about messages here, not subscription requests. As I 
> understand the terms, a "reject" is an SMTP response to a remote
> server (or MTA) trying to send email. It means "I'm not accepting
> this email, you choose what to do with it". The sending MTA may
> choose to generate a DSN, and a DSN that reports a hard (5xx)
> rejection is often referred to as a bounce message.
> 
> With Mailman, rejection isn't possible. We've already accepted the
> message and queued it. When a Mailman list rule, or an administrator
> decides to "reject" a message, in fact they're choosing to send a DSN
> bounce message.

I think that's a good point.  What's really happening is that the admin
is disapproving the message and returning it back to the original
sender.  The question is, which term captures that better for
non-techies (I think techies will get it either way).  To me "reject"
is better than "bounce".  Has anybody seen any comments on this issue
on mailman-users?

Using the term "bounce" here also has the possibility of confusion with
the automated bounce processing system.

> There's a REALLY REALLY REALLY important difference in the case of
> spam. Most spambots will ignore a reject and NOT generate a DSN
> bounce message. However, if you choose to bounce the message, then a
> DNS will be sent to an innocent third party. That's collateral spam,
> and it's a nightmare.

Right, but we're not talking about an automated process here, we're
talking about the actions a list admin will take manually.  I honestly
don't think it's feasible for a list admin to be managing malware.
Ideally, 99% of all malware should be filtered lower in the stack,
before Mailman (and the list admin) ever sees it.

Of course, no filter is perfect, so if an admin does see spam, then she
has the option of discarding it, which is why that operation has been
optimized (Discard all messages marked deferred).  Bottom line is that
all malware that sneaks through whatever filters are in place should
always be discarded, never rejected.

> Unfortunately, RFC2821 says that you must generate such collateral
> spam, and that's why I want my MTA to be able to read Mailman's
> config - so that it can reject email properly at SMTP time.

Very soon now I am going to start work on a SQLite backend for MM2.2.
If we're lucky, I'll be able to use something like SQLAlchemy or
SQLObject which will buy you many other RDBMS's at the same time.  Then
it's just a simple matter of publishing the schema, right? <wink>

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcYjXEjvBPtnXfVAQLj+gQAucBdCYrIwrGv1vVws2kvPNDRk3MFoQNY
k1VOr2KQEgkqLE7tdkw4JZAMN22KxyCsIvs3TRwEQcrChU/kEySNqVJAZT2+KW5T
8NM4Y2fug53SGdjiv/C6Ig/wg3cXWseBC9+RnZdd/vKOC4XHXl5NM6dujkJn8fWy
7DauaMvv5qY=
=ggpj
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun  7 20:20:09 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 14:20:09 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060607142009.12546a36@resist.wooz.org>

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

On Wed, 07 Jun 2006 15:51:54 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> > A better approach would be to structure the
> > Mailman code in such a way that large parts of it can be used as a
> > library, which could serve as the basis for sites writing their own
> > MTA extension, or any other specialized Mailman-based application.
> 
> Perhaps. Even better would be to hold rosters in open databases.
> Exim, for example, can read sql, ldap, flat files and so on.

It's likely we'll do that too, to some degree, for MM2.2 (see my other
response).

> I don't think it's Mailman's job to examine the content of messages -
> that's the job of a spam or virus filter.

I agree.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcY2XEjvBPtnXfVAQLI5QP/ZSTtijaiiFIDCsc9jiYsey3KnhdcNa7j
k7K4PYKs4QGvvsq5vtnMokosEuJjsr9oVWDuq+esXMjEp52j0EH2XbOSORsb3DXz
kHo6a4H5W2QU+DZPwcUikDRWGIc+bQPQAcsBKUzcDqGzRNLvNnIGAlQRa6dp4yKN
NDcIipGKRoA=
=o/ZY
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun  7 20:35:28 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 14:35:28 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p0620071cc0acbd64e581@[10.0.1.210]>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
Message-ID: <20060607143528.1249af3f@resist.wooz.org>

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

On Wed, 7 Jun 2006 12:36:23 -0500
Brad Knowles <brad at stop.mail-abuse.org> wrote:

> 	We can't just be thinking of a single MTA here.  Just because
> it would be convenient to you to make all this magic happen in a way 
> that would be perfectly fine for Exim, doesn't mean that we can 
> ignore sendmail, postfix, and other programs.
> 
> 	If you want to write up some Exim-specific ways that would
> result in a tighter integration between the MTA and Mailman, I think
> that would be fine so long as they don't cause architectural changes 
> within Mailman that would result in a significantly worse integration 
> with other MTAs.

Totally agree.  OTOH, don't most MTAs provide /some/ way to call
external programs on messages at various points in their workflow?  If
so, then by providing richer and more unified Python APIs inside
Mailman, we can at least allow for developers to write extension
modules for their MTAs that more tightly couple Mailman and the MTA,
without having to perform major surgery on Mailman or duplicate lots of
code.

That's really the direction I'm heading in -- make Mailman more like a
(Python) library that can be used to write custom "applications".  Those
applications wouldn't need to reach into our dbs directly because they
ought to be able to get most answers to a question fairly directly.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcccHEjvBPtnXfVAQJO1QP/aHkb6YJa8+Gw/CI5dzDu8vjbTc4OqFbv
8yqaywKPKSz5ZysMQWdKa4w8Kqypp3vkF6K9gxjQbGj2eE6yxMOJnDBUWow5KSGm
heVUdUe3q3cM5QXrFr3uOL++JN7+FfA/xw4agJH/zL/+/65AKgzrlYGo8Ky/kU4B
wIA9c92288g=
=phJV
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Wed Jun  7 20:44:51 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 07 Jun 2006 19:44:51 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607141852.41f12e4c@resist.wooz.org>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
	<20060607141852.41f12e4c@resist.wooz.org>
Message-ID: <2BA1161BA40C5F4AB7BF8FB8@lewes.staff.uscs.susx.ac.uk>



--On 7 June 2006 14:18:52 -0400 Barry Warsaw <barry at python.org> wrote:

>
> I think that's a good point.  What's really happening is that the admin
> is disapproving the message and returning it back to the original
> sender.  The question is, which term captures that better for
> non-techies (I think techies will get it either way).  To me "reject"
> is better than "bounce".  Has anybody seen any comments on this issue
> on mailman-users?

How about "return to sender"? That is what you'd say in the real world with 
snail mail. Better might be "return to purported sender" or even "return to 
some poor guy who knows nothing about this email" ;)

-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Wed Jun  7 20:45:03 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 14:45:03 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p0620071ac0acbbc383b4@[10.0.1.210]>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<p0620071ac0acbbc383b4@[10.0.1.210]>
Message-ID: <20060607144503.4aa6bac6@resist.wooz.org>

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

On Wed, 7 Jun 2006 12:24:26 -0500
Brad Knowles <brad at stop.mail-abuse.org> wrote:

> 	It's not just the MTA extension frameworks, it's also the
> myriad of things that Mailman may choose to do or to look at when
> deciding what to do, based on content in the message.

I agree.

> 	I don't think it's feasible to completely re-write Mailman,
> or to completely re-write the MTAs, so that each of them has a deep 
> integral understanding of all the nuances and complexities of the 
> work that is being done by the other.
> 
> 	Short of doing a rewrite on that scale, I suspect that we're 
> going to continue to have these kinds of problems for some time.

There will certainly be limits to what you can do, but essentially the
idea is that the MTA would be asking Mailman what it would do with a
particular message.  Kind of like the MTA calling out to SpamAssassin
at various points in the SMTP protocol.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcer3EjvBPtnXfVAQKK5wP/fjgFY1rBOErUXr1y154MUSylRYGzEu7K
DqETUMsH/DuBB7Q+AUYxIeM0uS245p2jffGbWPI9pHl6Ysvb8NKo9tV+yMLlLaYs
GhyUZC29fBejqQI5EwvmDlWHSfXwku8S4yk7CFS2jnkOyfme0XMBwKj8YcLZ06aL
GdUMyKHq9XU=
=/bQu
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun  7 20:49:18 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 14:49:18 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <2BA1161BA40C5F4AB7BF8FB8@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
	<20060607141852.41f12e4c@resist.wooz.org>
	<2BA1161BA40C5F4AB7BF8FB8@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060607144918.2e3c80d9@resist.wooz.org>

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

On Wed, 07 Jun 2006 19:44:51 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> How about "return to sender"? That is what you'd say in the real
> world with snail mail. Better might be "return to purported sender"
> or even "return to some poor guy who knows nothing about this
> email" ;)

:)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcfrnEjvBPtnXfVAQJ0tQP/Re/20m7I6W6/ooQY4MIjf6l9AtQTPJqu
Fbue60fvRTlggfcmraQDulRN9aqoSo9UuykqlYDXyUN0LCLL3+34dqG/EFXQBge5
asL2XFZy7pARS90VTbutN5y5E3BfrhWSlfX250AWPbhN3H4LIhjaqJJQFPgi2QBm
yJEY5N4mtTg=
=9CRp
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Wed Jun  7 20:59:56 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 07 Jun 2006 19:59:56 +0100
Subject: [Mailman-Developers] Mailman on a cluster
Message-ID: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>

Hi,

I'm looking at running Mailman on a cluster of servers, sharing a single 
disk with Apple XSan.

I presume that everything done through the web interface must be resilient 
to multiple simultaneous attempts to modify - say - a list membership. So, 
I expect that I can put the list databases on a shared file system.

But, what about the queue runners. Is it safe to share the queues between 
servers? If its safe to run multiple queue runners on one queue on one 
machine, then I should be OK - but I'm not sure that Mailman does that. If 
not, then I'm probably safer leaving the queues on unshared file systems, 
and accepting that a some queued items won't get processed while a cluster 
member is unavailable.


-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Wed Jun  7 21:26:48 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 15:26:48 -0400
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060607152648.4200440a@resist.wooz.org>

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

On Wed, 07 Jun 2006 19:59:56 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> I'm looking at running Mailman on a cluster of servers, sharing a
> single disk with Apple XSan.
> 
> I presume that everything done through the web interface must be
> resilient to multiple simultaneous attempts to modify - say - a list
> membership. So, I expect that I can put the list databases on a
> shared file system.

Mailman's locking scheme is NFS-safe, and should be safe on all shared
files systems that support POSIX semantics.  Given this, there should
be no race conditions against the list databases, through any of the
access mechanisms. Just make sure that if you have really huge lists,
your cgi timeouts are set appropriately or your web server could kill
the Mailman cgis while they wait for some other process's list lock to
be released (this is the case even if you weren't clustered).  Make
sure your list lock timeouts are set appropriately too because you
really don't want them getting broken.

> But, what about the queue runners. Is it safe to share the queues
> between servers? If its safe to run multiple queue runners on one
> queue on one machine, then I should be OK - but I'm not sure that
> Mailman does that. If not, then I'm probably safer leaving the queues
> on unshared file systems, and accepting that a some queued items
> won't get processed while a cluster member is unavailable.

This should be safe too.  Mailman uses a sha1 hash space slicing
algorithm to ensure that each qfile is managed by exactly one qrunner
process.  No locking is required as long as you configure your slices
appropriately.  It's still the case though that should a cluster member
go down, that portion of the hash space managed by those qrunners won't
get processed.  It should be fairly easy to reconfigure a backup though
to handle the hash space while the primary is off-line.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcoeHEjvBPtnXfVAQKRSwP/ezLkaIFz2DHCxbW4fjqL2BIqlI4NTDcp
kYt0kF+yGOBpVP9lYTrg2trAOZAXvaXPO8NZ0ujbO9ffKgTspKt10f4m+Oma/pm6
TMRRgo1Gp5GkImzYVrWXgywAg5jmXngSLcaxsbKej54pHKwv1uj01kRYNu7jrTJI
RjJiB70mtJA=
=iSah
-----END PGP SIGNATURE-----

From Dale at Newfield.org  Wed Jun  7 21:32:49 2006
From: Dale at Newfield.org (Dale Newfield)
Date: Wed, 07 Jun 2006 22:32:49 +0300
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
Message-ID: <448729E1.50507@Newfield.org>

Ian Eiloart wrote:
> I'm looking at running Mailman on a cluster of servers, sharing a single 
> disk with Apple XSan.

Barry, none of the bdb stuff you were working on is in the 2.1 tree, is 
it?  bdb does not guarantee acid properties over networked file systems...

-Dale Newfield
  Dale at Newfield.org

From fil at rezo.net  Wed Jun  7 21:53:41 2006
From: fil at rezo.net (Fil)
Date: Wed, 7 Jun 2006 21:53:41 +0200
Subject: [Mailman-Developers] archiving size issue
Message-ID: <20060607195341.GR14428@rezo.net>


Hello,

my server's drive is saturated now and my problem #1 is with the
mailing-list archives. I have a total of 5GB of archives in .mbox format...
which make a whopping 12GB when you add the html-generated archives.

This makes me think that we might have room for improvement here... either
to "archive on another computer" (using ssh maybe?), or to generate the
archive HTML pages on the fly (with proper caching of the thread structure
of course). It would also help a lot if the Message-Id were part of the url,
I think. I'm not looking for a solution, but hints would already be great.

-- Fil


From barry at python.org  Wed Jun  7 21:54:53 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 15:54:53 -0400
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <448729E1.50507@Newfield.org>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
	<448729E1.50507@Newfield.org>
Message-ID: <20060607155453.020d4694@resist.wooz.org>

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

On Wed, 07 Jun 2006 22:32:49 +0300
Dale Newfield <Dale at Newfield.org> wrote:

> Ian Eiloart wrote:
> > I'm looking at running Mailman on a cluster of servers, sharing a
> > single disk with Apple XSan.
> 
> Barry, none of the bdb stuff you were working on is in the 2.1 tree,
> is it?  bdb does not guarantee acid properties over networked file
> systems...

I just did a quick poke around the svn repository and I think you're
right. IIRC, they were cvs rm'd quite a while ago, so it's possible
they can be resurrected with the right Subversion magic.  I wouldn't
put much faith in them though -- does anybody (other than
Sleepycat^H^H^H^H^H^H^H^H^H^HOracle) really know how to write robust
and reliable BDB systems? ;)

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcvDnEjvBPtnXfVAQJK6gP/fo8llEMr0nLxLKBMktDriJrTNYg6qN9/
msR6RAfgRKt74/2ES/lOBfSSf2Mid9KyiI+5VfZlR/Jg3R07aHBKAkNPrsUFyo1o
x70Zhsp+kOFlZp4XPBKdUsU9ItU+h0U11wgbvCNBiQPXAGcG8lorFhPdR7h+6qry
9107kpZTUDU=
=ovYc
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jun  7 22:06:22 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 16:06:22 -0400
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <20060607195341.GR14428@rezo.net>
References: <20060607195341.GR14428@rezo.net>
Message-ID: <20060607160622.4f0fe1cd@resist.wooz.org>

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

On Wed, 7 Jun 2006 21:53:41 +0200
Fil <fil at rezo.net> wrote:

> my server's drive is saturated now and my problem #1 is with the
> mailing-list archives. I have a total of 5GB of archives in .mbox
> format... which make a whopping 12GB when you add the html-generated
> archives.
> 
> This makes me think that we might have room for improvement here...
> either to "archive on another computer" (using ssh maybe?), or to
> generate the archive HTML pages on the fly (with proper caching of
> the thread structure of course). It would also help a lot if the
> Message-Id were part of the url, I think. I'm not looking for a
> solution, but hints would already be great.

Ultimately, I think generating the archive html on the fly is the right
way to go.  That approach provides so many possible benefits at the
mere <wink> cost of cpu time.  When the original archive system was
designed, that cost was too high, and thus we have the static page
rendering approach.  But today I think the tradeoff tips in the other
direction.

Also, the mbox file is really only needed these days in order to regen
your archive, but that's fraught with pain anyway because there's no
guarantee (in fact a pretty good anti-guarantee) that your message urls
will be the same after regeneration.  So yes, a predictable and
reproducible message url is part of the solution.

As I always say when this topic comes up, I'd love to have some
motivated developers come forward to help with an archiver redesign, so
if you're interested in doing work here, let me know!

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIcxw3EjvBPtnXfVAQLdzAQAuLrOQwkiAo0SN3YwmzZ7K/8cocvxIf05
iZNJ5zq7koIjjcF4cSR/cxbVey543NIz+SBR7HeG4gZ6C7ZrZ7SSgXo+c7o+d2BL
RA5B347arj3IOmFlW64STotGE4dKzBPdDRMTK/Px4Z8g22Hs6ntntGv78uQ2wDm3
IerVcP7TMuY=
=DoDP
-----END PGP SIGNATURE-----

From bob at nleaudio.com  Wed Jun  7 23:02:01 2006
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Wed, 07 Jun 2006 17:02:01 -0400
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <20060607160622.4f0fe1cd@resist.wooz.org>
References: <20060607195341.GR14428@rezo.net>
	<20060607160622.4f0fe1cd@resist.wooz.org>
Message-ID: <44873EC9.5070108@nleaudio.com>

Umm, may I humbly request there be an option NOT to dynamically generate them?? :-)  One of my boxes 
gets git hard by people reading the archives, and I also run ht:dig to comb through the files every 
night, which would be a bit different with a database format.  I already have boxes that slow down 
to a crawl by those CMS database-driven apps!

Bob

Barry Warsaw wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 7 Jun 2006 21:53:41 +0200
> Fil <fil at rezo.net> wrote:
> 
> 
>>my server's drive is saturated now and my problem #1 is with the
>>mailing-list archives. I have a total of 5GB of archives in .mbox
>>format... which make a whopping 12GB when you add the html-generated
>>archives.
>>
>>This makes me think that we might have room for improvement here...
>>either to "archive on another computer" (using ssh maybe?), or to
>>generate the archive HTML pages on the fly (with proper caching of
>>the thread structure of course). It would also help a lot if the
>>Message-Id were part of the url, I think. I'm not looking for a
>>solution, but hints would already be great.
> 
> 
> Ultimately, I think generating the archive html on the fly is the right
> way to go.  That approach provides so many possible benefits at the
> mere <wink> cost of cpu time.  When the original archive system was
> designed, that cost was too high, and thus we have the static page
> rendering approach.  But today I think the tradeoff tips in the other
> direction.
> 
> Also, the mbox file is really only needed these days in order to regen
> your archive, but that's fraught with pain anyway because there's no
> guarantee (in fact a pretty good anti-guarantee) that your message urls
> will be the same after regeneration.  So yes, a predictable and
> reproducible message url is part of the solution.
> 
> As I always say when this topic comes up, I'd love to have some
> motivated developers come forward to help with an archiver redesign, so
> if you're interested in doing work here, let me know!
> 
> - -Barry
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> 
> iQCVAwUBRIcxw3EjvBPtnXfVAQLdzAQAuLrOQwkiAo0SN3YwmzZ7K/8cocvxIf05
> iZNJ5zq7koIjjcF4cSR/cxbVey543NIz+SBR7HeG4gZ6C7ZrZ7SSgXo+c7o+d2BL
> RA5B347arj3IOmFlW64STotGE4dKzBPdDRMTK/Px4Z8g22Hs6ntntGv78uQ2wDm3
> IerVcP7TMuY=
> =DoDP
> -----END PGP SIGNATURE-----
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
> 
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
> 

From barry at python.org  Thu Jun  8 00:10:51 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 7 Jun 2006 18:10:51 -0400
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <44873EC9.5070108@nleaudio.com>
References: <20060607195341.GR14428@rezo.net>
	<20060607160622.4f0fe1cd@resist.wooz.org>
	<44873EC9.5070108@nleaudio.com>
Message-ID: <20060607181051.085729d4@resist.wooz.org>

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

On Wed, 07 Jun 2006 17:02:01 -0400
"Bob Puff at NLE" <bob at nleaudio.com> wrote:

> Umm, may I humbly request there be an option NOT to dynamically
> generate them?? :-)  One of my boxes gets git hard by people reading
> the archives, and I also run ht:dig to comb through the files every
> night, which would be a bit different with a database format.  I
> already have boxes that slow down to a crawl by those CMS
> database-driven apps!

:)

Hopefully caching will help, but don't worry.  It's much more likely
that nothing will change. :)

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIdO63EjvBPtnXfVAQKadAP/fZ9XZ/IoLSLB1U0o5RtsbwhG6frxPmiX
/5NM0FsY7JJnDGBEDkUal0AHAUpDb1yMmiojm2OIA8zt41kkgj/0WxWWTBdFXTFG
p1ov1fcGZCkhlLoKEdlD8h8OEmNz/StfSJZvQAdJQdkExhSqzKCfRK/hXR9gjC++
y6/RLhjSDKw=
=ines
-----END PGP SIGNATURE-----

From brad at stop.mail-abuse.org  Thu Jun  8 06:28:30 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 23:28:30 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607141852.41f12e4c@resist.wooz.org>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<FF123E66FF6ED4311CA18F4A@lewes.staff.uscs.susx.ac.uk>
	<20060607141852.41f12e4c@resist.wooz.org>
Message-ID: <p06200700c0ad5737b87a@[10.0.1.210]>

At 2:18 PM -0400 2006-06-07, Barry Warsaw wrote:

>                                                         To me "reject"
>  is better than "bounce".  Has anybody seen any comments on this issue
>  on mailman-users?

	Reject is the correct term.  Ian misunderstood what you're 
talking about, and got off on the wrong track.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 06:34:57 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 23:34:57 -0500
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <448729E1.50507@Newfield.org>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
	<448729E1.50507@Newfield.org>
Message-ID: <p06200702c0ad59212b60@[10.0.1.210]>

At 10:32 PM +0300 2006-06-07, Dale Newfield wrote:

>  Ian Eiloart wrote:
>>  I'm looking at running Mailman on a cluster of servers, sharing a single
>>  disk with Apple XSan.
>
>  Barry, none of the bdb stuff you were working on is in the 2.1 tree, is
>  it?  bdb does not guarantee acid properties over networked file systems...

	My understanding is that Berkeley db doesn't work at all on NFS, 
because it uses mmap to handle access to the database files, and mmap 
on NFS is an undefined operation.  This is the same problem that 
people wanting to use Cyrus on NFS face, for the same reason -- 
Berkely db on NFS doesn't work.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 06:36:51 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 23:36:51 -0500
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <20060607155453.020d4694@resist.wooz.org>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
	<448729E1.50507@Newfield.org>
	<20060607155453.020d4694@resist.wooz.org>
Message-ID: <p06200703c0ad5994461d@[10.0.1.210]>

At 3:54 PM -0400 2006-06-07, Barry Warsaw wrote:

>                                                          I wouldn't
>  put much faith in them though -- does anybody (other than
>  Sleepycat^H^H^H^H^H^H^H^H^H^HOracle) really know how to write robust
>  and reliable BDB systems? ;)

	Well, I'm pretty sure that Eric Allman can, since he worked 
closely with those guys back when he was at UCB, and he also spent 
some time writing the original Postgres database.

	But one positive example does not prove a trend.  ;)

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 06:38:43 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 23:38:43 -0500
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <20060607160622.4f0fe1cd@resist.wooz.org>
References: <20060607195341.GR14428@rezo.net>
	<20060607160622.4f0fe1cd@resist.wooz.org>
Message-ID: <p06200704c0ad59f15c02@[10.0.1.210]>

At 4:06 PM -0400 2006-06-07, Barry Warsaw wrote:

>  Ultimately, I think generating the archive html on the fly is the right
>  way to go.  That approach provides so many possible benefits at the
>  mere <wink> cost of cpu time.  When the original archive system was
>  designed, that cost was too high, and thus we have the static page
>  rendering approach.  But today I think the tradeoff tips in the other
>  direction.

	I think we need to have both solutions.  I have some really 
anemic machines running Mailman, and I can't imagine what they'd do 
if they had to generate HTML archives on the fly.

>  As I always say when this topic comes up, I'd love to have some
>  motivated developers come forward to help with an archiver redesign, so
>  if you're interested in doing work here, let me know!

	I can give some input and feedback based on my own experiences, 
but I'm not a developer.  ;(

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 06:32:01 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 7 Jun 2006 23:32:01 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607143528.1249af3f@resist.wooz.org>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
Message-ID: <p06200701c0ad5800e790@[10.0.1.210]>

At 2:35 PM -0400 2006-06-07, Barry Warsaw wrote:

>  Totally agree.  OTOH, don't most MTAs provide /some/ way to call
>  external programs on messages at various points in their workflow?

	Sendmail has milter, and that has now been brought into postfix 
(as of 2.3), but I can't speak for any other MTAs.  What would need 
to happen would be a custom program would have to be written for each 
MTA to interact with it in the way that MTA works, but which has a 
deep understanding of Mailman and the configuration for each list and 
recipient, and could effectively do a "dry run" for each message.

	Of course, this would have to happen after the 
anti-spam/anti-virus milters, and then some sites are going to use 
accept & scan techniques as opposed to milter, so there may need to 
be multiple different "MTA adapters", even for a particular MTA.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From iane at sussex.ac.uk  Thu Jun  8 13:20:56 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 12:20:56 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p06200701c0ad5800e790@[10.0.1.210]>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
Message-ID: <A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>



--On 7 June 2006 23:32:01 -0500 Brad Knowles <brad at stop.mail-abuse.org> 
wrote:

> At 2:35 PM -0400 2006-06-07, Barry Warsaw wrote:
>
>>  Totally agree.  OTOH, don't most MTAs provide /some/ way to call
>>  external programs on messages at various points in their workflow?
>
> 	Sendmail has milter, and that has now been brought into postfix (as of
> 2.3), but I can't speak for any other MTAs.  What would need to happen
> would be a custom program would have to be written for each MTA to
> interact with it in the way that MTA works, but which has a deep
> understanding of Mailman and the configuration for each list and
> recipient, and could effectively do a "dry run" for each message.

No, that's not true. What's required is that Mailman provide a simple API 
to allow MTA developers to ask Mailman whether a particular sender is 
permitted to post to the list. Holding rosters (a v3 proposal) in open 
databases would solve this problem - at least for Exim.

Although Mailman is capable of filtering on other factors, I don't think 
the number of cases is significant. However, it might be possible to extend 
the API to provide information on other list policies.

> 	Of course, this would have to happen after the anti-spam/anti-virus
> milters, and then some sites are going to use accept & scan techniques as
> opposed to milter, so there may need to be multiple different "MTA
> adapters", even for a particular MTA.

If an MTA is doing accept and scan, then none of this is relevant. If the 
MTA doesn't query Mailman BEFORE accepting the message, then there's never 
any point in doing it at all.

-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun  8 13:30:03 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 12:30:03 +0100
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <20060607152648.4200440a@resist.wooz.org>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
	<20060607152648.4200440a@resist.wooz.org>
Message-ID: <84136F8DF6C0AE5650F2B26B@lewes.staff.uscs.susx.ac.uk>



--On 7 June 2006 15:26:48 -0400 Barry Warsaw <barry at python.org> wrote:

>
>> I'm looking at running Mailman on a cluster of servers, sharing a
>> single disk with Apple XSan.
>>
>> I presume that everything done through the web interface must be
>> resilient to multiple simultaneous attempts to modify - say - a list
>> membership. So, I expect that I can put the list databases on a
>> shared file system.
>
> Mailman's locking scheme is NFS-safe, and should be safe on all shared
> files systems that support POSIX semantics.  Given this, there should
> be no race conditions against the list databases, through any of the
> access mechanisms. Just make sure that if you have really huge lists,
> your cgi timeouts are set appropriately or your web server could kill
> the Mailman cgis while they wait for some other process's list lock to
> be released (this is the case even if you weren't clustered).  Make
> sure your list lock timeouts are set appropriately too because you
> really don't want them getting broken.

That's good. It's an essential requirement that all the web servers see the 
same information.

>> But, what about the queue runners. Is it safe to share the queues
>> between servers? If its safe to run multiple queue runners on one
>> queue on one machine, then I should be OK - but I'm not sure that
>> Mailman does that. If not, then I'm probably safer leaving the queues
>> on unshared file systems, and accepting that a some queued items
>> won't get processed while a cluster member is unavailable.
>
> This should be safe too.  Mailman uses a sha1 hash space slicing
> algorithm to ensure that each qfile is managed by exactly one qrunner
> process.  No locking is required as long as you configure your slices
> appropriately.  It's still the case though that should a cluster member
> go down, that portion of the hash space managed by those qrunners won't
> get processed.  It should be fairly easy to reconfigure a backup though
> to handle the hash space while the primary is off-line.

OK, so I have to figure out how to configure the slices to avoid clashes, 
but still won't gain anything until I figure out a backup scheme. I have 
failover between cluster members, so that should be doable. On the other 
hand, I might just live with the downtime - cluster members don't tend to 
go off line for more than a few minutes.

Thanks Barry. I feel like I know what I'm doing now!

> - -Barry



-- 
Ian Eiloart
IT Services, University of Sussex

From t.d.lee at durham.ac.uk  Thu Jun  8 13:39:22 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Thu, 8 Jun 2006 12:39:22 +0100 (BST)
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060607092046.54b2a0a0@geddy.wooz.org>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
Message-ID: <Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>

On Wed, 7 Jun 2006, Barry Warsaw wrote:

> [...]
> It's just that we'll be redesigning the web u/i as part of the Google
> SoC project (don't worry, it's not a forgone conclusion that that work
> will be integrated into the mainline release).  As we redesign and
> rewrite, I think we should standardize on "Approve" for actions to be
> taken by the list administrator.
>
> [...]
> So I think the following terms should be used consistently (I'm not
> suggesting a mass rewrite to adhere to this):
>
> Approve
> Hold
> Reject
> Discard

Throwing another item into the pot...

... on May 19th I started a thread "sender-based authorisation".  In
summary, this is intended as a defence against spoof.  The incoming email
would carry a header (of first line in body) of something like:
   Authorised:  sender-pw

where "sender-pw" is associated with the (claimed) From-address.  This is
different from, but complementary to, "Approved: list-pw".

(See the thread itself for the gory detail.)

This thread seemed to be accepted in principle, and as a step towards the
"to-do" item.

Given that I'm just about to start on implementing this, it would be nice
to establish whether this sender-related word "Authorised" is the
appropriate word, or if there is something better.

Locally, we need to get moving on implementing this concept.  Whilst my
local code might get heavily replaced as future versions of Mailman
(re-)implement these ideas, it would nevertheless be useful, from the
persepctive of our users, to get the terminology agreed early on.)

-- 

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

From barry at python.org  Thu Jun  8 14:21:51 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 8 Jun 2006 08:21:51 -0400
Subject: [Mailman-Developers] Mailman on a cluster
In-Reply-To: <84136F8DF6C0AE5650F2B26B@lewes.staff.uscs.susx.ac.uk>
References: <F9A1901919FB16FE62657D4E@lewes.staff.uscs.susx.ac.uk>
	<20060607152648.4200440a@resist.wooz.org>
	<84136F8DF6C0AE5650F2B26B@lewes.staff.uscs.susx.ac.uk>
Message-ID: <097F701F-107B-47EE-9DD2-78149071D146@python.org>

On Jun 8, 2006, at 7:30 AM, Ian Eiloart wrote:
>
> OK, so I have to figure out how to configure the slices to avoid  
> clashes, but still won't gain anything until I figure out a backup  
> scheme. I have failover between cluster members, so that should be  
> doable. On the other hand, I might just live with the downtime -  
> cluster members don't tend to go off line for more than a few minutes.

In that case, the complexity of reconfiguring a backup may not be  
worth it.  The worst that will happen is that that machine's slice of  
messages will have to wait a few minutes before getting processed,  
and since mail delivery order is never guaranteed anyway (iow, the  
delay could have happened anywhere else along the trail), it's  
possible the delay in bringing the cluster member back up won't be  
noticeable.

>
> Thanks Barry. I feel like I know what I'm doing now!
>

That makes one of us! :)

-Barry


From barry at python.org  Thu Jun  8 14:48:28 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 8 Jun 2006 08:48:28 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
Message-ID: <0C0EBF15-6A6C-4663-96BE-732A877935D0@python.org>

On Jun 8, 2006, at 7:39 AM, David Lee wrote:
>
> Given that I'm just about to start on implementing this, it would  
> be nice
> to establish whether this sender-related word "Authorised" is the
> appropriate word, or if there is something better.
>
> Locally, we need to get moving on implementing this concept.   
> Whilst my
> local code might get heavily replaced as future versions of Mailman
> (re-)implement these ideas, it would nevertheless be useful, from the
> persepctive of our users, to get the terminology agreed early on.)
>

Seems reasonable (I should go back and re-read that thread, but I  
think I get the gist of it), except for the English-speaking world's  
inability to agree on the spelling of that word. :)  In the US, it's  
"Authorized".

I suppose you could accept both keywords.

-Barry


From brad at stop.mail-abuse.org  Thu Jun  8 15:52:26 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 8 Jun 2006 08:52:26 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
	<A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p06200708c0addaca8f3d@[192.168.1.101]>

At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote:

>  No, that's not true. What's required is that Mailman provide a simple API
>  to allow MTA developers to ask Mailman whether a particular sender is
>  permitted to post to the list. Holding rosters (a v3 proposal) in open
>  databases would solve this problem - at least for Exim.

	That's fine, for Exim.

>  Although Mailman is capable of filtering on other factors, I don't think
>  the number of cases is significant. However, it might be possible to extend
>  the API to provide information on other list policies.

	I disagree that it's not significant.  If you want to extend the 
"simple API" argument to other aspects of the filtering Mailman is 
capable of doing, that's fine.


	But you still have to have something to use that API to tell the 
MTA what it needs to know and when, and I don't think we can 
necessarily depend on the MTA authors to create that.  Maybe the Exim 
authors could and would do so quickly, but that's not the only MTA we 
have to concern ourselves with.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From iane at sussex.ac.uk  Thu Jun  8 16:26:25 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 15:26:25 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
Message-ID: <FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:

>  The incoming email
> would carry a header (of first line in body) of something like:
>    Authorised:  sender-pw
>
> where "sender-pw" is associated with the (claimed) From-address.  This is
> different from, but complementary to, "Approved: list-pw".

That's neither approval nor authorisation, it's authentication - proving 
that the person who used the email address also knew the password 
associated with it. It's far better to insist on authenticated SMTP for ALL 
message submission.

>
> Given that I'm just about to start on implementing this, it would be nice
> to establish whether this sender-related word "Authorised" is the
> appropriate word, or if there is something better.
>

I've had a look through that thread, and I'm not sure what you're trying to 
achieve. Generally, there are two aspects to deciding whether someone can 
post to a list: "authorisation" and "authentication".

Passwords are usually used for both, but it's far better to separate the 
functions. Knowledge of a personal password serves to authenticate you, but 
not to authorise you. Knowledge of a shared password is sometimes used for 
authorisation, but can't be used for authentication. Even for 
authorisation, passwords are extremely weak.



-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun  8 16:35:55 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 15:35:55 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p06200708c0addaca8f3d@[192.168.1.101]>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
	<A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
	<p06200708c0addaca8f3d@[192.168.1.101]>
Message-ID: <F1015388BBF016CE1B62012F@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 08:52:26 -0500 Brad Knowles <brad at stop.mail-abuse.org> 
wrote:

> At 12:20 PM +0100 2006-06-08, Ian Eiloart wrote:
>
>>  No, that's not true. What's required is that Mailman provide a simple
>>  API to allow MTA developers to ask Mailman whether a particular sender
>>  is permitted to post to the list. Holding rosters (a v3 proposal) in
>>  open databases would solve this problem - at least for Exim.
>
> 	That's fine, for Exim.
>
>>  Although Mailman is capable of filtering on other factors, I don't think
>>  the number of cases is significant. However, it might be possible to
>>  extend the API to provide information on other list policies.
>
> 	I disagree that it's not significant.  If you want to extend the "simple
> API" argument to other aspects of the filtering Mailman is capable of
> doing, that's fine.
>
>
> 	But you still have to have something to use that API to tell the MTA
> what it needs to know and when, and I don't think we can necessarily
> depend on the MTA authors to create that.  Maybe the Exim authors could
> and would do so quickly, but that's not the only MTA we have to concern
> ourselves with.

Well, that doesn't matter. Obviously no solution is going to work for *all* 
MTAs. Some couldn't work with *any* solution.

The thing is that if you decide that Mailman isn't going to share its data 
with anyone, then nobody can set up a Mailman system which doesn't generate 
collateral spam. I'm not suggesting that Mailman should relinquish its 
internal functionality, just that it should expose that functionality.

In fact, for exim, the MTA authors may have to do nothing, it might just be 
a matter of fixing the configuration. In fact, its conceivable that I could 
do that already, but I'd much rather know that Mailman developers had some 
kind of commitment to solving the collateral spam problem. And I'd like 
there to be a supported method for doing that (an API). At the moment, I 
ask my list administrators to NEVER automatically bounce (sorry, "reject") 
messages - and I don't think that's satisfactory.


-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Thu Jun  8 17:25:37 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 8 Jun 2006 11:25:37 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060608112537.6f2607e7@resist.wooz.org>

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

On Thu, 08 Jun 2006 15:26:25 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> > where "sender-pw" is associated with the (claimed) From-address.
> > This is different from, but complementary to, "Approved: list-pw".
> 
> That's neither approval nor authorisation, it's authentication -

That's a good point.

> Passwords are usually used for both, but it's far better to separate
> the functions. Knowledge of a personal password serves to
> authenticate you, but not to authorise you. Knowledge of a shared
> password is sometimes used for authorisation, but can't be used for
> authentication. Even for authorisation, passwords are extremely weak.

There has been some interest in the past on associating pubkeys with
email addresses and using those to authenticate senders of signed
messages.  In the long run, that's probably a worthy avenue to pursue.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIhBcnEjvBPtnXfVAQKZTwP/a0ULu7v8TQyrjAgI3Uj/znrsy+Kh24qp
ilmE3Y/E9YXiYaSwpgdrLIyIH4zODXspML8l4jnscOBNexlpKNqfY4ZA9ky2oKoI
x1YWDZmdVbrWyO5y3pN0bNOhQOkdiBqAs1STv5TP1VoN95eHQQrVlpGTMf6jTGll
ZBl3kfV7xrU=
=oLd8
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun  8 17:37:33 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 8 Jun 2006 11:37:33 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <F1015388BBF016CE1B62012F@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
	<A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
	<p06200708c0addaca8f3d@[192.168.1.101]>
	<F1015388BBF016CE1B62012F@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060608113733.135ff45a@resist.wooz.org>

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

On Thu, 08 Jun 2006 15:35:55 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> The thing is that if you decide that Mailman isn't going to share its
> data with anyone, then nobody can set up a Mailman system which
> doesn't generate collateral spam. I'm not suggesting that Mailman
> should relinquish its internal functionality, just that it should
> expose that functionality.

All of Mailman's functionality already /is/ exposed, although it may
not be in a format you are familiar and/or comfortable with.  I think a
lot of people don't get this, so it's important to emphasize.

Mailman is more than just open source.  Because it's written in Python,
even a deployed and operational system has complete access to Mailman's
implementation, not just its data.  Take a look at the command line
scripts some time.  There's really nothing special about them because
they use exactly the same exposed functionality as any MTA extension
would use.  The only thing special about them is that one of us wrote
it and it comes with Mailman.

It's not like your typical MTA written in C where if they don't expose
the right hooks, you're mostly SOL unless you can implement the hooks
yourself, recompile and redeploy the new binary.

Okay, you have to be a Python programmer and you probably have to
understand enough of Mailman to know what the consequences of your code
is, but that really isn't a huge hurdle (certainly the former isn't for
any experienced programmer and for the latter, that's why we're
here! :).

> In fact, for exim, the MTA authors may have to do nothing, it might
> just be a matter of fixing the configuration. In fact, its
> conceivable that I could do that already, but I'd much rather know
> that Mailman developers had some kind of commitment to solving the
> collateral spam problem. And I'd like there to be a supported method
> for doing that (an API). At the moment, I ask my list administrators
> to NEVER automatically bounce (sorry, "reject") messages - and I
> don't think that's satisfactory.

I certainly agree that the entire email stack has to be defensive about
collateral spam.  I do believe that scripts could be written that could
help an MTA make /some/ decisions about the disposition of an email
message lower down in that stack.  I'm not even opposed to distributing
some with Mailman that have a proven track record, nor am I opposed to
refactoring some code and "blessing" some APIs that make this job
easier with some guarantees of stability across releases.  But I'm not
going to write them. :) There really is nothing stopping anyone else
from starting to do that now, if you think about the problem in the
right way.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRIhEPXEjvBPtnXfVAQJC/wP+KCPhMYf4nDYRJx9/gH4f5T4dy5TjFb0q
AxvGWNNq7UZOisMQwnyF9VmEFDFBZDzAfCVttgDIRF27ZqTIDeMOdb8vayCmWk9T
n5Yj+oo6iPNsgsKGce07rXSHWFEVTqb1xx55Tcv8O0qshoBpLGmITQG+ueBQ/h/0
J2icggSEFB4=
=hiCr
-----END PGP SIGNATURE-----

From t.d.lee at durham.ac.uk  Thu Jun  8 17:54:40 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Thu, 8 Jun 2006 16:54:40 +0100 (BST)
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
Message-ID: <Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>

On Thu, 8 Jun 2006, Ian Eiloart wrote:

> --On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:
>
> >  The incoming email
> > would carry a header (of first line in body) of something like:
> >    Authorised:  sender-pw
> >
> > where "sender-pw" is associated with the (claimed) From-address.  This is
> > different from, but complementary to, "Approved: list-pw".
>
> That's neither approval nor authorisation, it's authentication - proving
> that the person who used the email address also knew the password
> associated with it. [...]

Thanks, Ian.  I agree with that technical view.  That suggests that the
header (of first line of body) would need to be something like:
   Authenticated:  sender-pw

To the average non-techie managerial type, what terminology (Authorised?
Authenticated? etc.) is preferable?


> [...] It's far better to insist on authenticated SMTP for ALL
> message submission.

That would, indeed, probably be the ideal.  But that would itself mean
that all paths by which the Mailman machine might be reached would have to
be known to have an enforced mechanism for authenticated SMTP.  (And what
about (say) "cron" jobs generating email which might legitimately go
through lists?)

An insitution's (university's) "smtphost" service might naturally restrict
access to its own users and thus the authentication could use, say, its
central NIS/AD/LDAP-like user-base.  But its Mailman service might extend
considerably beyond those bounds to include collaboration with other
places, for which a much wider user-base would be needed.  (Suppose, for
instance, that this very "mailman-developers" list were hosted at your own
university?)

Even if those problems could be overcome, one would still need to ensure
that Mailman can know for certain that authenticated SMTP had been used.
Which takes us off to another branch (about Mailan API, milters, etc.)
of this fragmenting discussion!...


>
> >
> > Given that I'm just about to start on implementing this, it would be nice
> > to establish whether this sender-related word "Authorised" is the
> > appropriate word, or if there is something better.
> >
>
> I've had a look through that thread, and I'm not sure what you're trying to
> achieve. Generally, there are two aspects to deciding whether someone can
> post to a list: "authorisation" and "authentication".
>
> Passwords are usually used for both, but it's far better to separate the
> functions. Knowledge of a personal password serves to authenticate you, but
> not to authorise you. Knowledge of a shared password is sometimes used for
> authorisation, but can't be used for authentication. Even for
> authorisation, passwords are extremely weak.

Agreed.  That earlier thread was simply setting the ball rolling.

The problem that precipitated that thread was an incident in which two
emails went through our majordomo lists to the whole university (20,000
accounts), because those emails spoofed the "From" to match an entry in
the "posters" file of those lists.  So we are looking towards protecting
these potentially massive distributions with a "From+verification"
concept.  (Hence our looking at Mailman, which looks much closer than
majordomo to being able to offer that, especially as it is being actively
developed.)

Thanks again.

-- 

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

From iane at sussex.ac.uk  Thu Jun  8 18:06:43 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 17:06:43 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <20060608113733.135ff45a@resist.wooz.org>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
	<A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
	<p06200708c0addaca8f3d@[192.168.1.101]>
	<F1015388BBF016CE1B62012F@lewes.staff.uscs.susx.ac.uk>
	<20060608113733.135ff45a@resist.wooz.org>
Message-ID: <C90467D6FD125C369528E584@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 11:37:33 -0400 Barry Warsaw <barry at python.org> wrote:

>
>> In fact, for exim, the MTA authors may have to do nothing, it might
>> just be a matter of fixing the configuration. In fact, its
>> conceivable that I could do that already, but I'd much rather know
>> that Mailman developers had some kind of commitment to solving the
>> collateral spam problem. And I'd like there to be a supported method
>> for doing that (an API). At the moment, I ask my list administrators
>> to NEVER automatically bounce (sorry, "reject") messages - and I
>> don't think that's satisfactory.
>
> I certainly agree that the entire email stack has to be defensive about
> collateral spam.  I do believe that scripts could be written that could
> help an MTA make /some/ decisions about the disposition of an email
> message lower down in that stack.  I'm not even opposed to distributing
> some with Mailman that have a proven track record, nor am I opposed to
> refactoring some code and "blessing" some APIs that make this job
> easier with some guarantees of stability across releases.  But I'm not
> going to write them. :) There really is nothing stopping anyone else
> from starting to do that now, if you think about the problem in the
> right way.

That's fair enough. I do have an idea about how to use a python script with 
Exim. I don't know enough to make it efficient, though. Maybe there's a 
problem with my python installation, or the way that I invoke it, but it 
seems that even a simple query takes four or five seconds to run:

rinka-12 # date ; /local/mailman/bin/list_members ian-test4 ; date
Thu Jun  8 16:47:09 BST 2006
foo at example.ac.uk
bar at example.ac.uk
baz at example.ac.uk
Thu Jun  8 16:47:13 BST 2006

But, it takes about 0.7 seconds to print "hello world", and truss shows a 
lot of files being opened just to get a list of members.

Now, my Exim installation makes up to about a dozen LDAP queries to deliver 
an email. The queries are cached, and my average time to deliver an email 
is a second or two - and that's including virus a spam scanning.

OK, maybe I should just get on and implement this. If Exim caches the 
results, then it's not going to be too bad.





-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun  8 18:18:33 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 17:18:33 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org> 
	<PC1740200606062202440490b107c516@msapiro> 
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
Message-ID: <043DD976975A1E62626E32AA@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:

> On Thu, 8 Jun 2006, Ian Eiloart wrote:
>
>> --On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:
>>
>> >  The incoming email
>> > would carry a header (of first line in body) of something like:
>> >    Authorised:  sender-pw
>> >
>> > where "sender-pw" is associated with the (claimed) From-address.  This
>> > is different from, but complementary to, "Approved: list-pw".
>>
>> That's neither approval nor authorisation, it's authentication - proving
>> that the person who used the email address also knew the password
>> associated with it. [...]
>
> Thanks, Ian.  I agree with that technical view.  That suggests that the
> header (of first line of body) would need to be something like:
>    Authenticated:  sender-pw
>
> To the average non-techie managerial type, what terminology (Authorised?
> Authenticated? etc.) is preferable?
>

Not "Authenticated". That implies that authentication has already occurred. 
What you're doing is supplying a token to be used for authentication. So, 
"Authentication" would be better. Or even "Password".

Oh, and if it's an email header, shouldn't it be X-Authentication, or 
whatever?

-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun  8 18:24:39 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 08 Jun 2006 17:24:39 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org> 
	<PC1740200606062202440490b107c516@msapiro> 
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
Message-ID: <B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:

>
>> [...] It's far better to insist on authenticated SMTP for ALL
>> message submission.
>
> That would, indeed, probably be the ideal.  But that would itself mean
> that all paths by which the Mailman machine might be reached would have to
> be known to have an enforced mechanism for authenticated SMTP.  (And what
> about (say) "cron" jobs generating email which might legitimately go
> through lists?)

Well, I guess that a typical Message Submission Agent would require 
authenticated SMTP *except* for a list of specificed (host IP, sender email 
address) pairs.

> An insitution's (university's) "smtphost" service might naturally restrict
> access to its own users and thus the authentication could use, say, its
> central NIS/AD/LDAP-like user-base.  But its Mailman service might extend
> considerably beyond those bounds to include collaboration with other
> places, for which a much wider user-base would be needed.  (Suppose, for
> instance, that this very "mailman-developers" list were hosted at your own
> university?)

True. But are you really asking people to email secrets around? If you are, 
them I presume you're going to encrypt communication between your MTAs? 
Otherwise none of this is going to gain you anything.

I presume you're going to have Mailman remove those tokens before delivery? 
Otherwise spoofing will be just as easy as before. To be honest, I'm 
skeptical about all of this. Do you have a history of people spoofing to 
your lists?

> Even if those problems could be overcome, one would still need to ensure
> that Mailman can know for certain that authenticated SMTP had been used.
> Which takes us off to another branch (about Mailan API, milters, etc.)
> of this fragmenting discussion!...



-- 
Ian Eiloart
IT Services, University of Sussex

From brad at stop.mail-abuse.org  Thu Jun  8 20:20:20 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 8 Jun 2006 13:20:20 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p06200709c0ae1831f34f@[192.168.1.101]>

At 3:26 PM +0100 2006-06-08, Ian Eiloart wrote:

>>  where "sender-pw" is associated with the (claimed) From-address.  This is
>>  different from, but complementary to, "Approved: list-pw".
>
>  That's neither approval nor authorisation, it's authentication - proving
>  that the person who used the email address also knew the password
>  associated with it. It's far better to insist on authenticated SMTP for ALL
>  message submission.

	For the application that David is looking at, "Authorized" would 
probably be the most appropriate term.

>  I've had a look through that thread, and I'm not sure what you're trying to
>  achieve. Generally, there are two aspects to deciding whether someone can
>  post to a list: "authorisation" and "authentication".

	David is looking for a way to do a per-sender way of using the 
existing "Approved:" mechanism, without having to share the list 
password across a large number of senders.  Each user would get their 
own password that would achieve the same result.

	But otherwise, there should be no additional security exposure, 
and no change to the security threat model.

>  Passwords are usually used for both, but it's far better to separate the
>  functions. Knowledge of a personal password serves to authenticate you, but
>  not to authorise you. Knowledge of a shared password is sometimes used for
>  authorisation, but can't be used for authentication. Even for
>  authorisation, passwords are extremely weak.

	This is a debate best reserved for discussing the entire 
"Approved:" mechanism as a whole, as opposed to something that David 
should have to try to fix as a part of the extension work that he is 
looking at.

	There are lots of deeper technical and architectural details here 
that need to be addressed, and I think that's more appropriate to ask 
Barry, Tokio, and Mark to look into those issues as opposed to David.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 20:26:03 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 8 Jun 2006 13:26:03 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
Message-ID: <p0620070ac0ae1ba0c164@[192.168.1.101]>

At 4:54 PM +0100 2006-06-08, David Lee wrote:

>  To the average non-techie managerial type, what terminology (Authorised?
>  Authenticated? etc.) is preferable?

	I think that the authentication thing is a red herring.  Stick to 
the original idea and make relatively minimal modifications to the 
code, and let Barry, Tokio, Mark, and others deal with the deeper 
technical and architectural issues that Ian is raising.

>  That would, indeed, probably be the ideal.  But that would itself mean
>  that all paths by which the Mailman machine might be reached would have to
>  be known to have an enforced mechanism for authenticated SMTP.  (And what
>  about (say) "cron" jobs generating email which might legitimately go
>  through lists?)

	Which is part of why you shouldn't worry about trying to solve 
this problem.  With your original concept, you're not really opening 
any new security holes, and you shouldn't have to worry about trying 
to close those that already exist.

	Just make sure that you put in the appropriate cleanup code into 
place to remove the headers in question, as is done today for the 
"Approved:" header.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From brad at stop.mail-abuse.org  Thu Jun  8 20:40:03 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 8 Jun 2006 13:40:03 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org> 
	<PC1740200606062202440490b107c516@msapiro> 
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p0620070bc0ae1c4ce9b5@[192.168.1.101]>

At 5:24 PM +0100 2006-06-08, Ian Eiloart wrote:

>  Well, I guess that a typical Message Submission Agent would require
>  authenticated SMTP *except* for a list of specificed (host IP, sender email
>  address) pairs.

	Mailman is not an MTA or an MSA.  It makes use of MTAs and MSAs, 
but it is neither of these things itself.  Therefore, it's not 
appropriate to ask David to fix MTA and MSA problems with respect to 
the code he's trying to add to Mailman.

>  True. But are you really asking people to email secrets around? If you are,
>  them I presume you're going to encrypt communication between your MTAs?
>  Otherwise none of this is going to gain you anything.

	The only thing that's secret is the password used to authorize 
their ability to post to the list.

>  I presume you're going to have Mailman remove those tokens before delivery?

	I'm sure.

>  Otherwise spoofing will be just as easy as before. To be honest, I'm
>  skeptical about all of this. Do you have a history of people spoofing to
>  your lists?

	Yes.  Please re-read the thread.  Using the "Approved:" mechanism 
will prevent future spoofing, but brings along a whole host of other 
problems, such as having to share the list password with all the 
potential senders, which increases the security exposure due to the 
probability of the password being accidentally exposed.  Then there 
is the issue of having to change the shared list password, and having 
to have everyone memorize the new shared password.

	Using a per-sender password for the same mechanism will prevent 
the spoofing, eliminate the probability of accidentally exposing the 
shared password, and make recovery from accidental exposure of a 
password much easier -- only the one user will be affected by having 
to change and remember the new password.


	Some additional code will have to be added to handle the addition 
of storing a per-user "Authorized" password, and a per-user 
authorization/approval mechanism (akin to the list of 
approved_nonmembers), as well as a cleanup mechanism to try and 
ensure sure that the new password doesn't get inadvertently exposed 
by Mailman.

	But extending the existing "Approved:" mechanism is clearly the 
way to approach this problem.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From t.d.lee at durham.ac.uk  Fri Jun  9 10:47:27 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Fri, 9 Jun 2006 09:47:27 +0100 (BST)
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <043DD976975A1E62626E32AA@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<043DD976975A1E62626E32AA@lewes.staff.uscs.susx.ac.uk>
Message-ID: <Pine.GSO.4.58.0606090938080.11090@arachne.dur.ac.uk>

On Thu, 8 Jun 2006, Ian Eiloart wrote:

> --On 8 June 2006 16:54:40 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:
>
> > On Thu, 8 Jun 2006, Ian Eiloart wrote:
> >
> >> --On 8 June 2006 12:39:22 +0100 David Lee <t.d.lee at durham.ac.uk> wrote:
> >>
> >> >  The incoming email
> >> > would carry a header (of first line in body) of something like:
> >> >    Authorised:  sender-pw
> >> >
> >> > where "sender-pw" is associated with the (claimed) From-address.  This
> >> > is different from, but complementary to, "Approved: list-pw".
> >>
> >> That's neither approval nor authorisation, it's authentication - proving
> >> that the person who used the email address also knew the password
> >> associated with it. [...]
> >
> > Thanks, Ian.  I agree with that technical view.  That suggests that the
> > header (of first line of body) would need to be something like:
> >    Authenticated:  sender-pw
> >
> > To the average non-techie managerial type, what terminology (Authorised?
> > Authenticated? etc.) is preferable?
> >
>
> Not "Authenticated". That implies that authentication has already occurred.
> What you're doing is supplying a token to be used for authentication. So,
> "Authentication" would be better. Or even "Password".

I had picked on the past-tense terminology ("Authorised", "Authenticated",
etc.) simply because the FAQ talks about an "Approved" (past tense)
header.  But I believe the code also accepts (present tense) "Approve".
So I had antcipated that my proposal would be similarly tense-tolerant!

> Oh, and if it's an email header, shouldn't it be X-Authentication, or
> whatever?

Two consistency trends pulling in opposite directions!

1. RFC-ish things suggest "X-Whatever:".

2. Mailman practice (the existing "Approved") suggests "Whatever:".

I was assuming I should follow the Mailman convention.  (Whether the
Mailman convention needs revision is another matter...)


-- 

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

From t.d.lee at durham.ac.uk  Fri Jun  9 10:59:37 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Fri, 9 Jun 2006 09:59:37 +0100 (BST)
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p0620070ac0ae1ba0c164@[192.168.1.101]>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<p0620070ac0ae1ba0c164@[192.168.1.101]>
Message-ID: <Pine.GSO.4.58.0606090950150.11090@arachne.dur.ac.uk>

On Thu, 8 Jun 2006, Brad Knowles wrote:

> At 4:54 PM +0100 2006-06-08, David Lee wrote:
>
> >  To the average non-techie managerial type, what terminology (Authorised?
> >  Authenticated? etc.) is preferable?
>
> 	I think that the authentication thing is a red herring.  Stick to
> the original idea and make relatively minimal modifications to the
> code, and let Barry, Tokio, Mark, and others deal with the deeper
> technical and architectural issues that Ian is raising.
>
> >  That would, indeed, probably be the ideal.  But that would itself mean
> >  that all paths by which the Mailman machine might be reached would have to
> >  be known to have an enforced mechanism for authenticated SMTP.  (And what
> >  about (say) "cron" jobs generating email which might legitimately go
> >  through lists?)
>
> 	Which is part of why you shouldn't worry about trying to solve
> this problem.  With your original concept, you're not really opening
> any new security holes, and you shouldn't have to worry about trying
> to close those that already exist.
>
> 	Just make sure that you put in the appropriate cleanup code into
> place to remove the headers in question, as is done today for the
> "Approved:" header.

Thanks, Brad, for this and your previous emails.  Your have nicely grasped
both sides:

(1) that this piece of string could be very long, and is an issue
primarily for the Mailman development gurus in a global and relatively
long timescale, context;

(2) that my own particular per-sender password proposal is intended to be
a small, self-contained thing, modelled on the existing "Approved:", and
with a very similar set of security issues (positive and negative), in a
local, short timescale, context.

It's giving me the confidence to go ahead on this item, but I hope to keep
in mind compatibility with (anticipation of) possible future developments.

Thanks again.


-- 

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

From iane at sussex.ac.uk  Fri Jun  9 12:06:08 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 09 Jun 2006 11:06:08 +0100
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p0620070bc0ae1c4ce9b5@[192.168.1.101]>
References: <20060606234945.0f135eb8@geddy.wooz.org> 
	<PC1740200606062202440490b107c516@msapiro> 
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>
	<p0620070bc0ae1c4ce9b5@[192.168.1.101]>
Message-ID: <437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>



--On 8 June 2006 13:40:03 -0500 Brad Knowles <brad at stop.mail-abuse.org> 
wrote:

> At 5:24 PM +0100 2006-06-08, Ian Eiloart wrote:
>
>>  Well, I guess that a typical Message Submission Agent would require
>>  authenticated SMTP *except* for a list of specificed (host IP, sender
>>  email address) pairs.
>
> 	Mailman is not an MTA or an MSA.  It makes use of MTAs and MSAs, but it
> is neither of these things itself.  Therefore, it's not appropriate to
> ask David to fix MTA and MSA problems with respect to the code he's
> trying to add to Mailman.

I'm not asking him to do that. I'm talking about the ecology of the 
situation.

>>  True. But are you really asking people to email secrets around? If you
>>  are, them I presume you're going to encrypt communication between your
>>  MTAs? Otherwise none of this is going to gain you anything.
>
> 	The only thing that's secret is the password used to authorize their
> ability to post to the list.

Yes, that's the secret that I'm talking about.

>>  I presume you're going to have Mailman remove those tokens before
>>  delivery?
>
> 	I'm sure.
>
>>  Otherwise spoofing will be just as easy as before. To be honest, I'm
>>  skeptical about all of this. Do you have a history of people spoofing to
>>  your lists?
>
> 	Yes.  Please re-read the thread.  Using the "Approved:" mechanism will
> prevent future spoofing, but brings along a whole host of other problems,
> such as having to share the list password with all the potential senders,
> which increases the security exposure due to the probability of the
> password being accidentally exposed.  Then there is the issue of having
> to change the shared list password, and having to have everyone memorize
> the new shared password.
>
> 	Using a per-sender password for the same mechanism will prevent the
> spoofing,

Only if you ensure that the entire email transmission chain is encrypted. 
That's only possible if you know the sender is on-site (on your campus, in 
your company, whatever). If that's true, then you can rely on authenticated 
SMTP anyway.

> eliminate the probability of accidentally exposing the shared
> password, and make recovery from accidental exposure of a password much
> easier -- only the one user will be affected by having to change and
> remember the new password.
>
>
> 	Some additional code will have to be added to handle the addition of
> storing a per-user "Authorized" password, and a per-user
> authorization/approval mechanism (akin to the list of
> approved_nonmembers), as well as a cleanup mechanism to try and ensure
> sure that the new password doesn't get inadvertently exposed by Mailman.
>
> 	But extending the existing "Approved:" mechanism is clearly the way to
> approach this problem.



-- 
Ian Eiloart
IT Services, University of Sussex

From fil at rezo.net  Fri Jun  9 15:43:35 2006
From: fil at rezo.net (Fil)
Date: Fri, 9 Jun 2006 15:43:35 +0200
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <20060607181051.085729d4@resist.wooz.org>
References: <20060607195341.GR14428@rezo.net>
	<20060607160622.4f0fe1cd@resist.wooz.org>
	<44873EC9.5070108@nleaudio.com>
	<20060607181051.085729d4@resist.wooz.org>
Message-ID: <20060609134330.GN18418@rezo.net>

To continue this thread I decided to start splitting the big listname.mbox
files into something like
        archives/private/listname.mbox/listname-2006-06.mbox

This will enable compression of the older mboxes, and proper archival
without copying the whole 5Gb of archive each night.

The patch would be, in Archiver.py:


+import time

-                            self.internal_name() + '.mbox')
+                            self.internal_name() + time.strftime('-%Y-%m') + '.mbox')


Do you think there can be some unintended consequence? I don't allow
downloading of the raw .mbox file.

-- Fil


From msapiro at value.net  Fri Jun  9 15:59:24 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 9 Jun 2006 06:59:24 -0700
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>
Message-ID: <PC1740200606090659240500a26eb9ac@msapiro>

Ian Eiloart wrote:
>
>--On 8 June 2006 13:40:03 -0500 Brad Knowles <brad at stop.mail-abuse.org> 
>wrote:
>>
>> 	Using a per-sender password for the same mechanism will prevent the
>> spoofing,
>
>Only if you ensure that the entire email transmission chain is encrypted. 
>That's only possible if you know the sender is on-site (on your campus, in 
>your company, whatever). If that's true, then you can rely on authenticated 
>SMTP anyway.


This thread has probably been flogged to death already, and my initial
deletion of this post was probably the correct decision rather than
now resurrecting it from the archive for this reply, but I just want
to add from the point of view of an interested observer, that I think
we all know that sending the list password in a header of an
unencrypted message is not very secure, and neither will this be
secure against some kinds of attacks, but at least this proposal
potentially exposes a less powerful password.

David is only trying to address a very limited kind of attack. He has
multiple lists each with multiple authorized posters (but still a tiny
fraction of the list membership - these are basically announcement
lists). He is trying to protect the list from a list member's
determining by observation who the authorized posters are and spoofing
one of those addresses to mail to the list. This is a situation that
has occurred for him (at least twice, I think he said).

If this were one list with one or two authorized posters, he could
moderate everyone, and the authorized poster could use the Approved:
header to post, but this is too cumbersome in his environment unless
he made all the list passwords the same which is neither practical nor
wise. So, he wants to extend the existing method to one which allows
the authorized posters to post with a personal password.

We all know that this is not secure against all attacks, but David
feels that it will be good enough for his situation.

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


From brad at stop.mail-abuse.org  Fri Jun  9 16:01:31 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 9 Jun 2006 09:01:31 -0500
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org> 
	<PC1740200606062202440490b107c516@msapiro> 
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>
	<p0620070bc0ae1c4ce9b5@[192.168.1.101]>
	<437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>
Message-ID: <p06200700c0af2f3558b8@[192.168.1.101]>

At 11:06 AM +0100 2006-06-09, Ian Eiloart wrote:

>>  	Using a per-sender password for the same mechanism will prevent the
>>  spoofing,
>
>  Only if you ensure that the entire email transmission chain is encrypted.

	Using the existing "Approved:" mechanism would also prevent the 
spoofing, and would have the same exposures regarding encryption.

	We're not trying to fix all of the security problems in Mailman, 
we're just trying to take an existing mechanism (with known 
vulnerabilities) and extend that to work in a per-sender manner.

>  That's only possible if you know the sender is on-site (on your campus,
>  in your company, whatever). If that's true, then you can rely on
>  authenticated SMTP anyway.

	Red Herring.  We're not trying to fix all the possible security 
problems in Mailman.  That's a job for Barry, Tokio, Mark, and others.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From msapiro at value.net  Fri Jun  9 16:26:53 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 9 Jun 2006 07:26:53 -0700
Subject: [Mailman-Developers] archiving size issue
In-Reply-To: <20060609134330.GN18418@rezo.net>
Message-ID: <PC1740200606090726530375852948ac@msapiro>

Fil wrote:

>To continue this thread I decided to start splitting the big listname.mbox
>files into something like
>        archives/private/listname.mbox/listname-2006-06.mbox
<snip>
>
>Do you think there can be some unintended consequence? I don't allow
>downloading of the raw .mbox file.


Unless you've done something specific to prevent it, private.py will
always serve the listname.mbox/listname.mbox file whether or not
PUBLIC_MBOX = No.

Your change will stop all private.py access to .mbox files unless
changes are also made to private.py, because it currently only
recognizes the specific name 'listname.mbox/listname.mbox' as a .mbox
file. This may be a good or a bad thing depending on your point of
view.

Also, this will require changes if PUBLIC_MBOX = Yes to account for
multiple .mbox files. It might be worth considering replacing the
existing, monthly .txt files with the monthly .mbox files, but there
are issues here too regarding both exposing the full .mbox information
and the fact that with the suggested change, messages can be in one
month's archive and a different month's .mbox.

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


From barry at python.org  Fri Jun  9 17:32:48 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 9 Jun 2006 11:32:48 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <p06200700c0af2f3558b8@[192.168.1.101]>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<B9ADD1F43058CABA50155D7D@lewes.staff.uscs.susx.ac.uk>
	<p0620070bc0ae1c4ce9b5@[192.168.1.101]>
	<437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>
	<p06200700c0af2f3558b8@[192.168.1.101]>
Message-ID: <20060609113248.4448e079@resist.wooz.org>

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

On Fri, 9 Jun 2006 09:01:31 -0500
Brad Knowles <brad at stop.mail-abuse.org> wrote:

> 	Using the existing "Approved:" mechanism would also prevent
> the spoofing, and would have the same exposures regarding encryption.

Actually, that might be the right approach here.  Just use the existing
Approved header, but instead of checking it only against the list admin
password, check it against the user's password too.  In fact do that
first, falling back to the list admin password only if that fails.

No new header necessary.  Think 'sudo'.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRImUoHEjvBPtnXfVAQLTQQQAsstiGXz2mfDtK5hBBJeOrwftrcs3+/xo
QkNmjvSnVXyNqFMXQRhLcVB8o1PsJhPTTfXnDHRBwamK7Fow8RYlmNjF7g/QHMMu
jo7Zv1JtR+IYVJPm16DmPPhZJHPlWtenB2eWbu2ZB4WjChrHYzDQFg6GXyiwFFSo
lpMknsjNsMA=
=3UHn
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jun  9 17:12:19 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 9 Jun 2006 11:12:19 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <Pine.GSO.4.58.0606090938080.11090@arachne.dur.ac.uk>
References: <20060606234945.0f135eb8@geddy.wooz.org>
	<PC1740200606062202440490b107c516@msapiro>
	<20060607092046.54b2a0a0@geddy.wooz.org>
	<Pine.GSO.4.58.0606081226580.11090@arachne.dur.ac.uk>
	<FFE6F0893C5B740BF19CB5EB@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606081600210.11090@arachne.dur.ac.uk>
	<043DD976975A1E62626E32AA@lewes.staff.uscs.susx.ac.uk>
	<Pine.GSO.4.58.0606090938080.11090@arachne.dur.ac.uk>
Message-ID: <20060609111219.287faaa9@resist.wooz.org>

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

On Fri, 9 Jun 2006 09:47:27 +0100 (BST)
David Lee <t.d.lee at durham.ac.uk> wrote:

> > Not "Authenticated". That implies that authentication has already
> > occurred. What you're doing is supplying a token to be used for
> > authentication. So, "Authentication" would be better. Or even
> > "Password".
> 
> I had picked on the past-tense terminology ("Authorised",
> "Authenticated", etc.) simply because the FAQ talks about an
> "Approved" (past tense) header.  But I believe the code also accepts
> (present tense) "Approve". So I had antcipated that my proposal would
> be similarly tense-tolerant!

Password seems reasonable.

> > Oh, and if it's an email header, shouldn't it be X-Authentication,
> > or whatever?
> 
> Two consistency trends pulling in opposite directions!
> 
> 1. RFC-ish things suggest "X-Whatever:".
> 
> 2. Mailman practice (the existing "Approved") suggests "Whatever:".
> 
> I was assuming I should follow the Mailman convention.  (Whether the
> Mailman convention needs revision is another matter...)

Approved was chosen for compatibility with Majordomo, so there was a
long tradition before us.  Approve was added because so many people
mistyped the original ;).

When blazing our own trails we should be more RFC compliant.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRImP03EjvBPtnXfVAQLt6wP/Y/a4OuZ8r8kRm/JSrAh8jFU1d4OhsQ5c
l+s4kYYY3QE+IfGC92x+QRe6dVSp9jKEmtB08lA8pR2UvfYgc5xDMoZQ57ZYGyhA
f48FwdkOCfmr5MZgpfsbrMiR2fIKrzXx8bT6Bo803Sz07/F1+KbYLAlq3BSe8/4d
HP2qqroiZ5o=
=zWMz
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jun  9 17:09:35 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 9 Jun 2006 11:09:35 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <C90467D6FD125C369528E584@lewes.staff.uscs.susx.ac.uk>
References: <PC1740200606062202440490b107c516@msapiro>
	<1F376D442E2851D7278DDDE3@lewes.staff.uscs.susx.ac.uk>
	<20060607092611.643e6744@geddy.wooz.org>
	<E2F716869A454B535909364C@lewes.staff.uscs.susx.ac.uk>
	<p0620071cc0acbd64e581@[10.0.1.210]>
	<20060607143528.1249af3f@resist.wooz.org>
	<p06200701c0ad5800e790@[10.0.1.210]>
	<A260F0CEC9429D2D07BA81C9@lewes.staff.uscs.susx.ac.uk>
	<p06200708c0addaca8f3d@[192.168.1.101]>
	<F1015388BBF016CE1B62012F@lewes.staff.uscs.susx.ac.uk>
	<20060608113733.135ff45a@resist.wooz.org>
	<C90467D6FD125C369528E584@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060609110935.071a57d0@resist.wooz.org>

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

On Thu, 08 Jun 2006 17:06:43 +0100
Ian Eiloart <iane at sussex.ac.uk> wrote:

> That's fair enough. I do have an idea about how to use a python
> script with Exim. I don't know enough to make it efficient, though.
> Maybe there's a problem with my python installation, or the way that
> I invoke it, but it seems that even a simple query takes four or five
> seconds to run:
> 
> rinka-12 # date ; /local/mailman/bin/list_members ian-test4 ; date
> Thu Jun  8 16:47:09 BST 2006
> foo at example.ac.uk
> bar at example.ac.uk
> baz at example.ac.uk
> Thu Jun  8 16:47:13 BST 2006
> 
> But, it takes about 0.7 seconds to print "hello world", and truss
> shows a lot of files being opened just to get a list of members.

You should definitely use time(1) instead, but to open and print a 3
member list should be nearly instantaneous.  FWIW, it only takes me
about 1/2 second to do the same on a 2500 member list on fairly old h/w.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRImPMHEjvBPtnXfVAQICTQQArHcq2KOwZuFnRFj+gwJn+N2HAuNT7qwD
epQwc+zEfrSJ8Q1VECMh+g9/nDSHI2h7sp10ST46NMaj60Fyhr7TahSrfNsEZzgQ
5jhuQAPA0wdKUFciCVIRNrrkJCLJLIMjQ6sJXDil2BVT858MlR+XvrH77cahw4HZ
O/VCDexviSQ=
=Id8s
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jun  9 17:24:02 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 9 Jun 2006 11:24:02 -0400
Subject: [Mailman-Developers] 2.1.8 documentation mismatch
In-Reply-To: <PC1740200606090659240500a26eb9ac@msapiro>
References: <437C8037FE31DA14360CB721@lewes.staff.uscs.susx.ac.uk>
	<PC1740200606090659240500a26eb9ac@msapiro>
Message-ID: <20060609112402.35cbd760@resist.wooz.org>

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

On Fri, 9 Jun 2006 06:59:24 -0700
Mark Sapiro <msapiro at value.net> wrote:

> We all know that this is not secure against all attacks, but David
> feels that it will be good enough for his situation.

Which it probably is.

There have been others that have proposed registering pubkeys with email
addresses and authenticating against message signatures.  I think there
may even be patches out on SF to support this with gpg.  It seems to me
that that's the right long term solution, although email PKI is (still)
sadly poorly supported -- or understood by end users -- it seems.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRImSknEjvBPtnXfVAQJrCgP/f9oVtJmF/SDA/c/3jFi5ZJhqt3fRyA5X
oK1Zx7aetmBCPVi14hIwD4PBGAAs8tBfdFwerrxFu8iC7Fjj5huflYi2j04yqN2/
0rsYccVcbok8ci5lHFTukBpdR7O61Sshx1nlaUW4WxsWc6Zk644Hah4CoWSw9WeG
Hp40QSw9Eck=
=EH7y
-----END PGP SIGNATURE-----

From hdu at qualigo.de  Tue Jun 13 18:36:54 2006
From: hdu at qualigo.de (Haluk Durmus)
Date: Tue, 13 Jun 2006 19:36:54 +0300
Subject: [Mailman-Developers] edit moderated messages
Message-ID: <20060613193654.2c17a9f6.hdu@qualigo.de>

Hello, 

Is there any body working on this task ?

	[ 1198375 ] edit moderated messages directly on admindb page

If not I will give it a try.


thx,
Haluk


From barry at python.org  Wed Jun 14 03:15:20 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 13 Jun 2006 21:15:20 -0400
Subject: [Mailman-Developers] edit moderated messages
In-Reply-To: <20060613193654.2c17a9f6.hdu@qualigo.de>
References: <20060613193654.2c17a9f6.hdu@qualigo.de>
Message-ID: <DFBFC078-A84D-4EFE-BE4D-E41CF35DF6F9@python.org>

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

On Jun 13, 2006, at 12:36 PM, Haluk Durmus wrote:

> Hello,
>
> Is there any body working on this task ?
>
> 	[ 1198375 ] edit moderated messages directly on admindb page

Not that I know of.
- -Barry


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

iD8DBQFEj2Mp2YZpQepbvXERAvg8AJoD8Eq+L/UAHFpj+9o1B2IFEBElEQCfdVhO
39UwGffhZOxyVeuoKR0Iw10=
=BBeG
-----END PGP SIGNATURE-----

From i at mindlace.net  Fri Jun 16 03:01:12 2006
From: i at mindlace.net (emf)
Date: Thu, 15 Jun 2006 21:01:12 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
Message-ID: <449202D8.8060805@mindlace.net>

Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of 
Code project.

I'll keep a running log of my progress at

http://wiki.list.org/display/DEV/Summer+of+Code

My svn branch is 
https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ; 
feel free to check it out as the inclination strikes you.

I'm especially interested in getting any feedback, either on the wiki or 
here, about any and all WebUI - or UI in general - ideas in people's 
heads. While the SoC project is fairly constrained, I want to at least 
make the future easier.

~ethan fremen

From brad at stop.mail-abuse.org  Fri Jun 16 06:47:41 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 15 Jun 2006 23:47:41 -0500
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <449202D8.8060805@mindlace.net>
References: <449202D8.8060805@mindlace.net>
Message-ID: <p06200707c0b7e460d85d@[192.168.1.101]>

At 9:01 PM -0400 2006-06-15, emf wrote:

>  I'm especially interested in getting any feedback, either on the wiki or
>  here, about any and all WebUI - or UI in general - ideas in people's
>  heads.

	Speaking only for myself, I think there should be three main design goals:

		1.  KISS -- I sometimes have to do list administration and
			moderation from my Treo 650, so anything that depends on
			graphics, JavaScript, CSS, or anything fancy is really bad
			news.  Stick to a pure text-only UI as much as possible,
			and try doing some actual tests with various PDAs and
			phones, as well as all common browsers (including Safari)
			on all common desktop platforms (including MacOS X).
			This also means that the size of the pages should be kept
			as reasonably small as possible -- the smaller they are,
			the faster they load.

			Of course, the standard exemplars are Google and Yahoo!

			IMO, we're doing pretty good in this area today, but I would
			hate to see all the current WebUI code get thrown out and
			replaced with a Web2.0 AJAX/.NET framework.

		2.  Functionality -- As much as possible, make it "just work"
			out-of-the-box.  We've managed to accumulate a lot of cruft
			in the FAQ Wizard because there are a whole host of things
			that list moderators and administrators want to do with their
			lists, and some of them are easy with the WebUI, and some
			are not -- while others simply aren't possible at all, at
			least not from the WebUI.

			Ideally, I'd like to see everything in the FAQ Wizard get
			removed because it is no longer applicable.  At the very
			least, for anything that is related to the UI, there should
			not be any entries to go into any FAQ, because it "just works".

		3.  Completeness -- diametrically opposed to #1 and #2 above,
			anything that can be done from the command-line should be
			do-able from the WebUI.  This includes things like editing
			posts in the archives, editing posts before approving them,
			etc....

			It's going to be tough to balance #3 against #1 and #2.
			There may be a lot of things that you would like to do
			in this area that would require support in other parts of
			the code, and therefore you may not be able to do them.
			But I would like to see a concerted effort made.

>          While the SoC project is fairly constrained, I want to at least
>  make the future easier.

	Your work is very important to us.

	I'm not sure you fully understand how important.  Or how difficult.  ;)

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From j.e.vanbaal at uvt.nl  Fri Jun 16 10:22:32 2006
From: j.e.vanbaal at uvt.nl (Joost van Baal)
Date: Fri, 16 Jun 2006 10:22:32 +0200
Subject: [Mailman-Developers] Mailman WebUI improvement (was: Re: Hi! I'll
	be your intern for the summer :))
In-Reply-To: <449202D8.8060805@mindlace.net>
References: <449202D8.8060805@mindlace.net>
Message-ID: <20060616082232.GL16473@banach.uvt.nl>

Hi,

On Thu, Jun 15, 2006 at 09:01:12PM -0400, emf wrote:
> Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of 
> Code project.
> 
> I'll keep a running log of my progress at
> 
> http://wiki.list.org/display/DEV/Summer+of+Code
> 
> My svn branch is 
> https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ; 
> feel free to check it out as the inclination strikes you.
> 
> I'm especially interested in getting any feedback, either on the wiki or 
> here, about any and all WebUI - or UI in general - ideas in people's 
> heads. While the SoC project is fairly constrained, I want to at least 
> make the future easier.

Apart from what Brad told: there has been discussion on UI and usability
before (of course!). See the threads starting with

 Message-Id: <dc75c99c611fd979496448fb1cfcf869 at zone12.com>
 From: Terri Oda <terri at zone12.com>
 Date: Thu, 3 Mar 2005 13:38:38 -0500
 To: mailman-developers <mailman-developers at python.org>
 Subject: [Mailman-Developers] Mailman Usability

and

 Message-ID: <4458607A.5030804 at ita.chalmers.se>
 Date: Wed, 03 May 2006 09:49:14 +0200
 From: Dario Lopez-K?sten <dario at ita.chalmers.se>
 To: mailman-developers at python.org
 Subject: [Mailman-Developers] why not PageTemplates for GUI?

a.o.

Bye,

Joost

-- 
Joost van Baal                            http://abramowitz.uvt.nl/
                                                 Tilburg University
j.e.vanbaal at uvt.nl                                  The Netherlands
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060616/05bfe1a9/attachment.pgp 

From iane at sussex.ac.uk  Fri Jun 16 13:30:23 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 16 Jun 2006 12:30:23 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <449202D8.8060805@mindlace.net>
References: <449202D8.8060805@mindlace.net>
Message-ID: <EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>



--On 15 June 2006 21:01:12 -0400 emf <i at mindlace.net> wrote:

> Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of
> Code project.
>
> I'll keep a running log of my progress at
>
> http://wiki.list.org/display/DEV/Summer+of+Code
>
> My svn branch is
> https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ;
> feel free to check it out as the inclination strikes you.
>
> I'm especially interested in getting any feedback, either on the wiki or
> here, about any and all WebUI - or UI in general - ideas in people's
> heads. While the SoC project is fairly constrained, I want to at least
> make the future easier.

This is good news. Here's what I'd like to see happen:


    a) arbitrary page headers and footers so I can make it match the rest 
of my site.

    b) site-wide masking of features that we don't allow by policy. There's 
already some of this.

    c) templates for lists. We have four or five basic list styles 
(announce/discussion with open/closed membership and umbrella lists). When 
we create a list, I'd like to be able to specify there and then which style 
to use. Such a feature would rely on having a set of files on the server 
that hold the relevant list settings. The UI would simply let me pick which 
style to apply. The task here is not to design the templates, but to enable 
their easy application.

    d) When creating an list, I'd like to be able to choose an umbrella for 
it to live under, and have it inherit privacy settings from that list. So, 
to create a complex heirarchy, I'd start by creating the root list, adding 
privacy settings, and then work down the heirarchy - perhaps making the 
privacy settings more liberal as I go.

    e)

-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Fri Jun 16 19:33:50 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 16 Jun 2006 13:33:50 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <p06200707c0b7e460d85d@[192.168.1.101]>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
Message-ID: <EE58A0BB-7918-44DA-A4D0-BCB12B103887@python.org>

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

On Jun 16, 2006, at 12:47 AM, Brad Knowles wrote:

> 			IMO, we're doing pretty good in this area today, but I would
> 			hate to see all the current WebUI code get thrown out and
> 			replaced with a Web2.0 AJAX/.NET framework.

I certainly agree that we want to make sure the UI is not /dependent/  
on such fanciness, but I think it's acceptable for there to be some  
reasonable use of modern web UI tools, as long as the interface  
degrades gracefully.  Remember that we have users who require  
specialized browsers (e.g. screen talkers for the visually impaired)  
and some people who use text-only browsers like links/lynx.

> 			Ideally, I'd like to see everything in the FAQ Wizard get
> 			removed because it is no longer applicable.  At the very
> 			least, for anything that is related to the UI, there should
> 			not be any entries to go into any FAQ, because it "just works".

Yep.

> 		3.  Completeness -- diametrically opposed to #1 and #2 above,
> 			anything that can be done from the command-line should be
> 			do-able from the WebUI.  This includes things like editing
> 			posts in the archives, editing posts before approving them,
> 			etc....

I agree, although there's some work from the core to be done here.   
Too much of the functionality is embedded in Cgi scripts and not  
refactored out into utilities that other access methods could take  
advantage of.  List removal is something that comes to mind.  OTOH,  
this is something I have a keen interest in fixing.

> 	Your work is very important to us.
>
> 	I'm not sure you fully understand how important.  Or how  
> difficult.  ;)

Indeed!  Hopefully fun too though :)

- -Barry

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

iQCVAwUBRJLrfnEjvBPtnXfVAQK+WQQAkTJ9jxLATEH8/AbsWhHGvgsflVDsNQsk
ESo+a6gwCIBCe/LqljT5ljmZSyP/NDlzru0IRUxebuBBAgcDFMHAjpEUvgHSrbWB
r41LknnztZAG6OUDj/3sGUuvXUm/99wjxgE/D7ixhs3B7NlYLTJXL/DJpGfSci+G
Z449M2R8388=
=rA9G
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jun 16 19:36:14 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 16 Jun 2006 13:36:14 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
Message-ID: <62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>

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

On Jun 16, 2006, at 7:30 AM, Ian Eiloart wrote:

>     a) arbitrary page headers and footers so I can make it match  
> the rest
> of my site.

+1, with CSS to help in integration.

>     b) site-wide masking of features that we don't allow by policy.  
> There's
> already some of this.

+1

>     c) templates for lists. We have four or five basic list styles
> (announce/discussion with open/closed membership and umbrella  
> lists). When
> we create a list, I'd like to be able to specify there and then  
> which style
> to use. Such a feature would rely on having a set of files on the  
> server
> that hold the relevant list settings. The UI would simply let me  
> pick which
> style to apply. The task here is not to design the templates, but  
> to enable
> their easy application.

+1  I did a little experimentation with this in the mm3 branch and I  
don't think the basic mechanisms are that difficult.  The UI is the  
challenge (i.e. how do you set up a style?).

>     d) When creating an list, I'd like to be able to choose an  
> umbrella for
> it to live under, and have it inherit privacy settings from that  
> list. So,
> to create a complex heirarchy, I'd start by creating the root list,  
> adding
> privacy settings, and then work down the heirarchy - perhaps making  
> the
> privacy settings more liberal as I go.

Very interesting idea!
- -Barry

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

iQCVAwUBRJLsDnEjvBPtnXfVAQIaVQP8DKy0zzZ2SD10iHRGaBUI8UgE3M+9ugTt
Kjpo8ohrkCygEIk8UHFtkRc42u90HXMPjE9HUbdgVG0SAbPjiorwAK8YscKEYPWq
wf5L39+vdOZ/yBLC5lZ2e5PYhgh6dfatktH/9Q353LD/bWNnoOMAmJxo3U0OpkcE
Slep3Z3GcHY=
=Y578
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Mon Jun 19 12:31:30 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 19 Jun 2006 11:31:30 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
Message-ID: <182F894DC73A6D27677F14F0@lewes.staff.uscs.susx.ac.uk>



--On 16 June 2006 13:36:14 -0400 Barry Warsaw <barry at python.org> wrote:

>
>>     c) templates for lists. We have four or five basic list styles
>> (announce/discussion with open/closed membership and umbrella
>> lists). When
>> we create a list, I'd like to be able to specify there and then
>> which style
>> to use. Such a feature would rely on having a set of files on the
>> server
>> that hold the relevant list settings. The UI would simply let me
>> pick which
>> style to apply. The task here is not to design the templates, but
>> to enable
>> their easy application.
>
> +1  I did a little experimentation with this in the mm3 branch and I
> don't think the basic mechanisms are that difficult.  The UI is the
> challenge (i.e. how do you set up a style?).

Well, in our case, the styles would be site-wide and set up only once. We 
don't need a UI to set up the styles, because we've already created them. 
Our current workflow is
    1. Create a list through the UI
    2. Shell in to the list server
    3. Run a script which applies the style to the list.

I'd just like to avoid 2. and 3. by having some UI to apply the style on 
creation  - like the subethaedit example. I guess it would be nice for the 
CGI to look for a style file at -say- /mailman/styles/foo.style and a text 
description at /mailman/styles/foo.description - or to extract the 
description from the style file.

-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Mon Jun 19 13:05:43 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 19 Jun 2006 12:05:43 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <182F894DC73A6D27677F14F0@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
	<182F894DC73A6D27677F14F0@lewes.staff.uscs.susx.ac.uk>
Message-ID: <4D9556FA480B16E75D3C3250@lewes.staff.uscs.susx.ac.uk>



--On 19 June 2006 11:31:30 +0100 Ian Eiloart <iane at sussex.ac.uk> wrote:

>
>
> --On 16 June 2006 13:36:14 -0400 Barry Warsaw <barry at python.org> wrote:
>
>>
>>>     c) templates for lists. We have four or five basic list styles
>>> (announce/discussion with open/closed membership and umbrella
>>> lists). When
>>> we create a list, I'd like to be able to specify there and then
>>> which style
>>> to use. Such a feature would rely on having a set of files on the
>>> server
>>> that hold the relevant list settings. The UI would simply let me
>>> pick which
>>> style to apply. The task here is not to design the templates, but
>>> to enable
>>> their easy application.
>>
>> +1  I did a little experimentation with this in the mm3 branch and I
>> don't think the basic mechanisms are that difficult.  The UI is the
>> challenge (i.e. how do you set up a style?).
>
> Well, in our case, the styles would be site-wide and set up only once. We
> don't need a UI to set up the styles, because we've already created them.
> Our current workflow is
>     1. Create a list through the UI
>     2. Shell in to the list server
>     3. Run a script which applies the style to the list.
>
> I'd just like to avoid 2. and 3. by having some UI to apply the style on
> creation  - like the subethaedit example.

Sorry, I wasn't paying attention there. Someone sent me this link, 
<http://subetha.tigris.org/images/list_create.png> and in my 
caffeine-deprived haze I didn't notice (a) this is a rival email list 
project not the subethaedit text editor, and (b) they hadn't posted to the 
list.

> I guess it would be nice for
> the  CGI to look for a style file at -say- /mailman/styles/foo.style and
> a text  description at /mailman/styles/foo.description - or to extract
> the  description from the style file.



-- 
Ian Eiloart
IT Services, University of Sussex

From mcn4 at leicester.ac.uk  Mon Jun 19 15:45:22 2006
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Mon, 19 Jun 2006 14:45:22 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
Message-ID: <20060619134522.GB28225@ultra.le.ac.uk>

On Fri, Jun 16, 2006 at 01:36:14PM -0400, Barry Warsaw wrote:
> >     a) arbitrary page headers and footers so I can make it match  
> > the rest
> > of my site.
> 
> +1, with CSS to help in integration.

That would be nice for me, too, definitely with CSS.

> >     b) site-wide masking of features that we don't allow by policy.  
> > There's
> > already some of this.
> 
> +1

I wrote a patch for that a while ago (assuming I understand what
you are after). See patch 1164457 on SF. It's for 2.1.5 as I
haven't had time to update yet (apart from a couple of security
patches). I doubt it would be difficult to update, though, as it's
very small.

I use it to disable the "owner" list setting, as list owners here
have to request that change via our information desk staff, and
then my back-end script handles it.

Matthew


-- 
Matthew Newton <mcn4 at le.ac.uk>

UNIX and e-mail Systems Administrator, Network Support Section,
Computer Centre, University of Leicester,
Leicester LE1 7RH, United Kingdom

From msapiro at value.net  Mon Jun 19 21:59:11 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 19 Jun 2006 12:59:11 -0700
Subject: [Mailman-Developers] Topics revisited:
Message-ID: <PC1740200606191259110625ea21d03c@msapiro>

After starting a thread on this list
(http://mail.python.org/pipermail/mailman-developers/2006-May/018787.html>
and also posting a request for feedback on Mailman-Users
<http://mail.python.org/pipermail/mailman-users/2006-June/051588.html>
which received no replies, I think I'm almost done with this. My patch
is attached for review, comment.

Basically, I implement a new Utils.strip_verbose_pattern() function
which converts verbose patterns to single-line, non-verbose
equivalents and add code to versions.py for a one time conversion of
existing topics regexps.

I then modify the Gui, etc so that all future multi-line patterns are
stored as entered, but compiled and used with the lines connected by
'|'.

Specifically, I would like advice and comment on two things.

First since the strip_verbose_pattern() function is basically a
one-time, list conversion function, would it be better added to
versions.py rather than Utils.py.

Second, when a topic pattern is first entered, an attempt is made to
compile it, and if this throws an exception, the error is reported in
the Gui and the topic is ignored. A similar thing is also done in
MailList.py which will catch (eventually) and log bad topic regexps
that might be entered with config_list or withlist.

My question here is in the error message and log message, The pattern I
report as invalid is the '|' joined pattern and not the original
entry. I think this makes more sense, but I'm interested in what
others think.

Finally, in writing this post I have thought of another issue. Someone
may have a saved config_list 'template' with old style 'verbose' topic
regexps which wouldn't get converted if applied to a new 2.2.x list.
Is this something to be concerned about? Note that this could be an
issue any time a list attribute is deleted or has its set of values
manipulated.

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Topics.patch.txt
Url: http://mail.python.org/pipermail/mailman-developers/attachments/20060619/31de9cb8/attachment.txt 

From i at mindlace.net  Wed Jun 21 00:57:12 2006
From: i at mindlace.net (emf)
Date: Tue, 20 Jun 2006 18:57:12 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <p06200707c0b7e460d85d@[192.168.1.101]>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
Message-ID: <44987D48.4020406@mindlace.net>


>         1.  KISS -- I sometimes have to do list administration and
>             moderation from my Treo 650, so anything that depends on
>             graphics, JavaScript, CSS, or anything fancy is really bad
>             news. 

Ug, yeah. There's so much cruft stuck in so many places that I've just 
started over writing (x)html templates. I will be using CSS mostly so 
that underneath the pages can be Very Simple; I've got a Palm TX and 
table pages can be brutal. Additionally, I fully intend to have a CSS 
file just for mobile devices.

I will also be using JavaScript to add responsiveness to the UI for 
traditional browsers, but I swear on a stack of comic books that It 
Shall Degrade Gracefully.

>             Stick to a pure text-only UI as much as possible,

Please forgive my insouciance on this point, but I believe one of the 
weaknesses of the current interface is that it provides no visual cues 
as to what is important/relevant. I will be using icons to draw the 
user's eye to relevant details, but I have no intention of gobbling up 
screen space for bling or committing similar crimes like using 
image-only links; the interface will be fully functional and 
aesthetically reasonable with images turned completely off.

>             and try doing some actual tests with various PDAs and
>             phones, as well as all common browsers (including Safari)
>             on all common desktop platforms (including MacOS X).

Well, I've got me a testing lab right here! I'm only slightly kidding. 
Aside from the aforementioned TX, I have an intel mac, so I plan on 
installing Windows soon so I can see how things work on that end.

I'm also going to make sure it's fine in links or lynx.

>             I would
>             hate to see all the current WebUI code get thrown out and
>             replaced with a Web2.0 AJAX/.NET framework.

I will be using some XMLHTTPRequest action, but only to allow 
partial-form-submission, and it will degrade to "submit the whole page" 
gracefully.

>         2.  Functionality & 3. Completeness

I'm not committed to doing much with these problems in this project, but 
I assure you it is my desire as well; I'm hoping to get us closer to the 
day where there is One Holy UI that works identically across web/email/cli.

>     I'm not sure you fully understand how important.  Or how difficult.  ;)

Thanks! happily I feel like I'm making quite a bit of progress, so I 
think we might just get something viable out of this.

~ethan

From i at mindlace.net  Wed Jun 21 01:01:16 2006
From: i at mindlace.net (emf)
Date: Tue, 20 Jun 2006 19:01:16 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
Message-ID: <44987E3C.7000703@mindlace.net>

Ian Eiloart wrote:
>    a) arbitrary page headers and footers so I can make it match the rest 
> of my site.

I'll give you this *and* throw in "arbitrary page-chunks you can plop 
right into your page", in case you just want to expose, say, the 
moderator interface.

>    b) site-wide masking of features that we don't allow by policy. 
> There's already some of this.

No feature shall be visible if it doesn't or shouldn't function. Gotcha.

>    c) templates for lists. We have four or five basic list styles 
> (announce/discussion with open/closed membership and umbrella lists). 
> When we create a list, I'd like to be able to specify there and then 
> which style to use.

Without getting too far into file management, I hope to have something 
beyond "three links; have fun". Not sure I can necessarily address the 
configuration issue.

>    d) When creating an list, I'd like to be able to choose an umbrella 
> for it to live under, and have it inherit privacy settings from that 
> list. 

This is great; I'm not sure I can do all that without writing a fair 
amount of under-the-UI code.

~ethan fremen

From brad at stop.mail-abuse.org  Wed Jun 21 02:09:06 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Tue, 20 Jun 2006 19:09:06 -0500
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <44987D48.4020406@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
	<44987D48.4020406@mindlace.net>
Message-ID: <p06200703c0be3e3a3f18@[192.168.1.101]>

At 6:57 PM -0400 2006-06-20, emf wrote:

>  Well, I've got me a testing lab right here! I'm only slightly kidding.
>  Aside from the aforementioned TX, I have an intel mac, so I plan on
>  installing Windows soon so I can see how things work on that end.
>
>  I'm also going to make sure it's fine in links or lynx.

	That's good enough for me.

>  Thanks! happily I feel like I'm making quite a bit of progress, so I
>  think we might just get something viable out of this.

	You've already made me feel a lot better about the probably 
outcome of this project, and I'm pretty confident that you will be 
fully successful.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From t.d.lee at durham.ac.uk  Wed Jun 21 10:47:47 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Wed, 21 Jun 2006 09:47:47 +0100 (BST)
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <44987E3C.7000703@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
Message-ID: <Pine.GSO.4.58.0606210938260.4594@arachne.dur.ac.uk>

On Tue, 20 Jun 2006, emf wrote:

> Ian Eiloart wrote:
> [...]
> >    d) When creating an list, I'd like to be able to choose an umbrella
> > for it to live under, and have it inherit privacy settings from that
> > list.
>
> This is great; I'm not sure I can do all that without writing a fair
> amount of under-the-UI code.

Going slightly off to one-side...

One of the things on the TODO list:
   http://www.gnu.org/software/mailman/todo.html
is:
    Allow lists of the same name in two different virtual domains

(i.e. "thislist at somedom.com" and "thislist at otherdom.org", where "thislist"
and "thislist" are the same name).

I suspect that most of this functionality would likewise be "under-the-UI"
and so not directly related to your "work on the Web UI" brief.

But it would be worth bearing this in mind so that your code could
interwork as near as reasonably possible with any future virtual-domain
developments.  For instance, when your code passes processes a "listname"
consider also having a "virthost" sitting alongside it, even if, for the
moment, that is null, or default or always-the-same etc.

-- 

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

From iane at sussex.ac.uk  Wed Jun 21 15:09:44 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 21 Jun 2006 14:09:44 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <44987E3C.7000703@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
Message-ID: <F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>



--On 20 June 2006 19:01:16 -0400 emf <i at mindlace.net> wrote:
>
>>    d) When creating an list, I'd like to be able to choose an umbrella
>> for it to live under, and have it inherit privacy settings from that
>> list.
>
> This is great; I'm not sure I can do all that without writing a fair
> amount of under-the-UI code.
>

:) Maybe not.

How about this for extra:

1) Display a list of ALL members - just their names and addresses.
2) Delete ALL the list members with one click - OK, and maybe a confirm 
dialog!


The aim here is that I can completely change the list membership (through a 
delete-all and mass subscribe) before sending a mailing. The reason is that 
I have some users who maintain lists outside of Mailman. I'd like them to 
be able to take advantage of other Mailman features.


-- 
Ian Eiloart
IT Services, University of Sussex

From lcarlson at d.umn.edu  Wed Jun 21 15:05:10 2006
From: lcarlson at d.umn.edu (Laura Carlson)
Date: Wed, 21 Jun 2006 08:05:10 -0500
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
Message-ID: <84F5BFBEBEF7807D0A48932E@lcarslon.d.umn.edu>

On Thu, Jun 15, 2006 at 09:01:12PM -0400, emf wrote:

> I'm especially interested in getting any feedback, either on the wiki
> or  here, about any and all WebUI - or UI in general - ideas in
> people's  heads.

Hi Ethan,

I mentioned this about a year ago [1], it would be great if the Mailman 
templates, like the general list information page and the user specific 
options page, were accessible and standards compliant.

For instance when the end user views the  current pages, they get form 
labels that are not explicitly associated with their controls.

Using the <label> element is the best way to ensure that people using 
screen readers and other assistive technology have access to all the 
information necessary to complete forms online. This makes it possible 
for screen readers to explicitly identify the onscreen text as a label 
for the <input> element. The <label> element and its for attribute were 
added to HTML specifically to support accessible labeling of form 
controls.

- The <label> element assigns a label to a form <input> element (one 
label to one input).
- The for attribute defines the explicit control that the label is 
associated with.
- The for attribute must match the <input> element's id attribute's 
value exactly.
- Each id attribute must be unique within a document.

Example <label> with for and id attributes markup:

<label for="name">
Your name
<input id="name" name="name" title="Enter your first name." size="40" 
type="text" />
</label>

So...for each form control, place its label in a <label> element. A 
<label> is attached to a specific form control through the use of the 
for attribute. The value of the for attribute must be the same as the 
value of the id attribute of the form control.

When form fields are not labeled explicitly, screen readers will skip 
over the text on your form when users try to enter data. For example, a 
screen reader will simply say, "Edit" or "Edit box," forcing the user 
to guess what information is being requested. Screen readers will not 
speak any text on a form that is not placed inside a tag such as a 
link, label, button, or legend.

When form fields are labeled explicitly, the browser can tell the user 
definitively which label applies to the given control. Usually, 
clicking on the label positions the cursor in the form field, or 
toggles the value of radio buttons or check boxes. This is intuitive 
for many users and provides a larger target for the mouse.

Use of the <label> element is especially important if tables are used 
to lay out a form. Another advantage of using the <label> element is 
that you can have more control over how field labels appear, using 
style sheets.

Related forms accessibility references:

http://joeclark.org/book/sashay/serialization/Chapter12.htm
http://www.accessify.com/features/tutorials/accessible-forms/
http://www.webaim.org/techniques/forms/
http://www.d.umn.edu/goto/accessibility#forms

Also adding alt attributes to images [2], using good html heading
structure [3] [4], and validating to W3C standards [5] [6] would aid 
accessibility.

All the best,
Laura

[1] http://tinyurl.com/ey8tu
[2] http://www.d.umn.edu/goto/accessibility#alt
[3] http://www.webaim.org/techniques/semanticstructure/
[4] http://www.d.umn.edu/goto/standards#structure
[5] http://validator.w3.org/
[6] http://www.d.umn.edu/goto/standards#validation

___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN  55812-3009
http://www.d.umn.edu/goto/webdesign/

From i at mindlace.net  Wed Jun 21 19:31:49 2006
From: i at mindlace.net (emf)
Date: Wed, 21 Jun 2006 13:31:49 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <84F5BFBEBEF7807D0A48932E@lcarslon.d.umn.edu>
References: <84F5BFBEBEF7807D0A48932E@lcarslon.d.umn.edu>
Message-ID: <44998285.1010109@mindlace.net>

Laura Carlson wrote:

> I mentioned this about a year ago [1], it would be great if the Mailman 
> templates, like the general list information page and the user specific 
> options page, were accessible and standards compliant.

Thanks very much for your feedback, Laura! I am something of a standards 
fanatic; all the pages I've re-written so far have made heavy use of 
label (although I use the implicit label where possible), fieldset, 
legend, thead & tbody and the title attribute to provide as much support 
for assistive technologies and alternative renderings as I can.

Once I have a clear idea what form elements will be where, I am also 
going to add tabindex and accesskey attributes to the form elements.

Because all the mailman templates are a hideous mismatch of CAPS TAGS 
and lcase tags and all sort of tag-soupishness, I'm re-doing them all as 
xhtml strict.

Right now the xhmtml templates are all checked in at:

https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui/Mailman/Gui/templates/kid/

I'm thinking I'm going to move the kid thing up to templates, move the 
existing templates back to their original location. There are too many 
advantages for me in switching over to mod_python, so for the moment my 
"backward compatibility" stance is to leave the old cgi-bin stuff as is 
and just focus on implementing everything using mod_python.

> When form fields are not labeled explicitly, screen readers will skip 
> over the text on your form when users try to enter data.

What's also lame is the way that the user can't click on the label to 
toggle/enter the input item.

Thanks for all the references. If you know of a way that I can actually 
test JAWS or another screen reader, I would be grateful for the pointer.

~ethan fremen

From i at mindlace.net  Wed Jun 21 19:37:36 2006
From: i at mindlace.net (emf)
Date: Wed, 21 Jun 2006 13:37:36 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
Message-ID: <449983E0.90504@mindlace.net>

Ian Eiloart wrote:

> How about this for extra:
> 
> 1) Display a list of ALL members - just their names and addresses.
> 2) Delete ALL the list members with one click - OK, and maybe a confirm 
> dialog!

Hm. This comes slightly in opposition to the desire to have a more 
user-centered mailman interface; what happens if a user changes their 
preferences and you re-build the entire list?

An associated problem is what happens to users that are subbed to >1 list?

I recognize this may not be an issue in your specific case, I just think 
that issues like these will be more of a deal when we don't keep 
"members" in per-list silos.

Perhaps something that might be more appropriate would be a "member 
differ", wherein you upload a list of email addresses, and it shows you 
the list of emails that were on the list but aren't now, and those that 
would be added, and gives you the option to either accept all the 
changes or selectively modify them.

When you say you'd like these people to be able to take advantage of 
"other mailman features", which features do you mean?

~ethan fremen


From i at mindlace.net  Wed Jun 21 20:28:18 2006
From: i at mindlace.net (emf)
Date: Wed, 21 Jun 2006 14:28:18 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <x7k67bi5wn.fsf@winfirst.com>
References: <84F5BFBEBEF7807D0A48932E@lcarslon.d.umn.edu>	<44998285.1010109@mindlace.net>
	<x7k67bi5wn.fsf@winfirst.com>
Message-ID: <44998FC2.2010701@mindlace.net>

larryt at winfirst.com wrote:

> I'm not aware of anything about mod_python that would make your work
> not also support FastCGI and SCGI.  Am I correct?

I don't know for certain; I was planning on at least trying to implement
RSS feeds as an output filter, which as far as I know means I'm hooking
into Apache's request stack at a level FastCGI and SCGI don't touch.

I suspect there is a way to wrap things so that they'll work as a
fastcgi/scgi/cgi, but I don't know that I'm going there.

~ethan fremen


From i at mindlace.net  Wed Jun 21 21:51:52 2006
From: i at mindlace.net (emf)
Date: Wed, 21 Jun 2006 15:51:52 -0400
Subject: [Mailman-Developers] SoC: status update
Message-ID: <4499A358.2040005@mindlace.net>

http://wiki.list.org/display/DEV/Summer+of+Code

Gentlebeings,

I have updated the summer of code page above to indicate my current 
progress and record the synthesis of the opinions I have received so far.

Thank you for the excellent feedback you've provided so far; don't be 
shy about continuing, either here or on the wiki.

~ethan fremen

From mcn4 at leicester.ac.uk  Thu Jun 22 00:45:49 2006
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Wed, 21 Jun 2006 23:45:49 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <449983E0.90504@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
Message-ID: <20060621224549.GA4684@ultra.le.ac.uk>

On Wed, Jun 21, 2006 at 01:37:36PM -0400, emf wrote:
> > How about this for extra:
> > 
> > 1) Display a list of ALL members - just their names and addresses.
> > 2) Delete ALL the list members with one click - OK, and maybe a confirm 
> > dialog!

> Perhaps something that might be more appropriate would be a "member 
> differ", wherein you upload a list of email addresses, and it shows you 
> the list of emails that were on the list but aren't now, and those that 
> would be added, and gives you the option to either accept all the 
> changes or selectively modify them.

This sounds like the command-line "sync_members" program. I've
been meaning to add a web interface to that for a while, but
haven't managed to get around to it.

I guess it depends on what you use Mailman for. In then general
internet-user-subscribes-themselves-mailing-list it's great. For a
University with central management of some lists, it isn't quite
what is needed all the time.

One thing that happens each year here for some lists is that all
list members of "course-year2" get moved to "course-year3",
"course-year1" to "course-year2", and new members added to
"course-year1". I can do this easily from the command line with a
"list_members | sync_members", but I'd really prefer the owners to
be able to do it themselves.

Which reminds me, another thing I've been wanting to add is
"download members as text file" (basically the same as 1 above),
which would go together with the sync_members option.

Matthew


-- 
Matthew Newton <mcn4 at le.ac.uk>

UNIX and e-mail Systems Administrator, Network Support Section,
Computer Centre, University of Leicester,
Leicester LE1 7RH, United Kingdom

From tkikuchi at is.kochi-u.ac.jp  Thu Jun 22 02:38:52 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Thu, 22 Jun 2006 09:38:52 +0900
Subject: [Mailman-Developers] SoC: status update
In-Reply-To: <4499A358.2040005@mindlace.net>
References: <4499A358.2040005@mindlace.net>
Message-ID: <4499E69C.5020009@is.kochi-u.ac.jp>

emf wrote:
> http://wiki.list.org/display/DEV/Summer+of+Code
> 
> Gentlebeings,
> 
> I have updated the summer of code page above to indicate my current 
> progress and record the synthesis of the opinions I have received so far.
> 
> Thank you for the excellent feedback you've provided so far; don't be 
> shy about continuing, either here or on the wiki.
> 
> ~ethan fremen

Hi Ethan,

Since you are working on Web Interface, I have an important 
suggestion/request on the charset we use.

I think we should use 'UTF-8' exclusively on WUI.  We can eliminate many 
problems we have on current web pages including the pipermail archive, 
while current language-charset database should be retained for email 
message usage.

Cheers,

-- 
Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/


From sub1.dev.mailman at msquared.id.au  Thu Jun 22 03:39:04 2006
From: sub1.dev.mailman at msquared.id.au (Msquared)
Date: Thu, 22 Jun 2006 09:39:04 +0800
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060622013904.GQ29847@sliderule.msquared.com.au>

On Wed, Jun 21, 2006 at 02:09:44PM +0100, Ian Eiloart wrote:

> 2) Delete ALL the list members with one click - OK, and maybe a confirm 
> dialog!

Don't forget to fail gracefully if there is no Javascript (ie: server-side
generates the confirm dialog).

Regards, Msquared...

From dandrews at visi.com  Thu Jun 22 07:50:06 2006
From: dandrews at visi.com (David Andrews)
Date: Thu, 22 Jun 2006 00:50:06 -0500
Subject: [Mailman-Developers] Fwd: Re: Hi! I'll be your intern for the
 summer :)
Message-ID: <7.0.1.0.2.20060622004949.0377a4d0@visi.com>


>Date: Wed, 21 Jun 2006 21:50:57 -0500
>To: emf <i at mindlace.net>
>From: David Andrews <dandrews at visi.com>
>Subject: Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
>
>>Ethan Freeman Said:
>>Thanks for all the references. If you know of a way that I can actually 
>>test JAWS or another screen reader, I would be grateful for the pointer.
>>
>>~ethan fremen
>
>Hi:
>
>I am a blind guy who runs a bunch of lists who is hanging out here, just for this.  I will be happy to help you test your pages.  Also, you can download demo versions of JAWS http://www.freedomscientific.com and Window-Eyes http://www.gwmicro.com
>
>However, unless you are an experienced user, there can be dangers in sighted guys doing this kind oftesting.  I spent half an hour on the phone one day trying to explain to a developer how you entered data into a web form, and why it was different than from him and his mouse.  Some of the cues are pretty subtle, and unless you are used to them you might not realize they aren't there if things are kind of sort of working.
>
>Dave


From iane at sussex.ac.uk  Thu Jun 22 12:33:07 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 22 Jun 2006 11:33:07 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <449983E0.90504@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
Message-ID: <913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>



--On 21 June 2006 13:37:36 -0400 emf <i at mindlace.net> wrote:

> Ian Eiloart wrote:
>
>> How about this for extra:
>>
>> 1) Display a list of ALL members - just their names and addresses.
>> 2) Delete ALL the list members with one click - OK, and maybe a confirm
>> dialog!
>
> Hm. This comes slightly in opposition to the desire to have a more
> user-centered mailman interface; what happens if a user changes their
> preferences and you re-build the entire list?

Well, for some of our lists it's simply inappropriate for users to set 
preferences. Let me give you an instance. We're a University. People make 
enquiries about studying here. We have to send an email to all of those 
people because -say- there's been a change in the registration process.

> An associated problem is what happens to users that are subbed to >1 list?
>
> I recognize this may not be an issue in your specific case, I just think
> that issues like these will be more of a deal when we don't keep
> "members" in per-list silos.
>
> Perhaps something that might be more appropriate would be a "member
> differ", wherein you upload a list of email addresses, and it shows you
> the list of emails that were on the list but aren't now, and those that
> would be added, and gives you the option to either accept all the
> changes or selectively modify them.
>
> When you say you'd like these people to be able to take advantage of
> "other mailman features", which features do you mean?

Well, our MTA won't accept more than 250 recipients per email, so when 
people need to email several thousand recipients, they have to split their 
recipient lists into blocks. It would be much better to simply paste them 
into a Mailman web UI, and let Mailman handle the details.

Why 250? Well, actually that's because our LDAP server barfs if you make 
more than about 300 queries on one connection. Those queries might be 
validating local email addresses.

So, I could implement this another way, but Mailman also offers me 
authentication and authorisation, and allows me to ensure proper footers on 
the emails, and probably some other useful stuff too.

> ~ethan fremen
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe:
> http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a
> c.uk
>
> Security Policy:
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp



-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun 22 12:38:01 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 22 Jun 2006 11:38:01 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <20060621224549.GA4684@ultra.le.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net> <20060621224549.GA4684@ultra.le.ac.uk>
Message-ID: <5EAC83B5E43F2A7382BDE72A@lewes.staff.uscs.susx.ac.uk>



--On 21 June 2006 23:45:49 +0100 Matthew Newton <mcn4 at leicester.ac.uk> 
wrote:

> On Wed, Jun 21, 2006 at 01:37:36PM -0400, emf wrote:
>> > How about this for extra:
>> >
>> > 1) Display a list of ALL members - just their names and addresses.
>> > 2) Delete ALL the list members with one click - OK, and maybe a
>> > confirm  dialog!
>
>> Perhaps something that might be more appropriate would be a "member
>> differ", wherein you upload a list of email addresses, and it shows you
>> the list of emails that were on the list but aren't now, and those that
>> would be added, and gives you the option to either accept all the
>> changes or selectively modify them.
>
> This sounds like the command-line "sync_members" program. I've
> been meaning to add a web interface to that for a while, but
> haven't managed to get around to it.

Yes, that's exactly it. In fact, I use sync_members to sync some student 
and staff lists with our personnel database. However, there are some lists 
that need to be synced occasionally with - for example - excel spreadsheets 
that belong to people without access to our servers.

> I guess it depends on what you use Mailman for. In then general
> internet-user-subscribes-themselves-mailing-list it's great. For a
> University with central management of some lists, it isn't quite
> what is needed all the time.
>
> One thing that happens each year here for some lists is that all
> list members of "course-year2" get moved to "course-year3",
> "course-year1" to "course-year2", and new members added to
> "course-year1". I can do this easily from the command line with a
> "list_members | sync_members", but I'd really prefer the owners to
> be able to do it themselves.

Another way of managing that is to name the lists after the year that the 
student enrolled. For example course-2004, course-2005. That way you only 
need to handle the occasional student who suspends studies for a year, or 
something. If you like, you can create aliases (in your MTA config) like 
course-year1 for the list names and just move the pointers at the relevant 
time.

> Which reminds me, another thing I've been wanting to add is
> "download members as text file" (basically the same as 1 above),
> which would go together with the sync_members option.
>
> Matthew



-- 
Ian Eiloart
IT Services, University of Sussex

From lcarlson at d.umn.edu  Thu Jun 22 16:22:25 2006
From: lcarlson at d.umn.edu (Laura Carlson)
Date: Thu, 22 Jun 2006 09:22:25 -0500
Subject: [Mailman-Developers] Forms Acessibility (was Re: Hi! I'll be your
 intern for the summer :)) summer :)
Message-ID: <ACBA54DA2410A50DFAAA81EA@lcarslon.d.umn.edu>

--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote:

> Thanks very much for your feedback, Laura! I am something of a
> standards  fanatic; all the pages I've re-written so far have made
> heavy use of  label (although I use the implicit label where
> possible), fieldset,  legend, thead & tbody and the title attribute
> to provide as much support  for assistive technologies and
> alternative renderings as I can.

Wonderful news to hear that you support accessibility and web 
standards, Ethan. Yes, fieldset, legend, thead, tbody and the title 
attributes are very important for structural markup.

> Once I have a clear idea what form elements will be where, I am also
> going to add tabindex and accesskey attributes to the form elements.

I would like to mention a few things regarding implicit labels, 
accesskeys, and tabindex.

LABELS

The W3C identifies two different types of labels: implicit and explicit 
[1]. Basically, the difference is that implicit labels are an older, 
(deprecated in WCAG 2.0) technique that wrap around their target field 
elements; explicit labels use the for attribute to indicate which form 
element they describe (that value of the for attribute is the id of the 
element it describes.

I would caution against using implicit labels. Explicit association is 
preferable. WCAG 1.0 12.4 advises web developers to "Associate labels 
explicitly with their controls."[2]

It also says in section 508:
"Experience has shown that implicit labeling should be avoided for two 
reasons. First, implicit labeling is not reliably supported by many 
screen readers and, in particular, does not work well if explicit 
labels are simultaneously used anywhere on the same web page. Often, 
the output can be wildly inaccurate and confusing. Second, if any text 
separates a label from its associated form element, an implicit label 
becomes impractical and confusing because the label itself is no longer 
easily identified with the form element.[3]"  For an illustration of 
this visit Roger Hudson's Web Essential 05 Association Examples [4].

If you use explicit labels, you're specifically providing information 
about each form element. Each form control should have its own LABEL. 
Add the FOR attribute to tie the LABEL to the form control's ID 
attribute.

ACCESSKEYS

Something to be aware of is that the current opinion of many 
accessibility experts is that accesskeys mostly work against 
accessibility.

Because of the many conflicts, defining accesskeys seems to be a waste 
of time unless you are designing for a controlled environment such as 
an intranet. Joe Clark suggests that there are at least 36 characters 
that can be used for accesskey attributes [5]. However, John Foliot's 
and Derek Featherstone's [6] [7] unofficial survey/research concluded 
that there really are no useful access keys not already reserved by 
some application or other. When you take internationalization issues 
into account, it becomes pretty much of a hopeless cause.

Part of this is that browsers by default don't indicate the accesskey 
assignments or tabbing order. No one argues with the idea behind 
accesskey, and it's usefulness. But given the current state of affairs, 
and the potential for confusion and/or conflict with various adaptive 
technologies, they have issues.

So... Based on the existing issues I usually  advise developers to not 
use accesskeys. However, best practice is that IF accesskeys are used:

- Always supply a legend that defines the accesskeys.
- Make sure this legend is on or available from every page on the 
site...perhaps in an accessibility statement.
- Supply title attributes on any accesskeys used.
- Keep the number of accesskeys to a minimum.
- Test to make sure that accesskeys help usability more than they 
hinder accessibility.

TABINDEX

If you have a logical page design tabindex isn't usually necessary. By 
default, with no tabindex attributes present, the browser will tab 
through elements in the order in which they appear in the source code. 
Using just one tabindex for the first field like you did for the 
exercise isn't bad, but just having a sensible natural order to start 
with, meets WCAG requirements for HTML documents.

If the tabindex attribute is not assigned to all fields, JAWS first 
moves through the items with a tabindex assigned, then moves through 
the other form fields and links in the order they appear on the page.

You can usually lighten your HTML and usually forego tabindex. But if 
there is something very weird with link or form presentation so they 
don't function in a sensible order it can be helpful to have a 
tabindex. In any event I suggest it may be better to avoid having a 
weird ordering in HTML. If tabbing needed to come in anything but their 
natural order, I think I would probably regard my document structure as 
flawed and would rework it. When a form is well structure, and still 
reflects that structure when styles are turn off, the tab flow is often 
the same with or without coding tabindex. If that is the case, don't 
bother coding it when tab order is simple and clear.

The W3C checkpoint [8] that actually refers to tabindex essentially 
says specify tab order via the tabindex attribute or ensure a logical 
page design. Often people seem to forget about the logical tab order 
that almost always exists and is reasonable. In fact, I'd say you have 
to work pretty hard to actually need to go outside the logical order 
that naturally exists within standards-based sites. Further, when 
people do implement tabindex, sometimes it breaks expected interaction 
because the order is either non-intuitive or it is completely out of 
line with where you think you are headed next.

In my experience tabindex just makes forms more annoying to use. In 
most cases I'd rather web developers just let the browser get on with 
working out the tab order and stop trying to guess where the user wants 
to tab to.

Ethan, thanks for all of your hard work.

All the best,
Laura

[1] http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#label
[2] http://www.w3.org/TR/WCAG10-TECHS/#tech-associate-labels
[3] http://www.access-board.gov/sec508/guide/1194.22.htm#(n)
[4] http://we05.com/resources/roger-hudson/association_examples.html
[5] http://joeclark.org/book/sashay/serialization/Chapter08.html#p-4125
[6] http://www.wats.ca/show.php?contentid=43
[7] http://www.wats.ca/show.php?contentid=32
[8] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-tab-order

___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN  55812-3009
http://www.d.umn.edu/goto/webdesign/

From lcarlson at d.umn.edu  Thu Jun 22 16:23:02 2006
From: lcarlson at d.umn.edu (Laura Carlson)
Date: Thu, 22 Jun 2006 09:23:02 -0500
Subject: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi! I'll
 be your intern for the summer :))
Message-ID: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>

--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote:

> If you know of a way that I can
> actually  test JAWS or another screen reader, I would be grateful for
> the pointer.

David Andrews already mentioned the demo versions of JAWS and 
Window-Eyes [1]. Thank you Dave for offering to help test! Dave can 
provide valuable insights and expertise. Human Evaluation is very 
important  [2]. Ethan please do download and try a screen reader. But 
like Dave said, it is best for inexperienced users not make design 
decisions based on their experiences with screen readers. It?s just too 
different from someone who uses the technology on a daily basis, 
because they have to.

Home Page Reader [3] is also a good tool for web developers and 
designers who are looking to try out a speaking browser. It will give 
you somewhat of an idea of how the blind or visually impaired would 
experience your pages. It presents a web page in two different views. 
It places the graphics view, a true rendering of the Web page, in the 
upper portion of the program window. Then, it shows a text view of the 
Web page in a window below that graphics view. Again, you'll gain an 
appreciation for what a blind user would hear when listening to your 
Web page. There is a free 30 day free demo available.  There is also a 
tutorial on Testing Web accessibility with Home Page Reader available 
[4]

One of the tools that I have my students use is to test forms is the 
WAVE. [5]  It will spot violations like missing labels, labels not 
associated with inputs, empty labels, etc. and notify you with icons. 
[6]

Cynthia [7] is also one online tool that every web developer should be 
familiar with. In the hands of someone trained to do accessibility 
checks, it's really no better or worse than any of the other tools. 
Cynthia analyzes web pages and checks for a set of accessibility 
problems that can be checked for automatically. Although it is a very 
limited program, it is also a good program. It can help with the 
checking process. The rest needs to depend upon human judgement.

There's a great little Colour Contrast Analyser Firefox Extension [8] 
by Gez Lemon I have found useful lately. It saves time and helps take 
the guesswork out of determining accessible color combinations. It can 
go through a page and check (give you pass or fail) on luminosity 
contrast ratios, difference in brightness, and difference in color.

Many, many more helpful accessibility tools exist. To get an idea of 
the number visit the Tool Section of the Web Design Reference. [9]

All the best,
Laura

[1] http://tinyurl.com/e9bno
[2]http://webaim.org/articles/process/human.php
[3] http://www-3.ibm.com/able/solution_offerings/hpr.html
[4] http://www-3.ibm.com/able/guidelines/web/webhprtest.html
[5] http://www.wave.webaim.org/wave/index.jsp
[6] http://www.wave.webaim.org/wave/explanation.htm
    (Scroll down to the forms section)
[7] http://www.contentquality.com/
[8] http://tinyurl.com/awlqm
[9] http://www.d.umn.edu/goto/tools
___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN  55812-3009
http://www.d.umn.edu/goto/webdesign/

From carbonnb at gmail.com  Thu Jun 22 21:37:43 2006
From: carbonnb at gmail.com (Bryan Carbonnell)
Date: Thu, 22 Jun 2006 15:37:43 -0400
Subject: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi!
	I'll be your intern for the summer :))
In-Reply-To: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
References: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
Message-ID: <e04a6c920606221237g21103d20p1326403810a3ff2e@mail.gmail.com>

> --On Thursday, June 22, 2006 4:15 AM +0200 emf wrote:
>
> > If you know of a way that I can
> > actually  test JAWS or another screen reader, I would be grateful for
> > the pointer.

If you are a Firefox user, there is an extension called Fangs [1] that
emulates the output from JAWS. It doesn't speak it, rather it dipslays
in text what JAWS would speak.

[1] http://www.standards-schmandards.com/fangs

-- 
Bryan Carbonnell - carbonnb at gmail.com
Life's journey is not to arrive at the grave safely in a well
preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"

From fil at rezo.net  Thu Jun 22 22:40:49 2006
From: fil at rezo.net (Fil)
Date: Thu, 22 Jun 2006 22:40:49 +0200
Subject: [Mailman-Developers] a picture,
	and a problem with the Debian package
Message-ID: <20060622204048.GO522@rezo.net>

Hello,

here's a nice picture. The answer is in the mail
http://www.flickr.com/photos/82626280 at N00/172609494/

More seriously (or, maybe, less), I've spent a few minutes trying to figure
out a problem a user was having (on irc). The problem was that she had
configured the list to be in Spanish, but it kept sending welcome messages
in English.
I finally traced it to the Debian installation, which has weird symlinks:
        /var/lib/mailman/templates -> /etc/mailman

ls -al /etc/mailman/
total 36
drwxr-xr-x  4 root list 4096 2006-04-22 19:46 .
drwxr-xr-x 95 root root 8192 2006-06-21 10:41 ..
drwxr-xr-x  2 root root 4096 2005-10-04 18:17 en
drwxr-xr-x  2 root root 4096 2006-02-10 17:46 fr

that's 2 languages only!
whereas /usr/share/mailman/ contains all the templates (including es/, which
she linked into /etc/mailman/ and solved the problem)

For me, if this is confirmed and not a weird thing on my and her Debian
installation, it's a problem that should be solved.

-- Fil


From lionel at mamane.lu  Fri Jun 23 00:12:11 2006
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Fri, 23 Jun 2006 00:12:11 +0200
Subject: [Mailman-Developers] multilingual templates in Debian mailman [was:
	a picture, and a problem with the Debian package]
In-Reply-To: <20060622204048.GO522@rezo.net>
References: <20060622204048.GO522@rezo.net>
Message-ID: <20060622221211.GA7792@capsaicin.mamane.lu>

(I'm the currently least inactive maintainer of the Debian package.)

On Thu, Jun 22, 2006 at 10:40:49PM +0200, Fil wrote:

> The problem was that she had
> configured the list to be in Spanish, but it kept sending welcome messages
> in English.
> I finally traced it to the Debian installation,

When installing the mailman package, you got asked which languages you
want that site to support. You didn't include Spanish in the list. Use
"dpkg-reconfigure mailman" to change the list. All languages supported
by a list on the site are forced on, meaning if you turn them off,
they are turned back on in your back.

> which has weird symlinks:
>         /var/lib/mailman/templates -> /etc/mailman

Templates can be changed by the administrator and are thus considered
as configuration files and are thus in /etc/, as per Debian policy
(and Linux FHS). This guarantees that a package upgrade won't override
changes the administrator may have made.

> whereas /usr/share/mailman/ contains all the templates (including es/, which
> she linked into /etc/mailman/ and solved the problem)

That linking may or may not confuse the maintainer scripts of the
package, I'm not sure. If you want to play it safe, have your user
remove that link and use "dpkg-reconfigure mailman".

-- 
Lionel

From fil at rezo.net  Fri Jun 23 14:02:10 2006
From: fil at rezo.net (Fil)
Date: Fri, 23 Jun 2006 14:02:10 +0200
Subject: [Mailman-Developers] multilingual templates in Debian mailman
	[was: a picture, and a problem with the Debian package]
In-Reply-To: <20060622221211.GA7792@capsaicin.mamane.lu>
References: <20060622204048.GO522@rezo.net>
	<20060622221211.GA7792@capsaicin.mamane.lu>
Message-ID: <20060623120208.GM522@rezo.net>

> When installing the mailman package, you got asked which languages you
> want that site to support. You didn't include Spanish in the list. Use
> "dpkg-reconfigure mailman" to change the list. All languages supported
> by a list on the site are forced on, meaning if you turn them off,
> they are turned back on in your back.

Why are not all templates installed, instead of only a subset?
What happens if Mailman adds a template, or modifies one?

> > which has weird symlinks:
> >         /var/lib/mailman/templates -> /etc/mailman
> 
> Templates can be changed by the administrator and are thus considered
> as configuration files and are thus in /etc/, as per Debian policy
> (and Linux FHS). This guarantees that a package upgrade won't override
> changes the administrator may have made.

OK. Why are not the templates in /etc/mailman/templates/ ? I find this
a bit confusing

> That linking may or may not confuse the maintainer scripts of the
> package, I'm not sure. If you want to play it safe, have your user
> remove that link and use "dpkg-reconfigure mailman".

I'll tell her if she comes back on the irc channel :)

Thanks for the explanations

-- Fil


From lionel at mamane.lu  Sat Jun 24 11:22:38 2006
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Sat, 24 Jun 2006 11:22:38 +0200
Subject: [Mailman-Developers] multilingual templates in Debian mailman
	[was: a picture, and a problem with the Debian package]
In-Reply-To: <20060623120208.GM522@rezo.net>
References: <20060622204048.GO522@rezo.net>
	<20060622221211.GA7792@capsaicin.mamane.lu>
	<20060623120208.GM522@rezo.net>
Message-ID: <20060624092238.GA20342@capsaicin.mamane.lu>

On Fri, Jun 23, 2006 at 02:02:10PM +0200, Fil wrote:

>> When installing the mailman package, you got asked which languages
>> you want that site to support. You didn't include Spanish in the
>> list. Use "dpkg-reconfigure mailman" to change the list. All
>> languages supported by a list on the site are forced on, meaning if
>> you turn them off, they are turned back on in your back.

> Why are not all templates installed, instead of only a subset?

For disk space usage reasons. I think previous versions did that (it
was before I became really active in the Debian mailman
package). People with tiny root partitions complained loudly, so the
current compromise was implemented.

> What happens if Mailman adds a template, or modifies one?

If mailman adds a template, you can add it to the supported set with
"dpkg-reconfigure mailman". Maybe you'll even be asked on upgrade.

If mailman modifies a template:

 - If the administrator has not modified the same template, too, then
   the new mailman template gets installed on upgrade.

 - If the administrator has modified the same template, the upgrade
   procedure shows hir the old Mailman template, the new Mailman
   template, the version that is now in /etc/mailman/XX/foo, diffs
   between those, etc and asks him what to do (keep what's now in
   /etc/mailman/XX/foo, install the new mailman template, try to apply
   the diff between the old and new mailman template to what's now in
   /etc/mailman/XX/foo, give the administrator a shell to sort it out
   manually, ...)

>>> which has weird symlinks:
>>>         /var/lib/mailman/templates -> /etc/mailman

>> Templates can be changed by the administrator and are thus
>> considered as configuration files and are thus in /etc/, as per
>> Debian policy (and Linux FHS). This guarantees that a package
>> upgrade won't override changes the administrator may have made.

> OK. Why are not the templates in /etc/mailman/templates/ ? I find
> this a bit confusing

/etc/mailman/templates/ would have been a good choice indeed.

-- 
Lionel

From terri at zone12.com  Thu Jun 29 04:34:19 2006
From: terri at zone12.com (Terri Oda)
Date: Wed, 28 Jun 2006 22:34:19 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <44987D48.4020406@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
	<44987D48.4020406@mindlace.net>
Message-ID: <9ced0e5e3f834347af6ae56585c85649@zone12.com>

Oh, goodness, Ethan... I was excited when Barry told me we were getting 
a SoC student to do this, and you sound *exactly* what we need.  I'll 
try to restrain myself from declaring everlasting love until I've seen 
some finished work, but I will say that I'm very happy to have you on 
the project.  (Even if I'll probably have to rewrite all the docs once 
you're done... ;)  )

1. Integration with look/feel of people's existing websites

As others have said, the biggest question I get from people is usually 
along the lines of "How can I make Mailman fit in to the rest of my 
website?"   Some of the, you aren't going to have much control over 
(Top of list: why can't we just have users with one password for 
mailman and everything else?) but things like making the interface all 
css friendly (is the plan for it to be all xhtml-compliant?) and 
providing configurable headers and footers will make a pretty huge 
difference right there.

2. Simplified (possibly customizable?) interface as an option

I'd also like to see it possible to make a page that contains a 
simplified version of the interface.  I, as a geek, love having a 
billion settings to mess with, but lots of list managers aren't so 
inclined, and it'd be nice to give them just a simple (customizable) 
set of functions so they don't throw up their hands and decide that 
mailman is too scary.  This could probably be done if the xhtml gives 
us control over each item to be displayed, and different people could 
use different templates with the options they don't want/need turned 
off.  I can imagine even terribly technical users might like to have a 
mailman admin page which just contains the things they use most often 
so they don't have to delve into the entire interface all the time.

This might, incidentally, help a lot with the 
completeness-versus-simplicity problem that is inherent in all 
interfaces.   It might also make my job as a documenter hellishly 
difficult when people start emailing me and saying "but I don't have 
that option!" but I can deal with that. ;)

3. Organization

I dislike the way the list admin interface is currently organized.  
People are forever looking for things in the wrong places, which is 
probably a sign that the things are in the wrong places and we should 
maybe move them. :)   I wish I had time to figure out what these places 
are and tell you, but if you start finding the same thing, or you get 
people testing your designs and going to the wrong spot, make note, 
please?

4. Wishful thinking....

I don't suppose you'll have time to make some of the options less 
utterly confusing?  For example, I've yet to have anyone guess what an 
umbrella list was and what it's for unless they were already familiar 
with mailing lists...

5. Archives?

Are you going to get a chance to touch the archives?  A lot of the same 
things apply for templating there, and people always want that same 
look/feel.

Of course, I really really want to replace pipermail with something a 
bit more modern (I'm looking at finding a nice way to use apache's 
mbox_mod for my current lists -- if anyone's got instructions for that, 
drop me a line!), but I think that's a little outside your scope. :)  
Still, getting  it so the archives at least use the same CSS might be 
nice.

---

I'll probably think of a dozen more things to say later, but as 
everyone else seems to have covered the most important things I'll try 
to restrain myself a bit. :)  I'm very excited to see this happen, 
though -- I think the web interface is often heralded as one of 
Mailman's strengths, and it'll be nice to see it a bit more polished 
and modern and less like someone's opened up a dusty panel and let us 
grab all the live wires we want. :)

  Terri


From brad at stop.mail-abuse.org  Thu Jun 29 06:06:48 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 29 Jun 2006 00:06:48 -0400 (EDT)
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <9ced0e5e3f834347af6ae56585c85649@zone12.com>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]> <44987D48.4020406@mindlace.net>
	<9ced0e5e3f834347af6ae56585c85649@zone12.com>
Message-ID: <48587.72.177.126.107.1151554008.squirrel@mail.his.com>

Terri Oda said:

> 5. Archives?
>
> Are you going to get a chance to touch the archives?  A lot of the same
> things apply for templating there, and people always want that same
> look/feel.

Check the Mailman 2.2 ToDo list at
<http://wiki.list.org/display/DEV/Mailman+2.2>.  If what you want is not
already covered there, please feel free to add a comment at the bottom.

> Of course, I really really want to replace pipermail with something a
> bit more modern (I'm looking at finding a nice way to use apache's
> mbox_mod for my current lists -- if anyone's got instructions for that,
> drop me a line!), but I think that's a little outside your scope. :)

Better support of third-party archiving systems is also on the list.

> Still, getting  it so the archives at least use the same CSS might be
> nice.

Yup.  Also note that Ethan has his own ToDo space at
<http://wiki.list.org/display/DEV/Summer+of+Code>.

> I'll probably think of a dozen more things to say later, but as
> everyone else seems to have covered the most important things I'll try
> to restrain myself a bit. :)  I'm very excited to see this happen,
> though -- I think the web interface is often heralded as one of
> Mailman's strengths, and it'll be nice to see it a bit more polished
> and modern and less like someone's opened up a dusty panel and let us
> grab all the live wires we want. :)

IME, Mailman is a huge improvement over Majordomo+Majorcool, but could
certainly use more work to make it both simpler and easier to use
(especially for neophyte list participants and less experienced list
admins), while also making it more powerful and easier to use for the more
experienced people out there.

>From everything I've seen, I think Ethan's work is going to be a huge
improvement in both areas.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From i at mindlace.net  Thu Jun 29 07:14:14 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 01:14:14 -0400
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <9ced0e5e3f834347af6ae56585c85649@zone12.com>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
	<44987D48.4020406@mindlace.net>
	<9ced0e5e3f834347af6ae56585c85649@zone12.com>
Message-ID: <44A361A6.6020708@mindlace.net>

Terri Oda wrote:

> 1. Integration with look/feel of people's existing websites
> 
> As others have said, the biggest question I get from people is usually 
> along the lines of "How can I make Mailman fit in to the rest of my 
> website?" 

The main thing I'm doing in this regard is building each piece of 
functionality, down to individual options, as separate pages/page 
snippets that will work if embedded into another page.

If the user has JavaScript and a browser that supports XMLHttpRequest, 
the form submissions will happen asynchronously and feedback will occur 
within the site's page; if they do not they will go to a 
mailman-specific page that can still be styled by the site administrator.

>  Some of the, you aren't going to have much control over (Top 
> of list: why can't we just have users with one password for mailman and 
> everything else?)

While I can't take this on this summer, I am building "as if" mailman 
has a concept of a user and - if Barry doesn't come back from vacation 
with a Super Happy Report with regards to SQLAlchemy - writing glue code 
to make the UI behave as if there were a concept of a user. Said glue 
code should be able to handle the site providing user/pass details, as 
it will already be looping through the list(s) collecting user/pass details.

There are some icky complications with this- if the site doesn't notify 
the glue code a user's pass has changed, it won't be for mailman, and if 
the code gets halted before it updates all the passwords for a user the 
user might end up with some lists failing to allow auth.

It comes down to me not being able to figure out how to make a user 
interface for software with no real concept of a user, so I will do the 
lifting required to at least generate the appearance of such.

> but things like making the interface all css friendly 
> (is the plan for it to be all xhtml-compliant?)

Unless I am forced to go transitional by browser vagarities, all my 
pages will be xhtml strict.

> and providing 
> configurable headers and footers will make a pretty huge difference 
> right there.

The headers and footers are going to be window dressing*. Every single 
other component will be embeddable from any program capable of fetching 
an url using basic auth.

* they will of course be stylish and customizable, but from what I've 
seen, the First Thing every site administrator wants to do is rip chunks 
out of the UI and embed them into their pages.

> 2. Simplified (possibly customizable?) interface as an option

I'm using standard elements and CSS's ability to style child nodes as 
much as possible; this means that interface elements should take on the 
site's styles "automagically", with the possible requirement of adding 
selectors for those sub-elements they hadn't styled themselves.

(It is making me wish I didn't have to specify *which* header level I 
meant, but enh.)

> I'd also like to see it possible to make a page that contains a 
> simplified version of the interface. 

My thought is I don't know in advance which options are most important 
to which users.

Therefore I'm working on a page that (ala google's customized home page) 
lets you drag/drop option elements around (or reorder them via form 
submissions, if you're without javascript).

I'm also making a config page for a site/domain/list administrator that 
will allow the specification of which options should be available and in 
what order.

> 3. Organization
> 
> I dislike the way the list admin interface is currently organized.  

a-bloody-men to that. The first thing I've done is move the wordy and 
visually cluttering help text and its confusing sub-pages with more help 
into pop up / submit-form-to-display elements.

The other half of that is as above; I don't think I know the Right 
Places, so I'll defer to the site administrator as to which options 
should be presented in which order.

> 4. Wishful thinking....
> 
> For example, I've yet to have anyone guess what an 
> umbrella list was and what it's for unless they were already familiar 
> with mailing lists...

The help thing might address this issue, but the other side of this 
point is that I will try to provide a "task centric" approach; the 
current interface is noun heavy and verb light. I'm going to try to 
offer a "so you want to..." interface option so that people can figure 
out they want an umbrella list, for example.

> 5. Archives?
> 
> Are you going to get a chance to touch the archives?  A lot of the same 
> things apply for templating there, and people always want that same 
> look/feel.

Yes. Basically my approach is punting on pre-rendering archives entirely 
in favor of dynamically rendering* the .mbox / rfc8222 files as 
xhtml/RSS/atom.

This will avoid the "re-archiving your 10 years of archives totally 
horks your box" situation I encountered once, a while ago. Additionally 
it will eliminate the maddening index-by-artificial-date-segment stuff 
that currently amputates threads. Finally, the "private/public archives 
have totally different paths" bit will be gone.

Again all eye candy will be provided by CSS, not the underlying xhtml, 
and site administrators will be able to call the archive-browsing widget 
directly, bypassing the header/footer otherwise placed on the archives.

* I intend to cache the most expensive bits, like the thread tree, and 
archive views that have already been rendered, so that a historical 
thread that suddenly becomes popular won't kill your box.

This will, however, place additional CPU load on the box, especially if 
people opt to read mailing lists in their feed reader; OTOH, right now 
you can't see what people are talking about until the pipermail process 
kicks off, so I suspect it will be tolerable.

~ethan



From barry at python.org  Thu Jun 29 11:26:15 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:26:15 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <182F894DC73A6D27677F14F0@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<62B0E6E7-64F0-4B8E-B26F-AE2F1C41F2DD@python.org>
	<182F894DC73A6D27677F14F0@lewes.staff.uscs.susx.ac.uk>
Message-ID: <B9BD49D4-1E2F-423A-B89A-0F2766EE914A@python.org>

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

On Jun 19, 2006, at 3:31 AM, Ian Eiloart wrote:

> Well, in our case, the styles would be site-wide and set up only  
> once. We don't need a UI to set up the styles, because we've  
> already created them. Our current workflow is
>    1. Create a list through the UI
>    2. Shell in to the list server
>    3. Run a script which applies the style to the list.
>
> I'd just like to avoid 2. and 3. by having some UI to apply the  
> style on creation  - like the subethaedit example. I guess it would  
> be nice for the CGI to look for a style file at -say- /mailman/ 
> styles/foo.style and a text description at /mailman/styles/ 
> foo.description - or to extract the description from the style file.

This is definitely possible, and not at all difficult.  I had some  
working examples in the mm3 branch.  It might be possible to get  
something like this into 2.2.

- -Barry

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

iQCVAwUBRKOct3EjvBPtnXfVAQKyQAQAlngoFyRl1V+nSqFhU3PaBtRaQLaOa9Dy
8mJKhEiS8DU3q3uKFd9oxVUOogQRKn1EEeWTO/pxVqIR4jaoRdl3270QH42WAbSJ
9OBgCDce+az/ed33ChUobRAytllPJdc6RjqPRuFwrKx2Qif1JSBnzTFo6yFhhPGN
FDMrvS/1jUA=
=J0cH
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 29 11:30:54 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:30:54 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <Pine.GSO.4.58.0606210938260.4594@arachne.dur.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<Pine.GSO.4.58.0606210938260.4594@arachne.dur.ac.uk>
Message-ID: <294740E2-ED08-4C61-97A1-7A39558FBA63@python.org>

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

On Jun 21, 2006, at 1:47 AM, David Lee wrote:

> One of the things on the TODO list:
>    http://www.gnu.org/software/mailman/todo.html
> is:
>     Allow lists of the same name in two different virtual domains
>
> (i.e. "thislist at somedom.com" and "thislist at otherdom.org", where  
> "thislist"
> and "thislist" are the same name).

I've started working on this in my 2.2 branch, but haven't ironed out  
all the details yet.  It's a top priority for me, but there are some  
gotchas.  I still think it's doable.

- -Barry

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

iQCVAwUBRKOdznEjvBPtnXfVAQK7PwP/aXNj1xz2bpH7iFhNHTQ1rHprGMiR1a6r
x58V3F9XtCt03gHtN2QP6lg13CJ8NDyQOIAAbnmzNWMA+7w0X5NqnzpGULJi2PwP
BwFsLsiwMVDIHegFLv5Lm35usAP8uhD1Vx1xI958CKsalk7V3qM3Aakl7lQBOXZG
msDp88oUBGw=
=EyCe
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 29 11:36:10 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:36:10 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <449983E0.90504@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
Message-ID: <EC2F8730-7D37-4ACA-A82B-4B4859ED550B@python.org>

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

On Jun 21, 2006, at 10:37 AM, emf wrote:

>> How about this for extra:
>>
>> 1) Display a list of ALL members - just their names and addresses.
>> 2) Delete ALL the list members with one click - OK, and maybe a  
>> confirm
>> dialog!
>
> Hm. This comes slightly in opposition to the desire to have a more
> user-centered mailman interface; what happens if a user changes their
> preferences and you re-build the entire list?
>
> An associated problem is what happens to users that are subbed to  
> >1 list?
>
> I recognize this may not be an issue in your specific case, I just  
> think
> that issues like these will be more of a deal when we don't keep
> "members" in per-list silos.

Definitely, and what about when list memberships come from external  
rosters (e.g. external systems or generated on demand)?

- -Barry

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

iQCVAwUBRKOfCnEjvBPtnXfVAQJ89AP8DFF6sGVUUhS0kH/+yCmympS4MURhM6k7
1RJCq9M9hBFsS+ZrByWf9N042J+zYPmTeTB4UQEpNdDlauG3VVrcKODazu6juhiL
bpC1ccT2jZd22Q5gQcdSiMjE+qmXSrP1VgL9WSl2qC69IGdCNoKn31I3q452zN9x
mzCuMbq4c00=
=IpxP
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 29 11:38:35 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:38:35 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <20060621224549.GA4684@ultra.le.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<20060621224549.GA4684@ultra.le.ac.uk>
Message-ID: <598550B4-689D-4B6D-A2F0-52214A6F5AEB@python.org>

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

On Jun 21, 2006, at 3:45 PM, Matthew Newton wrote:

> One thing that happens each year here for some lists is that all
> list members of "course-year2" get moved to "course-year3",
> "course-year1" to "course-year2", and new members added to
> "course-year1". I can do this easily from the command line with a
> "list_members | sync_members", but I'd really prefer the owners to
> be able to do it themselves.
>
> Which reminds me, another thing I've been wanting to add is
> "download members as text file" (basically the same as 1 above),
> which would go together with the sync_members option.

What if we built a framework for site owners to add their own canned  
actions, or a per list or per domain basis?  A list owner wouldn't be  
able to do much more than click a button to invoke the action, but it  
would probably allow you to do both things.

- -Barry

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

iQCVAwUBRKOfm3EjvBPtnXfVAQLIvAQAiIPBm08SiXSzZJe2PGXLXlM265mFfjWV
TEgnku73Mf92VPvBUc9dmcp3K4Ans3MlFm1x196Wj+e953X9i1o0tb+TW8Gm3/GQ
TM/aQ3CmTm0omzk/0AyUSFAtGxgK71CHYxVWcSrJpwOaaPuX6jUbXMHtsBscwVWC
XWqJpM/50nE=
=MNp2
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 29 11:40:44 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:40:44 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
Message-ID: <FFF64F7A-699D-43DC-82BC-03F4C3637DB0@python.org>

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

On Jun 22, 2006, at 3:33 AM, Ian Eiloart wrote:

> Well, our MTA won't accept more than 250 recipients per email, so when
> people need to email several thousand recipients, they have to  
> split their
> recipient lists into blocks. It would be much better to simply  
> paste them
> into a Mailman web UI, and let Mailman handle the details.
>
> Why 250? Well, actually that's because our LDAP server barfs if you  
> make
> more than about 300 queries on one connection. Those queries might be
> validating local email addresses.

Is that per email or per smtp transaction?  If the latter,  
SMTP_MAX_RCPTS handles that.

- -Barry


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

iQCVAwUBRKOgHHEjvBPtnXfVAQLO7wP/VidKVEnoMK3FkxOjcvh/sMCDhFqhKWwm
pbUIrMNge83hSnAOtvheeGkIFC4jij+wUXpXinwRJET7b3s06rA0n16Tu11KLWTU
kueTs/5LRJMB6QhVoHuIP51pHyLt/tjpdT5jltrtjBlfsoH4FyiM7zwa7VVKKj+F
Gox2g4U2fJM=
=yHh7
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jun 29 11:43:29 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 02:43:29 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <9ced0e5e3f834347af6ae56585c85649@zone12.com>
References: <449202D8.8060805@mindlace.net>
	<p06200707c0b7e460d85d@[192.168.1.101]>
	<44987D48.4020406@mindlace.net>
	<9ced0e5e3f834347af6ae56585c85649@zone12.com>
Message-ID: <CACEA228-A444-4FEA-A79C-9A89766792A6@python.org>

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

On Jun 28, 2006, at 7:34 PM, Terri Oda wrote:

> Oh, goodness, Ethan... I was excited when Barry told me we were  
> getting
> a SoC student to do this, and you sound *exactly* what we need.  I'll
> try to restrain myself from declaring everlasting love until I've seen
> some finished work, but I will say that I'm very happy to have you on
> the project.  (Even if I'll probably have to rewrite all the docs once
> you're done... ;)  )

Can't add much except +1 to everything you said Terri! :)

- -Barry

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

iQCVAwUBRKOgwXEjvBPtnXfVAQKA/gP+Les6cw7wP1EePlKyNL7M2yWpBdWxTEra
GqTiO2uh8oY1ezuSUbZ+6JEjEh0p/PXhHDUAlHcg2emCr4d7ZzcXwpWs8lsln17P
W/kFOcitrpVI/IgSiqdZaILRC7gxEcJS2DYEIZNSRPRB+B0WP0g4sl7Jp9n5q5mA
oiyxh5HkemU=
=+Amo
-----END PGP SIGNATURE-----

From t.d.lee at durham.ac.uk  Thu Jun 29 11:46:44 2006
From: t.d.lee at durham.ac.uk (David Lee)
Date: Thu, 29 Jun 2006 10:46:44 +0100 (BST)
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <294740E2-ED08-4C61-97A1-7A39558FBA63@python.org>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<Pine.GSO.4.58.0606210938260.4594@arachne.dur.ac.uk>
	<294740E2-ED08-4C61-97A1-7A39558FBA63@python.org>
Message-ID: <Pine.GSO.4.58.0606291034210.4594@arachne.dur.ac.uk>

On Thu, 29 Jun 2006, Barry Warsaw wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jun 21, 2006, at 1:47 AM, David Lee wrote:
>
> > One of the things on the TODO list:
> >    http://www.gnu.org/software/mailman/todo.html
> > is:
> >     Allow lists of the same name in two different virtual domains
> >
> > (i.e. "thislist at somedom.com" and "thislist at otherdom.org", where
> > "thislist"
> > and "thislist" are the same name).
>
> I've started working on this in my 2.2 branch, but haven't ironed out
> all the details yet.  It's a top priority for me, but there are some
> gotchas.  I still think it's doable.

Many thanks.  That would be greatly appreciated.  We are a multiple-domain
site (one main, about thirty much smaller), making the transition from
majordomo to Mailman.  In general, Mailman is a huge improvement, but this
lack of true multiple-domain support is a significant retrograde aspect in
our transition.

Is there an estimate of likely timescale for 2.2 ?  (Yes, I know these
things slip!  But approximate: two months?  six months?  a year?)  When
you get to the beta stage, I would hope we could offer to try it.

Thanks.

-- 

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

From barry at python.org  Thu Jun 29 12:04:01 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jun 2006 03:04:01 -0700
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <Pine.GSO.4.58.0606291034210.4594@arachne.dur.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<Pine.GSO.4.58.0606210938260.4594@arachne.dur.ac.uk>
	<294740E2-ED08-4C61-97A1-7A39558FBA63@python.org>
	<Pine.GSO.4.58.0606291034210.4594@arachne.dur.ac.uk>
Message-ID: <8D985F5F-17E6-438C-B4C5-76BB18AC2A64@python.org>

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

On Jun 29, 2006, at 2:46 AM, David Lee wrote:

> Is there an estimate of likely timescale for 2.2 ?  (Yes, I know these
> things slip!  But approximate: two months?  six months?  a year?)   
> When
> you get to the beta stage, I would hope we could offer to try it.

I'd really like to see a 2.2 in 2006, but I haven't worked backward  
to think about what an alpha/beta schedule would look like to  
accomplish that.

- -Barry

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

iQCVAwUBRKOlkXEjvBPtnXfVAQJmbwP8D0GlbihIIHEvimZ3rCvR+HV/Gd+1JaqN
ClMR1DPrIA09tDzY+MOwzZrdji+mNRUeAsjxv9kiEh9Bo548SO61PNFTNcsmPQB2
Y4uqeRSSYRbv+H/63AXamLhKefuJMRZlldn5lrXpnTOszFCI7trodPwM+/J/JJZN
5SHTxTVfOJ0=
=LYaC
-----END PGP SIGNATURE-----

From iane at sussex.ac.uk  Thu Jun 29 12:11:56 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 29 Jun 2006 11:11:56 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <FFF64F7A-699D-43DC-82BC-03F4C3637DB0@python.org>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
	<FFF64F7A-699D-43DC-82BC-03F4C3637DB0@python.org>
Message-ID: <F1DFE0B0575AC98E0B3C729F@lewes.staff.uscs.susx.ac.uk>



--On 29 June 2006 02:40:44 -0700 Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jun 22, 2006, at 3:33 AM, Ian Eiloart wrote:
>
>> Well, our MTA won't accept more than 250 recipients per email, so when
>> people need to email several thousand recipients, they have to
>> split their
>> recipient lists into blocks. It would be much better to simply
>> paste them
>> into a Mailman web UI, and let Mailman handle the details.
>>
>> Why 250? Well, actually that's because our LDAP server barfs if you
>> make
>> more than about 300 queries on one connection. Those queries might be
>> validating local email addresses.
>
> Is that per email or per smtp transaction?  If the latter,
> SMTP_MAX_RCPTS handles that.
>

Yes, we were forced to set SMTP_MAX_RCPTS to a lowish value, because our 
MTA->LDAP connection breaks after handling a certain number of queries - 
generating hard failures instead of soft. It might be more clever to set a 
number closer to the real limit (360, iirc), and to actually count the 
number of queries made, but it's much simpler to tell people 250 is the 
limit than to tell them they can have as many as the like, as long as there 
are no more than 359 local recipients. Especially as we host some 
apparently remote domains.


-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Jun 29 12:44:24 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 29 Jun 2006 11:44:24 +0100
Subject: [Mailman-Developers] Hi! I'll be your intern for the summer :)
In-Reply-To: <EC2F8730-7D37-4ACA-A82B-4B4859ED550B@python.org>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<EC2F8730-7D37-4ACA-A82B-4B4859ED550B@python.org>
Message-ID: <52E8C21B0B0DE5B84740BA76@lewes.staff.uscs.susx.ac.uk>



--On 29 June 2006 02:36:10 -0700 Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jun 21, 2006, at 10:37 AM, emf wrote:
>
>>> How about this for extra:
>>>
>>> 1) Display a list of ALL members - just their names and addresses.
>>> 2) Delete ALL the list members with one click - OK, and maybe a
>>> confirm
>>> dialog!
>>
>> Hm. This comes slightly in opposition to the desire to have a more
>> user-centered mailman interface; what happens if a user changes their
>> preferences and you re-build the entire list?
>>
>> An associated problem is what happens to users that are subbed to
>> > 1 list?
>>
>> I recognize this may not be an issue in your specific case, I just
>> think
>> that issues like these will be more of a deal when we don't keep
>> "members" in per-list silos.
>
> Definitely, and what about when list memberships come from external
> rosters (e.g. external systems or generated on demand)?
>

Well, then I'd want an interface to delete all the members of a roster. In 
the case of the lists that I'm concerned with, those lists would would only 
have one roster anyway.


-- 
Ian Eiloart
IT Services, University of Sussex

From i at mindlace.net  Thu Jun 29 15:39:28 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 09:39:28 -0400
Subject: [Mailman-Developers] bulk subscriber changes
In-Reply-To: <913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
Message-ID: <44A3D810.5090103@mindlace.net>

Ian Eiloart wrote:

> Well, for some of our lists it's simply inappropriate for users to set 
> preferences. 

OK, I can see this. My query/issue is this: as I understand it, 
completely re-setting the list membership will also reset mailman's 
memory of who bounces, etc. So if any of the new members were old 
members with subscription issues, mailman goes through the same rigamarole.

It still seems to me like "set the active membership of the list to this 
list of email addresses", with existing addresses being retained, 
non-existent addresses dropped/set nomail, and new ones added, would 
address your needs without breaking things in the case that other admins 
use the feature.

Does that sound right/ok?

> So, I could implement this another way, but Mailman also offers me 
> authentication and authorisation, and allows me to ensure proper footers 
> on the emails, and probably some other useful stuff too.

What I hear you saying is you would like "one-off" lists; is it 
important that the list persists? It seems odd, but perhaps what you 
want, to have lists whose membership entirely changes every n mailings 
but retains the same email address.

Are there any regularities to the emails you add? e.g. might the set of 
emails you add after a delete be equivalent to some past set of emails?

I'm just thinking that the example you gave - sending all enquiring 
students a registration-change notice - is a case where you might want 
to keep some knowledge of past email addresses to which you had sent 
notices.

Not that I'm necessarily signing up to implement some "remember past 
emails" kind of thing, but the feature you want could be implemented by, 
for example, setting all the emails that don't occur in the most recent 
set to nomail, rather than just throwing them away.

~ethan


From iane at sussex.ac.uk  Thu Jun 29 16:36:12 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 29 Jun 2006 15:36:12 +0100
Subject: [Mailman-Developers] bulk subscriber changes
In-Reply-To: <44A3D810.5090103@mindlace.net>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
	<44A3D810.5090103@mindlace.net>
Message-ID: <CF5FF7C0E1CAC998ABCDE658@lewes.staff.uscs.susx.ac.uk>



--On 29 June 2006 09:39:28 -0400 emf <i at mindlace.net> wrote:

> Ian Eiloart wrote:
>
>> Well, for some of our lists it's simply inappropriate for users to set
>> preferences.
>
> OK, I can see this. My query/issue is this: as I understand it,
> completely re-setting the list membership will also reset mailman's
> memory of who bounces, etc. So if any of the new members were old
> members with subscription issues, mailman goes through the same
> rigamarole.
>
> It still seems to me like "set the active membership of the list to this
> list of email addresses", with existing addresses being retained,
> non-existent addresses dropped/set nomail, and new ones added, would
> address your needs without breaking things in the case that other admins
> use the feature.
>
> Does that sound right/ok?

Yes, that sounds good. I'd be uploading a list of addresses to be synced 
with the current membership.

>> So, I could implement this another way, but Mailman also offers me
>> authentication and authorisation, and allows me to ensure proper footers
>> on the emails, and probably some other useful stuff too.
>
> What I hear you saying is you would like "one-off" lists; is it
> important that the list persists? It seems odd, but perhaps what you
> want, to have lists whose membership entirely changes every n mailings
> but retains the same email address.

Well, the list still retains knowledge of who is allowed to post. And - 
importantly - it handles the grunt work of actually getting the emails sent.

> Are there any regularities to the emails you add? e.g. might the set of
> emails you add after a delete be equivalent to some past set of emails?
>
> I'm just thinking that the example you gave - sending all enquiring
> students a registration-change notice - is a case where you might want
> to keep some knowledge of past email addresses to which you had sent
> notices.
>
> Not that I'm necessarily signing up to implement some "remember past
> emails" kind of thing, but the feature you want could be implemented by,
> for example, setting all the emails that don't occur in the most recent
> set to nomail, rather than just throwing them away.
>
> ~ethan

Erm, perhaps. It would still be nice to be able to delete all the members, 
though. For example, I can bulk subscribe a list of people. If I then 
notice that I've subscribed them to the wrong list, it's a pain to get them 
unsubscribed.

-- 
Ian Eiloart
IT Services, University of Sussex

From i at mindlace.net  Thu Jun 29 18:46:56 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 12:46:56 -0400
Subject: [Mailman-Developers] bulk subscriber changes
In-Reply-To: <CF5FF7C0E1CAC998ABCDE658@lewes.staff.uscs.susx.ac.uk>
References: <449202D8.8060805@mindlace.net>
	<EA759323377A7C92EFE160EE@lewes.staff.uscs.susx.ac.uk>
	<44987E3C.7000703@mindlace.net>
	<F3D7E9B359A902954F3BEEFD@lewes.staff.uscs.susx.ac.uk>
	<449983E0.90504@mindlace.net>
	<913E10752C2AD44178A62305@lewes.staff.uscs.susx.ac.uk>
	<44A3D810.5090103@mindlace.net>
	<CF5FF7C0E1CAC998ABCDE658@lewes.staff.uscs.susx.ac.uk>
Message-ID: <44A40400.10702@mindlace.net>

Ian Eiloart wrote:

> Yes, that sounds good. I'd be uploading a list of addresses to be synced 
> with the current membership.

Great! I'll go this route.

> Erm, perhaps. It would still be nice to be able to delete all the 
> members, though. For example, I can bulk subscribe a list of people. If 
> I then notice that I've subscribed them to the wrong list, it's a pain 
> to get them unsubscribed.

Yes, I very much want mass-manipulation :) as well. In addition to bulk 
unsub, I'm extending the membership management thingy to allow for 
iterative searches (preserving existing results) so that you can quickly 
get to a set of email addresses you'd like to perform some operation on.

~ethan

From i at mindlace.net  Thu Jun 29 18:54:08 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 12:54:08 -0400
Subject: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi!
 I'll be your intern for the summer :))
In-Reply-To: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
References: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
Message-ID: <44A405B0.70405@mindlace.net>

Laura Carlson wrote:

> David Andrews already mentioned the demo versions of JAWS and 
> Window-Eyes [1].

I'll use the firefox jawsy thing and see what I can do past that point 
once I get windows on this box.

> Home Page Reader [3] is also a good tool for web developers and 
> designers who are looking to try out a speaking browser.

I think I can make OS X read pages, too, so I'll poke into that.

> One of the tools that I have my students use is to test forms is the 
> WAVE. [5]  It will spot violations like missing labels, labels not 
> associated with inputs, empty labels, etc. and notify you with icons. 
> [6]

Great! I will use that and Cynthia.

> There's a great little Colour Contrast Analyser Firefox Extension [8] 

OOh, neat! I heart firefox's extensibility. I already use color-scheme 
generators (and stay away from shade-changes only), but this will be a 
help, as I happen to be a boy blessed with a fully functioning X 
chromosome and have no colour blindness.

~ethan

From i at mindlace.net  Thu Jun 29 18:58:18 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 12:58:18 -0400
Subject: [Mailman-Developers] SoC: status update
In-Reply-To: <4499E69C.5020009@is.kochi-u.ac.jp>
References: <4499A358.2040005@mindlace.net> <4499E69C.5020009@is.kochi-u.ac.jp>
Message-ID: <44A406AA.9090406@mindlace.net>

Tokio Kikuchi wrote:
> Hi Ethan,
> 
> Since you are working on Web Interface, I have an important 
> suggestion/request on the charset we use.

We will use UTF-8 exclusively on WUI, with the caveat that I will be 
sniffing any charset information contained in emails and attempt 
displaying (individual) emails with the charset referenced.

Pretty please, I need to set up a copy of someone's translation 
toolchain; can someone using OS X or Linux as their work operating 
system work with me to get an *exact* replica of their toolset?

I want to make translating as painless as possible but from what I can 
tell so far gettext is very low level and I suspect that people use more 
than just it to translate... am I right?

~ethan

From i at mindlace.net  Thu Jun 29 20:09:01 2006
From: i at mindlace.net (emf)
Date: Thu, 29 Jun 2006 14:09:01 -0400
Subject: [Mailman-Developers] ids, javascript, and Forms Acessibility
In-Reply-To: <ACBA54DA2410A50DFAAA81EA@lcarslon.d.umn.edu>
References: <ACBA54DA2410A50DFAAA81EA@lcarslon.d.umn.edu>
Message-ID: <44A4173D.3060802@mindlace.net>

Laura Carlson wrote:


> I would caution against using implicit labels.

I think your advice is correct. Here is the conundrum that had me using 
implicit labels in the first place:

a.) All mailman page-elements need to be embeddable into other pages; 
this means that I can't collide with unknown id's elsewhere on the page. 
Not too much of a problem; I can have a Mm- prefix to denote mailman ids.

b.) Many form elements will repeat. One example is a user looking at the 
options for >1 list at a time. Also, a.) means I can't know how many of 
"me" (where I'm a form-chunk) a site administrator has imbedded into the 
page.

Of course, "talking it out" has presented a potential solution; let me 
know if it seems off.

I'm thinking of using Kid to generate pseudo-random numbers for ids. 
This works great, except when someone wants to use an id selector in CSS 
or getElementById() in JavaScript.

If I do this, I'll have to use class attributes (which happily can 
contain many values) to disambiguate form elements for JavaScript, and 
JavaScript will have to add/remove class attributes to change display 
for CSS. This is fine save that View Source becomes more opaque for 
someone who just knows CSS and HTML.

> - Keep the number of accesskeys to a minimum.

The only accesskeys I want to provide would be for speeding moderation.
I'm filing the rest of your advice in the wiki, so that I may keep it in 
mind.

> TABINDEX
> 
> having a sensible natural order to start 
> with, meets WCAG requirements for HTML documents.

I think this is a good idea, but I'm not going to control the global 
order of the pages the controls sit in, which is probably an argument 
for forgoing tabindex all together.

> If the tabindex attribute is not assigned to all fields, JAWS first 
> moves through the items with a tabindex assigned, then moves through 
> the other form fields and links in the order they appear on the page.

This is interesting. I have some "global" controls I was going to have 
sit "on top" of the content, and float it right. Now it sounds like I 
should put the global controls after the content, and use absolute 
positioning to put them on the right. Constrains the page-flow a bit 
more than I would like, but it is probably worth it.

On the other hand, the first form element in the global control set is 
"turn global controls on/off" so perhaps that won't be that much of a 
bother.

~ethan

From dandrews at visi.com  Thu Jun 29 22:25:20 2006
From: dandrews at visi.com (David Andrews)
Date: Thu, 29 Jun 2006 15:25:20 -0500
Subject: [Mailman-Developers] Accessibility Testing Tools (was Re: Hi!
 I'll be your intern for the summer :))
In-Reply-To: <44A405B0.70405@mindlace.net>
References: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
	<44A405B0.70405@mindlace.net>
Message-ID: <7.0.1.0.2.20060629152327.03751468@visi.com>

If you have OSX10.4 Tiger there is a built-in screen reader called Voice Over.  I believe it is command-F5 to bring it up, but could be wrong there.  I have only used it briefly, and not at all with the web, but could probably get access to a machine at work.

Dave

At 11:54 AM 6/29/2006, emf wrote:
>Laura Carlson wrote:
>
>> David Andrews already mentioned the demo versions of JAWS and 
>> Window-Eyes [1].
>
>I'll use the firefox jawsy thing and see what I can do past that point 
>once I get windows on this box.
>
>> Home Page Reader [3] is also a good tool for web developers and 
>> designers who are looking to try out a speaking browser.
>
>I think I can make OS X read pages, too, so I'll poke into that.
>
>> One of the tools that I have my students use is to test forms is the 
>> WAVE. [5]  It will spot violations like missing labels, labels not 
>> associated with inputs, empty labels, etc. and notify you with icons. 
>> [6]
>
>Great! I will use that and Cynthia.
>
>> There's a great little Colour Contrast Analyser Firefox Extension [8] 
>
>OOh, neat! I heart firefox's extensibility. I already use color-scheme 
>generators (and stay away from shade-changes only), but this will be a 
>help, as I happen to be a boy blessed with a fully functioning X 
>chromosome and have no colour blindness.
>
>~ethan
>_______________________________________________
>Mailman-Developers mailing list
>Mailman-Developers at python.org
>http://mail.python.org/mailman/listinfo/mailman-developers
>Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
>Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
>Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/dandrews%40visi.com
>
>Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
>
>__________ NOD32 1.1617 (20060623) Information __________
>
>This message was checked by NOD32 antivirus system.
>http://www.eset.com


From brad at stop.mail-abuse.org  Fri Jun 30 01:27:55 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 29 Jun 2006 19:27:55 -0400 (EDT)
Subject: [Mailman-Developers] Accessibility Testing Tools (was Re: Hi!
 I'll be your intern for the summer :))
In-Reply-To: <7.0.1.0.2.20060629152327.03751468@visi.com>
References: <E3768EAE84263A30F80A846E@lcarslon.d.umn.edu>
	<44A405B0.70405@mindlace.net>
	<7.0.1.0.2.20060629152327.03751468@visi.com>
Message-ID: <36535.72.177.126.107.1151623675.squirrel@mail.his.com>

David Andrews said:

> If you have OSX10.4 Tiger there is a built-in screen reader called Voice
> Over.  I believe it is command-F5 to bring it up, but could be wrong
> there.  I have only used it briefly, and not at all with the web, but
> could probably get access to a machine at work.

Correct, this works with MacOS X 10.4 Tiger.  I've tried VoiceOver just to
play around with it a bit, and I didn't like it.  I turned it back off
soon thereafter.  I wouldn't want to be dependant on a program like this
for all my web access.

But if someone wants me to do some specific testing, please let me know. 
This is now my main machine, and I have both Safari and Firefox, and I can
install a number of other browsers for testing purposes (including Opera,
Camino, etc...).

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From lcarlson at d.umn.edu  Fri Jun 30 14:12:49 2006
From: lcarlson at d.umn.edu (Laura Carlson)
Date: Fri, 30 Jun 2006 07:12:49 -0500
Subject: [Mailman-Developers] Accessibility Testing Tools (was Re: Hi!
 I'll be your intern for the summer :)) Hi! I'll be your intern for the
 summer :))
In-Reply-To: <mailman.28611.1151604547.27774.mailman-developers@python.org>
References: <mailman.28611.1151604547.27774.mailman-developers@python.or
 g>
Message-ID: <BC693863BE82270852B23F21@lcarslon.d.umn.edu>

--On Thursday, June 29, 2006 8:09 PM +0200 emf wrote:

>> One of the tools that I have my students use is to test forms is the
>> WAVE. [5]  It will spot violations like missing labels, labels not
>> associated with inputs, empty labels, etc. and notify you with
>> icons.  [6]
>
> Great! I will use that and Cynthia.

Sounds good, Ethan. If you need any help interpreting the automated 
tools analysis and recommendations, please let me know.

To be effective, accessibility checkers should form part of a wider 
process that includes an informed person acting on their 
recommendations.

Where accessibility is concerned, human judgement is key. Knowledge is 
the best tool for ensuring accessibility. The tools are only useful if 
you know what they're looking for, and if you know how to interpret 
their suggestions (including allowing for special cases in your code 
that generate false alerts in the evaluation). They will also only 
verify a fraction of the things you need to do -- the rest of the 
checkpoints require "human judgement"-- i.e., knowledge.

Laura
___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 55812-3009
http://www.d.umn.edu/goto/webdesign/

From lcarlson at d.umn.edu  Fri Jun 30 16:19:04 2006
From: lcarlson at d.umn.edu (Laura Carlson)
Date: Fri, 30 Jun 2006 09:19:04 -0500
Subject: [Mailman-Developers] ids, javascript, and Forms Acessibility
In-Reply-To: <mailman.28611.1151604547.27774.mailman-developers@python.org>
References: <mailman.28611.1151604547.27774.mailman-developers@python.or
 g>
Message-ID: <9DC7F471157EA52B94E1611A@lcarslon.d.umn.edu>

--On Friday, June 30, 2006 12:00 PM +0200 emf wrote:

> I'm thinking of using Kid to generate pseudo-random numbers for ids.
> This works great, except when someone wants to use an id selector in
> CSS  or getElementById() in JavaScript.

> If I do this, I'll have to use class attributes (which happily can
> contain many values) to disambiguate form elements for JavaScript,
> and  JavaScript will have to add/remove class attributes to change
> display  for CSS. This is fine save that View Source becomes more
> opaque for someone who just knows CSS and HTML.

I'm not quite sure what you have in mind here, Ethan. But for CSS, 
mailman admins could use selectors based document structure the 
majority of the time, IF the documents are structured an intelligent 
way. This method would also have the benefit of dramatically reducing 
stylesheet size and aid maintenance.

Classes and IDs aren't always needed for CSS! If every type of element 
is going to have the same style, adding a class to every one is 
redundant. It is best to eliminate cases of classitis and divitis where 
valid XHTML will do.

In school, most people were forced to write essays in a standard 
outline format. That is exactly the way that XHTML works. Web pages 
should always have structured textual content in organized hierarchies 
(outlines). It might be useful to think about a print stylesheet to 
help you think about page structure. If you'd want a print document to 
look like an outline, or magazine article, you'd think of heading 
priorities, lists of useful references (links), and what items belong 
in a header, footer, or sidebar. So...

- For headings, use h1 - h6
- For paragraphs, use p
- For lists where the order isn't important, use ul and li
- For lists where the order is important, use ol and li
- For lists where you're defining something, use dl and dt
- For quotes, use blockquote with a corresponding cite attribute
- For links, use a with a corresponding title attribute.
- For bold text, use strong
- For citations, use cite
- For images, use img with a corresponding alt attribute and longdesc 
if needed.
- Use table, td and tr for tabular data only.
- Use div and span to:
   1. style sections of content.
   2. add generic structure to the document.
   3. or when warranted by lack of style sheet support.

Use of most any element instead of or in addition to those listed above 
(for the corresponding purpose) will reduce the semantic quality of the 
document. It is that simple.

Think very hard about the document tree and selector behavior. This is 
necessary (as painful as it may seem at first) to enable you to 
visualize a document's structure mentally and determine what selectors 
can be used to address parts of it. Give serious attention to the 
logical structure of a web page. Not only will your attention make it 
inherently more accessible, it will help insure that you are correctly 
pinpointing what you really want styled. This allows you to target 
selectors to accomplish precise tasks.

So a key to writing smart style sheets is mastering selectors. Using 
structure and selectors in an intelligent way can dramatically reduce 
stylesheet size and aid in maintenance.


>> TABINDEX
>>
>> having a sensible natural order to start
>> with, meets WCAG requirements for HTML documents.
>
> I think this is a good idea, but I'm not going to control the global
> order of the pages the controls sit in, which is probably an argument
> for forgoing tabindex all together.

I agree.


> I have some "global" controls I was going to
> have  sit "on top" of the content, and float it right. Now it sounds
> like I  should put the global controls after the content, and use
> absolute  positioning to put them on the right. Constrains the
> page-flow a bit  more than I would like, but it is probably worth it.

Float is probably a better way to go. It allows for more fluid layouts 
and a large degree of control over elements.

It would be good to add skip links to jump over global controls and 
navigation links.

Skipping navigation is important for accessibility [1]. Joe Clark 
explains the theory and coding techniques well [2]. Skipping navigation 
aids people who use screen readers or other types of assistive 
technologies so they do not have to wait for the assistive technology 
to work through and announce each of the standard navigational links 
before getting to the intended content. Navigation links can be tedious 
to wade through. Sighted people with good mobility can ignore them. A 
blind person using a screen reader must experience the links one after 
another, which is very inconvenient. So when there are lists of 
navigational of links, there needs to be a link to an anchor that skips 
them to get to the actual content of the page.

They were originally intended as a navigation aid for people with 
disabilities, but they are a also very useful to mobile phone users.

As Clark says, it is best to keep skip navigation links visible [3]. 
You can hide the text in links that allow users to skip the navigation, 
but then you have the problem that this hides an accessibility feature 
from those who can see and who cannot use a mouse.

All the Best,
Laura

[1] http://www.access-board.gov/sec508/guide/1194.22.htm#(o)
[2] http://joeclark.org/book/sashay/serialization/Chapter08.html
[3] http://joeclark.org/book/sashay/serialization/Chapter08.html#h4-2020

More Skip Navigation info:
http://www.d.umn.edu/goto/accessibility#skiplinks

___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 55812-3009
http://www.d.umn.edu/goto/webdesign/