Assistance Needed with Mailman Subscription Issue (Mailman 2.1)
![](https://secure.gravatar.com/avatar/86dd19fcd849c04829ff47f33edd9978.jpg?s=120&d=mm&r=g)
Hello,
First of all: Thanks for the insane amount of things I've learned just by reading along in the list here!
We are currently using Mailman 2.1.23 on a FreeBSD server with Sendmail, managing approximately 24 mailing lists. These lists are strictly for internal use, not publicly accessible, with membership ranging from 20 to 300. Quite cute.
To prevent self-subscription or any subscription requests via Mailman, we've undertaken the following steps:
Set the "advertising flag" of all lists to 'no'. Removed most of the email aliases, retaining only: mlist.sample: "|/usr/local/mailman/mail/mailman post mlist.sample" mlist.sample-admin: "|/usr/local/mailman/mail/mailman admin mlist.sample" mlist.sample-bounces: "|/usr/local/mailman/mail/mailman bounces mlist.sample" (And yes, we have also executed newaliases post these changes. ;-) )
Furthermore, we've removed the subscription section from the "listinfo" page by modifying the listinfo.html templates for all languages. This led to a noticeable decrease in subscription entries. However, we are still receiving some subscription requests, which is perplexing.
I can find the addresses in question in the "vette" log file, but nowhere else:
... vette:Dec 20 06:02:14 2023 (96837) mlist.sample: held subscription request from taryxxxx@icloud.com vette:Dec 20 06:06:27 2023 (5909) other.mlist: held subscription request from taryxxxx@icloud.com ...
These requests are puzzling as they seem to bypass our restrictions. I have searched through all server logs (I could imagine) and found no further mention of the addresses in question, nor any clues in the maillog nor corresponding entries in the httpd-access.log (for mailman pages).
Could anyone provide insights or suggestions on where to look or what we missed?
Thank you for your assistance.
Thomas
--
Be part of the change you want to see in this world.
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
On Wed, 20 Dec 2023, Thomas F. Holz wrote:
... Impressive list of actions taken snipped...
Could anyone provide insights or suggestions on where to look or what we missed?
Hmmm...
I would never say you've done all you can do, but here's some food for thought:
I've seen easily over a dozen clear examples where the only possible way ANY information got out there was that someone's email was collected, analyzed and data therefrom formed into what I would call an attack, but more realistically just a seriously dedicated effort at spamming.
There are "data leak points" at, first, EVERY SINGLE OCCASION where one of your emails transit the internet, primarily but not exclusively via people's ISPs and second the sites where your emails sit, primarily but not exclusively where your users have their emails hosted.
Any (all) of these - and more besides (e.g. non-ISP man-in-the-middle, forwarded email, etc) - are places where:
Your email domain is available, with;
The fact you run mailman because it's well known, the signature of its use in any given email is obvious, and has a known use-pattern for sign-ups and the like.
From these sources of data, "attacks" can be formulated, primarily because mailman is a well known package.
Further, the originating sources of these vectors of information flow include - or at least has included - pretty much ALL "the big boys" of free email account hosting. For example, they now claim to "not any more", but Google famously (infamously) has been publicly busted for cracking people's email and "using the results for marketing purposes." Beyond that, we (the community of computing professionals) KNOW this data is sold - and if you think it's uses are limited to marketing, you're being naive.
Remember, if it's free, and there's not a clear funding path for the service, YOU are the product! Free email? Hardly: You pay with YOUR data - AND the data of all those who email you! Think it doesn't matter? Think again; Google, as but one known example, is known to be attempting to create a dossier of "every single human on the planet", even those who don't use their products.
I conclude there's nothing you can really do about this short of running your own mail server that hosts everyone's email account and they access only via encrypted tools, such as a TLS connection from, say, Thunderbird. And even then you can't truly stop it since people forward emails. However, at least in that case, you can instantly drop all email inbound to mailman that didn't originate from your own server. ... A careful analysis of the attackers MIGHT give you some idea what their vector to you may have been, insofar as that's helpful.
I know that doesn't, as a practical matter, help much.
As an aside but perhaps pertinent for younger generations to make note of: It's been not only technically possible but fairly trivially easy for ALL email to be encrypted, point-to-point, in exactly the same way as we do HTTPS, for literally decades now. The only data that's truly required to be in the exposed information are exactly the same as required for an https connection, namely the destination domain, and there's a good argument to be made that that's the ONLY data that should be readily available, though you will surely find arguments by the don't-really-want-it crowd for the whole header to be unencrypted.
I personally advocate a built-in two-tier encryption, one where only the most minimal network information remains unencrypted, the entire email (including all header information) is encrypted, the mail server decrypts and can use the email headers, and where the email body can optionally be additionally encrypted in any of a number of ways, at the discretion of the sender and / or recipient, including open-sourced built-in options. Existing PGP, for example, can be expanded, and the likes of LetsEncrypt can provide users with their own keys, as needed - the creativity of the Open Source community should be unleashed on this problem anew.
As someone who was pushing for it way back then, starting around 1995 or '96 with nearly 20 years of email experience at that time, I can also tell you that the big powers that be DO NOT WANT us to have encrypted email (because, its easy to surmise, they want access to all our data). And, for those that didn't know, the founders of Proton Mail were also people who were advocating for fully-encrypted email and when it became clear that wasn't going to happen "in our lifetimes," they were so fired up about it, they did what they could. (I have zero affiliation with Proton, I just appreciate they DID something!)
Perhaps younger generations will push through encrypted email - my generation has largely either capitulated or "hung-up their spurs." IMNSHO, ubiquitous, fully encrypted email will spell the beginning of the end of spam - and email list attacks.
Good luck, Richard
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
On Wed, 20 Dec 2023, Thomas F. Holz wrote:
... Impressive list of actions taken snipped...
Could anyone provide insights or suggestions on where to look or what we missed?
Hmmm...
I would never say you've done all you can do, but here's some food for thought:
I've seen easily over a dozen clear examples where the only possible way ANY information got out there was that someone's email was collected, analyzed and data therefrom formed into what I would call an attack, but more realistically just a seriously dedicated effort at spamming.
There are "data leak points" at, first, EVERY SINGLE OCCASION where one of your emails transit the internet, primarily but not exclusively via people's ISPs and second the sites where your emails sit, primarily but not exclusively where your users have their emails hosted.
Any (all) of these - and more besides (e.g. non-ISP man-in-the-middle, forwarded email, etc) - are places where:
Your email domain is available, with;
The fact you run mailman because it's well known, the signature of its use in any given email is obvious, and has a known use-pattern for sign-ups and the like.
From these sources of data, "attacks" can be formulated, primarily because mailman is a well known package.
Further, the originating sources of these vectors of information flow include - or at least has included - pretty much ALL "the big boys" of free email account hosting. For example, they now claim to "not any more", but Google famously (infamously) has been publicly busted for cracking people's email and "using the results for marketing purposes." Beyond that, we (the community of computing professionals) KNOW this data is sold - and if you think it's uses are limited to marketing, you're being naive.
Remember, if it's free, and there's not a clear funding path for the service, YOU are the product! Free email? Hardly: You pay with YOUR data - AND the data of all those who email you! Think it doesn't matter? Think again; Google, as but one known example, is known to be attempting to create a dossier of "every single human on the planet", even those who don't use their products.
I conclude there's nothing you can really do about this short of running your own mail server that hosts everyone's email account and they access only via encrypted tools, such as a TLS connection from, say, Thunderbird. And even then you can't truly stop it since people forward emails. However, at least in that case, you can instantly drop all email inbound to mailman that didn't originate from your own server. ... A careful analysis of the attackers MIGHT give you some idea what their vector to you may have been, insofar as that's helpful.
I know that doesn't, as a practical matter, help much.
As an aside but perhaps pertinent for younger generations to make note of: It's been not only technically possible but fairly trivially easy for ALL email to be encrypted, point-to-point, in exactly the same way as we do HTTPS, for literally decades now. The only data that's truly required to be in the exposed information are exactly the same as required for an https connection, namely the destination domain, and there's a good argument to be made that that's the ONLY data that should be readily available, though you will surely find arguments by the don't-really-want-it crowd for the whole header to be unencrypted.
I personally advocate a built-in two-tier encryption, one where only the most minimal network information remains unencrypted, the entire email (including all header information) is encrypted, the mail server decrypts and can use the email headers, and where the email body can optionally be additionally encrypted in any of a number of ways, at the discretion of the sender and / or recipient, including open-sourced built-in options. Existing PGP, for example, can be expanded, and the likes of LetsEncrypt can provide users with their own keys, as needed - the creativity of the Open Source community should be unleashed on this problem anew.
As someone who was pushing for it way back then, starting around 1995 or '96 with nearly 20 years of email experience at that time, I can also tell you that the big powers that be DO NOT WANT us to have encrypted email (because, its easy to surmise, they want access to all our data). And, for those that didn't know, the founders of Proton Mail were also people who were advocating for fully-encrypted email and when it became clear that wasn't going to happen "in our lifetimes," they were so fired up about it, they did what they could. (I have zero affiliation with Proton, I just appreciate they DID something!)
Perhaps younger generations will push through encrypted email - my generation has largely either capitulated or "hung-up their spurs." IMNSHO, ubiquitous, fully encrypted email will spell the beginning of the end of spam - and email list attacks.
Good luck, Richard
participants (3)
-
Richard
-
Stephen J. Turnbull
-
Thomas F. Holz