From barry at python.org  Mon Nov  2 03:52:41 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 1 Nov 2009 21:52:41 -0500
Subject: [Mailman-Developers] GNU Mailman roadmap
Message-ID: <8817269A-60B2-4160-A235-DD4F7CAD6024@python.org>

As you know, Mailman 2.1 has long been in maintenance-only mode.   
Mailman 2.2 was where we were going to add new features and update the  
user interface, without changing the basic model.  Mailman 3 was where  
we were going to fix the model and modernize the architecture to allow  
for better embedded use.  Mark has been doing an incredible job fixing  
Mailman 2.1, and forward porting these fixes to Mailman 2.2.  I have  
been working on Mailman 3 and have released several alphas.

The current state of affairs is not ideal though.  Neither 2.2 nor 3.0  
has been released, there is confusion in the community as to which  
version to develop patches for, and frustration on our part that we  
have divided efforts and not as much community participation as we'd  
like.

Mark and I have decided therefore to combine our efforts under Mailman  
3, and we invite you to join us.  Working together, I feel confident  
that we can have a solid release of Mailman 3 very soon, hopefully by  
the end of the year.  Patrick Koetter and his group have expressed  
interest and resources in helping jump start the new Mailman user  
interface, which will be built on top of Mailman 3's REST interface.   
What do /you/ want to work on? :)

Here's the plan: Mark is going to put a 2.1.13 bug fix release out  
soon and will continue to fix only the most important bugs on the 2.1  
branch.  He'll forward port those fixes to the 2.2 branch for the few  
people who are running it from source, but there will never be a  
Mailman 2.2 release.  For all practical purposes, Mailman 2.2 is  
dead.  Mark will be joining me to focus all new development work on  
Mailman 3.0.

I hope this brings clarity to where we're going, and I hope that the  
renewed and concentrated efforts will encourage you to pull down the  
Mailman 3.0 code or alphas and begin testing and developing for it.

Enjoy,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091101/cd64f7c3/attachment.pgp>

From Brian.Mingus at Colorado.EDU  Mon Nov  2 06:59:36 2009
From: Brian.Mingus at Colorado.EDU (Brian J Mingus)
Date: Sun, 1 Nov 2009 22:59:36 -0700
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman roadmap
In-Reply-To: <8817269A-60B2-4160-A235-DD4F7CAD6024@python.org>
References: <8817269A-60B2-4160-A235-DD4F7CAD6024@python.org>
Message-ID: <9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>

On Sun, Nov 1, 2009 at 7:52 PM, Barry Warsaw <barry at python.org> wrote:

> As you know, Mailman 2.1 has long been in maintenance-only mode.  Mailman
> 2.2 was where we were going to add new features and update the user
> interface, without changing the basic model.  Mailman 3 was where we were
> going to fix the model and modernize the architecture to allow for better
> embedded use.  Mark has been doing an incredible job fixing Mailman 2.1, and
> forward porting these fixes to Mailman 2.2.  I have been working on Mailman
> 3 and have released several alphas.
>
> The current state of affairs is not ideal though.  Neither 2.2 nor 3.0 has
> been released, there is confusion in the community as to which version to
> develop patches for, and frustration on our part that we have divided
> efforts and not as much community participation as we'd like.
>
> Mark and I have decided therefore to combine our efforts under Mailman 3,
> and we invite you to join us.  Working together, I feel confident that we
> can have a solid release of Mailman 3 very soon, hopefully by the end of the
> year.  Patrick Koetter and his group have expressed interest and resources
> in helping jump start the new Mailman user interface, which will be built on
> top of Mailman 3's REST interface.  What do /you/ want to work on? :)
>
> Here's the plan: Mark is going to put a 2.1.13 bug fix release out soon and
> will continue to fix only the most important bugs on the 2.1 branch.  He'll
> forward port those fixes to the 2.2 branch for the few people who are
> running it from source, but there will never be a Mailman 2.2 release.  For
> all practical purposes, Mailman 2.2 is dead.  Mark will be joining me to
> focus all new development work on Mailman 3.0.
>
> I hope this brings clarity to where we're going, and I hope that the
> renewed and concentrated efforts will encourage you to pull down the Mailman
> 3.0 code or alphas and begin testing and developing for it.
>
> Enjoy,
> -Barry


Perhaps the failure of the mailman dev team to attract community
participation can be related not to any crazy versioning scheme but rather
to a failure to engage with the community. I have only recently subscribed
to this list and I can say that you and every other person that read my
e-mail saw fit to ignore it. Your null hypothesis, namely that people who
send questions and not patches to the list are not worth your time, costs
you dearly in the long run.

/Brian

From kaja at cs.au.dk  Mon Nov  2 10:25:15 2009
From: kaja at cs.au.dk (Kaja P. Christiansen)
Date: Mon, 02 Nov 2009 10:25:15 +0100
Subject: [Mailman-Developers] mailman/admindb: request for 'redirect' action
Message-ID: <4AEEA57B.6020902@cs.au.dk>


[This posting was originally sent on Oct 27th
but it seems it didn't make it to the list]

Hello all,

Our MTA provides strong and effective spam filtering
(MIMEdefang with Solido/greylisting/NilSimsa). Part
of the process is redirecting spam which gets through
to our spam filters.

In my role as Mailman site administrator for two busy domains
(at two continents :-) I have been greatly missing the 'Redirect'
action for mailman/admindb. Although Mailman has currently
4 actions and 4 sender filters in mailman/admindb, none of these
can be used for automated redirection of spam messages.

A field for an address for redirection of spam and a 'Redirect'
button would make a big difference for list administrators!

My apologies if this topic was already discussed -
mail archives for mailman-developers seemed down or very
busy today, so I couldn't check.

Kaja






From joost at greenskin.net  Tue Nov 10 13:52:30 2009
From: joost at greenskin.net (Joost Schuttelaar)
Date: Tue, 10 Nov 2009 13:52:30 +0100
Subject: [Mailman-Developers] FR: obscure email address in archives
Message-ID: <393279D3-2659-416D-B445-5643F08C2195@greenskin.net>

When the obscure email address feature in the admin settings is  
enabled, e-mail addresses are transformed into the format 'xxx AT xxx'  
in the archives. This may have worked 5 years ago to prevent spam  
harvesting. But it does not work anymore.

I've patched (well... butchered) my own install by modifying  
HyperArch.py to simply output 'EMAIL HIDDEN' instead of the obscured e- 
mail address, by replacing the regexes to a constant string at line 284.

I think a 'proper' feature like this would be a very welcome addition.  
Right now, it would be trivial to write a script to harvest tens of  
thousands of e-mail addresses from Mailman users...

-- 

Joost Schuttelaar
The Hague, NL


From barry at python.org  Wed Nov 11 15:36:43 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Nov 2009 08:36:43 -0600
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman roadmap
In-Reply-To: <9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>
References: <8817269A-60B2-4160-A235-DD4F7CAD6024@python.org>
	<9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>
Message-ID: <7FC13E2F-1D3B-46FF-83E0-018E1B51268B@python.org>

On Nov 1, 2009, at 11:59 PM, Brian J Mingus wrote:

> Perhaps the failure of the mailman dev team to attract community
> participation can be related not to any crazy versioning scheme but  
> rather
> to a failure to engage with the community. I have only recently  
> subscribed
> to this list and I can say that you and every other person that read  
> my
> e-mail saw fit to ignore it. Your null hypothesis, namely that  
> people who
> send questions and not patches to the list are not worth your time,  
> costs
> you dearly in the long run.

Hi Brian,

I'm sorry, but I don't remember seeing your message on the list.  For  
any misunderstandings like this, I take full blame and  
responsibility.  I can say that I value all contributions from the  
community, whether it be in the form of questions, patches,  
complaints, kudos, or stacks of dollar bills. :)

I think the mailman-developers list is fairly typical for an open  
source project.  I invite you to repost your message and this time  
I'll keep an eye out for it.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091111/fda4f406/attachment.pgp>

From barry at python.org  Wed Nov 11 15:37:56 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Nov 2009 08:37:56 -0600
Subject: [Mailman-Developers] mailman/admindb: request for 'redirect'
	action
In-Reply-To: <4AEEA57B.6020902@cs.au.dk>
References: <4AEEA57B.6020902@cs.au.dk>
Message-ID: <47D8B1E6-EDB0-4246-8C6C-1905E92E1A8D@python.org>

On Nov 2, 2009, at 3:25 AM, Kaja P. Christiansen wrote:

> A field for an address for redirection of spam and a 'Redirect'
> button would make a big difference for list administrators!

I really want imap access for admindb functionality. ;)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091111/ef5fd29b/attachment.pgp>

From barry at python.org  Wed Nov 11 15:40:47 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 11 Nov 2009 08:40:47 -0600
Subject: [Mailman-Developers] FR: obscure email address in archives
In-Reply-To: <393279D3-2659-416D-B445-5643F08C2195@greenskin.net>
References: <393279D3-2659-416D-B445-5643F08C2195@greenskin.net>
Message-ID: <2FE99400-14EB-4CA0-9E4C-41C89228859C@python.org>

On Nov 10, 2009, at 6:52 AM, Joost Schuttelaar wrote:

