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:
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:
Because of the processing sequence in bin/newlist and
Mailman/Cgi/create.py The initial archive index page for a new list is
built with a link to the listinfo page with host name DEFAULT_URL_HOST
instead of the host name supplied to newlist with -u or the host name of
the create web page.
** Affects: mailman
Importance: Undecided
Status: New
--
Initial 'emptyarchive' page can have wrong host name in listinfo page link
https://bugs.launchpad.net/bugs/529100
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
The List-Post header should be retained by default in messages in the
MIME format digest to facilitate 'reply list' with MUAs that have that
feature.
** Affects: mailman
Importance: Undecided
Status: New
--
List-Post header should be retained in MIME digest messages
https://bugs.launchpad.net/bugs/526143
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
The version of Mailman distributed with Apple's Mac OS X Server has a
hacked up mailmanctl, primarily to support not daemonizing in the
launchd environment. (I think). Their hack is ugly, and it'd be nice
if it was made unnecessary.
** Affects: mailman
Importance: Undecided
Status: New
--
Need a 'no-daemonize' option for '/bin/mailman start'
https://bugs.launchpad.net/bugs/497968
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
It seems when mailman encounters an email address with an underscore
embedded in the user name that is sent from a non-member, the held
message gets stuck and won't accept accept, defer, reject or delete ie
xxx_xxx(a)domain.com.
Tested this by setting up test list, using default setup only changing
administrative email and adding one member to accept the forwarded
email.
When sending from non-member with xxx_xxx(a)domain.com, moderation web
page will accept radio button for action, but no action is taken. The
moderation web page for moderation is re-displayed with no action taken.
At that point if mailman get other requests from non-members even if
thay are other email addresses, mailman will append these to the held
messages file and they will all stack up with no way to delete them. I
now have 3 held messages in one of my lists. One underscore sandwiched
between 2 'normal' email addresses.
I have tried:
Setting held days with no help
Looking at each individually and trying to delete
Add user to the mebership list (the moderate screen will then show the moderated user as a member)
All with no change. The radio button is activated, submit is hit and
mailman takes no action and re-displays the moderator screen.
Bluehost has this loaded as a basic service and I cannot get to the
files to manually delete the held messages. At this point, the only
work around is to delete the entire list and start from default (painful
for a big list).
Thanks,
** Affects: mailman
Importance: Undecided
Status: New
--
Held Messages Won't Accept Action - Underscore in Email
https://bugs.launchpad.net/bugs/529550
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.