Mailman 3 November 2012 - Mailman-coders

[Bug 693134] [NEW] Uncaught bounce from Dovecot when Quota Exceeded
by JorSol June 20, 2013

June 20, 2013

Public bug reported: I have a Debian 5 (Lenny) server with Postfix - Dovecot and Mailman 2.1.11 and 1700+ users. The problem is when Dovecot returns the bounce message about "Quota exceeded", Mailman don't recognize the format: Your message to <user(a)domain.com> was automatically rejected: Quota exceeded It's suposed that Mailman recognize this type of message using the VERP feature, I have "recipient_delimiter = +" in Postfix but Mailman don't detect message coming from Dovecot. /var/log/mailman/bounce: Dec 21 10:58:08 2010 (3214) listnews: bounce message w/no discernable addresses: <dovecot-1292944464-47721-0@mail> Dec 21 10:58:08 2010 (3214) noticias: forwarding unrecognized, message-id: <dovecot-1292944464-47721-0@mail> ** Affects: mailman Importance: Undecided Status: New ** Tags: dovecot mailman postfix -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/693134 Title: Uncaught bounce from Dovecot when Quota Exceeded

4 13

[Bug 886296] [NEW] Improve DSN handling for google 'inactive' accounts
by Kevin Fenzi May 30, 2013

May 30, 2013

Public bug reported: The DSN bouncer handler can't seem to parse out when a bounce is generated due to an inactive google account. See attached bounce file for example. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/886296 Title: Improve DSN handling for google 'inactive' accounts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/886296/+subscriptions

3 8

[Merge] lp:~sunu0000/postorius/general_settings into lp:postorius
by Tarashish Mishra March 18, 2013

March 18, 2013

Tarashish Mishra has proposed merging lp:~sunu0000/postorius/general_settings into lp:postorius. Requested reviews: Mailman Coders (mailman-coders) Related bugs: Bug #1062877 in Postorius: "General Settings" https://bugs.launchpad.net/postorius/+bug/1062877 For more details, see: https://code.launchpad.net/~sunu0000/postorius/general_settings/+merge/1322… Added placeholder text for General Settings -- https://code.launchpad.net/~sunu0000/postorius/general_settings/+merge/1322… Your team Mailman Coders is requested to review the proposed merge of lp:~sunu0000/postorius/general_settings into lp:postorius.

3 3

[Bug 1074374] [NEW] REST API: Problems with addresses and memberships after deleting a user.
by Florian Fuchs Dec. 31, 2012

Dec. 31, 2012

Public bug reported: Hi Barry, I ran into some trouble after deleting a user account via the rest API. Apparently the user's address records were kept, which lead to two problems: - Memberships cannot be retrieved via rest any more. - The deleted user cannot be created again using any of their previous addresses. Steps to reproduce: 1) Create a user through the REST API 2) Delete that user through the REST API 3) Repeat step 1) (possibly because a person wants to register again after leaving) => 500 status code is returned through the REST -- ExistingAddressError is raised. 4) Access /3.0/addresses => Result still contains the email address used in 1). 5) Access /3.0/members => 500 status code is returned As a workaround, I tried to delete all the user's addresses through the API, but doing that returned 405 (Method not allowed). Wouldn't it be best to delete all address/membership records from the db when a user record is deleted? Cheers Florian ** Affects: mailman Importance: Undecided Assignee: Barry Warsaw (barry) Status: New ** Tags: mailman3 rest-api -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1074374 Title: REST API: Problems with addresses and memberships after deleting a user. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1074374/+subscriptions

2 3

[Bug 1073506] [NEW] Drop support for Python 2.6
by Barry Warsaw Dec. 31, 2012

Dec. 31, 2012

Public bug reported: Whenever the dependency stack is ported to Python 3, Mailman 3 will be ported to Python 3. In the meantime, making the code Python 2.7 -3 clean is an intermediate step toward Python 3 support. In order to do this, we really need to drop Python 2.6 support and this will also allow us to improve the test suite, as well as other code improvements. Besides, Python 2.6 is 4 years old and in security-only maintenance mode, while Python 2.7 is stable and still supported for bug fixes. ** Affects: mailman Importance: High Assignee: Barry Warsaw (barry) Status: In Progress ** Tags: mailman3 ** Changed in: mailman Status: New => Triaged ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Milestone: None => 3.0.0b3 ** Tags added: mailman3 ** Changed in: mailman Status: Triaged => In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1073506 Title: Drop support for Python 2.6 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1073506/+subscriptions

