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:
Not sure what caused this error that showed up in mailman.log:
Aug 16 10:54:50 2011 (31400) Uncaught runner exception: u'foo.example.com'
Aug 16 10:54:50 2011 (31400) Traceback (most recent call last):
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration
self._process_one_file(msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/runners/virgin.py", line 37, in _dispose
process(mlist, msg, msgdata, 'virgin')
File "/home/sgoss/mailman_clone/src/mailman/core/pipelines.py", line 50, in process
handler.process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 360, in process
process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 202, in process
listinfo = mlist.script_url('listinfo')
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 243, in script_url
return urljoin(self.domain.base_url, target + '/' + self.fqdn_listname)
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 227, in domain
return getUtility(IDomainManager)[self.mail_host]
File "/home/sgoss/mailman_clone/src/mailman/model/domain.py", line 142, in __getitem__
raise KeyError(email_host)
KeyError: u'foo.example.com'
** Affects: mailman
Importance: Undecided
Status: New
** 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/827547
Title:
KeyError in "virgin" runner.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/827547/+subscriptions
Public bug reported:
You can subscribe an address to a mailing list, and you can subscribe a
user to a mailing list, if the user has a preferred address. There are
two problems with this.
* You can actually end up getting doubly subscribed (i.e. same address
with the same role). Normally, the subscription mechanism prevents you
from subscribing the same address with the same role more than once, or
the same user with the same role more than once. However, if you
subscribe once by the address, and once by the user whose preferred
address is that same address, the double subscription occurs.
* The Member repr() doesn't distinguish between a member that's
subscribed via explicit address, and one that's subscribed via preferred
address. This means that the above will appear as a double address
subscription, when it's really not.
Are these substantial problems that need to be fixed? Almost certainly
the second one does, but I haven't come up with an elegant repr() for
the case of a user subscribed with their preferred address.
** Affects: mailman
Importance: Low
Status: Confirmed
** 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/837700
Title:
Issues with users subscribed via their preferred address
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/837700/+subscriptions
Public bug reported:
I have a large number of subscriptions to mailing lists on python.org.
Delivery is disabled on most of them. This is exactly how I want it --
I don't want to keep up with the day to day matters of the list, but I
do want to be able to re-anable delivery and discuss things there should
the need arise without having to create a new account.
However, when I go on vacation, what I want to do is also disable a few high volume lists that I normally want
to read every day. Thus what I would really like to see is which lists are currently enabled, so I can decide
which one(s) if any I want to disable for the vacation. I don't want to disable the low-volume ones. Given
that I am going to have to re-enable the lists I want to read when I get back one by one, I want the number of lists that get temporarily disabled to be as small as possible. And I want to be able to email me the short list of what they were so I can remember which ones to turn on again.
Interestingly, the text of the message indicates a usability
misunderstanding, and a grammatical error. The text reads:
You can view a list of all the other mailing lists at python.org for which you are a member.
Use this if you want to make the same membership option changes to this other subscriptions.
It should be 'these other subscriptions'.
And the people who want to make the same membership option changes to all the lists they are subscribed to on a site are precisely the users who don't need the feature. They can blindly go off and change things
globally. If the number of lists they are subscribed to on that site is 1 -- i.e. they do not have any other subscriptions -- then saying to do things globally will do no harm.
The reason you might want to look is to check because you might _not_ want to do things globally. And once you are dealing with that case, things you do not want to do globally, then of course you want to see the
current settings that you have. But for my use case, all I care about is changing delivery status. All the
other options I either never change, or want to change globally. I suspect that most people use mailing
lists in this way, where the only thing they need to worry about is changes due to vacation, but I haven't
conducted any polls to test this theory.
This request sent to the tracker because the automated mail I recevied when some moderator refused
to accept my mail to mailman-dev with this feature request, with the message 'why don't you just disable delivery globally and then reset them globally when you return' said that this was the place for feature requests and not the mailing list. Hope this request is clearer and explains why globally disabling is not
what I want to do.
Thank you
** 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/793669
Title:
feature request. change the 'list my other subscriptions' to also
report if the other subscriptions are enabled or disabled
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.