Karl Semich writes:
I'm experiencing mailbombing via spoofed unsubscription and subscription requests from mailman lists. Mostly unsubscription requests from a mailman 2.1 list.
This is an unfortunate consequence of the fundamental design of using access to a mailbox as proof of identity.
There is really no way lists can defend you from these attacks without shutting down all "open subscription" lists. (Analysis below.)
Your best defense is to set a mail filter which discards or quarantines mail which matches either of the following regular expressions in "From":
.*-confirm(\+[A-Fa-f0-9]*)?@ # Used by Mailman 2.1 ^mailman@ # Used by Mailman 3.x
Unfortunately you will need to explicitly permit those addresses temporarily if you wish to subscribe to or unsubscribe from a Mailman list in the future. You can however restrict permission to the specific host (and for mailman 2, list) whose subscriptions you wish to manage.
Addresses matching the following regexp are used in "your post is held for moderation" messages (which can be triggered by posts apparently from you) on many lists:
.*-bounces@
However, such addresses are also used to send notifications that your mail was undeliverable, and to check for deliverability. I would not discard mail from this class of address until used in a clear pattern of attacks. In most cases the moderator's response will be to ban your address from posting, so it will only work once for the attacker on a given list.
I'm not sure if addresses matching any of the following can be triggered to send abusive confirmations:
.*-owner@ .*-request@
I would not filter them unless they are used in a clear pattern of attacks.
Is there any configuration option I can ask the list administrator to enable, to require my password to be provided before the confirmations are sent to me?
As Mark says, no.
If this configuration option does not exist yet, could anybody advise what sourcefiles would need modification so as to contribute it as a feature addition?
As Mark says, Mailman 2 is EOL, so we aren't accepting such contributions.
For Mailman 3, the only approach I can think of, which probably works for your use case, would be to require DMARC from alignment on requests via email, and multiple authentication methods (a "social auth" or a list of one-time recovery keys) on web requests so confirmation messages would not be needed, except for the first time a mailbox is linked to a user account.
Such code might be accepted, and an option to disable email administration of subscriptions might be (but with DMARC checking it's probably not necessary). Third party authentication is already available if sites enable it, and generation of recovery keys could be added, I suppose. Code to allow the member to disallow password resets when no password is set and third party authentication is in effect might be accepted. For Mailman 3 I'd start by looking at
mailman/src/mailman/commands/eml_membership.py mailman/src/mailman/model/subscriptions.py mailman/src/mailman/model/user.py
Steve