Hi all,

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?

If not, would it be acceptable to add that?

Any pointers if I were to try and add that?

--
bye,
pabs

Search Discussions

  • Barry Warsaw at Jul 11, 2011 at 3:40 pm

    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
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110711/dc0cc6c6/attachment.pgp>
  • Paul Wise at Jul 11, 2011 at 4:37 pm

    On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote:

    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. ...
    Yep
    Ok, great.
    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.
    With our current setup the disabled (or "graveyarded") list is removed
    from the /var/lib/mailman/lists dir and the aliases regenerated, so
    the MTA bounces messages to it and the admin interface for it cannot
    be logged into. Disabled lists are listed in a separate page in the
    web interface to the normal listinfo page. Some disabled lists might
    get their archives removed and some not.

    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.
    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:
    Thanks for the pointers, I will try that this week.

    --
    bye,
    pabs
  • Ian Eiloart at Jul 12, 2011 at 1:06 pm

    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
  • Barry Warsaw at Jul 12, 2011 at 3:11 pm

    On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:
    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.
    That's an interesting take on it. The LMTP server in Mailman could reject
    messages addressed to disabled lists, and that 5xx error should propagate
    through the MTA.

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110712/9284d412/attachment.pgp>
  • Patrick Ben Koetter at Jul 12, 2011 at 3:23 pm

    * Barry Warsaw <barry at list.org>:
    On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:

    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.
    That's an interesting take on it. The LMTP server in Mailman could reject
    messages addressed to disabled lists, and that 5xx error should propagate
    through the MTA.
    Is disabling a list a temporary measure? If it is, should the server reply a
    temporary error?

    421 <domain> Service not available, closing transmission channel
    (This may be a reply to any command if the service knows it
    must shut down)
    450 Requested mail action not taken: mailbox unavailable
    (e.g., mailbox busy)

    Or is it permanent?

    550 Requested action not taken: mailbox unavailable
    (e.g., mailbox not found, no access, or command rejected
    for policy reasons)

    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: signature.asc
    Type: application/pgp-signature
    Size: 316 bytes
    Desc: Digital signature
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110712/9fd31a86/attachment-0001.pgp>
  • Lindsay Haisley at Jul 12, 2011 at 3:44 pm

    On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote:
    Is disabling a list a temporary measure? If it is, should the server reply a
    temporary error?
    In my humble opinion, an intentionally disabled list should cause the
    mail system to generate a 500 class error (permanent error). 400 class
    errors (temporary errors) are generally reserved for situations where
    the _intention_ is that the mail should go through but is prevented from
    doing so by problems for which a solution is in progress. A 400 class
    error causes the originating system to cache and re-try delivery, so if
    a list returns a 400 class error, it's just "delayed", not truly
    "disabled". This may be a fine distinction, and if a list is disabled
    for technical reasons with the intention of bringing it back up in short
    order without losing traffic, then perhaps a 400 class error would be
    more appropriate.

    --
    Lindsay Haisley | "We have met the enemy, and it is us."
    FMP Computer Services |
    512-259-1190 | -- Pogo
    http://www.fmp.com |
  • Patrick Ben Koetter at Jul 12, 2011 at 6:52 pm

    * Lindsay Haisley <fmouse at fmp.com>:
    On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote:
    Is disabling a list a temporary measure? If it is, should the server reply a
    temporary error?
    In my humble opinion, an intentionally disabled list should cause the
    mail system to generate a 500 class error (permanent error). 400 class
    errors (temporary errors) are generally reserved for situations where
    the _intention_ is that the mail should go through but is prevented from
    doing so by problems for which a solution is in progress. A 400 class
    error causes the originating system to cache and re-try delivery, so if
    a list returns a 400 class error, it's just "delayed", not truly
    "disabled". This may be a fine distinction, and if a list is disabled
    ACK. Looking at the available codes I guess the best return code would probably
    be 550:

    550 Requested action not taken: mailbox unavailable (e.g., mailbox
    not found, no access, or command rejected for policy reasons)

    <http://www.rfc-editor.org/rfc/rfc5321.txt, section 4.2.3. Reply
    Codes in Numeric Order>

    p at rick


    --
    state of mind ()

    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
  • Barry Warsaw at Jul 12, 2011 at 8:39 pm

    On Jul 12, 2011, at 08:52 PM, Patrick Ben Koetter wrote:

    550 Requested action not taken: mailbox unavailable (e.g., mailbox
    not found, no access, or command rejected for policy reasons)

    <http://www.rfc-editor.org/rfc/rfc5321.txt, section 4.2.3. Reply
    Codes in Numeric Order>
    That would be my preference too. I recently had a use case for something like
    this. The import-sig on python.org was retired a few years ago, but I just
    resurrected it for the PEP 382 discussion. I probably would have used this
    feature for these sigs.

    It does lead me to think that "retired" might be a better term, and it makes
    me wonder whether actions like subscribing to a retired list would still be
    allowed.

    But maybe the OP has a different use case in mind and we could have a need for
    both a long-term, permanently failing retired lists, and shorter term,
    temporarily failing disabled lists.

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110712/44461036/attachment.pgp>
  • Stephen J. Turnbull at Jul 13, 2011 at 4:34 am
    Barry Warsaw writes:
    But maybe the OP has a different use case in mind and we could have a need for
    both a long-term, permanently failing retired lists, and shorter term,
    temporarily failing disabled lists.
    I don't really understand under what circumstances a list owner would
    want to disable the *whole list* and at the same time leave retries up
    to arbitrary MTAs out on the Internet. The poster may or may not get
    a DSN. Etc, etc.

    OTOH, I can imagine that for some purposes you might want a different
    status code, and I don't see any good reason for making that
    configurable and then restricting it to 5xx. Rather, document it as
    "this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with
    sufficient reason it could be a 4xx code, but we don't know of any
    examples offhand :-)."
  • Barry Warsaw at Jul 15, 2011 at 7:12 pm

    On Jul 13, 2011, at 01:34 PM, Stephen J. Turnbull wrote:
    Barry Warsaw writes:
    But maybe the OP has a different use case in mind and we could have a need for
    both a long-term, permanently failing retired lists, and shorter term,
    temporarily failing disabled lists.
    I don't really understand under what circumstances a list owner would
    want to disable the *whole list* and at the same time leave retries up
    to arbitrary MTAs out on the Internet. The poster may or may not get
    a DSN. Etc, etc.
    I agree. I think I like the term "retire" better than "disable" to more
    clearly designate a step in a list's life between active and deleted.

    A retired list would still exist, and people could (maybe?) still subscribe to
    it, etc. I think the core wouldn't treat retired lists much different than
    active lists except to either omit its aliases from regeneration, or give the
    appropriate LMTP code. One thing to think about is how MTAs like Exim will
    work since they don't use an alias file.
    OTOH, I can imagine that for some purposes you might want a different
    status code, and I don't see any good reason for making that
    configurable and then restricting it to 5xx. Rather, document it as
    "this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with
    sufficient reason it could be a 4xx code, but we don't know of any
    examples offhand :-)."
    Do you really think it needs to be configurable? I mean, if we can't think of
    a reason to not make it 5xx, why not just wait for the first wishlist bug
    report? :)

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110715/113a6503/attachment.pgp>
  • Patrick Ben Koetter at Jul 15, 2011 at 7:23 pm

    * Barry Warsaw <barry at list.org>:
    OTOH, I can imagine that for some purposes you might want a different
    status code, and I don't see any good reason for making that
    configurable and then restricting it to 5xx. Rather, document it as
    "this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with
    sufficient reason it could be a 4xx code, but we don't know of any
    examples offhand :-)."
    Do you really think it needs to be configurable? I mean, if we can't think of
    a reason to not make it 5xx, why not just wait for the first wishlist bug
    report? :)
    A configurable reply could provide a hint along the 550 like this:

    550 See: http://list.example.com/550/listname

    The listname ressource could inform why the list was retired e.g. because it
    was relocated or closed or where to find the retired lists archives ...

    p at rick

    --
    state of mind ()

    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: signature.asc
    Type: application/pgp-signature
    Size: 316 bytes
    Desc: Digital signature
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110715/8d19ca81/attachment.pgp>
  • Barry Warsaw at Jul 15, 2011 at 7:31 pm

    On Jul 15, 2011, at 09:23 PM, Patrick Ben Koetter wrote:
    A configurable reply could provide a hint along the 550 like this:

    550 See: http://list.example.com/550/listname

    The listname ressource could inform why the list was retired e.g. because it
    was relocated or closed or where to find the retired lists archives ...
    That's not a bad idea. So, we'd definitely want to record a reason for the
    status change to "retired".

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110715/d2c11a9e/attachment.pgp>
  • Stephen J. Turnbull at Jul 16, 2011 at 6:18 am
    Barry Warsaw writes:
    Do you really think it needs to be configurable? I mean, if we
    can't think of a reason to not make it 5xx, why not just wait for
    the first wishlist bug report? :)
    No, on second thought after reviewing the codes, the only appropriate
    5xx code is 550. So there's no reason I can think of for
    configurability at this point.
  • Ian Eiloart at Jul 20, 2011 at 10:38 am

    On 16 Jul 2011, at 07:18, Stephen J. Turnbull wrote:

    Barry Warsaw writes:
    Do you really think it needs to be configurable? I mean, if we
    can't think of a reason to not make it 5xx, why not just wait for
    the first wishlist bug report? :)
    No, on second thought after reviewing the codes, the only appropriate
    5xx code is 550. So there's no reason I can think of for
    configurability at this point.

    Sure, 550 is appropriate, but an rfc1893/2034 enhanced error code should be used, too. These might be useful:

    X.1.0 Other address status
    X.1.6 Destination mailbox has moved, No forwarding address
    X.2.1 Mailbox disabled, not accepting messages

    Also, there's a case for customising the text returned, if not the error code.

    --
    Ian Eiloart
    Postmaster, University of Sussex
    +44 (0) 1273 87-3148
  • Ian Eiloart at Jul 13, 2011 at 11:38 am

    On 12 Jul 2011, at 16:11, Barry Warsaw wrote:
    On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:

    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.
    That's an interesting take on it. The LMTP server in Mailman could reject
    messages addressed to disabled lists, and that 5xx error should propagate
    through the MTA.
    Yes, this should be used in combination with a call forward from the MTA at RCTP TO, so that it the MTA can determine the status of the mailing list *before* giving a reply to the sending MTA.
    -Barry
    _______________________________________________
    Mailman-Developers mailing list
    Mailman-Developers at python.org
    http://mail.python.org/mailman/listinfo/mailman-developers
    Mailman FAQ: http://wiki.list.org/x/AgA3
    Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
    Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.ac.uk

    Security Policy: http://wiki.list.org/x/QIA9
    --
    Ian Eiloart
    Postmaster, University of Sussex
    +44 (0) 1273 87-3148
  • Barry Warsaw at Jul 12, 2011 at 3:10 pm

    On Jul 11, 2011, at 06:37 PM, Paul Wise wrote:
    With our current setup the disabled (or "graveyarded") list is removed
    from the /var/lib/mailman/lists dir and the aliases regenerated, so
    the MTA bounces messages to it and the admin interface for it cannot
    be logged into. Disabled lists are listed in a separate page in the
    web interface to the normal listinfo page. Some disabled lists might
    get their archives removed and some not.
    I think this approach would actually be fairly easy to implement in the core,
    with additional ui considerations in the new web ui. It could be a matter of
    just adding the .enabled flag to mailing lists, and re-running the MM3 moral
    equivalent of genaliases when that flag changes. All the data associated with
    the mailing list would remain in the database.

    The web ui would then look at the .enabled flag to decide where and how to
    display the mailing list information, and whether to allow logins, etc. But
    it would still be able to get (and probably set) attributes on the mailing
    list.
    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.
    Should you still be able to contact a disabled list's owners? I think if
    you're just going to bounce messages addressed to mydisabledlist-*@example.com
    and the text is static, then it's probably best to point those aliases to a
    very simple replybot service (I have one I've been toying with) so it doesn't
    increase the load on Mailman.

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110712/09f6b5b2/attachment.pgp>
  • Benedict Stein at Jul 12, 2011 at 3:22 pm
    Hi Barry, it's just a matter of seconds to add this enabled flag to the
    django webui, just let me know once it is in core.

    Am Dienstag, den 12.07.2011, 11:10 -0400 schrieb Barry Warsaw:
    On Jul 11, 2011, at 06:37 PM, Paul Wise wrote:

    With our current setup the disabled (or "graveyarded") list is removed
    from the /var/lib/mailman/lists dir and the aliases regenerated, so
    the MTA bounces messages to it and the admin interface for it cannot
    be logged into. Disabled lists are listed in a separate page in the
    web interface to the normal listinfo page. Some disabled lists might
    get their archives removed and some not.
    I think this approach would actually be fairly easy to implement in the core,
    with additional ui considerations in the new web ui. It could be a matter of
    just adding the .enabled flag to mailing lists, and re-running the MM3 moral
    equivalent of genaliases when that flag changes. All the data associated with
    the mailing list would remain in the database.

    The web ui would then look at the .enabled flag to decide where and how to
    display the mailing list information, and whether to allow logins, etc. But
    it would still be able to get (and probably set) attributes on the mailing
    list.
    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.
    Should you still be able to contact a disabled list's owners? I think if
    you're just going to bounce messages addressed to mydisabledlist-*@example.com
    and the text is static, then it's probably best to point those aliases to a
    very simple replybot service (I have one I've been toying with) so it doesn't
    increase the load on Mailman.

    -Barry
    _______________________________________________
    Mailman-Developers mailing list
    Mailman-Developers at python.org
    http://mail.python.org/mailman/listinfo/mailman-developers
    Mailman FAQ: http://wiki.list.org/x/AgA3
    Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
    Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/benedict.stein%40googlemail.com

    Security Policy: http://wiki.list.org/x/QIA9

    --

    Einen sch?nen Tag w?nscht:
    Benedict Stein


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: This is a digitally signed message part
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110712/5cbf31b1/attachment.pgp>
  • Paul Wise at Jul 13, 2011 at 2:51 pm

    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.

    --
    bye,
    pabs
  • Benedict Stein at Jul 13, 2011 at 3:20 pm
    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?pageId960560

    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


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: This is a digitally signed message part
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110713/add38c19/attachment.pgp>
  • Benedict Stein at Jul 13, 2011 at 4:15 pm
    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?pageId960560

    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




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: This is a digitally signed message part
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110713/f592c825/attachment.pgp>
  • Barry Warsaw at Jul 15, 2011 at 7:24 pm

    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
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110715/cf4679f0/attachment.pgp>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-developers @
categoriespython
postedJul 10, '11 at 10:22p
activeJul 20, '11 at 10:38a
posts22
users8
websitelist.org

People

Translate

site design / logo © 2021 Grokbase