> When the obscure email address feature in the admin settings is  
> enabled, e-mail addresses are transformed into the format 'xxx AT  
> xxx' in the archives. This may have worked 5 years ago to prevent  
> spam harvesting. But it does not work anymore.
>
> I've patched (well... butchered) my own install by modifying  
> HyperArch.py to simply output 'EMAIL HIDDEN' instead of the obscured  
> e-mail address, by replacing the regexes to a constant string at  
> line 284.

Agreed.  I'm in the process right now of separating Pipermail (from  
the Mailman 3 branch) into its own project on Launchpad.  Hopefully  
this will enable and inspire folks to contribute changes to that  
project.

I plan to structure it as a typical distutils-style project so that  
it's very easy to integrate into Mailman, but separate enough that  
it's useful on its own.  You can follow the progress here:

https://launchpad.net/pipermail

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091111/77140aaa/attachment-0001.pgp>

From mark at msapiro.net  Wed Nov 11 15:47:15 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 11 Nov 2009 06:47:15 -0800
Subject: [Mailman-Developers] GNU Mailman roadmap
In-Reply-To: <9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>
Message-ID: <PC195200911110647150593105aea20@msapiro>

Brian J Mingus wrote:
>
>Perhaps the failure of the mailman dev team to attract community
>participation can be related not to any crazy versioning scheme but rather
>to a failure to engage with the community. I have only recently subscribed
>to this list


You are subscribed to mailman-users, not mailman-developers.


>and I can say that you and every other person that read my
>e-mail saw fit to ignore it.


Not true. There have been extreme moderation delays recently and your
post was only delivered to the mailman-users list on Sunday and it has
not been ignored.

I apologize for the moderation delay. We have added more resources to
the task which we hope will help.


>Your null hypothesis, namely that people who
>send questions and not patches to the list are not worth your time, costs
>you dearly in the long run.


If you read the archives of the mailman-users and mailman-developers
lists, I think you'll find that the above statement is unjustified.

Further, during the moderation delay, I had an irc conversation on
#mailman with someone about the subject of your original mailman-users
post. Was that you? Does that seem like I think your issue is not
worth my time?

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


From mark at msapiro.net  Wed Nov 11 15:51:52 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 11 Nov 2009 06:51:52 -0800
Subject: [Mailman-Developers] Network is unreachable
In-Reply-To: <c6144a8d0910290413r76834128h422ec99e8e5b48be@mail.gmail.com>
Message-ID: <PC195200911110651520562105aea26@msapiro>

Gerheim wrote:
>
>I've terminated to configure my server but when I create a list, the welcome
>message stops on queue.
>Analysing /var/log/mailman/smtp-failure I get:
>
>Oct 29 09:04:29 2009 (18551) delivery to test at xxx.xxx.xxx failed with code
>-1: (101, 'Network is unreachable')
>
>Could anyone help?


This is more a question for mailman-users at python.org, but ...

Mailman is unable to connect the the SMTP server defined as SMTPHOST in
Defaults.py/mm_cfg.py. This is normally 'localhost'.

Do you have an entry like

127.0.0.1  localhost

in /etc/hosts?

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


From mark at msapiro.net  Wed Nov 11 15:56:02 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 11 Nov 2009 06:56:02 -0800
Subject: [Mailman-Developers] FR: obscure email address in archives
In-Reply-To: <393279D3-2659-416D-B445-5643F08C2195@greenskin.net>
Message-ID: <PC195200911110656020515de58f3c5@msapiro>

Joost Schuttelaar wrote:

>When the obscure email address feature in the admin settings is  
>enabled, e-mail addresses are transformed into the format 'xxx AT xxx'  
>in the archives. This may have worked 5 years ago to prevent spam  
>harvesting. But it does not work anymore.


You may be interested in the thread "Proposed: remove
address-obfuscation code from Mailman 3" starting at
<http://mail.python.org/pipermail/mailman-developers/2009-August/020741.html>.

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


From adam-mailman at amyl.org.uk  Wed Nov 11 16:00:34 2009
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Wed, 11 Nov 2009 15:00:34 +0000
Subject: [Mailman-Developers] Network is unreachable
In-Reply-To: <c6144a8d0910290413r76834128h422ec99e8e5b48be@mail.gmail.com>
References: <c6144a8d0910290413r76834128h422ec99e8e5b48be@mail.gmail.com>
Message-ID: <20091111150034.GW24624@amyl.org.uk>

On Thu, Oct 29, 2009 at 09:13:32AM -0200, Gerheim wrote:
> Hi,
> 
> I've terminated to configure my server but when I create a list, the welcome
> message stops on queue.
> Analysing /var/log/mailman/smtp-failure I get:
> 
> Oct 29 09:04:29 2009 (18551) delivery to test at xxx.xxx.xxx failed with code
> -1: (101, 'Network is unreachable')

'xxx' is not (yet) a valid TLD[1]. If that's an effort to obfuscate,
it might be useful to not do so, so we can look up things like MX
records.

Is this transient, or permanent?
Does DNS resolution ordinarily work?
Is the host ping'able?
Are there routing problems/issues?

&c &c.


[1] http://iana.org/domains/root/db


-- 
``... a difficulty for every solution'' (Samuel, on the Civil Service)

From stephen at xemacs.org  Wed Nov 11 17:53:34 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 12 Nov 2009 01:53:34 +0900
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman roadmap
In-Reply-To: <9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>
References: <8817269A-60B2-4160-A235-DD4F7CAD6024@python.org>
	<9839a05c0911012159g37549f49vb21def8ff635f629@mail.gmail.com>
Message-ID: <87pr7pvw8h.fsf@uwakimon.sk.tsukuba.ac.jp>

Brian J Mingus writes:
 > I have only recently subscribed to this list and I can say that you
 > and every other person that read my e-mail saw fit to ignore
 > it.

I don't see anything in my folder or in the archives for this list
(Mailman Developers).  Perhaps you are referring to your post
"E-mail-based moderation" to Mailman Users?  If so, it would seem that
you have "seen fit to ignore" the replies you've already received:

http://mail.python.org/pipermail/mailman-users/2009-November/067633.html
http://mail.python.org/pipermail/mailman-users/2009-November/067646.html

It's quite reasonable for the developers to see replies from users
known to usually give good advice and assume the matter is settled, at
least until there's a followup.  It's not so reasonable for you to
assume that things regularly get dropped on the floor when you
discover that one similar message to a different list went unanswered
18 months ago, especially when you could just eyeball a few months'
worth of "thread view" in the archives and see it's simply not true.

 > Your null hypothesis, namely that people who send questions and not
 > patches to the list are not worth your time, costs you dearly in
 > the long run.

In fact the developers are quite good about replying on this list, and
some of the developers are usually available on the Mailman Users
list[1], as well as between 5 and 20 experienced users who are able to
answer most questions posed there.  It's true that the OPs don't
always consider the replies to be responsive to their needs, but then
I gather the developers' and FAQ meisters' salaries are several
million dollars in arrears....

While it's the obvious/traditional thing to do, making a request for
enhancement on a mailing list is no longer the most effective way to
get action.  Better would be to submit a "wishlist" bug at

https://bugs.launchpad.net/mailman/

because that won't get lost, or accidentally flushed from an INBOX if
overlooked for 48 hours.[2]  Wishlist bugs probably don't do as well as
average, but the details page (append "+bugs" to the above URL) shows
643 open bugs out of 1820, so about 2/3 of the reported bugs have been
addressed.  Many of the bugs labelled "new" have comments from
developers, and some are waiting on further input (sometimes for years
:-) from the reporter.


Footnotes: 
[1]  I personally wish Mark would cut his FAQ-answering time by about
80%; there are plenty of experienced users who can do the job well enough.

[2]  I think you have to go through a mildly annoying registration
process to submit a bug or feature request, but you only have to do it
once.



From mark at msapiro.net  Thu Nov 12 08:45:24 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 11 Nov 2009 23:45:24 -0800
Subject: [Mailman-Developers] [Mailman-Users] GNU Mailman roadmap
In-Reply-To: <87pr7pvw8h.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <PC195200911112345240765f2fe08d5@msapiro>

Stephen J. Turnbull wrote:

>[1]  I personally wish Mark would cut his FAQ-answering time by about
>80%; there are plenty of experienced users who can do the job well enough.


Of course you are right, but there is a reason my nickname on the
acknowledgements page is "Mailman's compulsive responder". I also have
a motto (not completely joking) "OCD is a terrible thing to waste".

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


From peibel at hotmail.com  Thu Nov 19 11:58:32 2009
From: peibel at hotmail.com (peibel80)
Date: Thu, 19 Nov 2009 02:58:32 -0800 (PST)
Subject: [Mailman-Developers] Mail of subscribe to mailing list with
 multiple users
Message-ID: <26421277.post@talk.nabble.com>



Hi, 

I?m new with Maiman.

I need make mail of subscription with multiple users,

Is possible make a mail with name-request at sudominio.com with several lines
of subscribe [contrase?a] [digest|nodigest] [address=]  command 

if is yes, I need a example,

if is not possible, as can be done?

thanks,

