Mailing lists sometimes do not honor moderation_action of non-members
We notice that sometimes mailing lists do not honor moderation_action of non-members. Instead, it follows the default action of the lists. It looks like we can sometimes fix the issue by adding/removing the non-members or adding/removing them as owner in certain order but we are not sure about exactly what we have to do. So, it looks like that it is not caused by the list configuration. We have already verified from the web UI, mailman client and the DB table member that moderation_action of the corresponding non-members are set correctly. Any clues for us to provide further information to troubleshoot the issue and any recommended workaround to get around the issue? Thanks a lot.
On 10/31/19 2:21 AM, Alan So wrote:
We notice that sometimes mailing lists do not honor moderation_action of non-members. Instead, it follows the default action of the lists. It looks like we can sometimes fix the issue by adding/removing the non-members or adding/removing them as owner in certain order but we are not sure about exactly what we have to do. So, it looks like that it is not caused by the list configuration. We have already verified from the web UI, mailman client and the DB table member that moderation_action of the corresponding non-members are set correctly. Any clues for us to provide further information to troubleshoot the issue and any recommended workaround to get around the issue? Thanks a lot.
Reasons why a post From: a non-member would not be treated according to that non-members moderation_action include the following:
If any address in any of the places configured in mailman -> sender_headers (default = From: header, envelope sender, Reply-To: header, Sender: header) is that of a member, that member's moderation_action will apply.
If any of the addresses above matches an address or pattern in one of the lists *_these_nonmembers attributes that action will apply rather than the corresponding non-member's moderation_action.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Understood that member's moderation_action will supersede non-member's moderation_action. (But how about owner? Owner alone should have no such setting. Sometimes issues occur when one are both owner and non-member)
For *_these_nonmembers, should they only exist in Mailman 2 and be converted using the "mailman import21" command? I cannot locate *_these_nonmembers using mailman client.
Just aware that *_these_nonmembers in the table mailinglist and we notice that they were migrated when we run 'mailman import21'. The type is BLOB. Can we clear all settings using the mysql command line as they are not exposed as REST API?
Double check the list that have issue:
On mailman 2, accept_these_nonmembers is empty discard_these_nonmembers is empty hold_these_nonmembers have a few email addresses
The list was imported to mailman 3 a few months ago.
On mailman 3, accept_these_nonmembers is empty hold_these_nonmembers is empty discard_these_nonmembers have a few email addresses which is the same as those in hold_these_nonmembers on mailman 2.
Therefore the import21 seem not importing the lists correctly.
On 11/1/19 2:30 AM, Alan So wrote:
Double check the list that have issue:
On mailman 2, accept_these_nonmembers is empty discard_these_nonmembers is empty hold_these_nonmembers have a few email addresses
The list was imported to mailman 3 a few months ago.
On mailman 3, accept_these_nonmembers is empty hold_these_nonmembers is empty discard_these_nonmembers have a few email addresses which is the same as those in hold_these_nonmembers on mailman 2.
Therefore the import21 seem not importing the lists correctly.
See <https://gitlab.com/mailman/mailman/issues/588>.
import21 should convert addresses in MM 2.1 *_these_nonmembers to MM 3 nonmembers with appropriate moderation_action and keep only regexp patterns in MM 3 *_these_nonmembers. Prior to core 3.3.0 this was not working.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
in https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/arc_sign.... I found this hint
"It is highly recommended that Mailman maintainers configure ARC siging of their outgoing email. ..."
So I added in my mailman.cfg: " [ARC] privkey: /path/to/private.key "
But I don't understand the meaning of
"... and located at: " #{config.ARC.selector}._domainkeys.#{config.ARC.domain} –ex.– test._domainkeys.example.com " Where can I find this string or where do I have to place it. I am using bind9 as dns-handler.
Thanks for your advice in advance.
Regards
Wolfgang
On 11/1/19 4:04 PM, Wolfgang Bock via Mailman-users wrote:
Hello,
in https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/arc_sign.... I found this hint
"It is highly recommended that Mailman maintainers configure ARC siging of their outgoing email. ..."
So I added in my mailman.cfg: " [ARC] privkey: /path/to/private.key "
But I don't understand the meaning of
"... and located at: " #{config.ARC.selector}._domainkeys.#{config.ARC.domain} –ex.– test._domainkeys.example.com "
This doesn't seem correct. The DNS TXT record should be added to #{config.ARC.selector}._domainkey.#{config.ARC.domain} (note _domainkey, not _domainkeys)
I.e., this is a normal DNS TXT record containing the public key for DKIM signing.
Where can I find this string or where do I have to place it. I am using bind9 as dns-handler.
Read the entire ARC section beginning at <https://gitlab.com/mailman/mailman/blob/master/src/mailman/config/schema.cfg...>. You have to configure more than just privkey.
Once you have configured
enabled: yes privkey: /some/location/yourprivatekey.pem selector: test (or whatever you want) domain: your_domain.com
The substitutions for #{config.ARC.selector} and #{config.ARC.domain} should be more clear.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
thanks for these hints. Now it works and outgoing mails from my lists are no longer greylisted.
.... ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=xx.de ... .... ARC-Seal: i=1; s=dkim; d=xx.de ....
Here my mailman.cfg (debian buster/dovecot/postfix/rspamd/mysql/mailman3)
quote
[ARC] enabled= yes selector= dkim privkey: /path/to/rspamd/dkim/{conf.ARC.domain}.{conf.ARC.selector}.key
unquote
The below mentioned hash should be deleted.
In the above mentioned directory the dkim key-files are saved in following style [domain].[selector].key
Regards
Wolfgang
Am 02.11.2019 um 01:19 schrieb Mark Sapiro:
On 11/1/19 4:04 PM, Wolfgang Bock via Mailman-users wrote:
Hello,
in https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/arc_sign.... I found this hint
"It is highly recommended that Mailman maintainers configure ARC siging of their outgoing email. ..."
So I added in my mailman.cfg: " [ARC] privkey: /path/to/private.key "
But I don't understand the meaning of
"... and located at: " #{config.ARC.selector}._domainkeys.#{config.ARC.domain} –ex.– test._domainkeys.example.com " This doesn't seem correct. The DNS TXT record should be added to #{config.ARC.selector}._domainkey.#{config.ARC.domain} (note _domainkey, not _domainkeys)
I.e., this is a normal DNS TXT record containing the public key for DKIM signing.
Where can I find this string or where do I have to place it. I am using bind9 as dns-handler.
Read the entire ARC section beginning at <https://gitlab.com/mailman/mailman/blob/master/src/mailman/config/schema.cfg...>. You have to configure more than just privkey.
Once you have configured
enabled: yes privkey: /some/location/yourprivatekey.pem selector: test (or whatever you want) domain: your_domain.com
The substitutions for #{config.ARC.selector} and #{config.ARC.domain} should be more clear.
Hello,
can someone give me an advice how I can configure in the postorius-menues the view of the from-part of my list-member like in this mailinglist:
Wolfgang Bock_via Mailman-users_ <mailman-users@mailman3.org>
case 1 reply goes to the list or to the member case 2 reply goes only to the list
Thanks in advance.
Regards Wolfgang
On 11/12/19 2:27 PM, Wolfgang Bock via Mailman-users wrote:
Hello,
can someone give me an advice how I can configure in the postorius-menues the view of the from-part of my list-member like in this mailinglist:
Wolfgang Bock_via Mailman-users_ <mailman-users@mailman3.org>
The above is the result of Settings -> DMARC Mitigatations -> DMARC mitigation action = "Replace From: with list address"
You can apply that to only messages From: a domain the publishes a DMARC policy of reject or quarantine or to all messages depending on DMARC Mitigate unconditionally.
case 1 reply goes to the list or to the member case 2 reply goes only to the list
The DMARC Mitigatations settings are independent of the various reply settings on the Alter Messages tab.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
thanks for your information. After creating the dmarc-entries in the DNS-databases everthing works as wanted!
Regards Wolfgang
Am 13.11.2019 um 06:02 schrieb Mark Sapiro:
On 11/12/19 2:27 PM, Wolfgang Bock via Mailman-users wrote:
Hello,
can someone give me an advice how I can configure in the postorius-menues the view of the from-part of my list-member like in this mailinglist:
Wolfgang Bock_via Mailman-users_ <mailman-users@mailman3.org>
The above is the result of Settings -> DMARC Mitigatations -> DMARC mitigation action = "Replace From: with list address"
You can apply that to only messages From: a domain the publishes a DMARC policy of reject or quarantine or to all messages depending on DMARC Mitigate unconditionally.
case 1 reply goes to the list or to the member case 2 reply goes only to the list
The DMARC Mitigatations settings are independent of the various reply settings on the Alter Messages tab.
Are there any pointer of documentation that I can clear all _these_nonmembers settings by updating the databases directly or using mailman shell? I am not so familiar with mailman shell though. We expect list owners use moderation_action only for members and non-members.
We are using and so the import21 did not do this correctly. mailman 3.2.0
On 11/3/19 6:58 PM, Alan So wrote:
Are there any pointer of documentation that I can clear all _these_nonmembers settings by updating the databases directly or using mailman shell? I am not so familiar with mailman shell though. We expect list owners use moderation_action only for members and non-members.
$ bin/mailman shell -l test.example.com Welcome to the GNU Mailman shell The variable 'm' is the test.example.com mailing list
m.accept_these_nonmembers = [] m.hold_these_nonmembers = [] m.reject_these_nonmembers = [] m.discard_these_nonmembers = []
That will just blindly clear them all.
If you want to see what you're clearing, you could do things like
if m.accept_these_nonmembers: ... m.accept_these_nonmembers ... m.accept_these_nonmembers = [] ...
which if the list's accept_these_nonmembers is non-empty will display it and then set it empty.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/1/19 1:34 AM, Alan So wrote:
Understood that member's moderation_action will supersede non-member's moderation_action. (But how about owner? Owner alone should have no such setting. Sometimes issues occur when one are both owner and non-member)
The fact that a post's sender might be an owner should have no effect.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Alan So -
Mark Sapiro -
Wolfgang Bock