From mark at msapiro.net Mon Dec 5 14:48:25 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 05 Dec 2016 19:48:25 -0000
Subject: [Bug 1647450] Re: bin/add_members causes NameError when
DISABLE_COMMAND_LOCALE_CSET = yes
References: <20161205190734.25729.4237.malonedeb@wampee.canonical.com>
Message-ID: <20161205194825.29354.45132.malone@gac.canonical.com>
Thank you for the report and patch. I have applied the patch for the
next release.
** Changed in: mailman
Importance: Undecided => Low
** Changed in: mailman
Status: New => Fix Committed
** Changed in: mailman
Milestone: None => 2.1.24
** Changed in: mailman
Assignee: (unassigned) => Mark Sapiro (msapiro)
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1647450
Title:
bin/add_members causes NameError when DISABLE_COMMAND_LOCALE_CSET =
yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1647450/+subscriptions
From futatuki at poem.co.jp Mon Dec 5 14:07:34 2016
From: futatuki at poem.co.jp (Yasuhito FUTATSUKI at POEM)
Date: Mon, 05 Dec 2016 19:07:34 -0000
Subject: [Bug 1647450] [NEW] bin/add_members causes NameError when
DISABLE_COMMAND_LOCALE_CSET = yes
Message-ID: <20161205190734.25729.4237.malonedeb@wampee.canonical.com>
Public bug reported:
On non ascii locale and DISABLE_COMMAND_LOCALE_CSET = yes,
bin/add_members get NameError because of uninitialized variable
Mailman.i18n._ctype_charset, which is used by Mailman.i18n.tolocale().
When DISABLE_COMMAND_LOCALE_CSET = yes, the function tolocale() is used
by bin/add_members only, so this affect only bin/add_members script.
** Affects: mailman
Importance: Undecided
Status: New
** Patch added: "least fix patch"
https://bugs.launchpad.net/bugs/1647450/+attachment/4787690/+files/i18n.py.leastfix.diff.txt
** Branch linked: lp:mailman/2.1
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1647450
Title:
bin/add_members causes NameError when DISABLE_COMMAND_LOCALE_CSET =
yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1647450/+subscriptions
From 266760 at bugs.launchpad.net Fri Dec 9 23:44:48 2016
From: 266760 at bugs.launchpad.net (Stephan)
Date: Sat, 10 Dec 2016 04:44:48 -0000
Subject: [Bug 266760] Re: moderation approval should send email notification
References: <20080905194239.1806.20962.launchpad@forster.canonical.com>
Message-ID: <20161210044448.23016.60231.malone@chaenomeles.canonical.com>
This is quite an issue for us since we had to configure 'emergency' =
'yes' due to spam with targeted spoofing of list member addresses.
Now, member posts are held without the poster being notified; they get
confused about what happened; they will re-post several times; until the
next day a moderator gets the digest of their piled-up posts.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/266760
Title:
moderation approval should send email notification
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/266760/+subscriptions
From 1648933 at bugs.launchpad.net Fri Dec 9 23:53:16 2016
From: 1648933 at bugs.launchpad.net (Stephan)
Date: Sat, 10 Dec 2016 04:53:16 -0000
Subject: [Bug 1648933] [NEW] admin_immed_notify=yes and
respond_to_post_requests=yes has no effect for member posts even when
emergency=yes
Message-ID: <20161210045316.16375.60016.malonedeb@soybean.canonical.com>
Public bug reported:
Our configuration includes 'admin_immed_notify' = 'yes', and 'respond_to_post_requests' = 'yes'.
Due to spam with targeted spoofing of list member addresses we had to configure 'emergency' = 'yes'.
But both the notifications to the moderators as well as the reply to the
poster informing them of the hold action only works for non-members!
Member posts are held without the poster being notified, they get
confused about what happened to their post, they will sometimes re-post
several times, until the next day a moderator gets the digest of their
piled-up posts.
** 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/1648933
Title:
admin_immed_notify=yes and respond_to_post_requests=yes has no effect
for member posts even when emergency=yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1648933/+subscriptions
From 266760 at bugs.launchpad.net Fri Dec 9 23:54:12 2016
From: 266760 at bugs.launchpad.net (Stephan)
Date: Sat, 10 Dec 2016 04:54:12 -0000
Subject: [Bug 266760] Re: moderation approval should send email notification
References: <20080905194239.1806.20962.launchpad@forster.canonical.com>
Message-ID: <20161210045412.16961.87111.malone@soybean.canonical.com>
I'm sorry, please disregard my comment #5. Our issue is somewhat
different, see https://bugs.launchpad.net/mailman/+bug/1648933
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/266760
Title:
moderation approval should send email notification
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/266760/+subscriptions
From mark at msapiro.net Sat Dec 10 00:15:58 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Dec 2016 05:15:58 -0000
Subject: [Bug 1648933] Re: admin_immed_notify=yes and
respond_to_post_requests=yes has no effect for member posts even when
emergency=yes
References: <20161210045316.16375.60016.malonedeb@soybean.canonical.com>
Message-ID: <20161210051558.12455.49823.malone@wampee.canonical.com>
** Patch added: "Patch to send notices for emergency moderation"
https://bugs.launchpad.net/mailman/+bug/1648933/+attachment/4789826/+files/Emergency.patch
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1648933
Title:
admin_immed_notify=yes and respond_to_post_requests=yes has no effect
for member posts even when emergency=yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1648933/+subscriptions
From mark at msapiro.net Sat Dec 10 00:18:50 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Dec 2016 05:18:50 -0000
Subject: [Bug 1648933] Re: admin_immed_notify=yes and
respond_to_post_requests=yes has no effect for member posts even when
emergency=yes
References: <20161210045316.16375.60016.malonedeb@soybean.canonical.com>
Message-ID: <20161210051850.12148.85986.malone@wampee.canonical.com>
As it says in the docstring in Mailman/Handlers/Emergency.py
"""Put an emergency hold on all messages otherwise approved.
No notices are sent to either the sender or the list owner for emergency
holds. I think they'd be too obnoxious.
"""
If you really want this, I've attached a patch that will do it.
** Changed in: mailman
Status: New => Won't Fix
** Changed in: mailman
Assignee: (unassigned) => Mark Sapiro (msapiro)
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1648933
Title:
admin_immed_notify=yes and respond_to_post_requests=yes has no effect
for member posts even when emergency=yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1648933/+subscriptions
From 1648933 at bugs.launchpad.net Sat Dec 10 07:46:42 2016
From: 1648933 at bugs.launchpad.net (Stephan)
Date: Sat, 10 Dec 2016 12:46:42 -0000
Subject: [Bug 1648933] Re: admin_immed_notify=yes and
respond_to_post_requests=yes has no effect for member posts even when
emergency=yes
References: <20161210045316.16375.60016.malonedeb@soybean.canonical.com>
Message-ID: <20161210124642.16961.87799.malone@soybean.canonical.com>
Wow, that was quick. I applied the patch and it does exactly what I
need: members and moderators are informed of held messages immediately.
Thank you very much!
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1648933
Title:
admin_immed_notify=yes and respond_to_post_requests=yes has no effect
for member posts even when emergency=yes
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1648933/+subscriptions
From stephen at xemacs.org Sun Dec 25 19:19:06 2016
From: stephen at xemacs.org (Stephen Turnbull)
Date: Mon, 26 Dec 2016 00:19:06 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161226001906.1121.48236.malone@soybean.canonical.com>
I believe the OP can get exactly the effect he wants by specifying a
DMARC policy record including "p=quarantine; pct=0". Mailman doesn't
(and arguably shouldn't) check the value of pct, let alone roll dice, on
p=quarantine or p=reject, so this policy will cause Mailman to mitigate
(if mitigation is available in that version of Mailman and requested by
the list admin). On the other hand, pct=0 means no conforming recipient
implementation will actually quarantine any messages. (Yes, pct=0 is
explicitly permitted by the RFC.) The vast majority of mail is covered
by conforming implementations according to DMARC.org testing (but I
don't know that this corner case was tested -- someone with a test
domain can do that easily enough, and if someone does, please report
whether it worked and which providers were tested to mailman-
users at python.org).
--
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
From jb-debbugs at wisemo.net Tue Dec 27 07:57:11 2016
From: jb-debbugs at wisemo.net (Jakob Bohm)
Date: Tue, 27 Dec 2016 12:57:11 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161227125711.536.88228.malone@wampee.canonical.com>
Stephen, using a different domain setting to compensate for mailman
misbehavior is the wrong way.
There is a DMARC RFC (technically Informational due to the bad state of
the relevant IETF WGs, as seen in the SPF/SenderID fiasco). This
explicitly states what proper e-mail software should and should not do
when a domain declares "p=none".
Mailman is intentionally disregarding the RFC and causing its default
behavior to cause problems for postmasters whose users are permitted to
participate in mailing lists, when the listmasters of those lists have
unfortunately chosen to use Mailman and follow whatever Mailman
documentation says is the suggested way to configure it. Fortunately,
some Mailman listmasters are waking up and choosing settings that are as
close to compliance as Mailman allows.
I am asking for RFC compliance and interoperability, not workarounds,
and especially not workarounds that need to be done by 3rd party
postmasters and depend on listmasters making non-default settings (such
as changing Mailman settings for domains with p=quarantine).
It is also worth noting that the restrictions imposed by DMARC (do not
forwarding mails with unchanged From header unless some other rules are
followed and applicable) is the unfortunate result of most common e-mail
MUA programs (At least Thunderbird and Outlook) failing to tell
recipients when the From: header differs from the MTA-checked envelope
from address, a limitation which has been exploited by spammers and
scammers for many many years with no MUA fix in sight.
--
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
From mark at msapiro.net Tue Dec 27 12:59:48 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 27 Dec 2016 17:59:48 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161227175948.14499.60847.malone@wampee.canonical.com>
Jakob writes "Mailman is intentionally disregarding the RFC and causing
its default behavior to cause problems for postmasters whose users are
permitted to participate in mailing lists ..."
I assume the RFC you are referring to is RFC 7960. I have read this RFC
and I do not draw the same conclusion. In particular, section 2,
paragraph 2 says
Note that domains that assert a "p=none" policy and email messages
that pass standard DMARC validation do not have any interoperability
issues.
which implies to me that it is not necessary to apply any mitigations to
messages From: domains publishing p=none.
Clearly you believe otherwise. Please identify specific RFC sections and
language that support your opinion.
The mitigations of modifying the From: header or wrapping the message
have negative consequences for users of at least some MUAs, so list
owners have incentives to apply them to as few messages as possible. We
are currently working on the mitigation strategy for Mailman 3 and have
decided at this point to not have controls over which policies trigger
mitigation, but when mitigating based on policy to apply mitigation for
p=reject and p=quarantine, and not p=none. If we are convinced that RFCs
say we SHOULD or MUST apply munge/wrap mitigations to messages from
p=none domains, we will do that, so please tell us why you think they
do.
--
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
From jb-debbugs at wisemo.net Thu Dec 29 11:19:35 2016
From: jb-debbugs at wisemo.net (Jakob Bohm)
Date: Thu, 29 Dec 2016 16:19:35 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161229161936.1274.14674.malone@soybean.canonical.com>
No, RFC 7489, specifically the configuration instructions in section
B.2.1
RFC 7960 at first glance (haven't read it end to end) seems to be an
attempt to document implementation status in mailing list software at
the time of publication.
--
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
From 1539384 at bugs.launchpad.net Thu Dec 29 11:59:12 2016
From: 1539384 at bugs.launchpad.net (Barry Warsaw)
Date: Thu, 29 Dec 2016 16:59:12 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161229165912.1379.32149.malone@soybean.canonical.com>
B.2.1 are just part of the examples, but even there it says: "Receivers
should not alter how they treat these messages because of this DMARC
policy record ("p=none")". This reinforces that no mitigations should
be applied to p=none.
--
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
From mark at msapiro.net Thu Dec 29 15:02:39 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 29 Dec 2016 20:02:39 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161229200239.3209.60742.malone@gac.canonical.com>
To elaborate on Barry's comment, RFC7849 defines DMARC and the policies
and reporting requests that domain managers can publish to implement
DMARC and the things that receivers of mail can do to implement the
published policies and reporting requests of From: domains. In this
context, Mailman is not a receiver, but rather is a mediator as defined
in section 5.3 of RFC5598 and discussed in section 5.2 of RFC7960.
I understand Jakob's issue and I understand that the implementation of
dmarc_none_moderation_action doesn't really solve that because it relies
on the cooperation of multiple third party mailing list operators to
enable it even though they have a disincentive to do so. It is precisely
because of this that that implementation is not being carried forward to
Mailman 3.
The underlying issue is that the original design of DMARC did not take
into account the role of mediators in mail delivery. RFC7960 is an
attempt to clarify the issues and suggest mitigations that mediators can
apply now and in the future, but none of this requires or even suggests
that a mediator should treat a p=none domain differently from a "no
policy" domain for purposes of applying DMARC mitigations.
I firmly believe Jakob's issue is with DMARC and not with Mailman and it
is not up to Mailman to fix it.
--
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
From jb-debbugs at wisemo.net Thu Dec 29 15:53:18 2016
From: jb-debbugs at wisemo.net (Jakob Bohm)
Date: Thu, 29 Dec 2016 20:53:18 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161229205319.2806.43887.malone@gac.canonical.com>
You are getting this all backwards.
While I agree that DMARC interacts badly with mailing lists in general,
writing mailing list software in ways that make this worse is not going
to help anybody.
DMARC as it exists today has a p=none feature which serves no other
known purpose than allowing postmasters to detect which, if any,
problems will occur for their particular domain, should they publish a
stricter policy.
This detection mission is completely frustrated if mailing lists that
are configured to *not* cause problems if DMARC is set to an active
policy continue cause false alarms in the p=none test mode.
I firmly believe that the wording about not taking different action for
"p=none" is directed only at recipients that would otherwise reject or
penalize mail based on the DMARC policy, not at mail forwarders deciding
if the e-mail should be handled in a DMARC-compatible way, e.g. by
enabling workarounds.
--
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
From mark at msapiro.net Thu Dec 29 18:12:51 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 29 Dec 2016 23:12:51 -0000
Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done
for p=none
References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com>
Message-ID: <20161229231251.3068.50815.malone@gac.canonical.com>
Clearly we disagree on this and I don't think either of us will convince
the other to change.
Mailman is trying to enable list owners to cope with DMARC in a way that
minimizes negative impacts on lists and their subscribers. This is an
evolving landscape. Some Microsoft services already are treating mail
with the same address in From: and To: as suspicious which impacts mail
currently DMARC mitigated by Mailman (as well as mail from anonymous
lists).
There are initiatives in progress to enable a mailing list to certify
that outgoing mail passed DMARC when it was received by the list
(Authenticated Received Chain and ). Thus, Mailman's handling of these things will
likely change in the future.
However, Mailman 2.1's DMARC mitigations are not likely to change, and
for the near term at least Mailman 3 is not going to apply mitigatations
to p=none mail unless the list owner chooses to apply mitigations to all
mail (similar to from_is_list in MM 2.1). Mailman developers believe
this is the correct approach and is RFC compliant.
--
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