Sorry for my inglish
-- 
View this message in context: http://old.nabble.com/Mail-of-subscribe-to-mailing-list-with-multiple-users-tp26421277p26421277.html
Sent from the Mailman - Dev mailing list archive at Nabble.com.


From mark at msapiro.net  Thu Nov 19 17:33:37 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 19 Nov 2009 08:33:37 -0800
Subject: [Mailman-Developers] Mail of subscribe to mailing list
	withmultiple users
In-Reply-To: <26421277.post@talk.nabble.com>
Message-ID: <PC1952009111908333701717ef8cf10@msapiro>

peibel80 wrote:
>
>I need make mail of subscription with multiple users,
>
>Is possible make a mail with name-request at sudominio.com with several lines
>of subscribe [contrase?a] [digest|nodigest] [address=]  command 
>
>if is yes, I need a example,


This question is more appropriate for mailman-users at python.org
<http://mail.python.org/mailman/listinfo/mailman-users>, but...

The email subscribe interface is designed for users to request their
own subscription, but it does allow alternate address specification,
so it will accommodate what you want.

You could send an email to name-request at sudominio.com with multiple
subscribe commands such as the following. You can put the first
subscribe caoomand in the Subject: and the rest in the body, or you
can put them all in the body with no Subject: or an innocuous subject
that doesn't say "subscribe"

example commands:

subscribe xyz01qwe digest address=user1 at example.com
subscribe address=user2 at example.com
subscribe nodigest

The first requests subscription for user1 at example.com in digest mode
with list password xyz01qwe

The second requests subscription for user2 at example.com with mode
determined by the list's digest_is_default setting and a randomly
generated list password

The third requests subscription for the sender of the email in
non-digest mode with a randomly generated list password

There are other possibilities. Note that the only way to specify a
'real name' is to not specify the address= option which will then take
the name and address from the From: header of the request.

Also, note that these are not 'administrative' subscribes; they are
user requests and as such are subject to confirmation/approval as
determined by the list's subscribe_policy.

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


From barry at python.org  Sat Nov 28 23:53:00 2009
From: barry at python.org (Barry Warsaw)
Date: Sat, 28 Nov 2009 17:53:00 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
Message-ID: <20091128175300.2b188a55@limelight.wooz.org>

Hi everybody,

I'm getting very near ready to release another alpha of Mailman 3, and on the
prompting of a private message from Robert Niederreiter I took some time to
fire up a VM and actually try Postfix+LMTP delivery in an experimental
production system.  I'd like to get some feedback from the Postfix experts in
the crowd so that we can update the wiki page here:

    http://wiki.list.org/display/DEV/LMTP+process

FTR: the VM is running Ubuntu Karmic Koala 9.10 server with Postfix 2.6.5 and
Mailman 3.0 from the lp:mailman bzr trunk.

To start with, I mostly followed the instructions in the wiki.  I tried using
the standard lmtp transport in master.cf, creating /etc/postfix/mailman_lists
as described in the wiki (not the dedicated list server example, but the
earlier one on the page).  I actually used:

# Key                   # Value
test at xxx.example.com    lmtp:xxx.example.com

where 'xxx.example.com' is replaced by my VM's host name.

The first gotcha is that unless you start Mailman as root, you can't bind its
LMTP server to port 24, which is Postfix's default.  By default Mailman's LMTP
server listens on localhost:8024, so you either need to append ':8024' on the
Value above, or set

    lmtp_tcp_port = 8024

in Postfix's main.cf.  I ended up doing the latter, but both work.

I set up transport_maps and local_recipient_maps just as outlined in the wiki
page, fired everything up, and then sent a message to the VM's Postfix while
tailing the logs.  I kept seeing "Connection refused" messages from Postfix
and it never hit Mailman's LMTP server.

This was highly confusing because I could see in the Postfix logs that it was
finding the right IP address for its own hostname and it was trying the right
port number.  Mailman's lmtp.log file claimed it was listening on the right IP
and port, and I could even telnet to it just fine.  So what was Postfix doing?

It seems that Karmic is playing tricks with /etc/hosts.  I've got DNS set up
to correctly resolve the VM's hostname, but there was actually an entry in
/etc/hosts that set xxx.example.com to 127.0.1.1.  I'm not entirely sure which
process looks at what, when, but clearly this inconsistency was a key part of
the problem.  The other thing that surprised me was that Postfix was also
consulting /var/spool/postfix/etc/hosts, and I had to change both /etc/hosts
and that file as well, so that the IP addresses jived with DNS.  This is
unsatisfactory, but it seemed critical to getting things working.

The last piece of the puzzle was to not use Postfix's standard lmtp server in
master.cf, but to define a new one like so:

mailman3 unix - - - - - lmtp -o disable_dns_lookups=yes

and then change the mailman_lists transport map to

# Key                   # Value
test at xxx.example.com    mailman3:xxx.example.com

After a restart, everything suddenly worked exactly as expected.

Robert was having a different problem, but hopefully he will follow up here
with his experience and let us know if any of the above helps.  If any Postfix
experts have words of wisdom to make this better, please let me know.

I probably need to work on better dropping of privileges for qrunners so that
you can 'bin/mailman start' as root, and once the LMTP runner binds to port
24, it can drop privs to 'mailman'.  I'll put that on the list for something
to do after the next alpha.

I'd also like to try to resurrect William Mead's LMTP branch.  Sadly, it won't
merge cleanly into trunk any more (not the least of which because it's in the
wrong bzr format).  If anybody would like to contribute that before I get to
it, I'd be grateful.

The good news is that I think Mailman 3 is getting more real every day.  My
plan over the next few weeks is:

* release alpha 4
* get i18n translations working
* complete the split of the pipermail project
* hopefully get Patrick and friends going on the web u/i
* announce something <wink>
* create a live test list that anybody can subscribe to

If you've been waiting to play with Mailman 3, wait no longer!

-Barry

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

From p at state-of-mind.de  Sun Nov 29 09:22:25 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 09:22:25 +0100
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <20091128175300.2b188a55@limelight.wooz.org>
References: <20091128175300.2b188a55@limelight.wooz.org>
Message-ID: <20091129082221.GB3902@state-of-mind.de>

Hi!

* Barry Warsaw <barry at python.org>:
> I'm getting very near ready to release another alpha of Mailman 3, and on the
> prompting of a private message from Robert Niederreiter I took some time to
> fire up a VM and actually try Postfix+LMTP delivery in an experimental
> production system.  I'd like to get some feedback from the Postfix experts in
> the crowd so that we can update the wiki page here:
> 
>     http://wiki.list.org/display/DEV/LMTP+process
> 
> FTR: the VM is running Ubuntu Karmic Koala 9.10 server with Postfix 2.6.5 and
> Mailman 3.0 from the lp:mailman bzr trunk.
> 
> To start with, I mostly followed the instructions in the wiki.  I tried using
> the standard lmtp transport in master.cf, creating /etc/postfix/mailman_lists
> as described in the wiki (not the dedicated list server example, but the
> earlier one on the page).  I actually used:
> 
> # Key                   # Value
> test at xxx.example.com    lmtp:xxx.example.com
> 
> where 'xxx.example.com' is replaced by my VM's host name.

Additionally you probably want to add square brackets around the hostname.

Quoting "man 5 transport":

  ...the [] suppress MX lookups.  This prevents mail routing loops when your
  machine is primary MX host for example.com.

> The first gotcha is that unless you start Mailman as root, you can't bind its
> LMTP server to port 24, which is Postfix's default.  By default Mailman's LMTP
> server listens on localhost:8024, so you either need to append ':8024' on the
> Value above, or set
> 
>     lmtp_tcp_port = 8024
> 
> in Postfix's main.cf.  I ended up doing the latter, but both work.

I think an option in MM3 should make this configurable.


> I set up transport_maps and local_recipient_maps just as outlined in the wiki
> page, fired everything up, and then sent a message to the VM's Postfix while
> tailing the logs.  I kept seeing "Connection refused" messages from Postfix
> and it never hit Mailman's LMTP server.
> 
> This was highly confusing because I could see in the Postfix logs that it was
> finding the right IP address for its own hostname and it was trying the right
> port number.  Mailman's lmtp.log file claimed it was listening on the right IP
> and port, and I could even telnet to it just fine.  So what was Postfix doing?
> 
> It seems that Karmic is playing tricks with /etc/hosts.  I've got DNS set up
> to correctly resolve the VM's hostname, but there was actually an entry in
> /etc/hosts that set xxx.example.com to 127.0.1.1.  I'm not entirely sure which
> process looks at what, when, but clearly this inconsistency was a key part of
> the problem.  The other thing that surprised me was that Postfix was also

On a sidenote: It also confuses a dhcpd server running on a machine that
promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket for that
two Ubuntu releases ago, but it seems they only keep carrying it further from
release to release instead of addressing it. At least that's the impression I
get without knowing the real cause.


> consulting /var/spool/postfix/etc/hosts, and I had to change both /etc/hosts

That's because LaMont Jones delivers the Debian/Ubuntu Postfix package
chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/hosts
instead of /etc/hosts.

> and that file as well, so that the IP addresses jived with DNS.  This is
> unsatisfactory, but it seemed critical to getting things working.
> 
> The last piece of the puzzle was to not use Postfix's standard lmtp server in

