Public bug reported:
If the case of the filename extension in the message doesn't agree with
that in *_filename_extension, they won't match. Matching should be case
insensitive.
** Affects: mailman
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** Affects: mailman/2.1
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: Fix Released
** Affects: mailman/3.0
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: In Progress
** Tags: mailman3
** Also affects: mailman/3.0
Importance: Medium
Assignee: Mark Sapiro (msapiro)
Status: Fix Released
** Also affects: mailman/2.1
Importance: Undecided
Status: New
** Changed in: mailman/3.0
Status: Fix Released => In Progress
** Changed in: mailman/3.0
Milestone: mailman-2.1 => 3.0.0b2
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/978351
Title:
Content Filtering *_filename_extension matches are case sensitive.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/978351/+subscriptions
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.
Public bug reported:
Trailing blanks on option "subject_prefix" are removed on subject lines
with non-ASCII characters. F.i., with options
preferred_language = "Français"
subject_prefix = "[prefix] "
(irrespective of encode_ascii_prefixes)
sending this (via Seamonkey Mail, LANG=en_US.UTF-8):
Subject: "[prefix] c'est du français"
results in reception of:
Subject: "[prefix]c'est du français"
** 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/1525954
Title:
mailman-2.1.20: option "subject_prefix": prefix trailing blanks are
removed when subject lines have non-ASCII characters
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1525954/+subscriptions
Public bug reported:
If you read the DMARC informational RFC (no longer just a draft), you
will see that there are 3 possible policies a mail domain (of a poster)
can set
p=reject All recipients should reject/drop mails with From: ...<at
ourdomain> that have neither DKIM not SPF pass for our ourdomain. Send
automatic reports of this to our postmaster at the specified rua
address.
p=quarantine All recipient spam filters should penalize ditto. Send
the same automatic reports.
p=none Recipients should act as if this policy was not there, but send
the automatic reports so we can decide if our policy needs fine tuning
before switching to a tougher p value.
Currently Mailman 2.1.20+ has code that applies reasonable adjustments
to avoid failures with posters from p=reject domains (such as Yahoo).
Mailman 2.1.20+ also has an option to do the same for p=quarantine.
But when a domain is set to p=none because the postmaster is trying to
figure out what will break if he/she/they turn on quarantine, Mailman
will continue sending mail in a way which causes all the backscatter
reports from everybody except the list owner.
As a postmaster I find this very annoying as it makes it hard to find
actual problems in the flurry of backscatter noise from making even a
few posts to a single Mailman list. Especially annoying is reports that
some servers received mails with failed DKIM from a 4th party IP, as it
is impossible to tell if those 4th parties were forwarding mails that
were broken by Mailman munging the Subject header or were handling mails
of some other kind needing a different correction.
I would therefore suggest the following change to the 2.1 branch (since
3.x is still not in a usable state):
* If dmarc_moderation_action is set to a value other than Reject or
Discard, the specified mitigation should be applied to domains with any
valid DMARC policy, not just reject.
The effect of this would be:
+ List admins need to do nothing extra, since this works with the
existing Mailman settings.
+ Domains that use p=none with a user posting to a list with action
other than Reject/Discard will see the true effects that setting
p=reject would have, and their users will see any change in the Mailing
list behavior and be able to complain to the local postmaster before the
domain goes to p=reject. Which is exactly the intended purpose of
p=none.
+ Domains that use p=none with a user posting to a list with action set
to Reject/Discard will receive a flurry of error reports reflecting how
badly things will break if they go to p=reject, but the users will not
loose their ability to post (because the reject/discard action is not
applied to domains with p=none). Again this is consistent with the
intended purpose of p=none.
+ Domains that use p=quarantine with a user posting to a list that has
not set dmarc_quarantine_moderation_action will see the same effects as
domains that use p=none (see above).
+ Domains that use p=quarantine with a user posting to a list that has
set dmarc_quarantine_moderation_action will see the same behavior as
for the current 2.1.20 code.
+ Domains that use p=reject will see the same behavior as for the
current 2.1.20 code.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: dmarc
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1539384
Title:
Non-blocking DMARC mitigations should also be done for p=none
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions
*** 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:
A number of .html and .txt templates can be edited via the web admin GUI
to create/update list specific versions of them. Any templates can be
edited to make list specific, domain specific or sitewide edited
versions, but this requires a level of access that many list admins
don't have. The templates that can currently be edited via the web admin
GUI are:
('listinfo.html', _('General list information page')),
('subscribe.html', _('Subscribe results page')),
('options.html', _('User specific options page')),
('subscribeack.txt', _('Welcome email text file')),
('masthead.txt', _('Digest masthead')),
The following would be useful additions to that list:
('postheld.txt', _('User notice of held post')),
('approve.txt', _('User notice of held subscription')),
('refuse.txt', _('Notice of post refused by moderator')),
('invite.txt', _('Invitation to join list')),
('verify.txt', _('Request to confirm subscription')),
('unsub.txt', _('Request to confirm unsubscription')),
('nomoretoday.txt', _('User notice of autoresponse limit')),
('postack.txt', _('User post acknowledgement')),
('disabled.txt', _('Subscription disabled by bounce warning')),
('admlogin.html', _('Admin/moderator login page')),
('private.html', _('Private archive login page')),
('userpass.txt', _('On demand password reminder')),
** Affects: mailman
Importance: Wishlist
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1583387
Title:
Allow list admin to edit more templates.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1583387/+subscriptions
Public bug reported:
The list attribute nonmember_rejection_notice is given as the reason for
an automatic rejection because the poster is in reject_these_nonmembers
or generic_nonmember_action is Reject.
It would be nice if this were also the default reject reason for a held
nonmember post.
** Affects: mailman
Importance: Wishlist
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1572330
Title:
RFE, make nonmember_rejection_notice if any the default admindb reject
reason for a nonmember post
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1572330/+subscriptions
Public bug reported:
bin/list_lists and the listinfo and the admin CGIs call
Utils.list_names() to get the names of all lists. They then instantiate
each list to determine if it meets the conditions for listing. It is
possible, particularly in installations with a large number of lists,
that a list can be deleted after its name is retrieved and before it is
instantiated. Instantiation then throws MMUnknownListError. This should
be caught in a try: and the list ignored.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1582532
Title:
bin/list_lists and both the listinfo and admin CGI overviews can throw
MMUnknownListError
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1582532/+subscriptions
Public bug reported:
If for some reason a site doesn't want to or can't access a
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL, maybe the site is IPv6 only and
there is no IPv6 source of the data, the site should be able to set
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL to None or a null string and avoid
the attempted retrieval, the failure of which causes other issues.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1578450
Title:
Mailman should allow setting DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL to
None or a null string.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1578450/+subscriptions
Public bug reported:
To debug low level smtplib failures, one can modify SMTPDirect.py to
enable debugging. There should be an mm_cfg.py setting for this.
** Affects: mailman
Importance: Low
Assignee: Mark Sapiro (msapiro)
Status: In Progress
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1573074
Title:
Provide a better way to enable smtplib debugging.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1573074/+subscriptions