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:
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:
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:
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
Public bug reported:
Most of the templates use a DOCTYPE of HTML 4.01 Transitional, but the
AST templates use HTML 3.2.
The patch updates the DOCTYPES for the AST templates.
** Affects: mailman
Importance: Undecided
Status: New
--
Templates for AST use inconsistent DOCTYPE
https://bugs.launchpad.net/bugs/500955
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
The DOCTYPE header for 2 files in the sk templates contain extra escape
characters around the quote marks.
** Affects: mailman
Importance: Undecided
Status: New
--
Extra escape characters in DOCTYPE
https://bugs.launchpad.net/bugs/500952
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
mailman Makefile should respect the LDFLAGS variable. See attached
patch.
** Affects: mailman
Importance: Undecided
Status: New
--
mailman should respect LDFLAGS
https://bugs.launchpad.net/bugs/637652
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.