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:
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.
Public bug reported:
As reported by Adrian von Bidder to Debian:
Please consider this trivial patch, which exposees message-ids to the
templates used for the email archive.
See it in action on lists.debian.ch. (I don't think my modification to
the templates should be in, but having te message-id exposed would mean
I won't have to remember to patch mailman on every update...)
(AFAICT mailman adds a Message-Id when an incoming email doesn't have
one, so this should never be a problem.)
** Affects: mailman
Importance: Undecided
Status: New
** Affects: mailman (Debian)
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/725498
Title:
expose message-id to templates
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