Public bug reported:
I have a large number of subscriptions to mailing lists on python.org.
Delivery is disabled on most of them. This is exactly how I want it --
I don't want to keep up with the day to day matters of the list, but I
do want to be able to re-anable delivery and discuss things there should
the need arise without having to create a new account.
However, when I go on vacation, what I want to do is also disable a few high volume lists that I normally want
to read every day. Thus what I would really like to see is which lists are currently enabled, so I can decide
which one(s) if any I want to disable for the vacation. I don't want to disable the low-volume ones. Given
that I am going to have to re-enable the lists I want to read when I get back one by one, I want the number of lists that get temporarily disabled to be as small as possible. And I want to be able to email me the short list of what they were so I can remember which ones to turn on again.
Interestingly, the text of the message indicates a usability
misunderstanding, and a grammatical error. The text reads:
You can view a list of all the other mailing lists at python.org for which you are a member.
Use this if you want to make the same membership option changes to this other subscriptions.
It should be 'these other subscriptions'.
And the people who want to make the same membership option changes to all the lists they are subscribed to on a site are precisely the users who don't need the feature. They can blindly go off and change things
globally. If the number of lists they are subscribed to on that site is 1 -- i.e. they do not have any other subscriptions -- then saying to do things globally will do no harm.
The reason you might want to look is to check because you might _not_ want to do things globally. And once you are dealing with that case, things you do not want to do globally, then of course you want to see the
current settings that you have. But for my use case, all I care about is changing delivery status. All the
other options I either never change, or want to change globally. I suspect that most people use mailing
lists in this way, where the only thing they need to worry about is changes due to vacation, but I haven't
conducted any polls to test this theory.
This request sent to the tracker because the automated mail I recevied when some moderator refused
to accept my mail to mailman-dev with this feature request, with the message 'why don't you just disable delivery globally and then reset them globally when you return' said that this was the place for feature requests and not the mailing list. Hope this request is clearer and explains why globally disabling is not
what I want to do.
Thank you
** 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/793669
Title:
feature request. change the 'list my other subscriptions' to also
report if the other subscriptions are enabled or disabled
Public bug reported:
In Mailman Membership Management, I would like to option to filter
search results by status viz (hide,nomail [reason], ack, not metoo,
nodupes, digest, plain)
** 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/707295
Title:
Membership Management Better Search Function
Public bug reported:
Feature request
Mailman 3 should try to fuzzily match unknown author addresses against
the member database. For example, if "turnbull(a)sk.domain.tld" is
subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same
person. This could probably be efficiently implemented by storing
domains in bigendian order, and testing for prefixes. Bonus points for
matching on full name. For example, for me personally
firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which
could not be reasonably associated by algorithm, but I always use the
same full name, which would be strong indication that it's me. Possibly
matching on mailbox would also be useful, but only as an optimization to
be confirmed by one of the other two (or maybe if the match is unique?)
Note that for the first example, the second "turnbull@shako" variant is
today used only by spammers; I haven't sent a message with that "From"
since 1995, and I doubt it's been used as "Sender" more than a very
small handful of times since 2000. For this reason, the feature should
*never* be automated. Instead, it should be part of the moderation
interface. If a match is detected, then an option should appear saying
something like "This address appears to be an alias for <member name and
address>. [ ] Add <unknown address> as an alias for <member>."
** Affects: mailman
Importance: Undecided
Status: New
** Description changed:
Feature request
Mailman 3 should try to fuzzily match unknown author addresses against
the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is
subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same
person. This could probably be efficiently implemented by storing
domains in bigendian order, and testing for prefixes. Bonus points for
matching on full name. For example, for me personally
firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which
could not be reasonably associated by algorithm, but I always use the
same full name, which would be strong indication that it's me. Possibly
matching on mailbox would also be useful, but only as an optimization to
be confirmed by one of the other two (or maybe if the match is unique?)
Note that for the first example, the second "turnbull@shako" variant is
today used only by spammers; I haven't sent a message with that "From"
since 1995, and I doubt it's been used as "Sender" more than a very
small handful of times since 2000. For this reason, the feature should
*never* be automated. Instead, it should be part of the moderation
interface. If a match is detected, then an option should appear saying
something like "This address appears to be an alias for <member name and
- address>. [ ] Add <unknown> address as an alias for <member>."
+ address>. [ ] Add <unknown address> as an alias for <member>."
** Description changed:
Feature request
Mailman 3 should try to fuzzily match unknown author addresses against
- the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is
- subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same
+ the member database. For example, if "turnbull(a)sk.domain.tld" is
+ subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same
person. This could probably be efficiently implemented by storing
domains in bigendian order, and testing for prefixes. Bonus points for
matching on full name. For example, for me personally
firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which
could not be reasonably associated by algorithm, but I always use the
same full name, which would be strong indication that it's me. Possibly
matching on mailbox would also be useful, but only as an optimization to
be confirmed by one of the other two (or maybe if the match is unique?)
Note that for the first example, the second "turnbull@shako" variant is
today used only by spammers; I haven't sent a message with that "From"
since 1995, and I doubt it's been used as "Sender" more than a very
small handful of times since 2000. For this reason, the feature should
*never* be automated. Instead, it should be part of the moderation
interface. If a match is detected, then an option should appear saying
something like "This address appears to be an alias for <member name and
address>. [ ] Add <unknown address> as an alias for <member>."
--
Mailman 3 member functions should "guess" address membership
https://bugs.launchpad.net/bugs/514625
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
In mailman 3.0.0a8, the locales directory contains actually mailman 2 translations.
The unsubscribe mail is not translated into French because the msgids are different between mailman2 and mailman3.
Do you have a script to generate a pot file and sync the po files?
I had to generate myself the French mo file from the po. It's maybe a
good idea to include mo files in the sdist, or generate mo files at
mailman startup.
** 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/881320
Title:
Mailman 3 translations
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/881320/+subscriptions
Public bug reported:
As discussed, confusion can arise between the archiving module for
mailman, and the manual mechanism of adding the archiving subscriber. Do
something, perhaps involving ban lists, to keep us out of trouble.
(I don't really know what is most sensible. I'd always imagined the
archiving module would simply be adding the special subscriber address,
but that's not the way it turned out.)
** 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/987019
Title:
special case archive(a)mail-archive.com
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/987019/+subscriptions
Public bug reported:
Currently, we define the X-Message-ID-Hash as the base32 encoding of the
sha1 hash of the Message-ID content (sans angle brackets as defined in
RFC 5322). The suggestion is made that List-Post value should be added
to this hash so as to be able to distinguish cross-posted messages.
This should be fine, and pretty easy. My only concern is that the
header name is now a misnomer.
I wonder, is it worth coming up with a better header? Now's the time to
do it since it's likely that there are almost no consumers of this
standard.
What about `Permalink-Hash` ?
** Affects: mailman
Importance: High
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/985149
Title:
Add List-Post value to permalink hash input
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/985149/+subscriptions
Public bug reported:
At the moment the LMTP runner rejects mails to non-existing lists after
the DATA stage.
# telnet localhost 8024
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.svr02.mucip.net Python LMTP runner 1.0
MAIL FROM: <berni(a)birkenwald.de>
250 Ok
RCPT TO: <thislistdoesnotexist(a)birkenwald.de>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Message-ID: <bal(a)blubb.de>
as
.
550 Requested action not taken: mailbox unavailable
It should reject invalid addresses in the RCPT TO stage, this way it
could easily be used with Postfix' feature "reject_unverified_recipient"
to avoid accepting and then bouncing messages.
** 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/982555
Title:
LMTP should reject unknown lists in RCPT-stage
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/982555/+subscriptions
Public bug reported:
It seems useful to record the list style that was used to create the
mailing list. Maybe this could be used later to propagate changes in
the style to lists that were created with it.
The problem is that the style machinery is way to over-engineered.
There's actually a priority system for applying a style to a mailing
list. This should be simplified anyway, and then we could store the
style name in the database. It makes no sense to do this with the
complicated scheme currently used.
** Affects: mailman
Importance: High
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/975711
Title:
Store the list style in the mailinglist table
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975711/+subscriptions
Public bug reported:
Sphinx is required to build the documentation.
However, it is not automatically installed
and the installation documentation fails to instruct that it be installed before building the online docs.
** 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/975670
Title:
Documentation fails to specifying sphinx requirement
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975670/+subscriptions
Public bug reported:
This page:
http://packages.python.org/mailman/src/mailman/docs/START.html
describes how to install, configure, and start Mailman 3. It's a bit
sparse and out-of-date. For example, it doesn't describe all the
locations that mailman.cfg is search for. It also doesn't describe
installing and running mm3 in a virtualenv. This would make a nice
bite-sized bug for someone wanting to contribution to Mailman.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: documentation easy mailman3
** Tags removed: bite-size
** Tags added: easy
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/965520
Title:
Improve installation documentation
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/965520/+subscriptions