lmtp client... SCNR

> master.cf, but to define a new one like so:
> 
> mailman3 unix - - - - - lmtp -o disable_dns_lookups=yes
> 
> and then change the mailman_lists transport map to
> 
> # Key                   # Value
> test at xxx.example.com    mailman3:xxx.example.com
> 
> After a restart, everything suddenly worked exactly as expected.

suddenly... :)


> Robert was having a different problem, but hopefully he will follow up here
> with his experience and let us know if any of the above helps.  If any Postfix
> experts have words of wisdom to make this better, please let me know.

If MM relies on Postfix defaults and the postmaster changes them in Postfix
the MM part might end up being unusable. 

I recommend to take full control of the settings in the Postfix transport map.
Let MM create its own Postfix style transport map. Set the "Postfix service
name" (in your example its mailman3), put the hostname in square brackets and
set the port.

> I probably need to work on better dropping of privileges for qrunners so that
> you can 'bin/mailman start' as root, and once the LMTP runner binds to port
> 24, it can drop privs to 'mailman'.  I'll put that on the list for something
> to do after the next alpha.

I like that idea.


> I'd also like to try to resurrect William Mead's LMTP branch.  Sadly, it won't
> merge cleanly into trunk any more (not the least of which because it's in the
> wrong bzr format).  If anybody would like to contribute that before I get to
> it, I'd be grateful.
> 
> The good news is that I think Mailman 3 is getting more real every day.  My
> plan over the next few weeks is:
> 
> * release alpha 4
> * get i18n translations working
> * complete the split of the pipermail project
> * hopefully get Patrick and friends going on the web u/i

I will update to the latest branch that should fix the language file problem
we had discovered and then we will work on the REST client/server.

p at rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

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

From p at state-of-mind.de  Sun Nov 29 10:30:15 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 10:30:15 +0100
Subject: [Mailman-Developers] Mailman and Submission port
Message-ID: <20091129093013.GC3902@state-of-mind.de>

MM developers,

I'd like to propose a change in MM3s default SMTP client port from port 25
(transport) to port 587 (submission).

Why? From my point of view mailman rather is a mail component that introduces
messages into a mail system than one that sits between MTAs and assists in
transporting messages that pass by.

RFC 4409 <http://www.rfc-editor.org/rfc/rfc4409.txt> explicitly defines a
submission port (587) for mail systems whose purpose is to accept message from
MUAs:

   However, SMTP is now also widely used as a message *submission*
   protocol, that is, a means for Message User Agents (MUAs) to
   introduce new messages into the MTA routing network.  The process
   that accepts message submissions from MUAs is termed a Message
   Submission Agent (MSA).


Apart from doing 'the right thing' what would be the benefit?

The RFC gives some ideas in a later section:

   (...) Even when submitted messages are complete, local site policy may
   dictate that the message text be examined or modified in some way, e.g., to
   conceal local name or address spaces.  Such completions or modifications
   have been shown to cause harm when performed by downstream MTAs -- that is,
   MTAs after the first-hop submission MTA -- and are in general considered to
   be outside the province of standardized MTA functionality.

>From my daily work with mailman the following "modified in some way"-tasks
come to my mind immediately:

- apply client and content policy that differs from the port 25 anti-spam
  policy
- add DKIM signatures because it is clear mailman messages are ORIGINATING
  from our network


What would we have to do, to make port 587 the default port? In section 4 the
RFC says, a MSA MUST do all of the following:

1. General Submission Rejection Code
2. Ensure All Domains Are Fully-Qualified
3. Require Authentication

To cut it short: 1. and 2. are trivial (at least in Postfix and I don't know
the others MTAs well enough to tell for them too). 3. requires to add SMTP AUTH
functionality to Mailman's SMTP client.


How should we implement SMTP AUTH in the MM SMTP client?

I propose for a start plaintext (PLAIN, LOGIN) and shared-secret mechanisms
(CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are the ones
used most widely in every day SMTP AUTH.

Later implementations could add GSSAPI and EXTERNAL. If plaintext mechanisms
are added we should also consider to add STARTTLS functionality to MM's SMTP
client to shield credentials while they are sent in a plaintext authentication
session.


p at rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563


From stephen at xemacs.org  Sun Nov 29 13:40:41 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 29 Nov 2009 21:40:41 +0900
Subject: [Mailman-Developers]  Mailman and Submission port
In-Reply-To: <20091129093013.GC3902@state-of-mind.de>
References: <20091129093013.GC3902@state-of-mind.de>
Message-ID: <87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>

Patrick Ben Koetter writes:

 > I'd like to propose a change in MM3s default SMTP client port from port 25
 > (transport) to port 587 (submission).

I don't see a real justification for such a change, given the
authentication requirement.  While Mailman can be used in relatively
closed setups, its central mission remains the more-or-less open
discussion list as far as I can see.  Closed lists, announcement
lists, and the like are very common, but I don't think they are the
overwhelming majority of uses yet.  Until they are, changing the
default is an annoyance to many.

It might be interesting to have both ports open by default, allowing a
different policy to be applied to each one.


From p at state-of-mind.de  Sun Nov 29 16:55:01 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 16:55:01 +0100
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20091129093013.GC3902@state-of-mind.de>
	<87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20091129155457.GA3831@state-of-mind.de>

* Stephen J. Turnbull <stephen at xemacs.org>:
> Patrick Ben Koetter writes:
> 
>  > I'd like to propose a change in MM3s default SMTP client port from port 25
>  > (transport) to port 587 (submission).
> 
> I don't see a real justification for such a change, given the
> authentication requirement.  While Mailman can be used in relatively
> closed setups, its central mission remains the more-or-less open
> discussion list as far as I can see.  Closed lists, announcement
> lists, and the like are very common, but I don't think they are the
> overwhelming majority of uses yet.  Until they are, changing the
> default is an annoyance to many.

The change I propose is not driven by considerations concerning pro or con
open/closed setups. Maybe you misunderstood me or I am misunderstanding your
reply.

To clarify: I don't want to require users to authenticate in order to allow
them to send. I want mailman to use a stanardized port for message submission
(and that brings in the authentication requirement).

Everybody seems to use a dedicated port to inject messages coming from
mailman. People do that either to completely avoid applying expensive content
filter rules to all messages coming from mailman or they do it to only run a
minimal subset of content filter rules.

I want to standardize that dedicated port and I propose to use the submission
port as recommended by RFC for scenarios like that. The authentication
requirement applies to the mailman server (read: SMTP client) only. It can be
set once in the global mailman configuration file. Users don't need to do
anything. It's completely transparent to them.

p at rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563


From barry at python.org  Sun Nov 29 19:09:15 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 13:09:15 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <20091129082221.GB3902@state-of-mind.de>
References: <20091128175300.2b188a55@limelight.wooz.org>
	<20091129082221.GB3902@state-of-mind.de>
Message-ID: <D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>

On Nov 29, 2009, at 3:22 AM, Patrick Ben Koetter wrote:

> Hi!
>
> * Barry Warsaw <barry at python.org>:
>> I'm getting very near ready to release another alpha of Mailman 3,  
>> and on the
>> prompting of a private message from Robert Niederreiter I took some  
>> time to
>> fire up a VM and actually try Postfix+LMTP delivery in an  
>> experimental
>> production system.  I'd like to get some feedback from the Postfix  
>> experts in
>> the crowd so that we can update the wiki page here:
>>
>>    http://wiki.list.org/display/DEV/LMTP+process
>>
>> FTR: the VM is running Ubuntu Karmic Koala 9.10 server with Postfix  
>> 2.6.5 and
>> Mailman 3.0 from the lp:mailman bzr trunk.
>>
>> To start with, I mostly followed the instructions in the wiki.  I  
>> tried using
>> the standard lmtp transport in master.cf, creating /etc/postfix/ 
>> mailman_lists
>> as described in the wiki (not the dedicated list server example,  
>> but the
>> earlier one on the page).  I actually used:
>>
>> # Key                   # Value
>> test at xxx.example.com    lmtp:xxx.example.com
>>
>> where 'xxx.example.com' is replaced by my VM's host name.
>
> Additionally you probably want to add square brackets around the  
> hostname.
>
> Quoting "man 5 transport":
>
>  ...the [] suppress MX lookups.  This prevents mail routing loops  
> when your
>  machine is primary MX host for example.com.

This could have been Robert's problem.  I'd forgotten that we actually  
do create the transport map automatically, if you set the  
configuration to use Postfix's LMTP delivery (this is the default).   
In that case, we generate a file called data/postfix_lmtp (and use  
postmap to create the .db file) which should be usable directly as the  
transport_map.  I've changed it to include the brackets around the  
host name.

This actually greatly simplifies things, since all you need to do is  
set transport_maps and local_recipients and you're done.

>> The first gotcha is that unless you start Mailman as root, you  
>> can't bind its
>> LMTP server to port 24, which is Postfix's default.  By default  
>> Mailman's LMTP
>> server listens on localhost:8024, so you either need to append ': 
>> 8024' on the
>> Value above, or set
>>
>>    lmtp_tcp_port = 8024
>>
>> in Postfix's main.cf.  I ended up doing the latter, but both work.
>
> I think an option in MM3 should make this configurable.

It does.  Also putting the port in the Mailman generated transport_map  
means the right thing will always happen (modulo the permission  
dropping part which won't make it into 3.0a4).

>> I set up transport_maps and local_recipient_maps just as outlined  
>> in the wiki
>> page, fired everything up, and then sent a message to the VM's  
>> Postfix while
>> tailing the logs.  I kept seeing "Connection refused" messages from  
>> Postfix
>> and it never hit Mailman's LMTP server.
>>
>> This was highly confusing because I could see in the Postfix logs  
>> that it was
>> finding the right IP address for its own hostname and it was trying  
>> the right
>> port number.  Mailman's lmtp.log file claimed it was listening on  
>> the right IP
>> and port, and I could even telnet to it just fine.  So what was  
>> Postfix doing?
>>
>> It seems that Karmic is playing tricks with /etc/hosts.  I've got  
>> DNS set up
>> to correctly resolve the VM's hostname, but there was actually an  
>> entry in
>> /etc/hosts that set xxx.example.com to 127.0.1.1.  I'm not entirely  
>> sure which
>> process looks at what, when, but clearly this inconsistency was a  
>> key part of
>> the problem.  The other thing that surprised me was that Postfix  
>> was also
>
> On a sidenote: It also confuses a dhcpd server running on a machine  
> that
> promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket  
> for that
> two Ubuntu releases ago, but it seems they only keep carrying it  
> further from
> release to release instead of addressing it. At least that's the  
> impression I
> get without knowing the real cause.

What's the bug number?

>> consulting /var/spool/postfix/etc/hosts, and I had to change both / 
>> etc/hosts
>
> That's because LaMont Jones delivers the Debian/Ubuntu Postfix package
> chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/ 
> hosts
> instead of /etc/hosts.

Ah, the pieces click together.  Thanks!

>> and that file as well, so that the IP addresses jived with DNS.   
>> This is
>> unsatisfactory, but it seemed critical to getting things working.
>>
>> The last piece of the puzzle was to not use Postfix's standard lmtp  
>> server in
>
> lmtp client... SCNR

Erp. ;)

>> master.cf, but to define a new one like so:
>>
>> mailman3 unix - - - - - lmtp -o disable_dns_lookups=yes
>>
>> and then change the mailman_lists transport map to
>>
>> # Key                   # Value
>> test at xxx.example.com    mailman3:xxx.example.com
>>
>> After a restart, everything suddenly worked exactly as expected.
>
> suddenly... :)

