Closed dpc22 closed 9 months ago
ikedas
commented
1 year ago The main reason for using the DSN for that notification is to make it less likely to cause backscatter.
On the other hand, the DSN is supposed to be sent back to the envelope sender. And for messages sent by most legitimate users, the envelope sender and originator (address in the From: field) will match.
In my opinion, it would be better to use inclusion feature.
ikedas
commented
1 year ago I appreciate that this is a "Doctor, it hurts when I poke myself in the eye. Well don't do that then" situation: the list include feature is probably a better approach. I'm just a bit concerned as to how many more cases of nested mailing lists are going to crawl out of the woodwork. I can't stop people from creating nested mailing lists. They have to contact me (as listmaster) to set up included lists, as that feature is restricted to listmaster.
edit_list.conf:
include_sympa_list owner,privileged_owner hidden
If you are a listmaster, you can customize edit_list.conf and make the include_sympa_list parameter editable by the owners.
dpc22
commented
1 year ago I think that these really have to be set up by the listmaster. If list owners could include lists themselves then some enterprising soul would include one of our "all-staff" lists into their own list in order to bypass the normal moderation controls on these lists and spam everyone.
Is there any scope for disabling these DSNs when messages are "Precedence: bulk" (or have some other marker indicating they were relayed via some another list on the same server)?
dpc22
commented
1 year ago Half a dozen nested lists with moderated sublists have triggered 100percent errrors in the last 4 days: previously these would have worked (albeit with lots of backscatter to the original sender).
ikedas
commented
1 year ago @dpc22,
Since you know where the changes made, reverting to those changes would avoid the problem for the time being.
84e4d6b
It seems, in fact, sufficient to revert only the changes to lib/Sympa/Spindle/ToModeration.pm (I guess the problem may be with status 4.3.0 instead of 2.3.0) and default/mail_tt2/message_report.tt2.
pascalmaes
commented
1 year ago I understand the use of DSN, but is it really necessary to send back the headers in the case of simple moderation?
Version
6.2.72
Installation method
My own rpm, derived from official rpm for RHEL 7
Expected behavior
Nested mailing lists should not trigger "list has 100 percents of its users in error. Something unusual must have happened." errors to the list owners and senders.
Actual behavior
We upgraded from Sympa 6.2.70 to 6.2.72 last week. One of my list owners complained that she is starting to see hundred percent errors on her list, and that this never used to happen.
Some investigation reveals that they have set up a mailing list which includes three moderated lists as subscribers (and no other subscribers). People used to send a message to the parent list and receive a "Your message has been forwarded to the moderators" message for each of the subsiduary lists.
Since the upgrade to Sympa 6.2.72 these messages are sent to the envelope sender address (the parent mailing list) rather than the original sender (I'm guessing the "From:" header in the body).
I can see that the code in ./lib/Sympa/Spindle/ToEditor.pm has changed from 6.2.70 to 6.2.72: Sympa::send_file() has been replaced by Sympa::send_dsn($list, $message, {}, '2.3.0')
Can I just check whether this was a delibarate change in behaviour?
Sympa probably shouldn't be sending "Your message has been forwarded to the moderators" messages back to the bounce handler address on the parent mailing list. Maybe these should be disabled if the message has obviously come from a mailing list (either by testing the return path, or looking for "Precedence: bulk")?
I appreciate that this is a "Doctor, it hurts when I poke myself in the eye. Well don't do that then" situation: the list include feature is probably a better approach. I'm just a bit concerned as to how many more cases of nested mailing lists are going to crawl out of the woodwork. I can't stop people from creating nested mailing lists. They have to contact me (as listmaster) to set up included lists, as that feature is restricted to listmaster.
edit_list.conf: