I think I've managed to get our Confluence license renewed, so those of you
with write privileges to wiki.list.org should be able to save pages again. If
not, please let me know.
I haven't heard much about the Moin conversion lately, but hopefully that will
happen before the next time our license runs out.
-Barry
Dear Mailman Developers,
we had a nice discussion this afternoon (13:00 - 15:00) UTC about this
topic.
I've written a small blogposts about the results which will be
implemented in near future.
http://benste.blogspot.com/2011/07/discussion-on-acls-using-mailman30-and.h…
Key aspects:
Decided to use a Proxy which:
* is responsible for exposing the user roles
* using it's own DB
* customizable to querry others - e.g. Launchpad
* needs to be authenticated at the Core using REST-API (might get
https)
* similar API to REST, but requiring a username to each request
* each request will be handled based on username is already
authenticated - e.g in a web-session
* will be able to raise HTTP401 (access denied) if user is not
allowed to do this action / get this option
* might authenticate users based on a request(user;pswd)
Python Bindings for REST will be able to use both either Proxyed
REST or direct access to Rest depending on wheter the UI decides
to use it with a User object.
direct REST-API Calls will only be able on localhost
--
Einen schönen Tag wünscht:
Benedict Stein
>
> I think bouncing at the MTA is slightly sub-optimal and that mailman
> could generate a more informative bounce indicating how to contact the
> server admin to get the list revived. Probably in the web interface
> there could be a "disabled lists" category. Server admins would
> probably want to be able to login to the disabled lists in the web
> interface, but maybe not the list admins.
Bouncing certainly is suboptimal, since it may create collateral spam. Better to reject the message at SMTP time with a 5xx response than to bounce.
However, it's probably possible to do what you want by putting the list on emergency moderation, and changing the message, is it not? Or something similar?
If that is possible, then what's required is simply a web interface to simplify that process.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
Hello Developers at Mailman
Thank you for your advice below, this solves my problem but also creates a
new problem.
The mobility of %(user_delivered_to)s is the issue. Is there something like
an msg_body, where you can compile the html letter and insert
%(user_delivered_to)s. That would obv be perfect.
Right now I have the issue of the msg_footer being inserted as an
attachment, but I have found a solution for that on the internet.
MIMEDefang... you obv know what I am talking about.
Msg_header does not work in MS office, but that won't work either because it
will be at the top of the emailer. See attachment.
Please let me know what you think.
Thanks in advance
-----Original Message-----
From: Mark Sapiro [mailto:mark@msapiro.net]
Sent: 15 July 2011 01:22 AM
To: Clayton Brown
Cc: mailman-developers(a)python.org
Subject: Re: [Mailman-Developers] A subscribe link
On 7/14/2011 1:18 AM, Clayton Brown wrote:
>
> Example: There must be a link on the cleansing email that looks like this:
> <a href='www.test.com/subscribe.php?id=recipient@test.co.za'>Opt In</a>
> It will be then easy for me to subscribe the recipient into a subscribe
> database and just create a list afterwards.
If the installation has set
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
in mm_cfg.py so that the 'personalize' settings appear on the list admin
Non-digest options page and personalize is set to Yes, then either the
replacement %(user_address)s or %(user_delivered_to)s can be used in
either msg_header or msg_footer to receive either the user's lower-cased
email address or case-preserved email address respectively.
Those replacements work only in msg_header and msg_footer. They don't
work in the message body and they don't work in digests.
E.g. You could put
Opt-in <www.test.com/subscribe.php?id=%(user_delivered_to)s>
in msg_footer. This may or may not be rendered as an active link
depending on the users MUA. You can't put an HTML tag in msg_header or
msg_footer, because it will always be in a text/plain part of the message.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On Jul 13, 2011, at 04:51 PM, Paul Wise wrote:
>By bounce I meant SMTP-time rejection, sounds like the LMTP stuff
>provides that (and mailman 2 doesn't use that IIRC).
Correct.
>Temporarily failing lists were not an objective.
Cool, I think we're agreed on that.
>The design of list objects seems to be heavily similar to how the UI
>is in mailman 2, I think it should be much more generic.
>
>For example:
>
>In the web UI turning on emergency moderation should set the first
>item in the receive pipeline to a hold() function.
>
>Disabling a list would set the first item in the receive pipeline to
>reject_disabled, set the first item in the subscription pipeline to
>reject_disabled, set the first item in the settings pipeline to
>admin_read_only etc.
This isn't exactly how MM3 works. In MM3, the incoming queue sends the
message through a chain, where each link has a rule and an action. An action
can be something like "jump to the `hold` chain", which is in fact exactly
what happens in the default built-in chain:
src/mailman/chains/builtin.py:
_link_descriptions = (
('approved', LinkAction.jump, 'accept'),
('emergency', LinkAction.jump, 'hold'),
...
There really aren't "subscription" or "settings" pipelines, and I'm not sure
they're the right way to implement what you have in mind.
>List objects should be flexible to support different kinds of lists,
>but the UI should hide most of that behind simple labels like "retired
>list", "public list", "private list" and the "emergency moderation"
>button.
MM3 has list styles, which are composeable and extensible. A style is only
applied at list creation time though.
>PS: Is there a Mailman UI yet? The link on the Mailman branches wiki
>page points to one with only one commit in it and no working code.
I think we're still waiting for Florian and the GSoC students to propose
branch merges into lp:mailmanweb.
>PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm
>thinking configuration filenames, data directories etc should be named
>mailman3 instead of mailman.
Maybe. I'd really like to not do that if it can be avoided. For example, the
configuration system is so different I can't see how there would be much
collision. The data directories, possibly, but I also think there are enough
knobs to allow site admins or vendor packagers to set things up with the
proper defaults. I don't think there will be any collisions on command line
program names.
Cheers,
-Barry
Good Morning Mailman Developers
I would like to know the following:
I want to send out an cleansing email to a list that I have, on the
cleansing email there must be a subscribe link.
When a recipient clicks on the subscribe link the recipient will
automatically be transferred into a new list called subscriptions.
Afterwards I have a subscriptions list and the old list which will be
deleted.
Alternatively is there some way Mailman can put the recipient's email
address in a variable in the email the recipient is receiving.
Example: There must be a link on the cleansing email that looks like this:
<a href='www.test.com/subscribe.php?id=recipient@test.co.za'>Opt In</a>
It will be then easy for me to subscribe the recipient into a subscribe
database and just create a list afterwards.
The main point here is, that when the recipient clicks on the 'Opt-in' link
their email address must automatically be captured, thus removing a step
where they will be
navigated to a page where they must first fill in their email address to be
subscribed.
I am in inexperience php developer, if there is a way that you know off
where I can capture the email's headers please let me know. Please remember
the way Mailman works in regards to posting an email. Does it allow for php
in the code or only HTML?
Thank You in advance
Clayton Brown
HI Paul, or all others who want to get involved into mm3 WebUI
development.
I'm closly listening your dicsussion.
The WebUI is work in progress and there is nothing stable yet.
However if you're interested taking a look at the dev snippets take a
look at the following branches:
https://code.edge.launchpad.net/mailmanwebgsoc2011
Feel free to contact Flo or me on IRC (#benste)
PS: Little tutorial on how to get it running:
http://wiki.list.org/pages/viewpage.action?pageId=11960560
Please really keep in mind th
Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise:
> On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote:
>
> > It sounds like a lot, but I'd think it's only a day or two of work, and I'm
> > happy to answer questions, review code, etc.
>
> I would like to get the design right first, after reading the full
> thread a couple of times, some thoughts:
>
> By bounce I meant SMTP-time rejection, sounds like the LMTP stuff
> provides that (and mailman 2 doesn't use that IIRC).
>
> Temporarily failing lists were not an objective.
>
> The design of list objects seems to be heavily similar to how the UI
> is in mailman 2, I think it should be much more generic.
>
> For example:
>
> In the web UI turning on emergency moderation should set the first
> item in the receive pipeline to a hold() function.
>
> Disabling a list would set the first item in the receive pipeline to
> reject_disabled, set the first item in the subscription pipeline to
> reject_disabled, set the first item in the settings pipeline to
> admin_read_only etc.
>
> List objects should be flexible to support different kinds of lists,
> but the UI should hide most of that behind simple labels like "retired
> list", "public list", "private list" and the "emergency moderation"
> button.
>
> PS: Is there a Mailman UI yet? The link on the Mailman branches wiki
> page points to one with only one commit in it and no working code.
>
> PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm
> thinking configuration filenames, data directories etc should be named
> mailman3 instead of mailman.
>
--
Einen schönen Tag wünscht:
Benedict Stein
HI Paul, or all others who want to get involved into mm3 WebUI
development.
I'm closly listening your dicsussion.
The WebUI is work in progress and there is nothing stable yet.
However if you're interested taking a look at the dev snippets take a
look at the following branches:
https://code.edge.launchpad.net/mailmanwebgsoc2011
Feel free to contact Flo or me on IRC (#benste)
PS: Little tutorial on how to get it running:
http://wiki.list.org/pages/viewpage.action?pageId=11960560
Please really keep in mind these are only suggested peaces of work which
don't even cover all basic functionallity.
Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise:
> On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote:
>
> > It sounds like a lot, but I'd think it's only a day or two of work, and I'm
> > happy to answer questions, review code, etc.
>
> I would like to get the design right first, after reading the full
> thread a couple of times, some thoughts:
>
> By bounce I meant SMTP-time rejection, sounds like the LMTP stuff
> provides that (and mailman 2 doesn't use that IIRC).
>
> Temporarily failing lists were not an objective.
>
> The design of list objects seems to be heavily similar to how the UI
> is in mailman 2, I think it should be much more generic.
>
> For example:
>
> In the web UI turning on emergency moderation should set the first
> item in the receive pipeline to a hold() function.
>
> Disabling a list would set the first item in the receive pipeline to
> reject_disabled, set the first item in the subscription pipeline to
> reject_disabled, set the first item in the settings pipeline to
> admin_read_only etc.
>
> List objects should be flexible to support different kinds of lists,
> but the UI should hide most of that behind simple labels like "retired
> list", "public list", "private list" and the "emergency moderation"
> button.
>
> PS: Is there a Mailman UI yet? The link on the Mailman branches wiki
> page points to one with only one commit in it and no working code.
>
> PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm
> thinking configuration filenames, data directories etc should be named
> mailman3 instead of mailman.
>
--
Einen schönen Tag wünscht:
Benedict Stein
On Jul 11, 2011, at 12:22 AM, Paul Wise wrote:
>For the Indymedia Mailman 2 install, we have a patch that allowed list
>disabling (and later re-enabling). Disabled lists had their
>settings/archives saved, did not accept mail and were listed on a
>separate page to listinfo. For a long-lived large mailman server
>serving local groups in many locations, management of the complete
>list life cycle was and still is essential for us.
>
>AFAICT Mailman 3 doesn't yet support such a concept, is that the case?
I've thought about this on and off over the years and still think it's a good
idea. No, MM3 does not have such a thing yet.
>If not, would it be acceptable to add that?
Yep, but I'd like to understand the semantics first. Do messages to the list
get bounced, and if so, by Mailman or the MTA? Currently, deleting a list
does remove its configuration, but (by default) retains its archives, which
can be deleted later. A disabled list would always have its archives
available I think.
>Any pointers if I were to try and add that?
I think the core feature would not be too hard to implement, but some
specifics would depend on answering the main question above. Here's an
outline of what you'd probably need to touch:
- IMailingList interface to add a `enabled` flag, along with (possibly)
methods to disable and re-enable a list. It's possible that the flag would
be a property and just setting `mlist.enabled = False` would be enough.
- mailman.sql to add that flag to the schema.
- MailingList model to plumb the flag through and implement the switching
logic.
- Add a new command class, probably in cli_lists.py to expose disable/enable
to `bin/mailman`. Perhaps implement this as options on the existing
`remove` command.
- Plumb this through to the REST API, either by extended the AList class in
src/mailman/rest/lists.py, or by exposing the flag in the ListConfiguration
class in src/mailman/rest/configuration.py.
- Tests and documentation!
It sounds like a lot, but I'd think it's only a day or two of work, and I'm
happy to answer questions, review code, etc.
-Barry
