From brad at stop.mail-abuse.org  Wed Apr  5 09:22:38 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 5 Apr 2006 02:22:38 -0500
Subject: [Mailman-Developers] XMLRPC interface
In-Reply-To: <442A98F6.9070308@caltha.pl>
References: <442A98F6.9070308@caltha.pl>
Message-ID: <p06200703c0591fe41a7e@[192.168.1.65]>

At 4:25 PM +0200 2006-03-29, Rafal Krzewski wrote:

>  We (http://caltha.pl) are currently developing a Java-powered WWW
>  application for group collaboration (http://cyklotron2.cyklotron.org).
>  The application includes (among others) discussion forums.

	There is already a fair amount of information in the FAQ Wizard 
about integrating Mailman with web forums, and I think there may also 
be some information there about XMLRPC.

	Before you get started doing too much work integrating Mailman 
into your Java environment, have you read all those entries?

>  My question at this point is whether this is the appropriate list to
>  discuss mailman-xmlrpc specific topics, or should these be taken to
>  somewhere else perhaps a dedicated list should be created at
>  http://savannah.nongnu.org/mail/?group=mailman-xmlrpc ?

	This list is where the core Mailman developers will be watching 
the various development related discussions, and I know that some of 
them are very interested in the XMLRPC stuff.

	I would suggest keeping these discussions on this list until you 
are recommended to move them somewhere else by one of the core 
developers (e.g., someone like Barry, Tokio, Mark, 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 simmosiil at hotmail.com  Wed Apr  5 21:39:58 2006
From: simmosiil at hotmail.com (Simmo Siil)
Date: Wed, 05 Apr 2006 22:39:58 +0300
Subject: [Mailman-Developers] Mailman listinfo and admin problem!
Message-ID: <BAY24-F6D74E06C5CBACB894B865A5CB0@phx.gbl>

I have 3 ways how people want to see mailman lists.
For example:
http://mail/mailman/listinfo
http://mail.subdomain.domain.com/mailman/listinfo
http://mail.domain.com/mailman/listinfo

Right now they can see information only in
http://mail/mailman/listinfo

If they look from other addresses, then the lists are empty.

How can it be done so that all the lists are showed
from every address.

I hope someone can help me...

With Best Regards,
Simmo

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


From msapiro at value.net  Wed Apr  5 22:08:06 2006
From: msapiro at value.net (Mark Sapiro)
Date: Wed, 5 Apr 2006 13:08:06 -0700
Subject: [Mailman-Developers] Mailman listinfo and admin problem!
In-Reply-To: <BAY24-F6D74E06C5CBACB894B865A5CB0@phx.gbl>
Message-ID: <PC17402006040513080606401281fd46@Notebook>

Simmo Siil wrote:
>
>How can it be done so that all the lists are showed
>from every address.

Put

VIRTUAL_HOST_OVERVIEW = Off

in mm_cfg.py

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


From Kucerar at hhmi.org  Wed Apr  5 15:26:51 2006
From: Kucerar at hhmi.org (Kucera, Rich)
Date: Wed, 5 Apr 2006 09:26:51 -0400
Subject: [Mailman-Developers] XMLRPC interface
Message-ID: <0EDA935F3B86D04E8408C7BC487B8C0E0136D353@hqexch3.hhmi.org>

> application ... discussion forums. 
[...]
> communicated with the Java application using, say XMLRPC. And bingo! 
> We are very much interested joining the effort in [Rich] 
> developing mailman-xmlrpc. 

Wouldn't NNTP support already used in mailman be easier to leverage for
integration with a collaboration CMS?  

Thanks,
-Rich


From Rafal.Krzewski at caltha.pl  Wed Apr  5 10:21:57 2006
From: Rafal.Krzewski at caltha.pl (Rafal Krzewski)
Date: Wed, 05 Apr 2006 10:21:57 +0200
Subject: [Mailman-Developers] XMLRPC interface
In-Reply-To: <p06200703c0591fe41a7e@[192.168.1.65]>
References: <442A98F6.9070308@caltha.pl> <p06200703c0591fe41a7e@[192.168.1.65]>
Message-ID: <44337E25.3020000@caltha.pl>

Brad Knowles wrote:

> There is already a fair amount of information in the FAQ Wizard 
> about integrating Mailman with web forums, and I think there may also be 
> some information there about XMLRPC.

I did check the FAQs throughly, and all I was able to find was that:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.026.htp

It gives some infomration about some products already integrated (to 
some degree) but no information how should one go about integrating 
Mailman with another product.

Also, no information about XMLRPC support in the FAQ - I might volunteer 
to add it once the patch is merged in Mailman trunk.

 >     Before you get started doing too much work integrating Mailman into
 > your Java environment, have you read all those entries?

Most of work is already done. We have Python side ready (some 
refactorings + extensions to J. Ginsberg & J. Tate work), and Java side 
of the integration is also done. Now we are working on the discussion 
board code. I expect this work to be complete next week - including 
in-house testing.

>     I would suggest keeping these discussions on this list until you are 
> recommended to move them somewhere else by one of the core developers 
> (e.g., someone like Barry, Tokio, Mark, etc...).

Will do. Unfortunately my attempts to contact J. Ginsberg and J. Tate 
failed completly so far, so I'm glad I have *someone* to talk about this 
  at last ;-)

I'll post our updated XMLRPC patch to SF bugtracker shortly.

regards,
Rafa?



From tkikuchi at is.kochi-u.ac.jp  Fri Apr  7 02:16:52 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri, 07 Apr 2006 09:16:52 +0900
Subject: [Mailman-Developers] Released: Mailman 2.1.8 release candidate
Message-ID: <4435AF74.1050607@is.kochi-u.ac.jp>

Hi all,

Mailman 2.1.8rc1 was released for the final test of 2.1.8.

Important: This is not only a release candidate but also include a fix 
for a cross-site scripting bug found in 2.1.7.  All sites running 
previous versions are adviced to upgrade to 2.1.8(rc1).  I am going to 
release the final by the next weekend if nothing serious happens.

Please download it from Sourceforge file area:
   http://sourceforge.net/project/showfiles.php?group_id=103

Cheers,

Tokio
---------------------------------------------------
Here is a history of user visible changes to Mailman.

2.1.8rc1 (07-Apr-2006)

   Security

     - A cross-site scripting hole in the private archive script of 2.1.7
       has been closed.  Thanks to Moritz Naumann for its discovery.

   Bug fixes and other patches

     - Bouncers support added: 'unknown user', Microsoft SMTPSVC, 
Prodigy.net
       and several others.

     - Updated email library to 2.5.7 which will encode payload into 
qp/base64
       upon setting.  This enabled backing out the scrubber related patches
       including 'X-Mailman-Scrubbed' header in 2.1.7.

     - Fix SpamDetect.py potential hold/reject loop problem.

     - A warning message from email package to the stderr can cause error
       in Logging because stderr may be detached from the process during
       the qrunner run.  We chose not to output errors to stderr but to
       the logs/error if the process is running under mailmanctl subprocess.

     - DKIM header cleansing was separated from Cleanse.py and added to
       -owner messages too.

     - Fixes: Lose Topics when go directly to topics URL (1194419).
       UnicodeError running bin/arch (1395683).  edithtml.py missing import
       (1400128).  Bad escape in cleanarch.  Wrong timezone in list archive
       index pages (1433673).  bin/arch fails with TypeError (1430236).
       Subscription fails with some Language combinations (1435722).
       Postfix delayed notification not recognized (863989).  2.1.7 (VERP)
       mistakes delay notice for bounce (1421285).  show_qfiles: 'str'
       object has no attribute 'as_string' (1444447).  Utils.get_domain()
       wrong if VIRTUAL_HOST_OVERVIEW off (1275856).

   Miscellaneous

     - Brad Knowles' mailman daily status report script updated to 0.0.16.


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




From kevin at kubasik.net  Fri Apr  7 03:31:45 2006
From: kevin at kubasik.net (Kevin Kubasik)
Date: Thu, 6 Apr 2006 21:31:45 -0400
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
References: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
Message-ID: <88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>

Hey, I'm a member of the Gnome Moderator Team[1] over at gnome.org. We
have a large collection of quite active mailing lists that a small
team (6 people) manage and moderate. While mailman has served us
faithfully, one feature that we have been looking to implement for a
long time is a unified moderation panel of sorts. Or a way for one
moderator to view all pending messages by logging in once. Since it is
not uncommon that one spammer crawls the site and sends the same
message to every list, it can become a routine exercise of repetition
to sign in 50+ times to discard the same message.

We have been looking to implement this feature internally, but most of
our python developers are swamped, and we haven't been able to find
someone with the expertise necessary. Has the feature already been
considered? if not, could it be considered for a future release?


[1]- http://live.gnome.org/ModeratorTeam
--
Cheers,
Kevin Kubasik
http://blog.kubasik.net/

From lionel at mamane.lu  Tue Apr 11 22:24:25 2006
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Tue, 11 Apr 2006 22:24:25 +0200
Subject: [Mailman-Developers] Released: Mailman 2.1.8 release candidate
In-Reply-To: <4435AF74.1050607@is.kochi-u.ac.jp>
References: <4435AF74.1050607@is.kochi-u.ac.jp>
Message-ID: <20060411202425.GA29896@capsaicin.mamane.lu>

On Fri, Apr 07, 2006 at 09:16:52AM +0900, Tokio Kikuchi wrote:

> Mailman 2.1.8rc1 was released for the final test of 2.1.8.

It seems you didn't tag this release in the CVS?

-- 
Lionel

From msapiro at value.net  Tue Apr 11 22:50:22 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 11 Apr 2006 13:50:22 -0700
Subject: [Mailman-Developers] Released: Mailman 2.1.8 release candidate
In-Reply-To: <20060411202425.GA29896@capsaicin.mamane.lu>
Message-ID: <PC1740200604111350220578372f56f8@msapiro>

Lionel Elie Mamane wrote:

>On Fri, Apr 07, 2006 at 09:16:52AM +0900, Tokio Kikuchi wrote:
>
>> Mailman 2.1.8rc1 was released for the final test of 2.1.8.
>
>It seems you didn't tag this release in the CVS?


It is tagged in CVS. The problem is that there was a major problem with
the developer CVS server at sourceforge.net and they are still not
pushing updates from the developer server to the public servers.

See <http://sourceforge.net/docs/A04>

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


From lionel at mamane.lu  Tue Apr 11 22:59:54 2006
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Tue, 11 Apr 2006 22:59:54 +0200
Subject: [Mailman-Developers] Released: Mailman 2.1.8 release candidate
In-Reply-To: <PC1740200604111350220578372f56f8@msapiro>
References: <20060411202425.GA29896@capsaicin.mamane.lu>
	<PC1740200604111350220578372f56f8@msapiro>
Message-ID: <20060411205954.GA19708@capsaicin.mamane.lu>

On Tue, Apr 11, 2006 at 01:50:22PM -0700, Mark Sapiro wrote:
> Lionel Elie Mamane wrote:
>> On Fri, Apr 07, 2006 at 09:16:52AM +0900, Tokio Kikuchi wrote:

>>> Mailman 2.1.8rc1 was released for the final test of 2.1.8.

>> It seems you didn't tag this release in the CVS?

> It is tagged in CVS. The problem is that (...) they are still not
> pushing updates from the developer server to the public servers.

I see. Thanks.

-- 
Lionel

From tkikuchi at is.kochi-u.ac.jp  Sat Apr 15 07:41:07 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat, 15 Apr 2006 14:41:07 +0900
Subject: [Mailman-Developers] RELEASED: Mailman 2.1.8
Message-ID: <44408773.6010206@is.kochi-u.ac.jp>

On behalf of the development team, I'm pleased to announce the release
of GNU Mailman 2.1.8.  In this release, we have fixed a cross-site
scripting security bug in the previous release (CVE-2006-1712),
integrated a new version of email library (email-2.5.7), and added
bounce processing supports for number of sites and MUAs.  It is highly
recommended that all sites using 2.1.7 and before should update to this
release.

Mailman is free software for managing email mailing lists and e-newsletters.

For more information, see:

     http://mailman.sourceforge.net/

For links to download the Mailman 2.1.8 source tarball, see:

     http://sourceforge.net/project/showfiles.php?group_id=103

(Note that uploading to the mirror sites may be delayed.)

-- 
Tokio Kikuchi


From barry at python.org  Sat Apr 15 20:34:07 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 15 Apr 2006 14:34:07 -0400
Subject: [Mailman-Developers] New Mailman wiki, Subversion (and other stuff)
Message-ID: <1145126047.3167.13.camel@resist.wooz.org>

For a while now, I've been trying to implement several project
management improvements for Mailman, so that future development can be
opened up to more people.  As Tokio's and Mark's work has shown, there
are very talented programmers out there that can contribute great stuff
to Mailman if given a chance.  Folks like Brad, JC, and Terri have also
contributed greatly in ways other than with code, and I'd like to make
it easier for others like them to help out.

With 2.1 in maintenance mode, planning for 2.2 gearing up, and my desire
to once again jump start 3.0 work, we need all the help we can get.

While I'm still working on some things, there have been some good
developments that I wanted to let you know about.  First, Atlassian has
offered free licenses and hosting for their excellent products Jira
(issue tracker) and Confluence (wiki).  I've used both for several years
now and I think they are top-notch applications; Jira is definitely one
of the best issue trackers I've used.

The wiki is now live, although not a lot of content has been moved
there.  Please see <http://wiki.list.org>.  You can browse the wiki
anonymously, but you must sign up to make any additions or changes.  I
would eventually like to move things like the Mailman FAQ, list of
Mailman users, online documentation (where it doesn't overlap with the
latex docs), and all community contributed content from the main web
site to the wiki.  If you've been looking for a way to contribute to
Mailman that doesn't involve coding, here's your chance!

While Jira is live, there's nothing yet there.  I've done only the
minimal configuration for the issue tracker, but have not yet even set
up any projects.  Still, you can go to <http://bugs.list.org> to sign up
or get a feel for the basics.  Right now, I'm working on a conversion
script that will take the SourceForge tracker data and massage it into a
form that Jira can import.  My plan is to move all issue tracking to
Jira from SF's trackers.

One option to getting there faster is to just start Jira from scratch --
i.e. not import the SF issues.  We could say that all 2.2 and 3.0 bugs
and patches must go to Jira, but that 2.1 bugs would stay on SF.  Then,
when 2.1 is retired, we'd retire the SF tracker (that may not be for a
long time though, given how pervasive 2.1 is).  I'm interested in
getting opinions about whether we should migrate all issues to Jira now,
split the issues as described above, or take some other approach.

Now that Mailman 2.1.8 is out, I've gone ahead and converted the SF CVS
repository to Subversion.  You can checkout the entire tree via
<https://svn.sourceforge.net/svnroot/mailman> but understand that that
will checkout /everything/ (trunk, tags, branches, etc).  If you just
want Mailman 2.1, you can check out
<https://svn.sourceforge.net/svnroot/mailman/branches/Release_2_1-maint>, or if you just want the trunk (2.2) you can check out <https://svn.sourceforge.net/svnroot/mailman/trunk>.  You should no longer be able to check anything into the CVS repository.  Not everyone who had write permission to CVS has been given Subversion write access.  If you still need write access to Subversion and don't have it, please let me know.

Now that the conversion is complete, I plan on doing some repo house
cleaning, such as moving the website stuff out of the main directory.
After that, we can decide to leave the Subversion repository on
SourceForge, or move it to Atlassian's hosting.  The latter gives us the
ability to control write permissions per directory and a hook to Fisheye
for repo browsing through the web.  Even if we want to move, we don't
need to do that right away, as an svn dump/restore should do the trick.

Now that these changes have been made, I think it's time to start
planning for Mailman 2.2.  To that end, I would like most development
artifacts to be recorded in the wiki, although discussion should still
happen on mailman-developers (there's a 'Development' space and a link
for 2.2 under that).  I also plan on getting our data imported into
Rosetta so we can coordinate i18n there; it's mostly my fault I've
dropped the ball on this one.

Longer term, as we begin to restart Mailman 3 development, all those
decisions will go in the wiki too.  I have some other thoughts about
Mailman 3 that I'd like to get feedback on, but as this message is
getting fairly long anyway, I'll defer that for the time being.

So in summary, please check out the wiki.  Let me know what you think
about importing the SF issues into Jira.  And check out the Subversion
repository.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060415/bf933fa7/attachment.pgp 

From stephen at xemacs.org  Tue Apr 18 15:17:07 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 18 Apr 2006 22:17:07 +0900
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>
	(Kevin Kubasik's message of "Thu, 6 Apr 2006 21:31:45 -0400")
References: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
	<88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>
Message-ID: <87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Kevin" == Kevin Kubasik <kevin at kubasik.net> writes:

    Kevin> Or a way for one moderator to view all pending messages by
    Kevin> logging in once. Since it is not uncommon that one spammer
    Kevin> crawls the site and sends the same message to every list,
    Kevin> it can become a routine exercise of repetition to sign in
    Kevin> 50+ times to discard the same message.

In the FAQ there's a script called mmfold.py (by Skip Montanaro, IIRC)
that massages one list's admin requests into a compact form; you
should be able to wrap that to get several lists worth in one go.

Also, I suspect if you search the mailman-users archives (maybe
mailman-developers? I forget) you'll find a thread which
discusses several ways to get all of your lists in one command, either
as frames or tabs in you browser.  It was a few months ago.

Sorry I can't be more specific offhand.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From barry at python.org  Wed Apr 19 01:17:35 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 18 Apr 2006 19:17:35 -0400
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
	<88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>
	<87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <1145402255.21199.122.camel@resist.wooz.org>

On Tue, 2006-04-18 at 22:17 +0900, Stephen J. Turnbull wrote:
> >>>>> "Kevin" == Kevin Kubasik <kevin at kubasik.net> writes:
> 
>     Kevin> Or a way for one moderator to view all pending messages by
>     Kevin> logging in once. Since it is not uncommon that one spammer
>     Kevin> crawls the site and sends the same message to every list,
>     Kevin> it can become a routine exercise of repetition to sign in
>     Kevin> 50+ times to discard the same message.
> 
> In the FAQ there's a script called mmfold.py (by Skip Montanaro, IIRC)
> that massages one list's admin requests into a compact form; you
> should be able to wrap that to get several lists worth in one go.

Yes, we really should add this to the contrib directory.  Skip, if
you're listening, I'm sure you sent me a version long ago, but if you
can send me the latest and greatest copy, I'll add it to the svn repo.

> Also, I suspect if you search the mailman-users archives (maybe
> mailman-developers? I forget) you'll find a thread which
> discusses several ways to get all of your lists in one command, either
> as frames or tabs in you browser.  It was a few months ago.

I remember that too, so it was probably mailman-developers.

A more principled solution to the problem will probably have to wait
until a unified user database is implemented (MM3).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060418/32ff1331/attachment.pgp 

From kevin at kubasik.net  Tue Apr 18 17:08:30 2006
From: kevin at kubasik.net (Kevin Kubasik)
Date: Tue, 18 Apr 2006 11:08:30 -0400
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
	<88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>
	<87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <88d636060604180808g7a389a29k9fcf1ccbcd9982f@mail.gmail.com>

Thanks much, I'll check it out.

Cheers,
Kevin Kubasik

On 4/18/06, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> >>>>> "Kevin" == Kevin Kubasik <kevin at kubasik.net> writes:
>
>    Kevin> Or a way for one moderator to view all pending messages by
>    Kevin> logging in once. Since it is not uncommon that one spammer
>    Kevin> crawls the site and sends the same message to every list,
>    Kevin> it can become a routine exercise of repetition to sign in
>    Kevin> 50+ times to discard the same message.
>
> In the FAQ there's a script called mmfold.py (by Skip Montanaro, IIRC)
> that massages one list's admin requests into a compact form; you
> should be able to wrap that to get several lists worth in one go.
>
> Also, I suspect if you search the mailman-users archives (maybe
> mailman-developers? I forget) you'll find a thread which
> discusses several ways to get all of your lists in one command, either
> as frames or tabs in you browser.  It was a few months ago.
>
> Sorry I can't be more specific offhand.
>
> --
> School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
>               Ask not how you can "do" free software business;
>              ask what your business can "do for" free software.
>


--
Cheers,
Kevin Kubasik
http://blog.kubasik.net/

From kevin at kubasik.net  Tue Apr 18 17:17:34 2006
From: kevin at kubasik.net (Kevin Kubasik)
Date: Tue, 18 Apr 2006 11:17:34 -0400
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <88d636060604180808g7a389a29k9fcf1ccbcd9982f@mail.gmail.com>
References: <88d636060604060458i33a785b8y665663c11a080b6f@mail.gmail.com>
	<88d636060604061831g5b9671f8p8a4c21af2c592550@mail.gmail.com>
	<87odyz10rw.fsf@tleepslib.sk.tsukuba.ac.jp>
	<88d636060604180808g7a389a29k9fcf1ccbcd9982f@mail.gmail.com>
Message-ID: <88d636060604180817g398afe68r3ba474af419944e4@mail.gmail.com>

Sorry, you wouldn't happen to know anything else about the thread
would you? I can't seem to find it, but maybe im just using the wrong
search terms.

-Kevin Kubasik

On 4/18/06, Kevin Kubasik <kevin at kubasik.net> wrote:
> Thanks much, I'll check it out.
>
> Cheers,
> Kevin Kubasik
>
> On 4/18/06, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> > >>>>> "Kevin" == Kevin Kubasik <kevin at kubasik.net> writes:
> >
> >    Kevin> Or a way for one moderator to view all pending messages by
> >    Kevin> logging in once. Since it is not uncommon that one spammer
> >    Kevin> crawls the site and sends the same message to every list,
> >    Kevin> it can become a routine exercise of repetition to sign in
> >    Kevin> 50+ times to discard the same message.
> >
> > In the FAQ there's a script called mmfold.py (by Skip Montanaro, IIRC)
> > that massages one list's admin requests into a compact form; you
> > should be able to wrap that to get several lists worth in one go.
> >
> > Also, I suspect if you search the mailman-users archives (maybe
> > mailman-developers? I forget) you'll find a thread which
> > discusses several ways to get all of your lists in one command, either
> > as frames or tabs in you browser.  It was a few months ago.
> >
> > Sorry I can't be more specific offhand.
> >
> > --
> > School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
> > University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
> >               Ask not how you can "do" free software business;
> >              ask what your business can "do for" free software.
> >
>
>
> --
> Cheers,
> Kevin Kubasik
> http://blog.kubasik.net/
>


--
Cheers,
Kevin Kubasik
http://blog.kubasik.net/

From msapiro at value.net  Wed Apr 19 05:08:22 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 18 Apr 2006 20:08:22 -0700
Subject: [Mailman-Developers] Unified Moderator Interface
In-Reply-To: <88d636060604180817g398afe68r3ba474af419944e4@mail.gmail.com>
Message-ID: <PC1740200604182008220265c56087df@msapiro>

Kevin Kubasik wrote:

>Sorry, you wouldn't happen to know anything else about the thread
>would you? I can't seem to find it, but maybe im just using the wrong
>search terms.

I think the post is
<http://mail.python.org/pipermail/mailman-developers/2006-January/018492.html>.

-- 
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 Apr 19 07:19:53 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 19 Apr 2006 01:19:53 -0400
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
	[7862]	trunk/mailman/Mailman/Cgi
In-Reply-To: <E1FW2Mf-0007fR-94@sc8-pr-svn1.sourceforge.net>
References: <E1FW2Mf-0007fR-94@sc8-pr-svn1.sourceforge.net>
Message-ID: <1145423993.21740.76.camel@geddy.wooz.org>

On Tue, 2006-04-18 at 19:24 -0700, msapiro at users.sourceforge.net wrote:
> Fix a couple of typos/oversights in Barry's type and logging changes.
> 
> Modified Paths:
> --------------
>     trunk/mailman/Mailman/Cgi/admin.py
>     trunk/mailman/Mailman/Cgi/admindb.py
> Modified: trunk/mailman/Mailman/Cgi/admin.py
> ===================================================================
> --- trunk/mailman/Mailman/Cgi/admin.py	2006-04-17 21:52:04 UTC (rev 7861)
> +++ trunk/mailman/Mailman/Cgi/admin.py	2006-04-19 02:24:19 UTC (rev 7862)
> @@ -552,7 +552,7 @@
>                        width='85%')
>  
>      for item in options:
> -        if isinstance(type, str):
> +        if isinstance(item, str):
>              # The very first banner option (string in an options list) is
>              # treated as a general description, while any others are
>              # treated as section headers - centered and italicized...

LOL!  I hit this one in my development tree and didn't get to checking
it in yet. (Yes, I'm experimenting with "things" :).

> Modified: trunk/mailman/Mailman/Cgi/admindb.py
> ===================================================================
> --- trunk/mailman/Mailman/Cgi/admindb.py	2006-04-17 21:52:04 UTC (rev 7861)
> +++ trunk/mailman/Mailman/Cgi/admindb.py	2006-04-19 02:24:19 UTC (rev 7862)
> @@ -24,6 +24,7 @@
>  import email
>  import errno
>  import signal
> +import logging
>  
>  from urllib import quote_plus, unquote_plus

Good catch, thanks!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060419/d10f0eae/attachment.pgp 

From tkikuchi at is.kochi-u.ac.jp  Sun Apr 23 01:30:54 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun, 23 Apr 2006 08:30:54 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
	[7858] trunk/mailman
In-Reply-To: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
Message-ID: <444ABCAE.6010405@is.kochi-u.ac.jp>

Hi Barry,

I had some hours playing with the new svn trunk.  (I was a little bit 
busy because our academic year begins April.)

bwarsaw at users.sourceforge.net wrote:
> Revision: 7858
> Author:   bwarsaw
> Date:     2006-04-16 21:08:17 -0700 (Sun, 16 Apr 2006)
> ViewCVS:  http://svn.sourceforge.net/mailman/?rev=7858&view=rev
> 
> Log Message:
> -----------
> - Convert all logging to Python's standard logging module.  Get rid of all
>   traces of our crufty old Syslog.  Most of this work was purely mechanical,
>   except for:

I get this for a fresh install of svn trunk.  You may have old install 
remained, if you haven't experienced this.

% bin/mailmanctl start
Traceback (most recent call last):
   File "bin/mailmanctl", line 112, in ?
     from Mailman.Logging.Syslog import syslog
ImportError: No module named Logging.Syslog

Also, if you send SIGHUP to reopen the logs, only the last reopen 
messages is recorded because each runners try to reopen the log file. 
We may have to restart qrunners if mailmanctl receive SIGHUP and it has 
started new log files.  We may also utilize the backupCount feature for 
log rotation (intruducing LOG_BACKUP_COUNT in Defaults.py).

>   
>   1) Initializing the loggers.  For this, there's a new module
>      Mailman/loginit.py (yes all modules from now on will use PEP 8
>      names).  We can't call this 'logging.py' because that will
>      interfere with importing the stdlib module of the same name (can
>      you say Python 2.5 and absolute imports?).
>      
>      If you want to write log messages both to the log file and to
>      stderr, pass True to loginit.initialize().  This will turn on
>      propagation of log messages to the parent 'mailman' logger, which
>      is set up to print to stderr.  This is how bin/qrunner works when
>      not running as a subprocess of mailmanctl.
>      
>   2) The driver script.  I had to untwist the StampedLogger stuff and
>      implement differently printing exceptions and such to log/error
>      because standard logging objects don't have a write() method.  So
>      we write to a cStringIO and then pass that to the logger.
>      
>   3) SMTPDirect.py because of the configurability of the log messages.
>      This required changing SafeDict into a dict subclass (which is
>      better than using UserDicts anyway -- yay Python 2.3!).  It's
>      probably still possible to flummox things up if you change the
>      name of the loggers in the SMTP_LOG_* variables in mm_cfg.py.
>      However, the worst you can do is cause output to go to stderr and
>      not go to a log file.
>      
>   Note too that all entry points into the Mailman system must call
>   Mailman.loginit.initialize() or the log output will go to stderr
>   (which may occasionally be what you want).  Currently all CGIs and
>   qrunners should be working properly.
>   
>   I wish I could have tested all code paths that touch the logger, but
>   that's infeasible.  I have tested this, but it's possible that there
>   were some mistakes in the translation.
>   
> - Mailman.Bouncers.BounceAPI.Stop is a singleton, but not a class
>   instance any more.
>   
> - True/False code cleanup, PEP 8 import restructuring, whitespace
>   normalization, and copyright year updates, as appropriate.
> 


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