Yeah.  Doesn't everybody call 6 hours on a Saturday "suddenly"? :)

>> Robert was having a different problem, but hopefully he will follow  
>> up here
>> with his experience and let us know if any of the above helps.  If  
>> any Postfix
>> experts have words of wisdom to make this better, please let me know.
>
> If MM relies on Postfix defaults and the postmaster changes them in  
> Postfix
> the MM part might end up being unusable.
>
> I recommend to take full control of the settings in the Postfix  
> transport map.
> Let MM create its own Postfix style transport map. Set the "Postfix  
> service
> name" (in your example its mailman3), put the hostname in square  
> brackets and
> set the port.

Yep, I like setting the service name to mailman3.  I'll note that  
Ubuntu's Postfix-Dovecot package already has a service for mailman  
(i.e. 2.x) which uses postfix-to-mailman.py.

>> I probably need to work on better dropping of privileges for  
>> qrunners so that
>> you can 'bin/mailman start' as root, and once the LMTP runner binds  
>> to port
>> 24, it can drop privs to 'mailman'.  I'll put that on the list for  
>> something
>> to do after the next alpha.
>
> I like that idea.
>
>
>> I'd also like to try to resurrect William Mead's LMTP branch.   
>> Sadly, it won't
>> merge cleanly into trunk any more (not the least of which because  
>> it's in the
>> wrong bzr format).  If anybody would like to contribute that before  
>> I get to
>> it, I'd be grateful.
>>
>> The good news is that I think Mailman 3 is getting more real every  
>> day.  My
>> plan over the next few weeks is:
>>
>> * release alpha 4
>> * get i18n translations working
>> * complete the split of the pipermail project
>> * hopefully get Patrick and friends going on the web u/i
>
> I will update to the latest branch that should fix the language file  
> problem
> we had discovered and then we will work on the REST client/server.

Excellent!  I forgot that one other thing must happen before 3.0 can  
be released; we need a migration script from 2.1.x to 3.0.

I'll update the wiki page and release 3.0a4 a little later today.   
Then perhaps other folks can try the LMTP connection on other *nix  
distributions.

Thanks Patrick,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/438fddee/attachment.pgp>

From p at state-of-mind.de  Sun Nov 29 19:39:47 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 19:39:47 +0100
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>
References: <20091128175300.2b188a55@limelight.wooz.org>
	<20091129082221.GB3902@state-of-mind.de>
	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>
Message-ID: <20091129183947.GA21882@state-of-mind.de>

* Barry Warsaw <barry at python.org>:
> >>It seems that Karmic is playing tricks with /etc/hosts.  I've got DNS set
> >>up to correctly resolve the VM's hostname, but there was actually an entry
> >>in /etc/hosts that set xxx.example.com to 127.0.1.1.  I'm not entirely
> >>sure which process looks at what, when, but clearly this inconsistency was
> >>a key part of the problem.  The other thing that surprised me was that
> >>Postfix was also
> >
> >On a sidenote: It also confuses a dhcpd server running on a machine that
> >promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket for that
> >two Ubuntu releases ago, but it seems they only keep carrying it further
> >from release to release instead of addressing it. At least that's the
> >impression I get without knowing the real cause.
> 
> What's the bug number?

<https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/340383>


> >>consulting /var/spool/postfix/etc/hosts, and I had to change
> >>both /etc/hosts
> >
> >That's because LaMont Jones delivers the Debian/Ubuntu Postfix package
> >chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/ hosts
> >instead of /etc/hosts.
> 
> Ah, the pieces click together.  Thanks!

BTW: Postfix notes that /etc/hosts and /var/spool/postfix/etc/hosts differ on
reload (at least on Debian/Ubuntu) and it sends a simliar note to syslog.

I know experience tells us not to look at logs because logging and writing
documentation is something you only get when you pay for it... ;) However with
Postfix it pays to read the log. Wietse did a good job on this.


> >>After a restart, everything suddenly worked exactly as expected.
> >
> >suddenly... :)
> 
> Yeah.  Doesn't everybody call 6 hours on a Saturday "suddenly"? :)

:)

> >>Robert was having a different problem, but hopefully he will follow up
> >>here with his experience and let us know if any of the above helps.  If
> >>any Postfix experts have words of wisdom to make this better, please let
> >>me know.
> >
> >If MM relies on Postfix defaults and the postmaster changes them in Postfix
> >the MM part might end up being unusable.
> >
> >I recommend to take full control of the settings in the Postfix transport
> >map.  Let MM create its own Postfix style transport map. Set the "Postfix
> >service name" (in your example its mailman3), put the hostname in square
> >brackets and set the port.
> 
> Yep, I like setting the service name to mailman3.  I'll note that
> Ubuntu's Postfix-Dovecot package already has a service for mailman
> (i.e. 2.x) which uses postfix-to-mailman.py.

If we came up with a reasonable set of default settings for the mailman3
service I take these to the Postfix developer list and try to have them added
to the Postfix default master.cf file.


> >>I probably need to work on better dropping of privileges for qrunners so
> >>that you can 'bin/mailman start' as root, and once the LMTP runner binds
> >>to port 24, it can drop privs to 'mailman'.  I'll put that on the list for
> >>something to do after the next alpha.
> >
> >I like that idea.
> >
> >
> >>I'd also like to try to resurrect William Mead's LMTP branch.  Sadly, it
> >>won't merge cleanly into trunk any more (not the least of which because
> >>it's in the wrong bzr format).  If anybody would like to contribute that
> >>before I get to it, I'd be grateful.
> >>
> >>The good news is that I think Mailman 3 is getting more real every day.
> >>My plan over the next few weeks is:
> >>
> >>* release alpha 4
> >>* get i18n translations working
> >>* complete the split of the pipermail project
> >>* hopefully get Patrick and friends going on the web u/i
> >
> >I will update to the latest branch that should fix the language file
> >problem we had discovered and then we will work on the REST client/server.
> 
> Excellent!  I forgot that one other thing must happen before 3.0 can
> be released; we need a migration script from 2.1.x to 3.0.

May I complement the list?

- logo contest 
- send the web interface off to a usability lab


p at rick


-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

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

From barry at python.org  Sun Nov 29 19:44:54 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 13:44:54 -0500
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <20091129093013.GC3902@state-of-mind.de>
References: <20091129093013.GC3902@state-of-mind.de>
Message-ID: <26B30CDF-D435-45FF-BAFF-810810354C5C@python.org>

On Nov 29, 2009, at 4:30 AM, Patrick Ben Koetter wrote:

> What would we have to do, to make port 587 the default port? In  
> section 4 the
> RFC says, a MSA MUST do all of the following:
>
> 1. General Submission Rejection Code
> 2. Ensure All Domains Are Fully-Qualified
> 3. Require Authentication
>
> To cut it short: 1. and 2. are trivial (at least in Postfix and I  
> don't know
> the others MTAs well enough to tell for them too). 3. requires to  
> add SMTP AUTH
> functionality to Mailman's SMTP client.
>
>
> How should we implement SMTP AUTH in the MM SMTP client?
>
> I propose for a start plaintext (PLAIN, LOGIN) and shared-secret  
> mechanisms
> (CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are  
> the ones
> used most widely in every day SMTP AUTH.
>
> Later implementations could add GSSAPI and EXTERNAL. If plaintext  
> mechanisms
> are added we should also consider to add STARTTLS functionality to  
> MM's SMTP
> client to shield credentials while they are sent in a plaintext  
> authentication
> session.

Should we decide to do this, changing the port number is easy.   
There's already a configuration variable for this (currently set of  
course to 25).

As for implementing SMTP AUTH, we are limited by what Python's smtplib  
supports.  From a cursory inspection of the module in Python 2.6, it  
looks like it supports PLAIN, LOGIN, and CRAM-MD5.  That may mean that  
the only thing we need to add to Mailman is plumbing for setting the  
user name and password in the config file.

Please open a bug on the Mailman project in Launchpad for this.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/0e8fb4a8/attachment.pgp>

From barry at python.org  Sun Nov 29 19:55:08 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 13:55:08 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <20091129183947.GA21882@state-of-mind.de>
References: <20091128175300.2b188a55@limelight.wooz.org>
	<20091129082221.GB3902@state-of-mind.de>
	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>
	<20091129183947.GA21882@state-of-mind.de>
Message-ID: <E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>

On Nov 29, 2009, at 1:39 PM, Patrick Ben Koetter wrote:

> <https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/340383>

Thanks, I've added this to the wiki page.

>>>> consulting /var/spool/postfix/etc/hosts, and I had to change
>>>> both /etc/hosts
>>>
>>> That's because LaMont Jones delivers the Debian/Ubuntu Postfix  
>>> package
>>> chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/  
>>> hosts
>>> instead of /etc/hosts.
>>
>> Ah, the pieces click together.  Thanks!
>
> BTW: Postfix notes that /etc/hosts and /var/spool/postfix/etc/hosts  
> differ on
> reload (at least on Debian/Ubuntu) and it sends a simliar note to  
> syslog.

Yeah, that's how I found out about it in the first place. ;)

> I know experience tells us not to look at logs because logging and  
> writing
> documentation is something you only get when you pay for it... ;)  
> However with
> Postfix it pays to read the log. Wietse did a good job on this.

Indeed!

>> Yep, I like setting the service name to mailman3.  I'll note that
>> Ubuntu's Postfix-Dovecot package already has a service for mailman
>> (i.e. 2.x) which uses postfix-to-mailman.py.
>
> If we came up with a reasonable set of default settings for the  
> mailman3
> service I take these to the Postfix developer list and try to have  
> them added
> to the Postfix default master.cf file.

+1.  I've opened LP bug 490030 to track the changes needed in Mailman.

https://bugs.launchpad.net/mailman/+bug/490030

>> Excellent!  I forgot that one other thing must happen before 3.0 can
>> be released; we need a migration script from 2.1.x to 3.0.
>
> May I complement the list?
>
> - logo contest

Yep, it's actually on my TODO list after I get 3.0a4 out.  I also need  
to finish setting up i18n.

> - send the web interface off to a usability lab

+1.  IIRC, Terri was going to look into this, but I'm not sure what's  
happened with that.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/ec47f846/attachment.pgp>

From p at state-of-mind.de  Sun Nov 29 20:02:33 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 20:02:33 +0100
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <26B30CDF-D435-45FF-BAFF-810810354C5C@python.org>
References: <20091129093013.GC3902@state-of-mind.de>
	<26B30CDF-D435-45FF-BAFF-810810354C5C@python.org>
Message-ID: <20091129190233.GB21882@state-of-mind.de>

* Barry Warsaw <barry at python.org>:
> On Nov 29, 2009, at 4:30 AM, Patrick Ben Koetter wrote:
> 
> >What would we have to do, to make port 587 the default port? In
> >section 4 the
> >RFC says, a MSA MUST do all of the following:
> >
> >1. General Submission Rejection Code
> >2. Ensure All Domains Are Fully-Qualified
> >3. Require Authentication
> >
> >To cut it short: 1. and 2. are trivial (at least in Postfix and I don't
> >know the others MTAs well enough to tell for them too). 3. requires to add
> >SMTP AUTH functionality to Mailman's SMTP client.
> >
> >How should we implement SMTP AUTH in the MM SMTP client?
> >
> >I propose for a start plaintext (PLAIN, LOGIN) and shared-secret mechanisms
> >(CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are the
> >ones used most widely in every day SMTP AUTH.
> >
> >Later implementations could add GSSAPI and EXTERNAL. If plaintext
> >mechanisms are added we should also consider to add STARTTLS functionality
> >to MM's SMTP client to shield credentials while they are sent in a
> >plaintext authentication session.
> 
> Should we decide to do this, changing the port number is easy.
> There's already a configuration variable for this (currently set of
> course to 25).
> 
> As for implementing SMTP AUTH, we are limited by what Python's
> smtplib supports.  From a cursory inspection of the module in Python
> 2.6, it looks like it supports PLAIN, LOGIN, and CRAM-MD5.  That may
> mean that the only thing we need to add to Mailman is plumbing for
> setting the user name and password in the config file.

Sounds like a thing rather easily done.

> Please open a bug on the Mailman project in Launchpad for this.

done.
<https://bugs.launchpad.net/mailman/+bug/490044>

p at rick


-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

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

From barry at python.org  Sun Nov 29 21:01:49 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 15:01:49 -0500
Subject: [Mailman-Developers] Mailman 3.0 alpha 4
Message-ID: <1086C8AD-5F5E-49B4-889F-3E1BF68891DD@python.org>

I'm happy to announce the release of Mailman 3.0 alpha 4.

Things are getting quite real now.  It's pretty easy to hook Mailman  
up to Postfix for both incoming and outgoing mail[1] and you can  
create mailing lists and populate them with addresses.  Currently, you  
must do this through the command line though.

Please download the latest tarball or grab the bzr branch, and put it  
through some paces.  Now is a good time to comment on the design and  
feature set for Mailman 3 as we are still in alpha. I'm still planning  
on releasing a first beta by the end of the year -- your testing,  
feedback, input, and contributions can help with that!

You can download the tarball either from the Cheeseshop, or Launchpad:

http://pypi.python.org/pypi/mailman/3.0.0a4
https://launchpad.net/mailman

Please note: Mailman 3.0a4 is not production ready yet.

Enjoy,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/a359d303/attachment.pgp>

From p at state-of-mind.de  Sun Nov 29 21:29:04 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Sun, 29 Nov 2009 21:29:04 +0100
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>
References: <20091128175300.2b188a55@limelight.wooz.org>
	<20091129082221.GB3902@state-of-mind.de>
	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>
	<20091129183947.GA21882@state-of-mind.de>
	<E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>
Message-ID: <20091129202901.GC21882@state-of-mind.de>

* Barry Warsaw <barry at python.org>:
> >May I complement the list?
> >
> >- logo contest
> 
> Yep, it's actually on my TODO list after I get 3.0a4 out.  I also
> need to finish setting up i18n.
> 
> >- send the web interface off to a usability lab
> 
> +1.  IIRC, Terri was going to look into this, but I'm not sure
> what's happened with that.

She did and offered a contact. As soon as the web interface has come to a
usable state I will try to set the testing on the tracks.

p at rick



-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563

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

From barry at python.org  Sun Nov 29 23:02:32 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 17:02:32 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <20091129202901.GC21882@state-of-mind.de>
References: <20091128175300.2b188a55@limelight.wooz.org>
	<20091129082221.GB3902@state-of-mind.de>
	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>
	<20091129183947.GA21882@state-of-mind.de>
	<E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>
	<20091129202901.GC21882@state-of-mind.de>
Message-ID: <4AEAF756-A0A3-4B2A-BB0A-974D40BB649C@python.org>

On Nov 29, 2009, at 3:29 PM, Patrick Ben Koetter wrote:

>> +1.  IIRC, Terri was going to look into this, but I'm not sure
>> what's happened with that.
>
> She did and offered a contact. As soon as the web interface has come  
> to a
> usable state I will try to set the testing on the tracks.

Cool.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/39bdc3ee/attachment.pgp>

From p at state-of-mind.de  Mon Nov 30 00:03:04 2009
From: p at state-of-mind.de (Patrick Ben Koetter)
Date: Mon, 30 Nov 2009 00:03:04 +0100
Subject: [Mailman-Developers] MM 3 alpha 4: UnicodeWarning
Message-ID: <20091129230304.GF24444@state-of-mind.de>

I just sent a message to my freshly installed MM 3 alpha 4 (on Ubuntu 9.04)
and got the following warning:

Nov 29 23:53:51 mailman postfix/lmtp[8620]: D409D32E12: to=<test at mailman.state-of-mind.de>, relay=127.0.0.1[127.0.0.1]:8025, delay=1.8, delays=0.07/0.01/0/1.7, dsn=2.0.0, status=sent (250 Ok)
Nov 29 23:53:51 mailman postfix/qmgr[8613]: D409D32E12: removed
/root/mailman/src/mailman/rules/administrivia.py:84: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  if line == '':

The delivery worked though.

p at rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstra?e 15      Telefon +49 89 3090 4664
81669 M?nchen              Telefax +49 89 3090 4666

Amtsgericht M?nchen        Partnerschaftsregister PR 563


From stephen at xemacs.org  Mon Nov 30 02:55:18 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 30 Nov 2009 10:55:18 +0900
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <20091129155457.GA3831@state-of-mind.de>
References: <20091129093013.GC3902@state-of-mind.de>
	<87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20091129155457.GA3831@state-of-mind.de>
Message-ID: <87hbscydx5.fsf@uwakimon.sk.tsukuba.ac.jp>

Patrick Ben Koetter writes:

 > To clarify: I don't want to require users to authenticate in order
 > to allow them to send. I want mailman to use a stanardized port for
 > message submission (and that brings in the authentication
 > requirement).

Oh, so this is outgoing?  Now I see.

I still don't think it's a good idea until we've checked that most
popular OS distros supply all their MTAs configured to accept on port
587, and we had better have a bullet-proof autoconfigurator for it.
MTA issues are the biggest FAQ that we don't have a good canned answer
for, and this is not going to make them fewer without a lot of
"cooperation" from MTA packagers.

On this family-oriented channel, I think it is best not to describe
the pain this will cause cPanel and Plesk clients.


From barry at python.org  Mon Nov 30 03:07:28 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 21:07:28 -0500
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <87hbscydx5.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20091129093013.GC3902@state-of-mind.de>
	<87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20091129155457.GA3831@state-of-mind.de>
	<87hbscydx5.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <3A721604-71F9-492F-A35B-A9DCF8053583@python.org>

On Nov 29, 2009, at 8:55 PM, Stephen J. Turnbull wrote:

> I still don't think it's a good idea until we've checked that most
> popular OS distros supply all their MTAs configured to accept on port
> 587, and we had better have a bullet-proof autoconfigurator for it.
> MTA issues are the biggest FAQ that we don't have a good canned answer
> for, and this is not going to make them fewer without a lot of
> "cooperation" from MTA packagers.

That would be good to know.  Maybe someone would like to contribute a  
script that did a bit of probing and spit out a sample configuration  
file?

> On this family-oriented channel, I think it is best not to describe
> the pain this will cause cPanel and Plesk clients.

IWBNI those folks would engage with us early (or, hmm, at all?) so  
that we could at least understand their requirements.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/eda7f6a4/attachment.pgp>

From barry at python.org  Mon Nov 30 03:53:18 2009
From: barry at python.org (Barry Warsaw)
Date: Sun, 29 Nov 2009 21:53:18 -0500
Subject: [Mailman-Developers] MM 3 alpha 4: UnicodeWarning
In-Reply-To: <20091129230304.GF24444@state-of-mind.de>
References: <20091129230304.GF24444@state-of-mind.de>
Message-ID: <150FD67E-7F86-4D02-A0C5-0172361860E4@python.org>

On Nov 29, 2009, at 6:03 PM, Patrick Ben Koetter wrote:

> I just sent a message to my freshly installed MM 3 alpha 4 (on  
> Ubuntu 9.04)
> and got the following warning:
>
> Nov 29 23:53:51 mailman postfix/lmtp[8620]: D409D32E12: to=<test at mailman.state-of-mind.de 
> >, relay=127.0.0.1[127.0.0.1]:8025, delay=1.8,  
> delays=0.07/0.01/0/1.7, dsn=2.0.0, status=sent (250 Ok)
> Nov 29 23:53:51 mailman postfix/qmgr[8613]: D409D32E12: removed
> /root/mailman/src/mailman/rules/administrivia.py:84: UnicodeWarning:  
> Unicode equal comparison failed to convert both arguments to Unicode  
> - interpreting them as being unequal
>  if line == '':
>
> The delivery worked though.

Interesting.  Do you have a copy of that message?  Is it reproducible?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/9b99515c/attachment.pgp>

From terri at zone12.com  Mon Nov 30 03:58:32 2009
From: terri at zone12.com (Terri Oda)
Date: Sun, 29 Nov 2009 21:58:32 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <20091129202901.GC21882@state-of-mind.de>
References: <20091128175300.2b188a55@limelight.wooz.org>	<20091129082221.GB3902@state-of-mind.de>	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>	<20091129183947.GA21882@state-of-mind.de>	<E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>
	<20091129202901.GC21882@state-of-mind.de>
Message-ID: <4B1334D8.4070005@zone12.com>

Patrick Ben Koetter wrote:
> * Barry Warsaw <barry at python.org>:
>>> - send the web interface off to a usability lab
>> +1.  IIRC, Terri was going to look into this, but I'm not sure
>> what's happened with that. 
> She did and offered a contact. As soon as the web interface has come to a
> usable state I will try to set the testing on the tracks.

Yup, I've got the appropriate people interested, but they're waiting for 
a design to test before we hash out the details of a lab study.  Really 
looking forwards to working with this team -- I've been very impressed 
with what they do and the insights they garner.

Incidentally, how's that web interface coming?  I don't want to make any 
promises yet, but if work permits I'd like to take a bit of an open 
source holiday and hack for a week mid-december... I was tentatively 
thinking archives, but I could be convinced to poke somewhere else. :)

  Terri

From cite at incertum.net  Mon Nov 30 06:27:05 2009
From: cite at incertum.net (Stefan =?utf-8?Q?F=C3=B6rster?=)
Date: Mon, 30 Nov 2009 06:27:05 +0100
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <20091129093013.GC3902@state-of-mind.de>
References: <20091129093013.GC3902@state-of-mind.de>
Message-ID: <20091130052705.GA2433@mail.incertum.net>

* Patrick Ben Koetter <p at state-of-mind.de>:
> From my daily work with mailman the following "modified in some way"-tasks
> come to my mind immediately:
> 
> - apply client and content policy that differs from the port 25 anti-spam
>   policy
> - add DKIM signatures because it is clear mailman messages are ORIGINATING
>   from our network

I seem to remember a certain training where the two of us were showing
some very different ways on how to deal with individual policies ;-)

I don't think changing the default port would be such a great idea.
The submission port is widely used for messages submitted by _end
users_ - with all the necessary precautions in place, i.e. DNS checks,
SMTP AUTH and content filtering (at least virus filtering).

MM generated messages don't need DNS or virus checks - the messages
were already scanned when they entered the system, and temporary
rejects on DNS errors are detrimental to MM's bounce recognizing
abilities. There's a high probability you'd have to create a SMTP
listener with a dedicated policy set anyways - changing SMTPPORT in
mm_cfg.py is only a very minor task in setting up a mailing list
server.


Cheers
Stefan

From iane at sussex.ac.uk  Mon Nov 30 12:28:28 2009
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 30 Nov 2009 11:28:28 +0000
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <3A721604-71F9-492F-A35B-A9DCF8053583@python.org>
References: <20091129093013.GC3902@state-of-mind.de>
	<87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20091129155457.GA3831@state-of-mind.de>
	<87hbscydx5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<3A721604-71F9-492F-A35B-A9DCF8053583@python.org>
Message-ID: <415DF40A80BB14666C606E11@lewes.staff.uscs.susx.ac.uk>



--On 29 November 2009 21:07:28 -0500 Barry Warsaw <barry at python.org> wrote:

> On Nov 29, 2009, at 8:55 PM, Stephen J. Turnbull wrote:
>
>> I still don't think it's a good idea until we've checked that most
>> popular OS distros supply all their MTAs configured to accept on port
>> 587, and we had better have a bullet-proof autoconfigurator for it.
>> MTA issues are the biggest FAQ that we don't have a good canned answer
>> for, and this is not going to make them fewer without a lot of
>> "cooperation" from MTA packagers.
>
> That would be good to know.  Maybe someone would like to contribute a
> script that did a bit of probing and spit out a sample configuration file?

Autoconfiguration shouldn't be too hard. Mailman has to be configured with 
a hostname. There are three options for the port:

custom configuration
587
25

Mailman can test the connectivity of each in turn, on the first message 
that it sends. Cache the port number on success. This should be run-time 
autoconfiguration, not install time autoconfiguration. That way, the 
configuration can cope with a change of host name. If a port becomes 
unavailable, then alternate ports could be tested...

Other mail clients do this, including Apple Mail and MS Outlook, when 
configuring new accounts.

Am I right in thinking that all the mail is typically routed through a 
local MTA?

>> On this family-oriented channel, I think it is best not to describe
>> the pain this will cause cPanel and Plesk clients.
>
> IWBNI those folks would engage with us early (or, hmm, at all?) so that
> we could at least understand their requirements.
>
> -Barry
>



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

