Public bug reported:
`bin/mailman create` has a -d option which says to create the domain of
the new mailing list's posting address if it doesn't already exist. At
Pycon it was observed that it was kind of silly to always have to
specify -d and that maybe it should be the default. The reason I didn't
do that was because of typos, which would be a bit of work to undo.
Maybe once we have list renaming exposed, this would be useful. But I'm
still not sure.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: easy mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975703
Title:
-d should (maybe) be the default for `bin/mailman create`
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975703/+subscriptions
Public bug reported:
Stephen observed that it might be useful to implement a pipeline of
handlers (even chain processing?) for other runners such as archive,
bounce, and command. This is probably not something for 3.0 final, thus
I'm marking it triaged,low. But it's an interesting idea and may lead
to other useful refactoring.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975702
Title:
Implement a pipeline in other runners
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975702/+subscriptions
Public bug reported:
In Mailman 3, technically rules should not have side effects. The
'approved' rule breaks this because it removes the Approved header (and
other supported headers) from the message. There should instead be a
handler that does the header cleaning, and the rule should not do this.
>From an implementation standpoint, the same code can be used in both the
handler and in the rule. You can use a slightly different API wrapper
and use a flag to indicate whether the header should be removed or not.
OTOH, some clever refactoring might make better sense.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/973790
Title:
'approved' rule should not modify the message
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/973790/+subscriptions
Public bug reported:
At the simplest, it should support GET on a Message-ID or X-Message-ID-
Hash value and return the bytes of the stored message, or 404.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/967954
Title:
IMessageStore should be exposed as a top level REST resource
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/967954/+subscriptions
Public bug reported:
Adding to the documentation some graphs in graphviz format.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/953531
Title:
Add graphs of the overall architecture
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/953531/+subscriptions
Public bug reported:
The bin/disabled.py script needs tests, documentation, and fixing in
Mailman 2.
** Affects: mailman
Importance: High
Assignee: Barry Warsaw (barry)
Status: Confirmed
** Tags: mailman3
** Changed in: mailman
Status: New => Confirmed
** Changed in: mailman
Importance: Undecided => High
** Changed in: mailman
Milestone: None => 3.0.0b1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/937154
Title:
bin/disabled.py is nonfunctional
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/937154/+subscriptions
Public bug reported:
Digest messages are sent out with a partial set of headers for each message.
The list of headers kept for each plain-text digested message is configured by the setting:
PLAIN_DIGEST_KEEP_HEADERS = [
'Message', 'Date', 'From',
'Subject', 'To', 'Cc',
'Message-ID', 'Keywords',
'Content-Type',
]
My users are very perplexed and frustrated by the e-mail headers
included in the digest - in particular, the Message-ID and Content-Type
are meaningless, and the To header is repetitive. All this "noise"
clutters up the content and makes the digest harder to read.
Given that this is a plain-text digest, with the headers listed in the
message body, I don't really see an RFC issue here? Yet they can only
be configured using a list-wide override in mm_cfg.py
I would be willing to work on this to allow a list admin to override the plain digest headers using the web interface, but want to hear from the development team if this is a patch they would be willing to consider before I invest the time.
thanks.
** 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/889635
Title:
Per-list configurable message headers for digests
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/889635/+subscriptions
Public bug reported:
When the LMTP runner or any other injection vector receives a message,
it should add a Received header to indicate the time at which Mailman
got the message. Use case: there is a spam filter between the incoming
MTA and Mailman, and the message sits in the spam filter for a while
before its administrator accepts the message.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
** Tags added: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/885715
Title:
Mailman should add a Received header
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/885715/+subscriptions
Public bug reported:
I am running Mailman 3 in a virtualenv with most of its package
dependencies installed through pip. In this particular configuration, if
I run `buildout`, the test script that is created cannot seem to load
zope.testrunner properly:
$ bin/test -vv
Traceback (most recent call last):
File "bin/test", line 35, in <module>
import zope.testrunner
ImportError: No module named testrunner
The workaround is to remove the eggs folder, pip install
zope.testrunner, and then re-run buildout.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/869347
Title:
bin/test script fails unless zope.testrunner is pip installed
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/869347/+subscriptions
Public bug reported:
You can subscribe an address to a mailing list, and you can subscribe a
user to a mailing list, if the user has a preferred address. There are
two problems with this.
* You can actually end up getting doubly subscribed (i.e. same address
with the same role). Normally, the subscription mechanism prevents you
from subscribing the same address with the same role more than once, or
the same user with the same role more than once. However, if you
subscribe once by the address, and once by the user whose preferred
address is that same address, the double subscription occurs.
* The Member repr() doesn't distinguish between a member that's
subscribed via explicit address, and one that's subscribed via preferred
address. This means that the above will appear as a double address
subscription, when it's really not.
Are these substantial problems that need to be fixed? Almost certainly
the second one does, but I haven't come up with an elegant repr() for
the case of a user subscribed with their preferred address.
** Affects: mailman
Importance: Low
Status: Confirmed
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/837700
Title:
Issues with users subscribed via their preferred address
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/837700/+subscriptions