From tkikuchi at is.kochi-u.ac.jp  Sun Apr 23 01:30:54 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun, 23 Apr 2006 08:30:54 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
	[7858] trunk/mailman
In-Reply-To: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
Message-ID: <444ABCAE.6010405@is.kochi-u.ac.jp>

Hi Barry,

I had some hours playing with the new svn trunk.  (I was a little bit 
busy because our academic year begins April.)

bwarsaw at users.sourceforge.net wrote:
> Revision: 7858
> Author:   bwarsaw
> Date:     2006-04-16 21:08:17 -0700 (Sun, 16 Apr 2006)
> ViewCVS:  http://svn.sourceforge.net/mailman/?rev=7858&view=rev
> 
> Log Message:
> -----------
> - Convert all logging to Python's standard logging module.  Get rid of all
>   traces of our crufty old Syslog.  Most of this work was purely mechanical,
>   except for:

I get this for a fresh install of svn trunk.  You may have old install 
remained, if you haven't experienced this.

% bin/mailmanctl start
Traceback (most recent call last):
   File "bin/mailmanctl", line 112, in ?
     from Mailman.Logging.Syslog import syslog
ImportError: No module named Logging.Syslog

Also, if you send SIGHUP to reopen the logs, only the last reopen 
messages is recorded because each runners try to reopen the log file. 
We may have to restart qrunners if mailmanctl receive SIGHUP and it has 
started new log files.  We may also utilize the backupCount feature for 
log rotation (intruducing LOG_BACKUP_COUNT in Defaults.py).