1 3

[Bug 1065447] [NEW] Feature request: REST api to verify password
by Dieter Maurer Dec. 31, 2012

Dec. 31, 2012

Public bug reported: "mailman" manages users with their individual passwords. It is supposed to be controlled via a REST api which uses a global (user independent) authentication. Obviously, an arbitrary user should not be allowed to change preferences (and other settings) for a different user. This implies that a REST client has to check user access rights and (especially) verify the user's identity. The typical way for user identity verification would be to check that the user knows the password registered with this user in "mailman". However, the REST api lacks a corresponding operation. The REST api should probably be extended by a "verify_password" user subresource. To avoid passwords being logged by typical webserver logging, the password to be verified should probably be submitted via "POST" (not transmitted as part of the "URL"). If the project does not want to go this route (password verification via a REST operation), then it must document how a client can verify a given cleartext password against the encrypted password information available as user attribute. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1065447 Title: Feature request: REST api to verify password To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1065447/+subscriptions

3 5

[Bug 1054730] [NEW] Set the verified_on flag for IAddress through the REST API
by Barry Warsaw Dec. 31, 2012

Dec. 31, 2012

Public bug reported: IAddress.verified_on is how the core knows whether the registered address has been verified or not. Because Postorius supports registration via BrowserID, and by definition a BrowserID email address must be verified, we want to allow Postorius to set the verified_on field via the REST API. This probably won't be a direct value setting. Instead, I think you want to POST true or false to .../addresses/foo(a)example.com/verified and that will set IAddresses.verified_on to now() or to None. ** Affects: mailman Importance: High Assignee: Barry Warsaw (barry) Status: New ** Tags: mailman3 rest -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1054730 Title: Set the verified_on flag for IAddress through the REST API To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1054730/+subscriptions

1 3

[Bug 1047286] [NEW] Notifications for core events
by George Chatzisofroniou Dec. 31, 2012

Dec. 31, 2012

Public bug reported: It would be great if core could provide notifications for more events to support plugins or any new internal functionality like: - New subscription - New thread started Those two notifications seems to be essential for the MM3-Metrics module (https://launchpad.net/mm3-metrics) in order to provide a nice overview of the system activity. Also, the notification that the core currently provides is that of a new posting. If this notification carried more information like the number of recipients or the message size we could provide additional interesting metrics via the MM3-Metrics module. ** Affects: mailman Importance: Undecided Status: New ** Tags: events metrics modules notifications plugins -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1047286 Title: Notifications for core events To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1047286/+subscriptions

2 4

[Bug 1035033] [NEW] bin/mailman --help could be improved
by Stephen Turnbull Dec. 31, 2012

Dec. 31, 2012

Public bug reported: What the "reopen" command does is not at all clear. (Is it like "reload" in an init script, rereading config files? If so, maybe "reload" would be a better name.) Presumably the "restart" command stops *and* starts the runners. You can assign this to me (it would be appreciated if you'd tell me what reopen does, although I guess I could read the code. :-) ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1035033 Title: bin/mailman --help could be improved To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1035033/+subscriptions

2 4

[Bug 982551] [NEW] ./mailman.cfg only used partially
by Bernhard Schmidt Dec. 31, 2012

Dec. 31, 2012

Public bug reported: GNU Mailman 3.0.0b1+ (current bzr head). http://packages.python.org/mailman/src/mailman/docs/START.html#running- mailman-3 talks about ./mailman.cfg being used as configuration (among others). This seems to be only partially true. I put this mailman.cfg into /usr/local/mailman --- [database] class: mailman.database.postgresql.PostgreSQLDatabase url: postgres://mailman:mailman@xxx/mailman [shell] use_ipython: yes [mta] incoming: mailman.mta.postfix.LMTP outgoing: mailman.mta.deliver.deliver lmtp_host: mailout.xxx lmtp_port: 8024 smtp_host: mailout.xxx smtp_port: 25 [runner.nntp] start: no --- and started bin/mailman start. The PostgreSQL database was initialized, bin/mailman status showed the correct configuration location. I could create lists and they were added in the SQL database. It would use ipython as shell. But it would still try to send mail through localhost, and it would still start the nntp runner. And LMTP would reject mails to the existing lists with "mailbox unavailable". So it seems the configuration was only used by the main process, but not by the runners. Moving the configuration to a non-relative location fixed it. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/982551 Title: ./mailman.cfg only used partially To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/982551/+subscriptions

2 7