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:
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:
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:
Approve follows SpamDetect in the default pipeline. If SpamDetect or
another custom or reordered handler preceding Approve holds a post
containing an Approve(d): header or pseudo-header, and that post is
approved, the Approve(d): header or pseudo-header will not be removed
from the delivered message.
** Affects: mailman
Importance: Undecided
Status: New
--
Approved: header not always removed
https://bugs.launchpad.net/bugs/501739
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
The tag <MM-Subscribe-Form-Start> which generates the <form> tag for the
subscribe form is in the <td> entry for the language form. This
generates invalid HTML which is a problem for at least some browsers.
There is also no DOCTYPE directive and other misplaced tags that cause
validation errors.
** Affects: mailman
Importance: Undecided
Status: New
--
listinfo.html templates have a misplaced form start tag
https://bugs.launchpad.net/bugs/514050
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
See the patches.
** Affects: mailman
Importance: Undecided
Status: New
--
An error in Simplified Chinese translation
https://bugs.launchpad.net/bugs/545772
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
Hi,
when someone come to the confirm page and enter his/her email-address,
the active button should be 'submit', not 'cancel'. Several people want
to press the enter-key to send the data, and in this case, he/she cancel
the progress.
Regards, Stefan
** Affects: mailman
Importance: Undecided
Status: New
--
Active button on /cgi-bin/mailman/confirm is 'cancel'
https://bugs.launchpad.net/bugs/530654
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.