>   
>   1) Initializing the loggers.  For this, there's a new module
>      Mailman/loginit.py (yes all modules from now on will use PEP 8
>      names).  We can't call this 'logging.py' because that will
>      interfere with importing the stdlib module of the same name (can
>      you say Python 2.5 and absolute imports?).
>      
>      If you want to write log messages both to the log file and to
>      stderr, pass True to loginit.initialize().  This will turn on
>      propagation of log messages to the parent 'mailman' logger, which
>      is set up to print to stderr.  This is how bin/qrunner works when
>      not running as a subprocess of mailmanctl.
>      
>   2) The driver script.  I had to untwist the StampedLogger stuff and
>      implement differently printing exceptions and such to log/error
>      because standard logging objects don't have a write() method.  So
>      we write to a cStringIO and then pass that to the logger.
>      
>   3) SMTPDirect.py because of the configurability of the log messages.
>      This required changing SafeDict into a dict subclass (which is
>      better than using UserDicts anyway -- yay Python 2.3!).  It's
>      probably still possible to flummox things up if you change the
>      name of the loggers in the SMTP_LOG_* variables in mm_cfg.py.
>      However, the worst you can do is cause output to go to stderr and
>      not go to a log file.
>      
>   Note too that all entry points into the Mailman system must call
>   Mailman.loginit.initialize() or the log output will go to stderr
>   (which may occasionally be what you want).  Currently all CGIs and
>   qrunners should be working properly.
>   
>   I wish I could have tested all code paths that touch the logger, but
>   that's infeasible.  I have tested this, but it's possible that there
>   were some mistakes in the translation.
>   
> - Mailman.Bouncers.BounceAPI.Stop is a singleton, but not a class
>   instance any more.
>   
> - True/False code cleanup, PEP 8 import restructuring, whitespace
>   normalization, and copyright year updates, as appropriate.
> 


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

From barry at python.org  Mon Apr 24 05:59:44 2006
From: barry at python.org (Barry Warsaw)
Date: Sun, 23 Apr 2006 23:59:44 -0400
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
	mailman:	[7858] trunk/mailman
In-Reply-To: <444ABCAE.6010405@is.kochi-u.ac.jp>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
Message-ID: <1145851184.13311.166.camel@resist.wooz.org>

On Sun, 2006-04-23 at 08:30 +0900, Tokio Kikuchi wrote:

> I had some hours playing with the new svn trunk.  (I was a little bit 
> busy because our academic year begins April.)
> 
> bwarsaw at users.sourceforge.net wrote:
> > Revision: 7858
> > Author:   bwarsaw
> > Date:     2006-04-16 21:08:17 -0700 (Sun, 16 Apr 2006)
> > ViewCVS:  http://svn.sourceforge.net/mailman/?rev=7858&view=rev
> > 
> > Log Message:
> > -----------
> > - Convert all logging to Python's standard logging module.  Get rid of all
> >   traces of our crufty old Syslog.  Most of this work was purely mechanical,
> >   except for:
> 
> I get this for a fresh install of svn trunk.  You may have old install 
> remained, if you haven't experienced this.
> 
> % bin/mailmanctl start
> Traceback (most recent call last):
>    File "bin/mailmanctl", line 112, in ?
>      from Mailman.Logging.Syslog import syslog
> ImportError: No module named Logging.Syslog

Try r7871.  I think I've fixed this now.

> Also, if you send SIGHUP to reopen the logs, only the last reopen 
> messages is recorded because each runners try to reopen the log file. 
> We may have to restart qrunners if mailmanctl receive SIGHUP and it has 
> started new log files.  We may also utilize the backupCount feature for 
> log rotation (intruducing LOG_BACKUP_COUNT in Defaults.py).

I decided not to use the RotatingFileHandler and leave file rotation to
external tools like logrotate.  Instead I implemented a subclass of
FileHandler that allows for reopening the log files (I wonder why this
isn't part of the base FileHandler).

One thing we may have to do though is set the log file encoding.  What
do you think about that?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060423/fee017f4/attachment.pgp 

From brad at stop.mail-abuse.org  Mon Apr 24 07:08:10 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon, 24 Apr 2006 00:08:10 -0500
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
 mailman:	[7858] trunk/mailman
In-Reply-To: <1145851184.13311.166.camel@resist.wooz.org>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
Message-ID: <p06200719c0720d7e9187@[192.168.1.100]>

At 11:59 PM -0400 2006-04-23, Barry Warsaw wrote:

>  One thing we may have to do though is set the log file encoding.  What
>  do you think about that?

	Log file encoding?  I'm not sure I understand what you mean.  I 
can think of a few different ways that could be interpreted, and I 
don't know for sure that any of them are the meaning you intended to 
convey.

	Could you clarify and/or elaborate?

-- 
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 tkikuchi at is.kochi-u.ac.jp  Mon Apr 24 08:19:17 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon, 24 Apr 2006 15:19:17 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
 [7858] trunk/mailman
In-Reply-To: <p06200719c0720d7e9187@[192.168.1.100]>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>	<444ABCAE.6010405@is.kochi-u.ac.jp>	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
Message-ID: <444C6DE5.80401@is.kochi-u.ac.jp>

Brad Knowles wrote:
> At 11:59 PM -0400 2006-04-23, Barry Warsaw wrote:
> 
> 
>> One thing we may have to do though is set the log file encoding.  What
>> do you think about that?
> 
> 
> 	Log file encoding?  I'm not sure I understand what you mean.  I 
> can think of a few different ways that could be interpreted, and I 
> don't know for sure that any of them are the meaning you intended to 
> convey.
> 
> 	Could you clarify and/or elaborate?
> 
Well, it should be a mess. :-(

Consider mailman get a spam from a foreign country and caused an error. 
  Mailman may complain UnicodeDecodeError and spew an excerpt containing 
unknown charset string.  This is certainly not printable if there is no 
encoding which means only us-ascii is accepted for the log file.  Even 
if you determine the charset for your language (eg. euc-jp for 
japanese), you still get error for a chinese spam.

It may be useful if the log output use 'replace' feature of encode() method.

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

From stephen at xemacs.org  Mon Apr 24 10:12:09 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 24 Apr 2006 17:12:09 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
 [7858] trunk/mailman
In-Reply-To: <444C6DE5.80401@is.kochi-u.ac.jp> (Tokio Kikuchi's message of
	"Mon, 24 Apr 2006 15:19:17 +0900")
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
Message-ID: <87r73npf3a.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Tokio" == Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> writes:

    Tokio> Consider mailman get a spam from a foreign country and
    Tokio> caused an error. Mailman may complain UnicodeDecodeError
    Tokio> and spew an excerpt containing unknown charset string.

This really should not happen.  Mailman should trap *all*
UnicodeDecodeErrors at a very low level.  (You simply cannot yet count
on malformed message == SPAM in all contexts yet.  Eg, just last week
the Mac users here started flaming the Windows-using administration
for distributing mojibake.)

Then it should wash the message to make it safe.  RFC 2047-encode any
8-bit headers, and use a base64 Content-Transfer-Encoding for any
8-bit message bodies or body parts that don't have a known, approved
charset specified.  Bonus points for checking that 8-bit body parts
with a specified charset actually conform to it.

Finally, reraise some kind of exception that can be handled at the
filtering policy level.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From barry at python.org  Mon Apr 24 20:25:52 2006
From: barry at python.org (Barry Warsaw)
Date: Mon, 24 Apr 2006 14:25:52 -0400
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
	mailman:	[7858] trunk/mailman
In-Reply-To: <444C6DE5.80401@is.kochi-u.ac.jp>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
Message-ID: <1145903152.13311.221.camel@resist.wooz.org>

On Mon, 2006-04-24 at 15:19 +0900, Tokio Kikuchi wrote:

> Well, it should be a mess. :-(

I'm hoping we can make it less so!

> Consider mailman get a spam from a foreign country and caused an error. 
>   Mailman may complain UnicodeDecodeError and spew an excerpt containing 
> unknown charset string.  This is certainly not printable if there is no 
> encoding which means only us-ascii is accepted for the log file.  Even 
> if you determine the charset for your language (eg. euc-jp for 
> japanese), you still get error for a chinese spam.
> 
> It may be useful if the log output use 'replace' feature of encode() method.

That's probably a good idea.  Also, I'm wondering if we should allow
users to set the log file encoding in Defaults.py, or whether we should
force utf-8, or try to interrogate the system for the encoding value.

Basically, the logger should be as liberal as possible, just in case we
let encoding problems slip through (more on that in the next follow up).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060424/6ad9c772/attachment.pgp 

From barry at python.org  Mon Apr 24 20:33:22 2006
From: barry at python.org (Barry Warsaw)
Date: Mon, 24 Apr 2006 14:33:22 -0400
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
	mailman:	[7858] trunk/mailman
In-Reply-To: <87r73npf3a.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
	<87r73npf3a.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <1145903602.13317.227.camel@resist.wooz.org>

On Mon, 2006-04-24 at 17:12 +0900, Stephen J. Turnbull wrote:
> >>>>> "Tokio" == Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> writes:
> 
>     Tokio> Consider mailman get a spam from a foreign country and
>     Tokio> caused an error. Mailman may complain UnicodeDecodeError
>     Tokio> and spew an excerpt containing unknown charset string.
> 
> This really should not happen.  Mailman should trap *all*
> UnicodeDecodeErrors at a very low level.  (You simply cannot yet count
> on malformed message == SPAM in all contexts yet.  Eg, just last week
> the Mac users here started flaming the Windows-using administration
> for distributing mojibake.)

The general approach should be that /everything/ gets converted to
Unicode at the boundaries of the system.  In Mailman 2.1, all the
Unicode and i18n stuff was bolted on afterward, which is why we've had
so much pain throughout, dealing with Unicode conversions.  Ideally,
we'd get rid of all that for 2.2 and deal only with Unicode
internally.  

We may have to make modifications to the email package though, but I'm
not sure.  It should probably always return Unicode for everything.

> Then it should wash the message to make it safe.  RFC 2047-encode any
> 8-bit headers, and use a base64 Content-Transfer-Encoding for any
> 8-bit message bodies or body parts that don't have a known, approved
> charset specified.  Bonus points for checking that 8-bit body parts
> with a specified charset actually conform to it.
> 
> Finally, reraise some kind of exception that can be handled at the
> filtering policy level.

That sounds about right.  Probably the email package should convert
everything to Unicode internally and place Defects on the message
objects that have illegal encodings.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060424/772757c5/attachment.pgp 

From msapiro at value.net  Mon Apr 24 21:08:02 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 24 Apr 2006 12:08:02 -0700
Subject: [Mailman-Developers] Problems with Vietnamese translation
Message-ID: <PC174020060424120802067161402ce1@msapiro>

I have just done a 'clean' configure and make install from the currend
subversion trunk. I see the following issues:

There is a templates/vi directory in the trunk. It is empty, but it
really shouldn't be there at all.

More importantly, po2templ.py didn't create any templates in
templates/vi. This appears to be because in
messages/vi/LC_MESSAGES/mailman.po, the magic

#: templates/en/filename:1

headers are missing the ' ' between '#:' and 'templates'.

-- 
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  Tue Apr 25 05:31:33 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon, 24 Apr 2006 22:31:33 -0500
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
 [7858] trunk/mailman
In-Reply-To: <1145903152.13311.221.camel@resist.wooz.org>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>	
	<444ABCAE.6010405@is.kochi-u.ac.jp>	
	<1145851184.13311.166.camel@resist.wooz.org>	
	<p06200719c0720d7e9187@[192.168.1.100]> 
	<444C6DE5.80401@is.kochi-u.ac.jp>
	<1145903152.13311.221.camel@resist.wooz.org>
Message-ID: <p06200701c0734868a048@[192.168.1.100]>

At 2:25 PM -0400 2006-04-24, Barry Warsaw wrote:

>  That's probably a good idea.  Also, I'm wondering if we should allow
>  users to set the log file encoding in Defaults.py, or whether we should
>  force utf-8, or try to interrogate the system for the encoding value.

	Personally, I think we should default to US-ASCII in the log 
files, but I can see where some people might want to select a 
different encoding in mm_cfg.py.

-- 
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  Tue Apr 25 07:28:26 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 24 Apr 2006 22:28:26 -0700
Subject: [Mailman-Developers] [Mailman-i18n] Problems with Vietnamese
	translation
In-Reply-To: <D3F505A0-21CC-4272-AE1E-0C9443DD5403@riverland.net.au>
Message-ID: <PC1740200604242228260984212bb212@msapiro>

Clytie Siddall wrote:
>
>On 25/04/2006, at 4:38 AM, Mark Sapiro wrote:
>>
>> More importantly, po2templ.py didn't create any templates in
>> templates/vi. This appears to be because in
>> messages/vi/LC_MESSAGES/mailman.po, the magic
>>
>> #: templates/en/filename:1
>>
>> headers are missing the ' ' between '#:' and 'templates'.
>
>AFAIK, there shouldn't be any templates in trunk. They've been =20
>converted into the mailman.po file. This will be much easier to =20
>manage, especially when updating translations.


Yes, there shouldn't be any templates in the subversion trunk, but that
isn't what I was saying. I'm saying that 'make install' did not
extract the templates from the mailman.po for the templates/vi/
directory in the insatlled system. The reason for this is the magic
templates headers in messages/vi/LC_MESSAGES/mailman.po look like

#:templates/en/admindbdetails.html:1
#:templates/en/admindbpreamble.html:1
#:templates/en/admindbsummary.html:1
#:templates/en/adminsubscribeack.txt:1
#:templates/en/adminunsubscribeack.txt:1
etc.

and they should look like

#: templates/en/admindbdetails.html:1
#: templates/en/admindbpreamble.html:1
#: templates/en/admindbsummary.html:1
#: templates/en/adminsubscribeack.txt:1
#: templates/en/adminunsubscribeack.txt:1
etc.

because the po2templ.py script that extracts them from the mailman.po
file is looking specifically for

            if line.startswith('#: templates'):

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


From stephen at xemacs.org  Tue Apr 25 16:23:24 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 25 Apr 2006 23:23:24 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
	mailman:	[7858] trunk/mailman
In-Reply-To: <1145903602.13317.227.camel@resist.wooz.org> (Barry Warsaw's
	message of "Mon, 24 Apr 2006 14:33:22 -0400")
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
	<87r73npf3a.fsf@tleepslib.sk.tsukuba.ac.jp>
	<1145903602.13317.227.camel@resist.wooz.org>
Message-ID: <871wvln38j.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "BAW" == Barry Warsaw <barry at python.org> writes:

    BAW> Ideally, we'd get rid of all that for 2.2 and deal only with
    BAW> Unicode internally.

The original encoded stuff should be squirreled away somewhere for
debugging and maybe spam detection, though.

    BAW> We may have to make modifications to the email package
    BAW> though, but I'm not sure.  It should probably always return
    BAW> Unicode for everything.

That would be my recommendation (modulo preserving the original
headers at least, and probably the original body too, for debugging
etc).


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From stephen at xemacs.org  Tue Apr 25 16:28:42 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 25 Apr 2006 23:28:42 +0900
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman:
 [7858] trunk/mailman
In-Reply-To: <p06200701c0734868a048@[192.168.1.100]> (Brad Knowles's message
	of "Mon, 24 Apr 2006 22:31:33 -0500")
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
	<1145903152.13311.221.camel@resist.wooz.org>
	<p06200701c0734868a048@[192.168.1.100]>
Message-ID: <87wtddlof9.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

    Brad> 	Personally, I think we should default to US-ASCII in
    Brad> the log files, but I can see where some people might want to
    Brad> select a different encoding in mm_cfg.py.

I really think the log files should be UTF-8.  The point is to make
them as ASCII as possible, but if you've got readable garbage that you
want to log, it should be readable.  People who lack the fonts or
whatever wouldn't be able to read it anyway; people who can will be
able to convert the UTF-8 to something they can use.

If the garbage doesn't seem to be readable (eg, naked 8-bit crap in
the headers) then it should be BASE64'd in the logs.



-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From msapiro at value.net  Tue Apr 25 23:23:15 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 25 Apr 2006 14:23:15 -0700
Subject: [Mailman-Developers] Another Vietnamese translation issue
Message-ID: <PC1740200604251423150031dec95cae@msapiro>

There is no entry for Vietnamese in the add_languages() statements in
Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT
entries in Defaults.py.in in the trunk.

-- 
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  Tue Apr 25 23:46:58 2006
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 25 Apr 2006 14:46:58 -0700
Subject: [Mailman-Developers] Logging issues on the trunk
Message-ID: <PC17402006042514465801714a60ba25@msapiro>

There are a few remaining issues regarding logging in the svn trunk.

1) The ReopenableFileHandler.__init__ method in Mailman/loginit.py
   calls

         logging.FileHandler.__init__(self, filename, mode, encoding)

   This method only allows the instance, filename and mode arguments.
   The encoding argument throws a TypeError exception.

2) The 'locks' log is missing from the LOGGERS tuple in loginit.py

