Public bug reported:
Setting localhost in postfix_lmtp works against Postfix defaults and
breaks delivery.
Reason: The Postfix lmtp client only uses dns queries by default to
search for hostnames. If the DNS server does not provide an answer for
"localhost" delivery from the lmtp client to mailman fails.
Solution: Provide "127.0.0.1" instead of "localhost". This does not
require DNS and is even faster because it saves DNS lookups.
Example:
hey2(a)mailman.state-of-mind.de
lmtp:[localhost.localdomain]:8024
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 3.0 mailman
--
setting localhost in postfix_lmtp breaks delivery
https://bugs.launchpad.net/bugs/544477
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
If the original message is multipart but not multipart/alternative and
content filtering removes all but one part, the message is left as a
multipart message with only the one sub-part instead of being recast as
just the sub-part.
This can cause msg_header and/or msg_footer to be added as separate
parts to a text/plain message instead of being added to the text/plain
body part.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: Triaged
** Changed in: mailman
Importance: Undecided => Medium
** Changed in: mailman
Status: New => Triaged
** Changed in: mailman
Milestone: None => 2.1.15
** Changed in: mailman
Assignee: (unassigned) => Mark Sapiro (msapiro)
** Description changed:
- If the original message in multipart but not multipart/alternative and
+ If the original message is multipart but not multipart/alternative and
content filtering removes all but one part, the message is left as a
multipart message with only the one sub-part instead of being recast as
just the sub-part.
This can cause msg_header and/or msg_footer to be added as separate
- parts to a text/plain message instead if being added to the text/plain
+ parts to a text/plain message instead of being added to the text/plain
body part.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/701558
Title:
Content filtering leaves a single sub-part in a multipart message.
Public bug reported:
Collapsing multipart/alternative parts to just the first alternative
only works if the message itself is multipart/alternative, or the
multipart/alternative part is at the first sub-level.
For example, given this structure:
multipart/mixed
| multipart/related
| | multipart/alternative
| | | text/plain
| | | text/html
| | image/jpeg
| application/msword
The multipart/alternative part will not be collapsed.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** Changed in: mailman
Importance: Undecided => Medium
** Changed in: mailman
Status: New => In Progress
** Changed in: mailman
Milestone: None => 2.1.14
** Changed in: mailman
Assignee: (unassigned) => Mark Sapiro (msapiro)
--
Content filtering fails to collapse alternatives.
https://bugs.launchpad.net/bugs/576675
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
If Content filtering accepts both message/rfc822 and
multipart/alternative MIME parts, and a message/rfc822 part contains a
message whose content type is multipart/alternative and
collapse_alternatives is Yes, the headers of the message in the
message/rfc822 part will be lost.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** 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/757062
Title:
Content filtering can remove the headers from a message/rfc822 part.
*** This bug is a security vulnerability ***
Private security bug reported:
We may have to set lifetime for input forms because of recent activities
on cross-site request forgery (CSRF). The form lifetime is successfully
deployed in frameworks like web.py or plone etc. Proposed branch
lp:~tkikuchi/mailman/form-lifetime implement lifetime in admin, admindb,
options and edithtml interfaces. Other forms like create and rmlist
have confirmation by password thus are safe regarding CSRF. The form
generation time is set by a hidden parameter whose value is calculated
following the mailman cookie algorithm. The default lifetime is set 1
hour in Default.py thus configurable by a site administrator. If a
password is set in request, authorization cookie is discarded so the
password authentication is forced. Wget tricks to manage list in FAQ
can be used as they are now.
** Affects: mailman
Importance: Undecided
Status: New
** Branch linked: lp:~tkikuchi/mailman/form-lifetime
--
You received this bug notification because you are a member of Mailman
Coders, which is a direct subscriber.
https://bugs.launchpad.net/bugs/775294
Title:
Set lifetime for input forms
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:
The test program reports an error if it detects an existing mailman.cfg:
Failure in test test_current_working_directory (mailman.tests.test_configfile.TestConfigFileSearch)
Traceback (most recent call last):
File "/usr/lib/python2.6/unittest.py", line 279, in run
testMethod()
File "/root/mailman/src/mailman/tests/test_configfile.py", line 107, in test_current_working_directory
self.assertEqual(found, config_file)
File "/usr/lib/python2.6/unittest.py", line 350, in failUnlessEqual
(msg or '%r != %r' % (first, second))
AssertionError: '/etc/mailman.cfg' != u'/tmp/tmpVfAIyB/home/alex/mailman/hacking/mailman.cfg'
I believe it should not do this. It should either silently ignore the
difference or use the test mailman.cfg or ... but not break.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 3.0 mailman
--
test breaks if existing mailman.cfg is found
https://bugs.launchpad.net/bugs/543618
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
Postfix has a very handy command called postconf(1) which lets you dump
all or one Postfix configuration variable. It would be very handy for
Mailman 3 to have something similar.
** Affects: mailman
Importance: Medium
Assignee: Barry Warsaw (barry)
Status: Triaged
** Affects: mailman/3.0
Importance: Medium
Assignee: Barry Warsaw (barry)
Status: Triaged
** Also affects: mailman/3.0
Importance: Medium
Assignee: Barry Warsaw (barry)
Status: Triaged
--
Add the equivalent of postconf(1)
https://bugs.launchpad.net/bugs/518517
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
List Moderator logins currently prompt for list moderator password only.
It would be good idea if prompt for username/password login as well.
Mailman: 2.1.9
** Affects: mailman
Importance: Undecided
Status: New
--
List Moderator Login should check for username
https://bugs.launchpad.net/bugs/674352
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.