From barry at python.org  Mon Nov 30 14:06:32 2009
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Nov 2009 08:06:32 -0500
Subject: [Mailman-Developers] Mailman and Submission port
In-Reply-To: <415DF40A80BB14666C606E11@lewes.staff.uscs.susx.ac.uk>
References: <20091129093013.GC3902@state-of-mind.de>
	<87ws19y052.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20091129155457.GA3831@state-of-mind.de>
	<87hbscydx5.fsf@uwakimon.sk.tsukuba.ac.jp>
	<3A721604-71F9-492F-A35B-A9DCF8053583@python.org>
	<415DF40A80BB14666C606E11@lewes.staff.uscs.susx.ac.uk>
Message-ID: <6A16478A-2C93-4FDA-B406-07761179DD39@python.org>

On Nov 30, 2009, at 6:28 AM, Ian Eiloart wrote:

> Autoconfiguration shouldn't be too hard. Mailman has to be  
> configured with a hostname. There are three options for the port:
>
> custom configuration
> 587
> 25
>
> Mailman can test the connectivity of each in turn, on the first  
> message that it sends. Cache the port number on success. This should  
> be run-time autoconfiguration, not install time autoconfiguration.  
> That way, the configuration can cope with a change of host name. If  
> a port becomes unavailable, then alternate ports could be tested...
>
> Other mail clients do this, including Apple Mail and MS Outlook,  
> when configuring new accounts.
>
> Am I right in thinking that all the mail is typically routed through  
> a local MTA?

Yes.  I should also say that I think adding support for AUTH (via  
smtplib.SMTP.login()) is somewhat orthogonal to port selection.  We  
should do the former even if we change nothing about current port  
selection.

Here's a thought on the latter for anybody wishing to hack: extend the  
semantics of [mta]smtp_port in Mailman 3 to allow for a list of  
whitespace separated ports to try, and add a cache_lifetime  
parameter.  If int(config.mta.smtp_port) fails, try splitting the  
variable and int'ing the items.  In that case, try each port in order  
and remember the winner for cache_lifetime.  You don't need to keep  
the cached value in the db; it would be fine to throw it away and re- 
probe on outgoing queue restart.

In the new tradition of the 21st century: branches welcome. :)  If  
someone does want to contribute here, please make the AUTH support a  
separate branch from the port probe support.  I will be happy to  
review any such branches.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091130/73f50c97/attachment.pgp>

From barry at python.org  Mon Nov 30 16:27:10 2009
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Nov 2009 10:27:10 -0500
Subject: [Mailman-Developers] Mailman 3 and LMTP
In-Reply-To: <4B1334D8.4070005@zone12.com>
References: <20091128175300.2b188a55@limelight.wooz.org>	<20091129082221.GB3902@state-of-mind.de>	<D0A4ADC9-DAF1-4822-8C36-EB5BE19E977E@python.org>	<20091129183947.GA21882@state-of-mind.de>	<E86B45AF-2E48-4530-A68A-C3B23675A2F7@python.org>
	<20091129202901.GC21882@state-of-mind.de>
	<4B1334D8.4070005@zone12.com>
Message-ID: <B7232C74-D076-4F08-88A3-610BB517B856@python.org>

On Nov 29, 2009, at 9:58 PM, Terri Oda wrote:

> Yup, I've got the appropriate people interested, but they're waiting  
> for a design to test before we hash out the details of a lab study.   
> Really looking forwards to working with this team -- I've been very  
> impressed with what they do and the insights they garner.
>
> Incidentally, how's that web interface coming?  I don't want to make  
> any promises yet, but if work permits I'd like to take a bit of an  
> open source holiday and hack for a week mid-december... I was  
> tentatively thinking archives, but I could be convinced to poke  
> somewhere else. :)

Either would rock.  I have a branch that rips Pipermail out of the  
Mailman 3 source and into a separate project on Launchpad:

https://edge.launchpad.net/pipermail

It's not functional yet because I've had to do some refactoring (e.g.  
of the i18n stuff), but it's getting there.  The branch should be  
owned by ~mailman-coders so you should be able to read and write to  
it.  Of course, if you don't think Pipermail is worth the effort... :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091130/0cdf9262/attachment.pgp>

From iane at sussex.ac.uk  Mon Nov 30 18:24:14 2009
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 30 Nov 2009 17:24:14 +0000
Subject: [Mailman-Developers] MM 3 alpha 4: UnicodeWarning
In-Reply-To: <20091129230304.GF24444@state-of-mind.de>
References: <20091129230304.GF24444@state-of-mind.de>
Message-ID: <EC1955FB05045B93C42D90C9@lewes.staff.uscs.susx.ac.uk>


I got a unicode warning, too. Running alpha4 with python26 on OSX 10.5. I 
didn't have Pyrex installed, and got warnings during the build process. 
Don't know if that's related.


bin/test
Test-module import failures:

Module: mailman.tests.test_documentation

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 22: 
ordinal not in range(128)


Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Error in test test_SMTP32_failure (mailman.tests.test_bounces.BounceTest)
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", 
line 279, in run
    testMethod()
  File "/Users/iane/Downloads 
?/mailman-3.0.0a4/src/mailman/tests/test_bounces.py", line 193, in 
test_SMTP32_failure
    with open(os.path.join(MSGDIR, 'postfix_01.txt')) as fp:
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py", 
line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 22: 
ordinal not in range(128)



Error in test test_bounce (mailman.tests.test_bounces.BounceTest)
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", 
line 279, in run
    testMethod()
  File "/Users/iane/Downloads 
?/mailman-3.0.0a4/src/mailman/tests/test_bounces.py", line 175, in 
test_bounce
    path = os.path.join(MSGDIR, filename)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py", 
line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 22: 
ordinal not in range(128)

  Ran 23 tests with 0 failures and 2 errors in 0.468 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

Test-modules with import problems:
  mailman.tests.test_documentation



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

From mark at msapiro.net  Mon Nov 30 22:39:24 2009
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 30 Nov 2009 13:39:24 -0800
Subject: [Mailman-Developers] MM 3 alpha 4: UnicodeWarning
In-Reply-To: <EC1955FB05045B93C42D90C9@lewes.staff.uscs.susx.ac.uk>
References: <20091129230304.GF24444@state-of-mind.de>
	<EC1955FB05045B93C42D90C9@lewes.staff.uscs.susx.ac.uk>
Message-ID: <4B143B8C.6050009@msapiro.net>

Ian Eiloart wrote:
> 
> I got a unicode warning, too. Running alpha4 with python26 on OSX 10.5.
> I didn't have Pyrex installed, and got warnings during the build
> process. Don't know if that's related.


It's different from Patrick's warning.

In your case, the issue appears to be the non-ascii character (0xe2
a-circumflex) in the name of the
/Users/iane/Downloads ?/ directory

>  File "/Users/iane/Downloads
> ?/mailman-3.0.0a4/src/mailman/tests/test_bounces.py", line 193, in
> test_SMTP32_failure
>    with open(os.path.join(MSGDIR, 'postfix_01.txt')) as fp:
>  File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py",
> line 70, in join
>    path += '/' + b
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 22:
> ordinal not in range(128)

Presumably MSGDIR has the same "/Users/iane/Downloads
?/mailman-3.0.0a4/" prefix.

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


From barry at python.org  Mon Nov 30 23:56:29 2009
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Nov 2009 17:56:29 -0500
Subject: [Mailman-Developers] MM 3 alpha 4: UnicodeWarning
In-Reply-To: <EC1955FB05045B93C42D90C9@lewes.staff.uscs.susx.ac.uk>
References: <20091129230304.GF24444@state-of-mind.de>
	<EC1955FB05045B93C42D90C9@lewes.staff.uscs.susx.ac.uk>
Message-ID: <C189E7E2-B9EB-4752-A424-5FB0A2C1D010@python.org>

On Nov 30, 2009, at 12:24 PM, Ian Eiloart wrote:

> Error in test test_SMTP32_failure  
> (mailman.tests.test_bounces.BounceTest)
> Traceback (most recent call last):
> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
> lib/python2.6/unittest.py", line 279, in run
>   testMethod()
> File "/Users/iane/Downloads ?/mailman-3.0.0a4/src/mailman/tests/ 
> test_bounces.py", line 193, in test_SMTP32_failure
>   with open(os.path.join(MSGDIR, 'postfix_01.txt')) as fp:
> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
> lib/python2.6/posixpath.py", line 70, in join
>   path += '/' + b
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position  
> 22: ordinal not in range(128)
>
> Error in test test_bounce (mailman.tests.test_bounces.BounceTest)
> Traceback (most recent call last):
> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
> lib/python2.6/unittest.py", line 279, in run
>   testMethod()
> File "/Users/iane/Downloads ?/mailman-3.0.0a4/src/mailman/tests/ 
> test_bounces.py", line 175, in test_bounce
>   path = os.path.join(MSGDIR, filename)
> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
> lib/python2.6/posixpath.py", line 70, in join
>   path += '/' + b
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position  
> 22: ordinal not in range(128)

I think Mark correctly diagnosed the problem.  Keep in mind that these  
are somewhat broken tests anyway because they should be using  
pkg_resource to get at those files instead of os.path.join() and  
open().  I don't know if that'll solve the problem though.

I'm not exactly sure how to fix this yet, but I'll try to see if I can  
reproduce it locally.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091130/25a57c4f/attachment-0001.pgp>