3) Mailman/LogFile.py still references Mailman.Logging.StampedLogger
   This is tricky if we want to maintain its current ability to be
   used outside of Mailman.

   I *think* we could change

        try:
            from Mailman.Logging.StampedLogger import StampedLogger
            _logfile = StampedLogger('locks')

   to

        try:
            from Mailman import loginit
            _logfile = logging.getLogger('mailman.locks')
            _logfile.write = _logfile.info

   where the import of loginit is just to see if it throws the
   exception. I'm not sure if we ever need to actually call

            loginit.initialize()

   as in most if not all cases, this has already been done by some
   superordinate importer of LogFile.

4) Many of the scripts/* files contain

        from Mailman.Logging.Utils import LogStdErr

        and

            LogStdErr('error', 'name')

I think these can just be deleted as the scripts/driver script
does the Mailman.loginit.initialize()

-- 
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  Wed Apr 26 17:16:21 2006
From: msapiro at value.net (Mark Sapiro)
Date: Wed, 26 Apr 2006 08:16:21 -0700
Subject: [Mailman-Developers] Problems with Vietnamese translation
In-Reply-To: <502EEE92-74E4-4482-B32C-262D5B229D90@riverland.net.au>
Message-ID: <PC1740200604260816210562071b1067@msapiro>

Clytie Siddall wrote:
>
>Weird. I used the latest .pot for Mailman, so the headers _should_ be  
>correct. I can't see how msgmerge can have changed that: it only  
>matches translations to original text. If the templates need to be  
>there in the installed system, I'll have to fix this. <sigh>  But I'd  
>still like to know how it happened. :(


I don't know. The mailman.pot does have the spaces between '#:' and the
path. msgmerge on my Cygwin test installation actually will put the
space in between '#:' and the path even if it isn't there in the
original mailman.po file, but if there are different msmerges out
there that exhibit different behavior, perhaps bin/po2templ.py needs
to be updated to account for differing formats.

In my case, I think the problem could be addressed by reordering
messages/Makefile.in to run msgmerge on the mailman.po before
po2templ.py and installing the templates, but if there are different
msgmerge behaviors, that wouldn't work for everyone. We'd need to
update po2templ.py.

It shouldn't be difficult to work up a patch to po2templ.py (using re)
that would make it more robust in this area. I'm willing to do that,
but I may not have time to get to it for a few days.


>Your next mail:
>
>> There is no entry for Vietnamese in the add_languages() statements in
>> Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT
>> entries in Defaults.py.in in the trunk.
>
>Who should add such entries? Should I? If so, please tell me what I  
>should do.

The comments in Defaults.py.in say in part

# Vgg: Language descriptions and charsets dictionary, any new supported
# language must have a corresponding entry here.

I think this means it's up to the translator to put it there, but I'm
not really familiar with Mailman i18n procedures.

If you look at Defaults.py.in in the trunk and in the Release_2_1-maint
branch (they're different in this respect) at the very end of the
file, it should be obvious what to do.


>Is this analagous with adding a language code to the ALL_LINGUAS line  
>in configure.in or configure.ac ?


No, not really.

configure.in contains commands to build ALL_LINGUAS by listing the
messages directory and selecting all subdirectory names of form '..'
and '.._..'.

The entries in Defaults.py are the same language codes, but they
contain the 'name' of the language (e.g., _(Vietnamese)), and the name
of the character set for the language.

-- 
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 Apr 26 19:39:06 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 26 Apr 2006 13:39:06 -0400
Subject: [Mailman-Developers] Logging issues on the trunk
In-Reply-To: <PC17402006042514465801714a60ba25@msapiro>
References: <PC17402006042514465801714a60ba25@msapiro>
Message-ID: <1146073146.11236.59.camel@resist.wooz.org>

On Tue, 2006-04-25 at 14:46 -0700, Mark Sapiro wrote:
> There are a few remaining issues regarding logging in the svn trunk.
> 
> 1) The ReopenableFileHandler.__init__ method in Mailman/loginit.py
>    calls
> 
>          logging.FileHandler.__init__(self, filename, mode, encoding)
> 
>    This method only allows the instance, filename and mode arguments.
>    The encoding argument throws a TypeError exception.

Looks like that's a Python 2.3/2.4 compatibility issue.  Dang.  Okay,
I'll figure out a workaround for that.

> 2) The 'locks' log is missing from the LOGGERS tuple in loginit.py

Thanks, I'll add that.

> 3) Mailman/LogFile.py still references Mailman.Logging.StampedLogger
>    This is tricky if we want to maintain its current ability to be
>    used outside of Mailman.
> 
>    I *think* we could change
> 
>         try:
>             from Mailman.Logging.StampedLogger import StampedLogger
>             _logfile = StampedLogger('locks')
> 
>    to
> 
>         try:
>             from Mailman import loginit
>             _logfile = logging.getLogger('mailman.locks')
>             _logfile.write = _logfile.info
> 
>    where the import of loginit is just to see if it throws the
>    exception. I'm not sure if we ever need to actually call
> 
>             loginit.initialize()
> 
>    as in most if not all cases, this has already been done by some
>    superordinate importer of LogFile.

That sounds about right.  We might want to parameterize the actual
logger name at the top in case someone wants to change that.  OTOH, I'm
not aware of anybody else actually using the LockFile.py implementation
outside of Mailman.

> 4) Many of the scripts/* files contain
> 
>         from Mailman.Logging.Utils import LogStdErr
> 
>         and
> 
>             LogStdErr('error', 'name')
> 
> I think these can just be deleted as the scripts/driver script
> does the Mailman.loginit.initialize()

That sounds right too.  Thanks for finding these Mark -- I'll attack
those tonight.  I'm also working on a diff that will replace getopt with
optparse and will put the bulk of the bin/* and cron/* scripts as
modules under Mailman.bin.  There will be a symlink from bin/mmshell to
the individual scripts, and mmshell will look at sys.argv[0] to figure
out which module to run.  The nice thing about this is that we won't
have to re-run configure every time one of those command line scripts
change, but only if mmshell changes.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060426/f7a27e3a/attachment.pgp 

From msapiro at value.net  Thu Apr 27 04:20:16 2006
From: msapiro at value.net (Mark Sapiro)
Date: Wed, 26 Apr 2006 19:20:16 -0700
Subject: [Mailman-Developers] Logging issues on the trunk
In-Reply-To: <1146073146.11236.59.camel@resist.wooz.org>
Message-ID: <PC174020060426192016028122d8af49@msapiro>

Barry Warsaw wrote:
>
>On Tue, 2006-04-25 at 14:46 -0700, Mark Sapiro wrote:

>> 1) The ReopenableFileHandler.__init__ method in Mailman/loginit.py
>>    calls
>>
>>          logging.FileHandler.__init__(self, filename, mode, encoding)
>>
>>    This method only allows the instance, filename and mode arguments.
>>    The encoding argument throws a TypeError exception.
>
>Looks like that's a Python 2.3/2.4 compatibility issue.  Dang.  Okay,
>I'll figure out a workaround for that.


It doesn't seem to me to be 2.3/2.4 compatibility. It doesn't work for
me with 2.4.1 and it didn't work for the poor soul who reported on
mailman-users that he tried building from source for the first time
and used the SVN trunk, and he has 2.3.5. There's no indication of an
encoding argument in either <http://docs.python.org/lib/node347.html>
or <http://docs.python.org/dev/lib/node391.html>


-- 
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  Thu Apr 27 05:07:31 2006
From: msapiro at value.net (Mark Sapiro)
Date: Wed, 26 Apr 2006 20:07:31 -0700
Subject: [Mailman-Developers] Problems with Vietnamese translation
In-Reply-To: <PC1740200604260816210562071b1067@msapiro>
Message-ID: <PC174020060426200731040622d8afd5@msapiro>

Mark Sapiro wrote:
>
>It shouldn't be difficult to work up a patch to po2templ.py (using re)
>that would make it more robust in this area. I'm willing to do that,
>but I may not have time to get to it for a few days.


Here's a patch

--- MM-Trunk/mailman/bin/po2templ.py 2006-04-18 18:06:32.484375000 -0700
+++ test-mailman-trunk/bin/po2templ.py 2006-04-26 19:42:24.843750000
-0700
@@ -27,8 +27,11 @@
 Usage: po2templ.py languages
 """

+import re
 import sys

+cre = re.compile('^#:[ ]*templates/en/(?P<filename>.*):1')
+

 ?
 def do_lang(lang):
@@ -38,10 +41,11 @@
     fp = file('messages/%s/LC_MESSAGES/mailman.po' % lang)
     try:
         for line in fp:
-            if line.startswith('#: templates'):
+            m = re.search(cre, line)
+            if m:
                 in_template = True
                 in_msg = False
-                filename = line[16:-3]
+                filename = m.group('filename')
                 outfilename = 'templates/%s/%s' % (lang, filename)
                 continue
             if in_template and line.startswith('#,'):


I tested this and it seems to work fine whether or not mailman.po has a
space after the '#:'.

Tokio,

Do you think we should go ahead and commit this on the trunk?

-- 
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  Thu Apr 27 15:32:06 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 27 Apr 2006 09:32:06 -0400
Subject: [Mailman-Developers] Logging issues on the trunk
In-Reply-To: <PC174020060426192016028122d8af49@msapiro>
References: <PC174020060426192016028122d8af49@msapiro>
Message-ID: <1146144726.21240.8.camel@geddy.wooz.org>

On Wed, 2006-04-26 at 19:20 -0700, Mark Sapiro wrote:
> Barry Warsaw wrote:

> >Looks like that's a Python 2.3/2.4 compatibility issue.  Dang.  Okay,
> >I'll figure out a workaround for that.
> 
> 
> It doesn't seem to me to be 2.3/2.4 compatibility. It doesn't work for
> me with 2.4.1 and it didn't work for the poor soul who reported on
> mailman-users that he tried building from source for the first time
> and used the SVN trunk, and he has 2.3.5. There's no indication of an
> encoding argument in either <http://docs.python.org/lib/node347.html>
> or <http://docs.python.org/dev/lib/node391.html>

Oh nice.  From scanning the logs, it appears as though the encoding
stuff appeared in 2.4.2.  Bad, bad, bad, bad, bad.

In any event, we need to make this stuff work with 2.3 so I'll fix that,
probably by writing a complete reopenable file handler from scratch.
That'll let us pass the error handling to the codec open too, which we
definitely need.

Won't happen in the about to go in next patch, but hopefully I will get
to it tonight.

Also, note to those running the trunk: development is picking up and
it's very possible that things may be unstable for a bit.  I'm going to
try to get the new tracker up as quickly as possible, but for now, just
let us know here on this mailing list and we'll get to it as soon as
possible.  

Also, if you're interested in working on Mailman 2.2, let us know.  I'd
like to get more people involved!

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060427/81c2f365/attachment.pgp 

From fil at rezo.net  Thu Apr 27 16:45:33 2006
From: fil at rezo.net (Fil)
Date: Thu, 27 Apr 2006 16:45:33 +0200
Subject: [Mailman-Developers] Logging issues on the trunk
In-Reply-To: <1146144726.21240.8.camel@geddy.wooz.org>
References: <PC174020060426192016028122d8af49@msapiro>
	<1146144726.21240.8.camel@geddy.wooz.org>
Message-ID: <20060427144530.GT2088@rezo.net>

> Also, if you're interested in working on Mailman 2.2, let us know.  I'd
> like to get more people involved!

I am interested; there are parts of my MySQL plugin patches that are
unrelated to MySQL, but permit to make the UI better for big lists.

-- Fil


From msapiro at value.net  Fri Apr 28 05:31:47 2006
From: msapiro at value.net (Mark Sapiro)
Date: Thu, 27 Apr 2006 20:31:47 -0700
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <4450E5D3.10304@imsa.edu>
Message-ID: <PC17402006042720314702039f372f1a@msapiro>

Neal Groothuis wrote:
>
>I would like to request that a feature be added in the next version of
>Mailman to allow a list administrator to disable rewriting of the
>"Sender:" header, or (better) for this behavior to be eliminated from
>Mailman altogether.


The best place to make this kind of request is in FeatureRequests in
the sourceforge.net tracker, and it is already there at
http://sourceforge.net/tracker/index.php?func=detail&aid=1460796&group_id=103&atid=350103.
Please look at that item and add your own comments as you wish.

Note however that there is motivation for keeping the Sender behavior
as is because there are still broken MTAs that will return bounces to
the Sender:, so anything that actually is implemented would likely be
an option with current behavior as the default.

Also, RFC 2822 arguably requires a Sender: header in the case of a list
sending mail on behalf of a poster.

-- 
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 Apr 28 05:46:20 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 27 Apr 2006 22:46:20 -0500
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <4450E5D3.10304@imsa.edu>
References: <4450E5D3.10304@imsa.edu>
Message-ID: <p0620070dc0773e58b486@[192.168.1.65]>

At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:

>  I would like to request that a feature be added in the next version of
>  Mailman to allow a list administrator to disable rewriting of the
>  "Sender:" header, or (better) for this behavior to be eliminated from
>  Mailman altogether.

	Have you filed an RFE at the appropriate SourceForge page for Mailman?

>   - Outlook treats the Sender field as a person sending on behalf of
>  another.  This seems to me to be a reasonable interpretation of the
>  Sender field, per RFC 2822 3.6.2.  When a "bounces" address is included
>  in the sender field, Outlook displays something along the lines of "From
>  listname-bounces+jim=reader.domain.com at mailman.server.com On behalf of
>  fred at poster.domain.com".  (See Mailman FAQ entry 2.3).  This is undesirable.

	This is an MUA problem.  See FAQ 2.3.

>   - Useful information (the original content of the Sender: header) is
>  lost by doing this.

	If the previous value of the "Sender:" field is being lost, then 
that should be corrected.  At the very least, the value should be 
saved in an "Old-Sender:" or "Previous-Sender:" or some other 
suitable renamed sender field.

>   - Bounces go to the envelope sender or Return-Path: header, not the
>  Sender: header, so this is not necessary for proper bounce handling.

	Mailman does not modify this header for the purpose of routing 
bounces to the appropriate place.  Mailman modifies this header 
because the original "From:" header is left unchanged and the RFC 
specifies that we should indicate when the message has been forwarded 
or sent by someone/something else on behalf of the entity in the 
"From:" field.

>   - Again from RFC 2822 3.6.2, the Sender: header should contain the
>  address of the agent responsible for transmitting the message, meaning
>  that a person who sends mail to the address in that header should expect
>  to reach said agent, not suggest to Mailman that a message bounced.

	Right.  Mailman is the agent responsible for transmitting the 
message, and this needs to be reflected.  However, we want to make 
sure to capture any potential messages that may be routed to the 
"Sender:" field and have them automatically processed through the 
part of the system that is designed to do that sort of thing.

>   - Information regarding interacting with the list is provided by the
>  List-* headers; including it in the Sender: field is unnecessary.

	No, it is necessary.  It's required by the RFCs.

>  Removing this (IMO) unwanted functionality is trivial:

	The problem is that you said you wanted to implement an option to 
allow people to turn it off, not to rip this feature completely out 
of the system.

	Implementing the option and putting in the necessary UI features 
so that site and list administrators can choose whether or not to 
modify the headers in this way is a considerably more complex task 
than just ripping out a feature you don't like.


	Give us some suitable code to make this feature optional and 
controllable by the site admin (and something that can be delegated 
to the list admin), and you'll have a much better chance of getting 
someone to pay attention to your request.

	Otherwise, keep applying the patch to each new version of Mailman 
as you install it.

-- 
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  Fri Apr 28 07:59:59 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 01:59:59 -0400
Subject: [Mailman-Developers] [Mailman-i18n] Problems with Vietnamese
	translation
In-Reply-To: <PC1740200604260816210562071b1067@msapiro>
References: <PC1740200604260816210562071b1067@msapiro>
Message-ID: <1146203999.10790.82.camel@resist.wooz.org>

On Wed, 2006-04-26 at 08:16 -0700, Mark Sapiro wrote:

> >Your next mail:
> >
> >> There is no entry for Vietnamese in the add_languages() statements in
> >> Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT
> >> entries in Defaults.py.in in the trunk.
> >
> >Who should add such entries? Should I? If so, please tell me what I  
> >should do.
> 
> The comments in Defaults.py.in say in part
> 
> # Vgg: Language descriptions and charsets dictionary, any new supported
> # language must have a corresponding entry here.
> 
> I think this means it's up to the translator to put it there, but I'm
> not really familiar with Mailman i18n procedures.

Just for the record, it's fine for the translator to add an entry here
for their language.  Often though, new languages are donated by people
who don't have commit privileges, so it should technically be done by
whoever does the initial commit of the language.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/59d434c2/attachment.pgp 

From barry at python.org  Fri Apr 28 14:42:23 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 08:42:23 -0400
Subject: [Mailman-Developers] Logging issues on the trunk
In-Reply-To: <PC17402006042514465801714a60ba25@msapiro>
References: <PC17402006042514465801714a60ba25@msapiro>
Message-ID: <1146228143.10787.92.camel@resist.wooz.org>

On Tue, 2006-04-25 at 14:46 -0700, Mark Sapiro wrote:
> There are a few remaining issues regarding logging in the svn trunk.

Thanks.  I think all these issues should be resolved now, however the
scripts/* scripts have only been minimally tested.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/81b81fc4/attachment.pgp 

From barry at python.org  Fri Apr 28 15:06:41 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 09:06:41 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <p0620070dc0773e58b486@[192.168.1.65]>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
Message-ID: <1146229601.10791.101.camel@resist.wooz.org>

On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:

> 	If the previous value of the "Sender:" field is being lost, then 
> that should be corrected.  At the very least, the value should be 
> saved in an "Old-Sender:" or "Previous-Sender:" or some other 
> suitable renamed sender field.

Probably Original-Sender:

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/0f78ca18/attachment.pgp 

From barry at python.org  Fri Apr 28 18:19:45 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 12:19:45 -0400
Subject: [Mailman-Developers] [Mailman-checkins] SF.net SVN:
	mailman:	[7858] trunk/mailman
In-Reply-To: <871wvln38j.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <E1FVL2c-0007Yf-VJ@sc8-pr-svn1.sourceforge.net>
	<444ABCAE.6010405@is.kochi-u.ac.jp>
	<1145851184.13311.166.camel@resist.wooz.org>
	<p06200719c0720d7e9187@[192.168.1.100]>
	<444C6DE5.80401@is.kochi-u.ac.jp>
	<87r73npf3a.fsf@tleepslib.sk.tsukuba.ac.jp>
	<1145903602.13317.227.camel@resist.wooz.org>
	<871wvln38j.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <1146241185.10791.120.camel@resist.wooz.org>

On Tue, 2006-04-25 at 23:23 +0900, Stephen J. Turnbull wrote:
> >>>>> "BAW" == Barry Warsaw <barry at python.org> writes:

>     BAW> We may have to make modifications to the email package
>     BAW> though, but I'm not sure.  It should probably always return
>     BAW> Unicode for everything.
> 
> That would be my recommendation (modulo preserving the original
> headers at least, and probably the original body too, for debugging
> etc).

We still have some time to do this in the email package for Python 2.5,
but not much.  PEP 356 says that Python 2.5 beta 1 is scheduled for June
24th, and after that we'll be feature frozen.

Can we discuss any necessary changes on the email-sig, please?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/243391d8/attachment.pgp 

From jwblist at loricamail.com  Fri Apr 28 19:29:24 2006
From: jwblist at loricamail.com (John W. Baxter)
Date: Fri, 28 Apr 2006 10:29:24 -0700
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <1146229601.10791.101.camel@resist.wooz.org>
Message-ID: <C0779F04.C339%jwblist@loricamail.com>

On 4/28/06 6:06 AM, "Barry Warsaw" <barry at python.org> wrote:

> On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
> 
>> If the previous value of the "Sender:" field is being lost, then
>> that should be corrected.  At the very least, the value should be
>> saved in an "Old-Sender:" or "Previous-Sender:" or some other
>> suitable renamed sender field.
> 
> Probably Original-Sender:

Probably, indeed.  But what happens if that header was already "taken" in
the process that brought the message to mailman for distribution to the
list?

(As usual, I have only questions, not answers.)

  --John



From ngroot at imsa.edu  Thu Apr 27 17:40:03 2006
From: ngroot at imsa.edu (Neal Groothuis)
Date: Thu, 27 Apr 2006 10:40:03 -0500
Subject: [Mailman-Developers] Sender field
Message-ID: <4450E5D3.10304@imsa.edu>

To reopen an old discussion:

I would like to request that a feature be added in the next version of
Mailman to allow a list administrator to disable rewriting of the
"Sender:" header, or (better) for this behavior to be eliminated from
Mailman altogether.

Rationale:

  - Outlook treats the Sender field as a person sending on behalf of
another.  This seems to me to be a reasonable interpretation of the
Sender field, per RFC 2822 3.6.2.  When a "bounces" address is included
in the sender field, Outlook displays something along the lines of "From
listname-bounces+jim=reader.domain.com at mailman.server.com On behalf of
fred at poster.domain.com".  (See Mailman FAQ entry 2.3).  This is undesirable.

  - Thunderbird also displays the sender field, which presents similar
confusion.

  - Useful information (the original content of the Sender: header) is
lost by doing this.

  - Bounces go to the envelope sender or Return-Path: header, not the
Sender: header, so this is not necessary for proper bounce handling.

  - Again from RFC 2822 3.6.2, the Sender: header should contain the
address of the agent responsible for transmitting the message, meaning
that a person who sends mail to the address in that header should expect
to reach said agent, not suggest to Mailman that a message bounced.

  - Information regarding interacting with the list is provided by the
List-* headers; including it in the Sender: field is unnecessary.


Removing this (IMO) unwanted functionality is trivial:

diff -ru mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py 
mailman-2.1.5/Mailman
/Handlers/SMTPDirect.py
--- mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py   2004-01-22 
17:02:07.0000
00000 -0600
+++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py        2006-04-26 
13:48:45.0000
00000 -0500
@@ -348,9 +348,9 @@
      # the Sender header at all.  Brad Knowles points out that MTAs tend to
      # wipe existing Return-Path headers, and old MTAs may still honor
      # Errors-To while new ones will at worst ignore the header.
-    del msg['sender']
+    # del msg['sender']
      del msg['errors-to']
-    msg['Sender'] = envsender
+    # msg['Sender'] = envsender
      msg['Errors-To'] = envsender
      # Get the plain, flattened text of the message, sans unixfrom
      msgtext = msg.as_string()

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

From ngroot at imsa.edu  Fri Apr 28 18:02:11 2006
From: ngroot at imsa.edu (Neal Groothuis)
Date: Fri, 28 Apr 2006 11:02:11 -0500
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <p0620070dc0773e58b486@[192.168.1.65]>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
Message-ID: <44523C83.6080509@imsa.edu>

It does not appear that Mailman modifies the "Sender:" field to comply 
with RFC 2822.  The list-bounces address is not the mailbox of the agent 
responsible for transmitting the message, as required in section 3.6.2. 
  The mailbox of the agent responsible for the transmission of the 
message would be the list-owner address.

Mailman's use the "Sender:" field does not seem to be in line with the 
intent of the RFC, nor with current usage of the field.   The example 
given in the RFC is of a secretary sending an email on behalf of someone 
else.  Outlook obviously interprets it this way.  Some versions of 
Thunderbird display both the Sender: and From: lines to the user, which 
may prove confusing if the Sender: address is not a person or an obvious 
alias for one.  Gmail uses it if you choose a "From" address that is not 
your gmail.com address.

Further, if Mailman is going to change the "Sender:" field, it should 
add Resent-* headers, per section 3.6.6 of RFC 2822; otherwise, the 
original sender information is lost.  The RFC does say that this is to 
be used when "users" reintroduce a message into the system, further 
providing evidence that automated components of the mail routing system 
shouldn't be changing these.  (Note that MTAs don't change the Sender: 
field, despite being, by their nature, agents responsible for 
transmission of messages.)

RFC 2369 provides headers which are to be used by mail list software to 
identify the various ways of interacting with the list, and Mailman 
already adds them.  This makes adding this information to the Sender: 
field redundant.

Based on all of this, Mark's note that there are some MTAs which bounce 
to the Sender: address is the only reason that I've seen why this 
behavior should continue.  Does anyone know what MTAs these are, or if 
they're even still in use?  If these buggy MTAs are common, I would 
suggest that an option be added to the list to enable this behavior, 
marked as an accomodation for buggy MTAs, and defaulting to "off".  I'll 
see if I can scrounge up the time to submit a patch to accomplish this, 
if it'll actually get included in a future release; otherwise I won't 
waste my time.  If these MTAs are not in use, I stand by my original 
recommendation to comment out/remove the two lines responsible for the 
behavior.

At any rate, the "keep patching" suggestion is unhelpful.   This is 
obviously a problem that many people are running into, enough that 
there's a FAQ entry about it.  It should be addressed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3283 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/503a8dd4/attachment-0001.bin 

From ngroot at imsa.edu  Fri Apr 28 20:05:45 2006
From: ngroot at imsa.edu (Neal Groothuis)
Date: Fri, 28 Apr 2006 13:05:45 -0500
Subject: [Mailman-Developers] [Mailman-Users]   Sender field
In-Reply-To: <C0779F04.C339%jwblist@loricamail.com>
References: <C0779F04.C339%jwblist@loricamail.com>
Message-ID: <44525979.6040301@imsa.edu>

John W. Baxter wrote:
> Probably, indeed.  But what happens if that header was already "taken" in
> the process that brought the message to mailman for distribution to the
> list?

As I noted in my previous response, I believe that the correct field (if 
Mailman were to add a "Sender:" header) to add would be "Resent-Sender". 
  Please see RFC 2822, section 3.6.6.  The "Resent-Sender" field may be 
multivalued, so this isn't a problem.  However, Mailman should not be 
modifying the Sender: field at all.

"Original-Sender" is a header used when gatewaying X.400 messages into 
RFC 822 messages for use in JNT mail networks.  It would not be 
appropriate for use here.


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

From msapiro at value.net  Fri Apr 28 20:06:38 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 28 Apr 2006 11:06:38 -0700
Subject: [Mailman-Developers] Problem with new bin/Makefile and Cygwin
Message-ID: <PC1740200604281106380218200daf20@msapiro>

The recent 'mmshell' change to bin/Makefile.in causes a problem in
Cygwin (I really have to make a 'real' test platform one of these
days, but that's another story).

The change adds

	for f in $(LN_SCRIPTS); \
	do \
	    rm -f $(DESTDIR)/$(SCRIPTSDIR)/$$f; \
	    (cd $(DESTDIR)/$(SCRIPTSDIR); $(LN_S) mmshell $$f); \
	done

This should really be

	for f in $(LN_SCRIPTS); \
	do \
	    rm -f $(DESTDIR)$(SCRIPTSDIR)/$$f; \
	    (cd $(DESTDIR)$(SCRIPTSDIR); $(LN_S) mmshell $$f); \
	done

DESTDIR is normally null and SCRIPTSDIR is $(prefix)/bin. With the
extra slash, this creates a path that on Cygwin winds up looking in my
case like '//cygdrive/f/test-mailman/bin'. Normally, the doubled slash
wouldn't matter, but /cygdrive/f is not a real directory, it is a
magic construct that refers to the root of the F: drive, and
//cygdrive/f doesn't work.

-- 
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 Apr 28 20:08:28 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 14:08:28 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <C0779F04.C339%jwblist@loricamail.com>
References: <C0779F04.C339%jwblist@loricamail.com>
Message-ID: <1146247708.10788.122.camel@resist.wooz.org>

On Fri, 2006-04-28 at 10:29 -0700, John W. Baxter wrote:
> On 4/28/06 6:06 AM, "Barry Warsaw" <barry at python.org> wrote:
> 
> > On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
> > 
> >> If the previous value of the "Sender:" field is being lost, then
> >> that should be corrected.  At the very least, the value should be
> >> saved in an "Old-Sender:" or "Previous-Sender:" or some other
> >> suitable renamed sender field.
> > 
> > Probably Original-Sender:
> 
> Probably, indeed.  But what happens if that header was already "taken" in
> the process that brought the message to mailman for distribution to the
> list?
> 
> (As usual, I have only questions, not answers.)

Original-Original-Sender:

(and so on, and so on... :)
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/6eb20b4a/attachment.pgp 

From bob at nleaudio.com  Fri Apr 28 20:23:21 2006
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Fri, 28 Apr 2006 14:23:21 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44525BFC.7070503@imsa.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu> <445259D3.3010302@nleaudio.com>
	<44525BFC.7070503@imsa.edu>
Message-ID: <44525D99.6040509@nleaudio.com>

Not quite.  http://new.openspf.org/FAQ/Envelope_from_scope

Neal Groothuis wrote:

> Bob Puff at NLE wrote:
> 
>> Don't forget to consider things like SPF, which I think uses the 
>> sender field.  Whatever is used for SPF _must_ be the domain of the 
>> mailman box, or you're gonna run into a pack of trouble.
> 
> 
> SPF is based on the client name presented in the HELO command in an SMTP 
> transaction and the return path, as given in the MAIL command.  The 
> Sender: field is not used.

From bob at nleaudio.com  Fri Apr 28 20:08:38 2006
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Fri, 28 Apr 2006 14:08:38 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44523C83.6080509@imsa.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu>
Message-ID: <44525A26.6000007@nleaudio.com>

Don't forget to consider things like SPF, which I think uses the sender field.  Whatever is used for 
SPF _must_ be the domain of the mailman box, or you're gonna run into a pack of trouble.

...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the 
FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com 
address.  Its a very bad problem, because AOL is saying its a SPF problem, when it clearly isn't (as 
  other aol people can post to the list and receive their posts), and all the aol users are being 
automatically unsubscribed from lists that this guy posts on.  But I digress...

Bob

Neal Groothuis wrote:

 > It does not appear that Mailman modifies the "Sender:" field to comply with RFC 2822.  The 
list-bounces address is not the mailbox of the agent responsible for transmitting the message, as 
required in section 3.6.2.  The mailbox of the agent responsible for the transmission of the message 
would be the list-owner address.
 >
 > Mailman's use the "Sender:" field does not seem to be in line with the intent of the RFC, nor 
with current usage of the field.

<snip>

From dallas at dreamhost.com  Fri Apr 28 20:47:55 2006
From: dallas at dreamhost.com (Dallas Bethune)
Date: Fri, 28 Apr 2006 11:47:55 -0700
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44523C83.6080509@imsa.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu>
Message-ID: <DDE91D61-13E3-4476-9151-77689180834D@dreamhost.com>

What I have noticed is most of our Outlook users are confused by the  
presence of the word 'bounces' in the From field more than they are  
annoyed at the way Outlook deals with the Sender header.  When they  
see 'bounces' they assume something went wrong.  For our uses just  
changing that list-bounces address to something less ominous looking  
would help.

	Dallas


On Apr 28, 2006, at 9:02 AM, Neal Groothuis wrote:

> It does not appear that Mailman modifies the "Sender:" field to  
> comply with RFC 2822.  The list-bounces address is not the mailbox  
> of the agent responsible for transmitting the message, as required  
> in section 3.6.2.  The mailbox of the agent responsible for the  
> transmission of the message would be the list-owner address.
>
> Mailman's use the "Sender:" field does not seem to be in line with  
> the intent of the RFC, nor with current usage of the field.   The  
> example given in the RFC is of a secretary sending an email on  
> behalf of someone else.  Outlook obviously interprets it this way.   
> Some versions of Thunderbird display both the Sender: and From:  
> lines to the user, which may prove confusing if the Sender: address  
> is not a person or an obvious alias for one.  Gmail uses it if you  
> choose a "From" address that is not your gmail.com address.
>
> Further, if Mailman is going to change the "Sender:" field, it  
> should add Resent-* headers, per section 3.6.6 of RFC 2822;  
> otherwise, the original sender information is lost.  The RFC does  
> say that this is to be used when "users" reintroduce a message into  
> the system, further providing evidence that automated components of  
> the mail routing system shouldn't be changing these.  (Note that  
> MTAs don't change the Sender: field, despite being, by their  
> nature, agents responsible for transmission of messages.)
>
> RFC 2369 provides headers which are to be used by mail list  
> software to identify the various ways of interacting with the list,  
> and Mailman already adds them.  This makes adding this information  
> to the Sender: field redundant.
>
> Based on all of this, Mark's note that there are some MTAs which  
> bounce to the Sender: address is the only reason that I've seen why  
> this behavior should continue.  Does anyone know what MTAs these  
> are, or if they're even still in use?  If these buggy MTAs are  
> common, I would suggest that an option be added to the list to  
> enable this behavior, marked as an accomodation for buggy MTAs, and  
> defaulting to "off".  I'll see if I can scrounge up the time to  
> submit a patch to accomplish this, if it'll actually get included  
> in a future release; otherwise I won't waste my time.  If these  
> MTAs are not in use, I stand by my original recommendation to  
> comment out/remove the two lines responsible for the behavior.
>
> At any rate, the "keep patching" suggestion is unhelpful.   This is  
> obviously a problem that many people are running into, enough that  
> there's a FAQ entry about it.  It should be addressed.
> _______________________________________________
> 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/dallas%40dreamhost.com
>
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py? 
> req=show&file=faq01.027.htp


From msapiro at value.net  Fri Apr 28 21:42:20 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 28 Apr 2006 12:42:20 -0700
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <DDE91D61-13E3-4476-9151-77689180834D@dreamhost.com>
Message-ID: <PC1740200604281242200140d8835660@msapiro>

Dallas Bethune wrote:

>For our uses just  
>changing that list-bounces address to something less ominous looking  
>would help.

It definitely looks to me as if something needs to be done. I think
perhaps offering 3 options either to the list admin on a per-list
basis with a site default or just a site option. I lean towards
per-list although it's more work to add to the GUI.

The options I see are

1) current behavior with perhaps the addition of putting the original
Sender: in another header.

2) like 1) only use list address instead of list-bounces.

3) don't touch Sender: at all.

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


From qralston+ml.mailman-developers at andrew.cmu.edu  Fri Apr 28 23:32:19 2006
From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston)
Date: Fri, 28 Apr 2006 17:32:19 -0400
Subject: [Mailman-Developers] Sender field
In-Reply-To: <74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
Message-ID: <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>

On 2006-04-27 at 22:46-05 Brad Knowles <brad at stop.mail-abuse.org> wrote:

> At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:
> 
> > Again from RFC 2822 3.6.2, the Sender: header should contain the
> > address of the agent responsible for transmitting the message,
> > meaning that a person who sends mail to the address in that header
> > should expect to reach said agent, not suggest to Mailman that a
> > message bounced.
> 
> Right.  Mailman is the agent responsible for transmitting the
> message, and this needs to be reflected.

This is not correct.  Quoting RFC2822 section 3.6.2:

    3.6.2. Originator fields

    The originator fields indicate the mailbox(es) of the source of
    the message.  The "From:" field specifies the author(s) of the
    message, that is, the mailbox(es) of the person(s) or system(s)
    responsible for the writing of the message.  The "Sender:" field
    specifies the mailbox of the agent responsible for the actual
    transmission of the message.  For example, if a secretary were to
    send a message for another person, the mailbox of the secretary
    would appear in the "Sender:" field and the mailbox of the actual
    author would appear in the "From:" field.

The Sender header should be employed by the orignator of the message,
and only the originator.  Mailman is not the originator of a message
sent to a list; it is merely a relay agent.

I will grant that the phrasing of the RFC is suboptimal here--it uses
"transmission" when a better word choice would have been "submission".
But the immediately proceeding example (of a secretary sending mail on
behalf of another person) clarifies the intent beyond any claim of
ambiguity.

> [Outlook's behavior] is an MUA problem.  See FAQ 2.3.

No, it's not.  As much as it pains me to say it, Outlook's behavior
matches perfectly the intent of the RFC.  It is Mailman's behavior of
rewriting the Sender header that is the problem.

> However, we want to make sure to capture any potential messages that
> may be routed to the "Sender:" field and have them automatically
> processed through the part of the system that is designed to do that
> sort of thing.

Mailman's "processing" behavior is to treat a reply to the Sender as a
bounce.  This is incorrect behavior, because many mail clients will
include address of the Sender header in a "reply-to-all" function,
causing Mailman to treat the reply as a bounce.

So, in summary, the disadvantages of Mailman's behavior of rewriting
the Sender header is that doing so is not in the intended spirit of
RFC2822, causes subscription grief, and breaks Outlook.  The advantage
is that it helps Mailman detect bounces from a slim minority of
brain-dead MTAs that send bounces to the Sender header.

> The problem is that you said you wanted to implement an option to
> allow people to turn it off, not to rip this feature completely out
> of the system.

I would argue that the best course of action is to excise Sender
header rewriting entirely and provide no option to turn it on.
(Mailman has way too many options already.)

If, however, an option is created to control the behavior, it should
definitely default to OFF (no Sender header rewriting), not on.

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA


From ehrbar at lists.econ.utah.edu  Fri Apr 28 22:13:25 2006
From: ehrbar at lists.econ.utah.edu (Hans G. Ehrbar)
Date: Fri, 28 Apr 2006 14:13:25 -0600
Subject: [Mailman-Developers]  [Mailman-Users] Sender field
In-Reply-To: <PC1740200604281242200140d8835660@msapiro> (message from Mark
	Sapiro on Fri, 28 Apr 2006 12:42:20 -0700)
References: <PC1740200604281242200140d8835660@msapiro>
Message-ID: <E1FZZLB-0001yR-US@lists.econ.utah.edu>


I strongly second the idea of replacing the listname-bounces
address by a different address which does not suggest that
something went wrong.  This brings to mind another example
of an unfortunate choice of words: on some of my mailing
lists people got outright paranoid because they received a
message that their submission was not accepted because of
"suspicious headers".  They thought they were being
censored.  Appearances sometimes mean a lot.

Hans G. Ehrbar

-- 
Hans G. Ehrbar   http://www.econ.utah.edu/~ehrbar   ehrbar at economics.utah.edu
Economics Department, University of Utah     (801) 581 7797 (my office)
1645 Campus Center Dr., Rm 308               (801) 581 7481 (econ office)
Salt Lake City    UT 84112-9300              (801) 585 5649 (FAX)


From lennon at reed.edu  Fri Apr 28 23:10:52 2006
From: lennon at reed.edu (Lennon Day-Reynolds)
Date: Fri, 28 Apr 2006 14:10:52 -0700
Subject: [Mailman-Developers] New Mailman wiki,
	Subversion (and other stuff)
In-Reply-To: <1145126047.3167.13.camel@resist.wooz.org>
References: <1145126047.3167.13.camel@resist.wooz.org>
Message-ID: <B657F5A0-5A00-47AC-9413-FC59BDB9466A@reed.edu>

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

On Apr 15, 2006, at 11:34 AM, Barry Warsaw wrote:
> Now that these changes have been made, I think it's time to start
> planning for Mailman 2.2.  To that end, I would like most development
> artifacts to be recorded in the wiki, although discussion should still
> happen on mailman-developers (there's a 'Development' space and a link
> for 2.2 under that).  I also plan on getting our data imported into
> Rosetta so we can coordinate i18n there; it's mostly my fault I've
> dropped the ball on this one.

I would like to offer my help in the GUI modernization aspects of the  
Mailman 2.2 plan. I've already done some work on a system in  
production here at Reed that uses web.py and Cheetah to present an  
alternate front-end, as well as applying our own CSS and templates  
styles to the built-in Mailman administration and moderation pages.

Our system also "fakes" a unified member database by forcing use of  
canonical internal email addresses and offers one-click subscriptions  
to users who've already authenticated through our single-sign-on  
infrastructure. As a part of that, I've also made some (horribly  
hackish, but useful as a proof-of-concept) modifications to the built- 
in CGI scripts' authN logic that allow them to check the existing  
HTTP auth credentials passed along by the web server to determine if  
a user has admin/mod privileges for a list.

We're pretty committed to Mailman, and have a number of systems I've  
written which integrate with it either via the command-line  
administrative tools or the internal Python API, so chance are we'll  
be spending a lot of time working on these issues regardless.  
Obviously, I'd prefer to maximize the chances that my work could get  
pushed upstream, so I'd love to work closely with you guys to  
coordinate priorities and coding standards.

Looking forward to working with you guys,

Lennon Day-Reynolds
System Support Specialist
Reed College
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEUoTfRtirLnfvQskRAm1KAJwIKh9mhzulbGbS8vEIbkOdlqUaywCghheB
h+VEM+/s7uohEVDMhgmOXuI=
=xnGf
-----END PGP SIGNATURE-----

From brad at stop.mail-abuse.org  Sat Apr 29 00:15:14 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 28 Apr 2006 17:15:14 -0500
Subject: [Mailman-Developers] Sender field
In-Reply-To: <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
	<4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
Message-ID: <p06200710c0784134609c@[192.168.1.65]>

At 5:32 PM -0400 2006-04-28, James Ralston wrote:

>  I will grant that the phrasing of the RFC is suboptimal here--it uses
>  "transmission" when a better word choice would have been "submission".
>  But the immediately proceeding example (of a secretary sending mail on
>  behalf of another person) clarifies the intent beyond any claim of
>  ambiguity.

	I read through all of section 3.4 pretty carefully. 
Unfortunately, I haven't been able to find any references to 
automated agents acting on behalf of other parties.  It is not 
exactly clear to me if a "relay agent" should be considered as a 
"user" (for which examples are given), or if it should be treated in 
some other manner.

	There are cases of "forwarding" mentioned where it is not 
appropriate to make any modifications to any headers, but there are 
other cases where modifications are acceptable or even recommended.

	Additional clarification would be very useful.

>  So, in summary, the disadvantages of Mailman's behavior of rewriting
>  the Sender header is that doing so is not in the intended spirit of
>  RFC2822, causes subscription grief, and breaks Outlook.  The advantage
>  is that it helps Mailman detect bounces from a slim minority of
>  brain-dead MTAs that send bounces to the Sender header.

	On the whole, I'm coming around to the view that Mailman should 
be using "Resent-" headers for the things it would like to add to the 
message (e.g., Resent-From:, Resent-Date:, Resent-Message-ID:, 
etc...), as well as the standard "List-" headers.

	However, it is not clear to me what the impact on the user 
community would be.

	Yes, some users would stop seeing things that are confusing them, 
because we would stop rewriting/replacing the "Sender:" field. 
Well-known MTAs would not have any problems with these changes, but I 
do have to wonder what the negative impact would be from less common 
MTAs, not to mention all the different MUAs that are out there.

>  I would argue that the best course of action is to excise Sender
>  header rewriting entirely and provide no option to turn it on.
>  (Mailman has way too many options already.)
>
>  If, however, an option is created to control the behavior, it should
>  definitely default to OFF (no Sender header rewriting), not on.

	Right now, I'm probably somewhere around 75% convinced that we 
should not be rewriting/replacing the "Sender:" header, and should be 
using appropriate "Resent-" headers instead.  At least, in the ideal 
world.


	However, In the real world, I am much less convinced that we 
should be making a radical change like this, at least not without a 
lot more experience in how things are actually impacted.

	I would support adding code to the system to make this change 
optional and to initially default to the old behaviour (allowing 
people who want to play with this option to do so), then in a future 
version to default to the proposed new behaviour (but still giving 
people the option to go back to the old method), and then finally to 
removing the option to revert to the old behaviour at some distant 
point in the future.

	But I definitely would not support just ripping out the offending code.

-- 
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  Sat Apr 29 00:23:23 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 28 Apr 2006 17:23:23 -0500
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44525D99.6040509@nleaudio.com>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu> <445259D3.3010302@nleaudio.com>
	<44525BFC.7070503@imsa.edu> <44525D99.6040509@nleaudio.com>
Message-ID: <p06200711c0784604814f@[192.168.1.65]>

At 2:23 PM -0400 2006-04-28, Bob Puff at NLE wrote:

>  Not quite.  http://new.openspf.org/FAQ/Envelope_from_scope

	No, in this case Neal appears to be correct -- SPF only deals 
with the envelope sender, as used in "MAIL FROM", and the "Sender:" 
header field is not used.

	However, DKIM would be a serious problem for us.

-- 
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  Sat Apr 29 01:06:01 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:06:01 -0400
Subject: [Mailman-Developers] Problem with new bin/Makefile and Cygwin
In-Reply-To: <PC1740200604281106380218200daf20@msapiro>
References: <PC1740200604281106380218200daf20@msapiro>
Message-ID: <1146265561.10787.134.camel@resist.wooz.org>

On Fri, 2006-04-28 at 11:06 -0700, Mark Sapiro wrote:
> The recent 'mmshell' change to bin/Makefile.in causes a problem in
> Cygwin (I really have to make a 'real' test platform one of these
> days, but that's another story).

Fixed in r7881.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/e57f7713/attachment.pgp 

From barry at python.org  Sat Apr 29 01:45:46 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:45:46 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44523C83.6080509@imsa.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu>
Message-ID: <1146267946.10789.157.camel@resist.wooz.org>

Now that I have a few minutes to breath ;) I'll try to summarize my
thoughts on this, and then perhaps go back later and follow up to
specific points later in the thread.

I'm sympathetic to ripping out the Sender: field munging.  It was always
primarily a workaround for buggy MTAs.  If the majority of MTAs out
there now Do The Right Thing, then of course we want to be RFC
compliant.  Outlook's behavior has always been a wart but so far, the
benefits have outweighed the costs.  If the benefits are minimal now,
then it should go.

The question that must be answered is: if we no longer munge Sender:
header, what are the right headers to set to increase the likelihood
that bounces will go where we want them to?

I don't care about the minority of still-deployed buggy MTAs that may
send bounces to the wrong place as long as we can be reasonably assured
they won't send them to /some/ wrong places.  For example, I think it
would be bad if they started spamming list owners with bounces, very bad
if they spammed the original message authors, and worse if they spammed
the mailing list with bounces.  We have almost none of that now and if
we removed the Sender: header and saw a huge increase in this bad
behavior, then the benefits of munging the header go way up.

Of course, we might not know until we start deploying, which would be
too late.  I encourage those of you who want to get rid of Sender:
munging to modify your Mailman 2.1 code now and see what happens. :)  Of
course, you'll let us know how that goes!  My recommendation would be to
record the results in the wiki.

I agree that the RFCs are a bit murky in this area, but it's relatively
clear that the RFC 2822 'secretary' example illustrates the intent of
Sender:.  Our list owners are not the agents transmitting the messages,
so listname-owner should clearly not go in Sender:.

We really want to increase the chances that Mailman will process all
bounces.  As I mention above, we absolutely can't be a vector for
spamming people with bounces they can't do anything about.  If some
buggy MTAs throw bounces away though, tough luck for their users.  There
should be enough compliant MTAs out there that the added cost of keeping
bogus addresses on a list because we never saw their bounces should be
low.

I don't really like list or site options for this kind of thing.  For
one thing, we already have too many options and adding list options
complicates the U/I and cognitive load for list admins who usually
really don't want to be bothered with this nonsense.  We should be
reducing the options a list admin has to worry about, not increasing
them.

This is not really appropriate for a site admin either because that's
too coarse of a decision.  A Mailman site talks to a huge array of MTAs
and MUAs, so I don't think you could make a good choice.  If anything,
should we determine that Sender: munging has to stay, it should be a
user option because only the user knows whether their MUA will present
them with an ugly message display.  A user could decide to turn off
Sender: munging, but I suspect it's still more than the typical user
will want to deal with.  And of course per-user options get into all the
personalization vs. performance issues.

Is listname-bounces confusing?  Yes, and I wouldn't be opposed to
changing this, although I'm not sure what we'd use.  listname-processor?
Well, let's hope we can just get rid of Sender: munging instead.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/e0e77216/attachment.pgp 

From barry at python.org  Sat Apr 29 01:50:20 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:50:20 -0400
Subject: [Mailman-Developers] [Mailman-Users]   Sender field
In-Reply-To: <44525979.6040301@imsa.edu>
References: <C0779F04.C339%jwblist@loricamail.com> <44525979.6040301@imsa.edu>
Message-ID: <1146268220.10790.160.camel@resist.wooz.org>

On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:

> As I noted in my previous response, I believe that the correct field (if 
> Mailman were to add a "Sender:" header) to add would be "Resent-Sender". 
>   Please see RFC 2822, section 3.6.6.

Whatever else we decide, I don't agree, or at least, it won't help us.
$3.6.6 says that Resent-* headers are to be added by a user.  It also
says that these are purely informational headers, so I don't see how
adding them will instruct a receiving MTA usefully.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/fd7340a6/attachment.pgp 

From barry at python.org  Sat Apr 29 01:51:32 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:51:32 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <44525A26.6000007@nleaudio.com>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu>  <44525A26.6000007@nleaudio.com>
Message-ID: <1146268292.10793.162.camel@resist.wooz.org>

On Fri, 2006-04-28 at 14:08 -0400, Bob Puff at NLE wrote:

> ...Trouble similar to a current problem I am having with AOL: they are
> bouncing all email with the 
> FROM: address of a specific AOL user, when mailman delivers the
> messages to -any- aol or cs.com 
> address.

Have you tried turning on full personalization so that every recipient
gets their own copy?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/1c389d58/attachment-0001.pgp 

From barry at python.org  Sat Apr 29 01:54:23 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:54:23 -0400
Subject: [Mailman-Developers] Sender field
In-Reply-To: <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
	<4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
Message-ID: <1146268463.10788.165.camel@resist.wooz.org>

On Fri, 2006-04-28 at 17:32 -0400, James Ralston wrote:

> I would argue that the best course of action is to excise Sender
> header rewriting entirely and provide no option to turn it on.
> (Mailman has way too many options already.)

I agree that this is what we should hope for.  Our data supporting the
rewriting of Sender is many years out of date, so we need to gather more
data.  Who's brave enough to try it? :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/07b78136/attachment.pgp 

From barry at python.org  Sat Apr 29 01:57:13 2006
From: barry at python.org (Barry Warsaw)
Date: Fri, 28 Apr 2006 19:57:13 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <E1FZZLB-0001yR-US@lists.econ.utah.edu>
References: <PC1740200604281242200140d8835660@msapiro>
	<E1FZZLB-0001yR-US@lists.econ.utah.edu>
Message-ID: <1146268633.10788.169.camel@resist.wooz.org>

On Fri, 2006-04-28 at 14:13 -0600, Hans G. Ehrbar wrote:

> This brings to mind another example
> of an unfortunate choice of words: on some of my mailing
> lists people got outright paranoid because they received a
> message that their submission was not accepted because of
> "suspicious headers".  They thought they were being
> censored.  Appearances sometimes mean a lot.

I totally agree that we need to do something about the "suspicious
headers" message.  I'm always getting questions from users who see this
asking what they've done to deserve such a dire message (answer: usually
nothing
! :).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/add880a5/attachment.pgp 

From brad at stop.mail-abuse.org  Sat Apr 29 02:12:11 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 28 Apr 2006 19:12:11 -0500
Subject: [Mailman-Developers] [Mailman-Users]     Sender field
In-Reply-To: <1146268220.10790.160.camel@resist.wooz.org>
References: <C0779F04.C339%jwblist@loricamail.com> <44525979.6040301@imsa.edu>
	<1146268220.10790.160.camel@resist.wooz.org>
Message-ID: <p06200712c0785d67fc8b@[192.168.1.65]>

At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:

>  On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:
>
>>  As I noted in my previous response, I believe that the correct field (if
>>  Mailman were to add a "Sender:" header) to add would be "Resent-Sender".
>>    Please see RFC 2822, section 3.6.6.
>
>  Whatever else we decide, I don't agree, or at least, it won't help us.
>  $3.6.6 says that Resent-* headers are to be added by a user.  It also
>  says that these are purely informational headers, so I don't see how
>  adding them will instruct a receiving MTA usefully.

	Siunce the RFC doesn't specifically talk about "relay agents" as 
separate from "users", I think we could argue that Mailman would 
qualify as a "user" in this context.  Therefore, the Resent-* headers 
seem to be most appropriate.

	But you are correct that these are purely informational and will 
be completely ignored by any MTA.  If we need something that will be 
noticed by other MTAs beyond the envelope sender and the 
"Return-Path:" & "Errors-To:" headers, then we're going to have to 
carefully think about this.


	I am still opposed to blindly making this change and letting the 
community find out what happens.

	I think we need to gather a lot more information about the likely 
outcome from this change, and I think the best way to achieve this is 
through giving admins (either site admins or list admins) the ability 
to set an option and choose whether or not they want to see what 
happens.

-- 
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  Sat Apr 29 04:46:50 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 28 Apr 2006 19:46:50 -0700
Subject: [Mailman-Developers] Log messages run together
Message-ID: <PC1740200604281946500687b6e5f421@msapiro>

As of revision 7877 to Mailman/loginit.py, log file messages lack a
terminating newline. Adding one to FMT as in

FMT     = '%(asctime)s (%(process)d) %(message)s\n'

fixes the problem.

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


From bob at nleaudio.com  Sat Apr 29 08:22:30 2006
From: bob at nleaudio.com (Bob Puff)
Date: Sat, 29 Apr 2006 02:22:30 -0400
Subject: [Mailman-Developers] [Mailman-Users] Sender field
In-Reply-To: <1146268292.10793.162.camel@resist.wooz.org>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<44523C83.6080509@imsa.edu> <44525A26.6000007@nleaudio.com>
	<1146268292.10793.162.camel@resist.wooz.org>
Message-ID: <20060429062128.M63022@nleaudio.com>


Yes, and it still happens.  Apparently, AOL has some filter based on a FROM:
address matching a specific list, and bounces it with an SPF error, which it
clearly is not.

Bob

---------- Original Message -----------
From: Barry Warsaw <barry at python.org>

> 
> Have you tried turning on full personalization so that every 
> recipient gets their own copy?
> 
> -Barry
------- End of Original Message -------


From stephen at xemacs.org  Sat Apr 29 15:16:30 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 29 Apr 2006 22:16:30 +0900
Subject: [Mailman-Developers] Sender field
In-Reply-To: <1146268463.10788.165.camel@resist.wooz.org> (Barry Warsaw's
	message of "Fri, 28 Apr 2006 19:54:23 -0400")
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
	<4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
	<1146268463.10788.165.camel@resist.wooz.org>
Message-ID: <87aca4fro1.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "BAW" == Barry Warsaw <barry at python.org> writes:

    BAW> I agree that this is what we should hope for.  Our data
    BAW> supporting the rewriting of Sender is many years out of date,
    BAW> so we need to gather more data.  Who's brave enough to try
    BAW> it? :)

If this can be done by modifying the list-specific pipeline, you got a
volunteer.  I'm willing to volunteer XEmacs's lists---our users can
deal with it, and if need be I can revert without much lossage.  We
share the MM installation with others, though, so it has to be
something done by substituting a modified Handler for our lists only.

You'll also need to tell me what I should be looking for; I have had
no need to pay much attention to MM bounces for several years.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From stephen at xemacs.org  Sat Apr 29 16:15:04 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 29 Apr 2006 23:15:04 +0900
Subject: [Mailman-Developers] Sender field
In-Reply-To: <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu> (James Ralston's
	message of "Fri, 28 Apr 2006 17:32:19 -0400")
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
	<4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
Message-ID: <873bfwfoyf.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "James" == James Ralston <qralston+ml.mailman-developers at andrew.cmu.edu> writes:

    James> The Sender header should be employed by the orignator of
    James> the message, and only the originator.  Mailman is not the
    James> originator of a message sent to a list;

OK up to here.

    James> it is merely a relay agent.

That is false.  Mailman edits the messages, both adding and removing
body content, and compiles the message for digests.  It may alter or
even remove some original headers.  The semantics of "originator" in
the context of a mailing list are quite unclear to me, and there is
not yet general agreement, as is evident from the long history of
wrangling over Reply-To munging, Mail-Followups-To, and the like.

I think the "best" behavior would be to consider that if the body of
the message is included unchanged (although header or footer may be
added), the originator of the message is the author or the author's
personal agent (original Sender).  In a digest, Mailman is pretty
clearly the Sender (since there must be at most one Sender mailbox).

In cases where HTML and/or MIME bodies are stripped, it's a tossup.
Or would be, if we didn't have "Resent-*" headers.

Anybody know if Outlook groks Resent-* headers?

    James> Mailman's "processing" behavior is to treat a reply to the
    James> Sender as a bounce.  This is incorrect behavior, because
    James> many mail clients will include address of the Sender header
    James> in a "reply-to-all" function, causing Mailman to treat the
    James> reply as a bounce.

s/incorrect/impractical/.  Those clients are broken.  If Mailman sends
an RFC 1153 digest, it *must* be the Sender, and the individual
messages presumably won't have them.  Secretaries who are privy to
their bosses' mail are reading it at the bosses address; those who
aren't, should not be getting copies of replies to their boss.  Etc,
etc.  Replying to Sender is dumb.

    James> I would argue that the best course of action is to excise
    James> Sender header rewriting entirely and provide no option to
    James> turn it on.  (Mailman has way too many options already.)

Only if Mailman is taught to add a full complement of Resent-*
headers.

Note that use of Resent-* headers has the serendipitous effect of
providing an easily available UUID for naming messages when archiving
(the content of the Resent-Message-Id field).  If there were a
List-Archive-Relative-URL header it could be copied there.



-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From stephen at xemacs.org  Sat Apr 29 17:00:14 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 30 Apr 2006 00:00:14 +0900
Subject: [Mailman-Developers] [Mailman-Users]     Sender field
In-Reply-To: <p06200712c0785d67fc8b@[192.168.1.65]> (Brad Knowles's message
	of "Fri, 28 Apr 2006 19:12:11 -0500")
References: <C0779F04.C339%jwblist@loricamail.com> <44525979.6040301@imsa.edu>
	<1146268220.10790.160.camel@resist.wooz.org>
	<p06200712c0785d67fc8b@[192.168.1.65]>
Message-ID: <87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:

    >> Whatever else we decide, I don't agree, or at least, it won't
    >> help us.  $3.6.6 says that Resent-* headers are to be added by
    >> a user.  It also says that these are purely informational
    >> headers, so I don't see how adding them will instruct a
    >> receiving MTA usefully.

Sender doesn't instruct *conformant* MTAs at all, does it?  AFAIK the
only thing that a RFC 2821-conforming MTA looks at is the Return-Path
header, and it's supposed to remove that.

So this is purely a matter of pragmatic self-defense against broken
MTAs that do bounce to Sender.

    Brad> 	Siunce the RFC doesn't specifically talk about "relay
    Brad> agents" as separate from "users", I think we could argue
    Brad> that Mailman would qualify as a "user" in this context.
    Brad> Therefore, the Resent-* headers seem to be most appropriate.

Agreed.  For a number of reasons, I think this information can be
useful.  As I mentioned elsewhere, the Resent-Message-Id field can be
used to supply a UUID that we can trust (eg, for constructing
canonical archive URLs).  Unlike the Received headers, these are
readable by humans who aren't wall-eyed, helpful in tracing delays,
for example.

    Brad> If we need something that will be noticed by other MTAs
    Brad> beyond the envelope sender and the "Return-Path:" &
    Brad> "Errors-To:" headers, then we're going to have to carefully
    Brad> think about this.

What's an Errors-To header?  I can't find it in the usual suspects.

But I don't see any particular need for thought.  Conforming Internet
MTAs don't look at message headers, period.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From msapiro at value.net  Sat Apr 29 18:03:22 2006
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 29 Apr 2006 09:03:22 -0700
Subject: [Mailman-Developers] Sender field
In-Reply-To: <87aca4fro1.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <PC174020060429090322037583f7a18d@msapiro>

Stephen J. Turnbull wrote:
>
>If this can be done by modifying the list-specific pipeline, you got a
>volunteer.  I'm willing to volunteer XEmacs's lists---our users can
>deal with it, and if need be I can revert without much lossage.  We
>share the MM installation with others, though, so it has to be
>something done by substituting a modified Handler for our lists only.


This can be done by making a modified SMTPDirect.py and modifying the
pipeline for the XEmacs lists. I'm pretty sure you know how to do
this, but after I was recently reminded (by you I think - thank you)
that this is a good way to do lots of things, I wrote a FAQ on it
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.067.htp>.
The specific changes to SMTPDirect.py would be at the beginning of
bulkdeliver().


>You'll also need to tell me what I should be looking for; I have had
>no need to pay much attention to MM bounces for several years.


You would be looking for bounces being returned to inappropriate places
such as the original poster or the list itself. Thus, list members
would have to be aware of the fact that there was a change and that
they should try to observe and report any change in received bounces
or other autoresponses to their posts. It might be tricky to filter
out actual change from perceived change due to being more aware.

-- 
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  Sat Apr 29 20:01:19 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Sat, 29 Apr 2006 13:01:19 -0500
Subject: [Mailman-Developers] Sender field
In-Reply-To: <873bfwfoyf.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <4450E5D3.10304@imsa.edu> <p0620070dc0773e58b486@[192.168.1.65]>
	<74581CA516FF252A4441207B@pcmy.sei.cmu.edu>
	<4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu>
	<873bfwfoyf.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06200716c07959cb244b@[192.168.1.65]>

At 11:15 PM +0900 2006-04-29, Stephen J. Turnbull wrote:

>                                                        If Mailman sends
>  an RFC 1153 digest, it *must* be the Sender, and the individual
>  messages presumably won't have them.

	Actually, in the case of a digest, Mailman would be the 
originator of the message, and put its address in the "From:" field, 
leaving the "Sender:" field blank.  The individual messages in the 
digest would have their own "From:" and possibly "Sender:" fields, 
but those would not be promoted to the digest itself.

	There's just no way you can do digests using any other method.

	But, most of what we've been talking about so far has to do with 
regular list activity with regards to individual messages, and not 
digests.

-- 
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  Sat Apr 29 19:43:44 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Sat, 29 Apr 2006 12:43:44 -0500
Subject: [Mailman-Developers] [Mailman-Users]     Sender field
In-Reply-To: <87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <C0779F04.C339%jwblist@loricamail.com> <44525979.6040301@imsa.edu>
	<1146268220.10790.160.camel@resist.wooz.org>
	<p06200712c0785d67fc8b@[192.168.1.65]>
	<87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06200714c07955f73e94@[192.168.1.65]>

At 12:00 AM +0900 2006-04-30, Stephen J. Turnbull wrote:

>      Brad> If we need something that will be noticed by other MTAs
>      Brad> beyond the envelope sender and the "Return-Path:" &
>      Brad> "Errors-To:" headers, then we're going to have to carefully
>      Brad> think about this.
>
>  What's an Errors-To header?  I can't find it in the usual suspects.

	That's the oldest technique for handling bounces.  It has been 
deprecated for a while, but I would be inclined to continue to at 
least provide the appropriate information.

-- 
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  Sat Apr 29 21:25:45 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 29 Apr 2006 15:25:45 -0400
Subject: [Mailman-Developers] Log messages run together
In-Reply-To: <PC1740200604281946500687b6e5f421@msapiro>
References: <PC1740200604281946500687b6e5f421@msapiro>
Message-ID: <1146338745.19084.3.camel@resist.wooz.org>

On Fri, 2006-04-28 at 19:46 -0700, Mark Sapiro wrote:
> As of revision 7877 to Mailman/loginit.py, log file messages lack a
> terminating newline. Adding one to FMT as in
> 
> FMT     = '%(asctime)s (%(process)d) %(message)s\n'
> 
> fixes the problem.

Fixed (slightly differently) in r7882.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060429/5d6e153f/attachment.pgp 

From jwblist at loricamail.com  Sat Apr 29 22:30:47 2006
From: jwblist at loricamail.com (John W. Baxter)
Date: Sat, 29 Apr 2006 13:30:47 -0700
Subject: [Mailman-Developers] [Mailman-Users]     Sender field
In-Reply-To: <87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <C0791B07.C398%jwblist@loricamail.com>

On 4/29/06 8:00 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Sender doesn't instruct *conformant* MTAs at all, does it?  AFAIK the
> only thing that a RFC 2821-conforming MTA looks at is the Return-Path
> header, and it's supposed to remove that.

There is no Return-Path: header during transmission of a message. The
Return-Path header is added in the process of delivery.
There is a return path, stated in the MAIL FROM:<example at example.com> SMTP
command.  (That command *can* have more stuff related to authentication.)
The return path is what should be used as the address of a bounce if a mail
system foolishly accepts a message and then creates a bounce.

Notice that if an MTA rejects a message (or one or more of the recipients of
the message), it is not bouncing or creating a bounce.  It is issuing an
error response...the MTA (or MUA in the case of message submission) that was
trying to send creates a bounce message if appropriate (for message
submission, the MUA notifies the user--or pretends to:  Microsoft by default
hides the notification remarkably well).

While multi-line text associated with the rejection code is provided for,
MUAs are very poor about showing it if a submission is rejected--some show
only the first line; some only the last line.  Even some MTAs "improve" the
text of the rejection.

  --John



From fil at rezo.net  Sun Apr 30 00:22:13 2006
From: fil at rezo.net (Fil)
Date: Sun, 30 Apr 2006 00:22:13 +0200
Subject: [Mailman-Developers] GNU FSF Assignment
Message-ID: <20060429222213.GI6557@rezo.net>

Hello,

can someone point me to the procedure/documents needed to assign copyright
to Barry^H^H^H^H^H the FSF ?  I can't find them on Google or on the GNU
project pages (??).

-- Fil


From barry at python.org  Sun Apr 30 02:49:42 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 29 Apr 2006 20:49:42 -0400
Subject: [Mailman-Developers] GNU FSF Assignment
In-Reply-To: <20060429222213.GI6557@rezo.net>
References: <20060429222213.GI6557@rezo.net>
Message-ID: <1146358182.8250.42.camel@geddy.wooz.org>

On Sun, 2006-04-30 at 00:22 +0200, Fil wrote:

> can someone point me to the procedure/documents needed to assign copyright
> to Barry^H^H^H^H^H the FSF ?  I can't find them on Google or on the GNU
> project pages (??).

Well, if you assigning your changes to me, it would be simple ('cause I
wouldn't ask for assignment in the first place ;).  But to assign your
changes to the FSF, AFAIK, you have to email assign at fsf.org and ask for
the appropriate form.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060429/0c4e1147/attachment.pgp 

From msapiro at value.net  Sun Apr 30 02:53:32 2006
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 29 Apr 2006 17:53:32 -0700
Subject: [Mailman-Developers] New Mailman logging
Message-ID: <PC1740200604291753320015f6fd384f@msapiro>

I think I've finally gotten a grasp of the new Mailman logging scheme
and I think there's something missing.

I see how the basic logging to files works and how the propagate flag
to loginit.initialize() controls propagation to the root 'mailman'
logger which logs to the sys.stderr stream.

What I think is missing is something analogous to the old
Mailman.Logging.Utils.LogStdErr() to cause writes to sys.stderr to be
logged instead of or in addition to being sent to the stderr stream.

The end result of this is that a few messages from bin/mailmanctl and
one message from bin/qrunner will only go to the stderr stream and
will not be logged. I don't see this as serious as I think all these
messages can only occur in response to fatal conditions in direct
response to a mailmanctl command.

However, there are also sys.stderr writes in the various scripts
invoked by the mail wrapper. These used to be logged as well as
written to the stderr stream (where they presumably end up in a DSN).
The error conditions that cause these messages occur because of bad
alaises or routers in the MTA (things that invoke the wrapper without
a list name) or aliases left after a list is removed. These should
probably still be logged.

-- 
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  Sun Apr 30 03:04:36 2006
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 29 Apr 2006 18:04:36 -0700
Subject: [Mailman-Developers] New Mailman logging
In-Reply-To: <PC1740200604291753320015f6fd384f@msapiro>
Message-ID: <PC174020060429180436096818eaa98c@msapiro>

Mark Sapiro wrote:
>
>What I think is missing is something analogous to the old
>Mailman.Logging.Utils.LogStdErr() to cause writes to sys.stderr to be
>logged instead of or in addition to being sent to the stderr stream.

I don't mean to imply that such a function is necessarily required.
Most problems (except maybe for messages from the Python library) can
easily be handled by changing the sys.stderr writes to logging calls.

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


From tkikuchi at is.kochi-u.ac.jp  Sun Apr 30 09:50:00 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun, 30 Apr 2006 16:50:00 +0900
Subject: [Mailman-Developers] Problems with Vietnamese translation
In-Reply-To: <PC174020060426200731040622d8afd5@msapiro>
References: <PC174020060426200731040622d8afd5@msapiro>
Message-ID: <44546C28.7020700@is.kochi-u.ac.jp>

Hi Mark,

> 
> I tested this and it seems to work fine whether or not mailman.po has a
> space after the '#:'.
> 
> Tokio,
> 
> Do you think we should go ahead and commit this on the trunk?
> 

Thanks for this patch.  I've committed this on the trunk slightly 
differently, though.

Cheers,

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

From barry at python.org  Sun Apr 30 14:33:54 2006
From: barry at python.org (Barry Warsaw)
Date: Sun, 30 Apr 2006 08:33:54 -0400
Subject: [Mailman-Developers] New Mailman logging
In-Reply-To: <PC174020060429180436096818eaa98c@msapiro>
References: <PC174020060429180436096818eaa98c@msapiro>
Message-ID: <1146400434.2269.13.camel@resist.wooz.org>

On Sat, 2006-04-29 at 18:04 -0700, Mark Sapiro wrote:

> I don't mean to imply that such a function is necessarily required.
> Most problems (except maybe for messages from the Python library) can
> easily be handled by changing the sys.stderr writes to logging calls.

+1

I'll make these changes to the scripts files when I get to them, if
nobody beats me to it.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060430/55b1c6f7/attachment.pgp