Security features of Mailman
![](https://secure.gravatar.com/avatar/3ab55172b2973968d5641bf9dc8d203a.jpg?s=120&d=mm&r=g)
Can you elaborate on the security features of Mailman and how it ensures a safe environment for email discussions?
Regards, Sanjay Jangam www.sanjayjangam.com
![](https://secure.gravatar.com/avatar/0fbcef57d028af495d8c9a5992405f78.jpg?s=120&d=mm&r=g)
On Tue, Jan 16, 2024 at 8:54 PM sanjay jangam <web.world.co.in.1@gmail.com> wrote:
Please disconnect your computer from the Internet and don't install Mailman. It cannot guarantee the safety of anything! Only you, the Sysadmin, can guarantee that by locking it from venturing outside and roaming around the server environment :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
sanjay jangam writes:
Can you elaborate on the security features of Mailman and how it ensures a safe environment for email discussions?
No. The question is poorly posed. You need to say against what threats you want to protect your discussions.
I can say this much: Mailman 3 does try to provide good authentication of users and a consistent model of authorization for access to its databases (user profiles, list user rosters and configuration). Mailman 2 does not.
Neither Mailman 2 nor Mailman 3 tries to provide cryptographic security (encryption or authentication) of list traffic, on the wire or at rest (ie, in archives).
Other than that, you have to define what you mean by "safe", and then I can tell you whether Mailman can satisfy that requirement and what you have to sacrifice to get it.
Steve
![](https://secure.gravatar.com/avatar/8e23ff1cfcdcf076bf065b253ad021cc.jpg?s=120&d=mm&r=g)
Please let me know which platform you'd like me to elaborate on, and I'll be happy to delve into its security features and how they create a safe environment for email discussions or API interactions, whichever is relevant. https://attitudecaption.com/
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Sron Dev writes:
Please let me know which platform you'd like me to elaborate on,
Me personally? None. I don't have time for theoretical discussions. Maybe somebody else does, you're welcome to pick a platform and hold forth (but see below for venue, this is almost certainly not the right list for that).
If you, or anyone else, has a specific feature request, or requirement for "ensur[ing] a safe environment for email discussions", I'd be happy to discuss what we can do about that. That discussion should move to mailman-developers@python.org or mailman-users@mailman3.org depending on whether the RFE is fairly clear (-developers) or if it needs refining by input from other users (-users), as new features are not going to be added to Mailman 2 (the subject of this list).
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Steve, Sron, et al:
Regarding:
"ensur[ing] a safe environment for email discussions"
...I would hope that all netizens are fully aware (and obviously not all are) that there is not and cannot be such a thing as "safe environment for email discussions" with email as now practiced and to create it requires a serious overhaul of the way email is conducted.
It doesn't have to be this way: email bodies and even the destination username and other parts of email headers COULD be encrypted when enroute via the same mechanisms as we have long used for secured web sites, and even end-to-end encryption isn't too difficult to implement, and I'd lay a substantial bet that an open-sourced effort harnessing the ideas of DKIM / SPF / DMARC could easily and simply accomplish this.
However, the simple (and for me painful) truth is that The Powers That Be _obviously_ do not want us to have secure communications. Their excuse is fear ("terrorism!") and their more dominant motive is profit. It's truly as simple is that.
Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.
And therefore any discussion of "ensur[ing] a safe environment for email discussions" is a real head-scratcher for me!
Chalk this one up as yet another entry in the long list of our collective needs shot down by the "this is why we can't have nice things" excuse.
Regards, Richard
P.S. PERHAPS someone reading this has the energy and gumption to change this?! I sure hope so! ...I've been using email for 47 years now, I did my part, I tried hard, it's up to younger generations to carry it forward now. But I'll be happy to assist anyone else's efforts on this!
RT
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
richard@karmannghia.org writes:
My original point was I feel perfectly safe here on Mailman lists (of course I am in a position to get people banned, so I am in fact safer than the average bear, though I would not mess with a Kodiak).
True, and in fact many sites implement the enroute part, it's called mandatory TLS. I would imagine the proposals to make traffic analysis more difficult would apply here too.
I've thought a lot about this, it has been proposed multiple times as a GSoC project for Mailman, and this is simply not true for mailing lists as implemented in Mailman. In particular, it's simply not possible to achieve end-to-end encryption as a mailing list function. The list has to have access to the session key to give access to that key to subscribers, at which point you've been hacker-in-the-middle-d. I can imagine applications where you're willing to trust the list, though, and if there were demand for that, I'd be willing to supervise a GSoC student who wanted to implement it.
Note that it is certainly possible to have end-to-end encryption of list email, but it requires that each poster have all the subscriber keys. I guess you could marry a keyserver with a mailing list, and if you want to call that "end-to-end encryption via mailing list" go ahead, but you still have to solve the problem of getting posters to keep their keyrings up to date, so I consider that "not a mailing list function".
And of course you only asked for security of "data in motion", but then you've got the harder problem of securing data at rest (which also requires cooperation from either recipients or from their MUAs -- buwhahahahaha!)
It's not that simple though. While you're gonna need some *serious* booking up before you can win that substantial bet ;-), it would be possible (and has been done, cypherpunkery is real!) The problem is that we don't want it as bad as the cypherpunks did. So far we've been able to resist laws that require backdoors (who knows how many backdoors are there by bribery or other skullduggery, but it's not *legal*). So for some things we can win. But if we want really secure mail, as secure as for financial networks (which aren't perfect but they do OK), we're going to have to pay for it, and the average bloke isn't interested. They'd rather be outraged when their secrets get blabbed and their brother-in-law who actually did the dirty deed says "wasn't me, was some 400-lb-hacker-in-Mom's-basement".
Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.
This is true. Security by obscurity works up to a point, but if you ever get targeted by the FBI you're toast.
I'm not volunteering for the hacking part, but if somebody eligible for GSoC wants to propose it, and the mentors like the proposal, I'll mentor it.
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
On Tue, 30 Jan 2024, Dmitri Maziuk wrote:
You're obviously correct, Dima; who your mail host is matters, and who your recipent(s) mail hosts are also matter and if either is like Google, Hotmail, Yahoo, etc, well... it's pretty pointless.
People need to remember: If it's free, YOU are the product!
But more than that, I try and get people to understand that due to their ignorant choice of gmail, for example, I won't send them all kinds of emails I might otherwise send, even though it's not encrypted end-to-end because (as someone pointed out) obscurity works to a point, so SOME things I might not mind sending in that way.
I have a good handful of friends who I have managed to convince to move to Proton Mail because I just won't deal with them via email if they remain on gmail, etc.
Richard
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Hi Steve, Dima, et al:
Thanks for almost-volunteering. But lets make sure we're "on the same page." And I make a few other remarks along the way to maybe getting somewhere useful.
It's faster if I just get to the point rather than framing things in response to prior posts, so I hope this attempt at brevity works.
"Email safety" writ large has two fundamentally distinct elements.
The first is what I'd call the safety of the email itself and this is primarily about accessibility. This may be called privacy: who can access the email contents.
The second pertains to the "safety implications" of email content. This is primarily about legal violations such as libel, threats, incitement of violence, doxing, etc. This type of concern exists for all email but is amplified in the context of an email list.
Policy issues are unique to email lists, may include concerns from either email safety category and those policies that properly belong in neither are not of any interest to this discussion primarily because, first, they aren't a genuine safety concern and, if implemented by list management software like mailman, in effect amount to censorship of list content. Since email lists are on whole privately owned and operated, that's fine, and examples of censorship we can all probably agree on are spam and virus filtering. A human can step in where automated processing can't determine policy violations, hence the existence of a manual banning process.
Having said all that, my only real interest here is on the accessibility (privacy) aspect, and list-management software like mailman DOES have something to say about architectural details of implementation for an encrypted email world.
Rather than an all or nothing approach to encryption, I advocate a multilayered approach, with multiple levels of control and input. It is in this layering that mailing list software input is important.
A straight-forward approach might be, for example, that the entire set of data transferred between two MTAs is encrypted save the destination system's network address and the destination port. The MTA decrypts to get access to all the headers needed to hand it off to an MDA/LDA, and so on, down the chain of functions. It's entirely reasonable to design the architecture so the list management code has optional access to the body of an email, so some sites might keep things encrypted until the end recipients while others leave email decrypted, or even where it's decrypted for local use such as filtering and archiving but reencrypted for further transport on to list members.
All of this and much more is not particularly difficult to accomplish from a technical point of view - it's only a "Small Matter Of Code" as Michael Stonebraker (Turing Award Winner) famously says.
...This is what I want to get at. If anyone reading this cares to lend a hand (like YOU, Steve!) or make commentary, please contact me off-list as this is not really a mailman concern! Not yet anyway.
Now, some closing comments:
From the point of view of a mailing list, if the list itself is functional then there's no issue with traffic analysis insofar as legitimate analysis of list traffic is concerned. One would imagine that in a properly architected system designed to encrypt various email headers, the design would account for email-list-pertinent options.
From here, your analysis goes ... weird. I suppose one of us misunderstood the other: What's needed is something like "mandatory TLS" but even better since that doesn't, so far as I know, differentiate between headers and the email body, much less parts of the header such as the subject line. But it's the scope that's the weird part; this needs to be done at the MTA level, not at the mailing list manager level. At least that's my view
It's also far simpler to solve this at the MTA level. But then maybe I misunderstood you.
BTW, given that Google was started with "deep state" money and their continuing, on-going super-close cooperation with them, I wouldn't be looking to any GSoC effort to do anything useful on this topic since the entire "security state" is devoted to THEM having full encryption and YOU having none. The back-dooring they've compelled is nothing short of appalling.
My offer to help still stands; I can be an awesome ally but I shouldn't be the one trying to drive this as I'm spread too thin already!
Either way, this has taken up enough of the mailman list's time! So, if anyone cares to be engaged in this, email me privately and maybe we can work something out? SOMEBODY's got to do this!
Regards, Richard
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Hi Richard,
Thanks for your followup. Although you suggested taking the conversation private, I want to at least continue for one more post because it's not clear to me that there's demand for this service that is enough to justify the likely substantial cost of development. I don't know how to implement poster-to-subscriber encryption on the one hand, and on the other hand most list owners are unable or unwilling to manage their own hosts, and therefore have to provide the ability to decrypt list traffic to a third party.
But I could be quite wrong, and it's the members of the Mailman community who are most likely to provide a critical mass of users to say "that's just what I've always wanted, and here are the features I want". If that critical mass doesn't show up, then I want to use my time (and resources such as summer interns) on features that our community *does* want.
The fact that nobody but you has raised their hand to say "I want this" or "my list owners would really like this" is not a point in its favor.
However, let me say to anybody who has read this far that although I have played and continue to play the devil's advocate against "privacy-preserving mailing lists", I want everybody to understand that I am very much in favor of privacy. But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic. On the positive side, reduced- expectation implementations with encryption on the wire both directions and in queue files, for example, which would pretty much eliminate attacks on data-in-motion and somewhat reduce the attack surface for data-at-rest (eg, in queues on disk on the list host and possibly even in archives) might be useful in some applications. I would be happy to discuss such applications, and the cost of implementing them in Mailman (ie, how much writing and rewriting of code).
richard@karmannghia.org writes:
I believe we already have that in some profiles of IPSec. But that has nothing to do with mailing lists, and I'm not real interested in going into MTA implementation.
The MTA decrypts
Then the MTA is an agent-in-the-middle, and an obvious point of attack.
It's entirely reasonable to design the architecture so the list management code has optional access to the body of an email,
Now the list manager is an agent-in-the-middle and a point of attack, too. Both are very likely unacceptable in the case of a large-scale hosting service, without a massive effort to design and implement a key management system that can restrict access to keys to authorized uses. Absent such a system, the operator of a mailing list would also need to be a system administrator with security qualifications to match perceived threats.
As I pointed out above, a lot of it is already implemented -- but not in MTAs/MDAs, MUAs, or mailing lists. All of which have multiple implementations and those implementations must agree exactly, or somebody is going to get hacked.
I'm not sure what you mean by "traffic analysis". I am suggesting that membership in some encrypted lists will be considered privacy- relevant, and therefore mail being delivered from what is likely a single-purpose host to a mailbox infringes privacy of the mailbox's owner. Consider for example a list for victims of stalking or domestic violence. Knowledge that a target is subscribed to such a list could trigger violence on the part of the abuser.
In the mailing list context, the fundamental question of "properly architected" is "who has which keys and how do they get them?" Mandatory TLS solves the problem automatically for a single TCP connection. This can be generalized to automatic secure key exchange for all members of a (sufficiently small) synchronous group chat in the chat software. I don't see how it can be generalized to a mailing list which is fundamentally asynchronous, should deal with recipients whose MTAs almost certainly don't participate in such key exchange protocols (other than TLS), and potentially of much larger scale.
and even end-to-end encryption isn't too difficult to implement,
How do you propose to make that work, even for the simplest case of just encrypting the whole SMTP DATA element? The MTA doesn't know who the ultimate recipients are. Mandatory TLS can secure privacy-on-the- wire by using a secure key exchange protocol such as Diffie-Hellman because all you need to know is "the recipient is on the other end of this connection". But the mailing list stands between the MTA and the recipient.
It's also far simpler to solve this at the MTA level. But then maybe I misunderstood you.
I don't think you have thought through what the mail flows are, and at what points messages need to be decrypted and accessible to which software (and therefore potentially to human agents such as host administrators).
As I've said several times before in this kind of conversation, what we need to do is identify specific privacy threats (mechanisms for infringement) and user populations who need protection from them, and then see if we can design a list (and probably MTA) architecture that provides that protection.
Steve
![](https://secure.gravatar.com/avatar/22a09d8e743b6c5ea3a340d7f7f3eaf1.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/
The idea is that there is a key for the list, the server decrypts the E-mails and encrypts it for the recipients who have supplied a key. Worked fine with that old version of Mailman 20 years ago.
But even in our quite nerdy environment only about the half of the subscribers submitted a key for the list. (excuses are like 'I want to use grep(1) for fulltext search in my list E-mails') So after the next mailman update we dropped the patch and run unencrypted again.
-- \ J. Dollinger FAW/n Ulm |zeitnot@irc| http://www.home.pages.de/~zeitnot/ \ "What're quantum mechanics?" -- "I don't know. People who / \ repair quantums, I suppose." (Terry Pratchett, Eric) /
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Juergen Dollinger writes:
We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/
Thank you for describing your experience! The people side is always hard. I'm not unhopeful though, but it's going to take work, especially good design.
That's exactly how I would do it, except you wouldn't receive posts until you submitted a key. Having half the copies vulnerable on-the-wire and on-disk would not fill me with warm fuzzy feelings. :-)
I think this could be fairly useful in environments where people are paranoid enough to leave the mail encrypted on disk. But even the DV case that I mentioned -- would it stay encrypted for long if a few of the abusers discovered its existence? It would only take one!
Today I don't think that excuse would fly, machines are fast enough that few email bodies would take noticable time to decrypt, and languages like Python and Perl provide very high quality email processing libraries. p-grep-p would be written real fast, and it would work fast too.
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Steven, Juergen, et al,
I had written most of this but interrupted, then Jurgen's email came in, so... this got an edit! If a spot or two seems awkward it's because of available time.
On Mon, 5 Feb 2024, Stephen J. Turnbull wrote:
It's very straight-forward:
Public Key Encryption is used: Subscribers who want encrypted email include their public key in their subscription details, just as they include their name and digest type choices. The list itself, for its reception, uses TLS. The outbound, from list server to subscriber is where "the magic happens," encrypting the outbound to each user using their own public key.
And then Juergen, as if on cue, added:
on Tue, 6 Feb 2024, Juergen Dollinger wrote:
I was unaware of this and I would have latched on with both hands!
Note that 20 years ago people, on whole, were less aware of the issues with unencrypted emails and that HALF DID sign up is rather amazing. Most users 20 years ago had "grown up with" a very friendly internet and remembered those times without perceiving the risks, while the newcomers were clueless to pretty much everything. Therefore the aprox. 50% number is amazing.
HOWEVER, just becasue ONE email list of a group who realized it was there had that experience says NOT A THING about how many who didn't know would love to have a list where users HAD to use encryption to be on the list!
Consider that the safest email is one in which sender and recipient are on the same system, MANY corporate environs would likely LOVE to have the added flexibility and security that could come from having an email list with this capability used for communications with not just employees but their vendors.
It's myopic to see just one's own use case and think it applies across the board.
Moving on, Steve goes on to say:
Over my long and storied 47 year career in computer science I've long noted that the vast majority of users:
Don't know what they really want;
Don't have a clue what's easy and what's hard, and;
Don't hang out on email lists like this one.
(BTW the vast majority of project managers fit this same profile and explains why we get such atrociously bad software sometimes, even from gifted teams; if management is ignorant, it leads to less-than-optimal results, especially with autocratic leadership that doesn't trust their teams or want their creativity or input. But I digress...)
Steve:
Your argument isn't any better.
The a majority of users have no clue that their emails are vulnerable in transit on the internet, much less as a separate risk from their email provider. So if it's your idea that we don't offer people the chance for better and only focus on giving people what they already know they want, progress is ... "suboptimal."
Good.
But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic.
That is abjectly false, Juergen proved it, and not only was it NOT difficult 20 years ago, in the 20 years since then what's fairly easily possible has expanded considerably.
BTW, that one of us doesn't know how such things are done, by the way, doesn't mean it's difficult. I love Will Roger's comment about such things: "Everybody's ignorant, just about different things is all!"
It's no strike against anyone they don't know how things might be accomplished, but something we all need to watch out for is our own false presumption that if we don't see how something can be done it must be hard.
The BIG question here is surely beyond this list's purview: Can we manage to get an easy-to-use mechanism where any given user's public key can be found? We now have at least The Electronic Frontier Foundation, LetsEncrypt, and Proton AG who might well lend some muscle in this venture: Think of a DNS-like system, perhaps even an actual evolution of DNS itself, that permits users to declare their public keys in a publicly findable way. For sites that want to keep user lists private but still do this, perhaps a validation server could be devized with site-specific policies on who gets to know what about a given username@domain entry - think "I want to send encrypted email to user@your.system," and the mail server or some similar server looks at the request and honors it by sending the public key or not.
I posit that such a change would cause an explosion of use of encryption for the simple reason that it's use can then be largely automated and thus remove a huge fraction of the burden from the individual. It would enable FAR more security, writ-large, than is under discussion here. I won't bother you with all of it but just point your brain in pondering the power of a very simple back-and-forth, "I use your key to send you something encrypted, you send it back encrypted with my key telling me what it is and we just validated each other."
IF a list manger like mailman wanted to handle this it surely could! In that instance the broader key management via DNS or DNS-like system is not necessary.
As for users wanting to grep emails, that's a lame excuse: Just leave the email unencrypted in your local folder! That one's born of lazyness not capability. However, using encryption today CAN BE an annoying thing. My goal is to remove the time consuming hassle.
Richard / Steve dialogue:
I've never seen / noticed that. A pointer would be nice!
The MTA decrypts
Then the MTA is an agent-in-the-middle, and an obvious point of attack.
Yawn. Let people decide what their comfort level of risk is. The idea is to ENABLE.
I never said this was only a mailing list issue. We, collectively, need a better infrastructure.
The privacy threat: Unencrypted email in transit on the internet.
Affected user population: All email users.
And yes, MTA is the correct level, though as noted above, an email list CAN help a lot WITHOUT an MTA level "fix".
Regards, Richard
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
richard@karmannghia.org writes:
It's very straight-forward:
C'mon, man, Grandpa knows how to tie his shoes. The construction of such an encrypted list not technically terribly complex---as you said yourself, a SMOC. The problems are describing *who* is the adversary, *what* will they do to invade your privacy, and *how* does the proposed system thwart those threats. You are completely ignoring those questions. And no, "unencrypted mail is a threat" to "everybody" isn't a serious attempt to address them, given that almost everyone is using MTAs that support TLS nowadays.
Subscribers who want encrypted email include their public key in their subscription details,
What about the needs of *posters*, who are *at least* as important as subscribers here, who want to keep *their* posts private? That's why "encryption-optional" lists make no sense to me, except as a proof of concept. And the prescription to greppers to leave their mail folders unencrypted is not comforting to the authors, either.
I see vanishly small added security in an encryption-optional mailing list of the kind Juergen described. As a proof-of-concept, it was a brave experiment that maybe could have led to something. But it didn't.
Round 'em up, man. I listen to the community. I'm listening to you.
So? I think they *do* know a very large fraction of what they want at the level of expressing *requirements* (WIBNI ...). Dealing with what's easy and what's hard is our problem as developers, not theirs. With that knowledge, we can help them refine and prioritize their requirements, and sometimes discover new ones. Convincing them that we understand their requirements and know easy vs. hard is also our problem. And the lack of like-thinking users on mailing lists like this one is a problem for advocates (like you?)
Your definition of "end-to-end" is not the one in common use. A system where an intermediate node decrypts, then reencrypts and forwards, is not "end-to-end encrypted" in any usage I've seen before,
It's really not useful to discuss technical issues if you won't at least use the accepted definitions of such critical terms. You're welcome to argue that given the threats you perceive, it's not an important requirement for an encrypted mailing list. But given the ease which which systems are penetrated these days, I disagree for most purposes I can think of.
Steve
![](https://secure.gravatar.com/avatar/02cc25ec5c6cd5c6a65a6d94817fe815.jpg?s=120&d=mm&r=g)
It appears to me that the author of this message just wants to deposit his spam. The website referenced in the message has nothing at all to do with Mail / Mailman / Computing.
Please don’t feed the trolls...
Christian
Sron Dev schrieb am 28.01.24 um 15:43:
Please let me know which platform you'd like me to elaborate on, and I'll be happy to delve into its security features and how they create a safe environment for email discussions or API interactions, whichever is relevant. https://attitudecaption.com/
![](https://secure.gravatar.com/avatar/0fbcef57d028af495d8c9a5992405f78.jpg?s=120&d=mm&r=g)
On Tue, Jan 16, 2024 at 8:54 PM sanjay jangam <web.world.co.in.1@gmail.com> wrote:
Please disconnect your computer from the Internet and don't install Mailman. It cannot guarantee the safety of anything! Only you, the Sysadmin, can guarantee that by locking it from venturing outside and roaming around the server environment :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
sanjay jangam writes:
Can you elaborate on the security features of Mailman and how it ensures a safe environment for email discussions?
No. The question is poorly posed. You need to say against what threats you want to protect your discussions.
I can say this much: Mailman 3 does try to provide good authentication of users and a consistent model of authorization for access to its databases (user profiles, list user rosters and configuration). Mailman 2 does not.
Neither Mailman 2 nor Mailman 3 tries to provide cryptographic security (encryption or authentication) of list traffic, on the wire or at rest (ie, in archives).
Other than that, you have to define what you mean by "safe", and then I can tell you whether Mailman can satisfy that requirement and what you have to sacrifice to get it.
Steve
![](https://secure.gravatar.com/avatar/8e23ff1cfcdcf076bf065b253ad021cc.jpg?s=120&d=mm&r=g)
Please let me know which platform you'd like me to elaborate on, and I'll be happy to delve into its security features and how they create a safe environment for email discussions or API interactions, whichever is relevant. https://attitudecaption.com/
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Sron Dev writes:
Please let me know which platform you'd like me to elaborate on,
Me personally? None. I don't have time for theoretical discussions. Maybe somebody else does, you're welcome to pick a platform and hold forth (but see below for venue, this is almost certainly not the right list for that).
If you, or anyone else, has a specific feature request, or requirement for "ensur[ing] a safe environment for email discussions", I'd be happy to discuss what we can do about that. That discussion should move to mailman-developers@python.org or mailman-users@mailman3.org depending on whether the RFE is fairly clear (-developers) or if it needs refining by input from other users (-users), as new features are not going to be added to Mailman 2 (the subject of this list).
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Steve, Sron, et al:
Regarding:
"ensur[ing] a safe environment for email discussions"
...I would hope that all netizens are fully aware (and obviously not all are) that there is not and cannot be such a thing as "safe environment for email discussions" with email as now practiced and to create it requires a serious overhaul of the way email is conducted.
It doesn't have to be this way: email bodies and even the destination username and other parts of email headers COULD be encrypted when enroute via the same mechanisms as we have long used for secured web sites, and even end-to-end encryption isn't too difficult to implement, and I'd lay a substantial bet that an open-sourced effort harnessing the ideas of DKIM / SPF / DMARC could easily and simply accomplish this.
However, the simple (and for me painful) truth is that The Powers That Be _obviously_ do not want us to have secure communications. Their excuse is fear ("terrorism!") and their more dominant motive is profit. It's truly as simple is that.
Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.
And therefore any discussion of "ensur[ing] a safe environment for email discussions" is a real head-scratcher for me!
Chalk this one up as yet another entry in the long list of our collective needs shot down by the "this is why we can't have nice things" excuse.
Regards, Richard
P.S. PERHAPS someone reading this has the energy and gumption to change this?! I sure hope so! ...I've been using email for 47 years now, I did my part, I tried hard, it's up to younger generations to carry it forward now. But I'll be happy to assist anyone else's efforts on this!
RT
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
richard@karmannghia.org writes:
My original point was I feel perfectly safe here on Mailman lists (of course I am in a position to get people banned, so I am in fact safer than the average bear, though I would not mess with a Kodiak).
True, and in fact many sites implement the enroute part, it's called mandatory TLS. I would imagine the proposals to make traffic analysis more difficult would apply here too.
I've thought a lot about this, it has been proposed multiple times as a GSoC project for Mailman, and this is simply not true for mailing lists as implemented in Mailman. In particular, it's simply not possible to achieve end-to-end encryption as a mailing list function. The list has to have access to the session key to give access to that key to subscribers, at which point you've been hacker-in-the-middle-d. I can imagine applications where you're willing to trust the list, though, and if there were demand for that, I'd be willing to supervise a GSoC student who wanted to implement it.
Note that it is certainly possible to have end-to-end encryption of list email, but it requires that each poster have all the subscriber keys. I guess you could marry a keyserver with a mailing list, and if you want to call that "end-to-end encryption via mailing list" go ahead, but you still have to solve the problem of getting posters to keep their keyrings up to date, so I consider that "not a mailing list function".
And of course you only asked for security of "data in motion", but then you've got the harder problem of securing data at rest (which also requires cooperation from either recipients or from their MUAs -- buwhahahahaha!)
It's not that simple though. While you're gonna need some *serious* booking up before you can win that substantial bet ;-), it would be possible (and has been done, cypherpunkery is real!) The problem is that we don't want it as bad as the cypherpunks did. So far we've been able to resist laws that require backdoors (who knows how many backdoors are there by bribery or other skullduggery, but it's not *legal*). So for some things we can win. But if we want really secure mail, as secure as for financial networks (which aren't perfect but they do OK), we're going to have to pay for it, and the average bloke isn't interested. They'd rather be outraged when their secrets get blabbed and their brother-in-law who actually did the dirty deed says "wasn't me, was some 400-lb-hacker-in-Mom's-basement".
Anyone who thinks their unencrypted emails are in any way secure on the open internet is, unfortunately SADLY mistaken.
This is true. Security by obscurity works up to a point, but if you ever get targeted by the FBI you're toast.
I'm not volunteering for the hacking part, but if somebody eligible for GSoC wants to propose it, and the mentors like the proposal, I'll mentor it.
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
On Tue, 30 Jan 2024, Dmitri Maziuk wrote:
You're obviously correct, Dima; who your mail host is matters, and who your recipent(s) mail hosts are also matter and if either is like Google, Hotmail, Yahoo, etc, well... it's pretty pointless.
People need to remember: If it's free, YOU are the product!
But more than that, I try and get people to understand that due to their ignorant choice of gmail, for example, I won't send them all kinds of emails I might otherwise send, even though it's not encrypted end-to-end because (as someone pointed out) obscurity works to a point, so SOME things I might not mind sending in that way.
I have a good handful of friends who I have managed to convince to move to Proton Mail because I just won't deal with them via email if they remain on gmail, etc.
Richard
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Hi Steve, Dima, et al:
Thanks for almost-volunteering. But lets make sure we're "on the same page." And I make a few other remarks along the way to maybe getting somewhere useful.
It's faster if I just get to the point rather than framing things in response to prior posts, so I hope this attempt at brevity works.
"Email safety" writ large has two fundamentally distinct elements.
The first is what I'd call the safety of the email itself and this is primarily about accessibility. This may be called privacy: who can access the email contents.
The second pertains to the "safety implications" of email content. This is primarily about legal violations such as libel, threats, incitement of violence, doxing, etc. This type of concern exists for all email but is amplified in the context of an email list.
Policy issues are unique to email lists, may include concerns from either email safety category and those policies that properly belong in neither are not of any interest to this discussion primarily because, first, they aren't a genuine safety concern and, if implemented by list management software like mailman, in effect amount to censorship of list content. Since email lists are on whole privately owned and operated, that's fine, and examples of censorship we can all probably agree on are spam and virus filtering. A human can step in where automated processing can't determine policy violations, hence the existence of a manual banning process.
Having said all that, my only real interest here is on the accessibility (privacy) aspect, and list-management software like mailman DOES have something to say about architectural details of implementation for an encrypted email world.
Rather than an all or nothing approach to encryption, I advocate a multilayered approach, with multiple levels of control and input. It is in this layering that mailing list software input is important.
A straight-forward approach might be, for example, that the entire set of data transferred between two MTAs is encrypted save the destination system's network address and the destination port. The MTA decrypts to get access to all the headers needed to hand it off to an MDA/LDA, and so on, down the chain of functions. It's entirely reasonable to design the architecture so the list management code has optional access to the body of an email, so some sites might keep things encrypted until the end recipients while others leave email decrypted, or even where it's decrypted for local use such as filtering and archiving but reencrypted for further transport on to list members.
All of this and much more is not particularly difficult to accomplish from a technical point of view - it's only a "Small Matter Of Code" as Michael Stonebraker (Turing Award Winner) famously says.
...This is what I want to get at. If anyone reading this cares to lend a hand (like YOU, Steve!) or make commentary, please contact me off-list as this is not really a mailman concern! Not yet anyway.
Now, some closing comments:
From the point of view of a mailing list, if the list itself is functional then there's no issue with traffic analysis insofar as legitimate analysis of list traffic is concerned. One would imagine that in a properly architected system designed to encrypt various email headers, the design would account for email-list-pertinent options.
From here, your analysis goes ... weird. I suppose one of us misunderstood the other: What's needed is something like "mandatory TLS" but even better since that doesn't, so far as I know, differentiate between headers and the email body, much less parts of the header such as the subject line. But it's the scope that's the weird part; this needs to be done at the MTA level, not at the mailing list manager level. At least that's my view
It's also far simpler to solve this at the MTA level. But then maybe I misunderstood you.
BTW, given that Google was started with "deep state" money and their continuing, on-going super-close cooperation with them, I wouldn't be looking to any GSoC effort to do anything useful on this topic since the entire "security state" is devoted to THEM having full encryption and YOU having none. The back-dooring they've compelled is nothing short of appalling.
My offer to help still stands; I can be an awesome ally but I shouldn't be the one trying to drive this as I'm spread too thin already!
Either way, this has taken up enough of the mailman list's time! So, if anyone cares to be engaged in this, email me privately and maybe we can work something out? SOMEBODY's got to do this!
Regards, Richard
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Hi Richard,
Thanks for your followup. Although you suggested taking the conversation private, I want to at least continue for one more post because it's not clear to me that there's demand for this service that is enough to justify the likely substantial cost of development. I don't know how to implement poster-to-subscriber encryption on the one hand, and on the other hand most list owners are unable or unwilling to manage their own hosts, and therefore have to provide the ability to decrypt list traffic to a third party.
But I could be quite wrong, and it's the members of the Mailman community who are most likely to provide a critical mass of users to say "that's just what I've always wanted, and here are the features I want". If that critical mass doesn't show up, then I want to use my time (and resources such as summer interns) on features that our community *does* want.
The fact that nobody but you has raised their hand to say "I want this" or "my list owners would really like this" is not a point in its favor.
However, let me say to anybody who has read this far that although I have played and continue to play the devil's advocate against "privacy-preserving mailing lists", I want everybody to understand that I am very much in favor of privacy. But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic. On the positive side, reduced- expectation implementations with encryption on the wire both directions and in queue files, for example, which would pretty much eliminate attacks on data-in-motion and somewhat reduce the attack surface for data-at-rest (eg, in queues on disk on the list host and possibly even in archives) might be useful in some applications. I would be happy to discuss such applications, and the cost of implementing them in Mailman (ie, how much writing and rewriting of code).
richard@karmannghia.org writes:
I believe we already have that in some profiles of IPSec. But that has nothing to do with mailing lists, and I'm not real interested in going into MTA implementation.
The MTA decrypts
Then the MTA is an agent-in-the-middle, and an obvious point of attack.
It's entirely reasonable to design the architecture so the list management code has optional access to the body of an email,
Now the list manager is an agent-in-the-middle and a point of attack, too. Both are very likely unacceptable in the case of a large-scale hosting service, without a massive effort to design and implement a key management system that can restrict access to keys to authorized uses. Absent such a system, the operator of a mailing list would also need to be a system administrator with security qualifications to match perceived threats.
As I pointed out above, a lot of it is already implemented -- but not in MTAs/MDAs, MUAs, or mailing lists. All of which have multiple implementations and those implementations must agree exactly, or somebody is going to get hacked.
I'm not sure what you mean by "traffic analysis". I am suggesting that membership in some encrypted lists will be considered privacy- relevant, and therefore mail being delivered from what is likely a single-purpose host to a mailbox infringes privacy of the mailbox's owner. Consider for example a list for victims of stalking or domestic violence. Knowledge that a target is subscribed to such a list could trigger violence on the part of the abuser.
In the mailing list context, the fundamental question of "properly architected" is "who has which keys and how do they get them?" Mandatory TLS solves the problem automatically for a single TCP connection. This can be generalized to automatic secure key exchange for all members of a (sufficiently small) synchronous group chat in the chat software. I don't see how it can be generalized to a mailing list which is fundamentally asynchronous, should deal with recipients whose MTAs almost certainly don't participate in such key exchange protocols (other than TLS), and potentially of much larger scale.
and even end-to-end encryption isn't too difficult to implement,
How do you propose to make that work, even for the simplest case of just encrypting the whole SMTP DATA element? The MTA doesn't know who the ultimate recipients are. Mandatory TLS can secure privacy-on-the- wire by using a secure key exchange protocol such as Diffie-Hellman because all you need to know is "the recipient is on the other end of this connection". But the mailing list stands between the MTA and the recipient.
It's also far simpler to solve this at the MTA level. But then maybe I misunderstood you.
I don't think you have thought through what the mail flows are, and at what points messages need to be decrypted and accessible to which software (and therefore potentially to human agents such as host administrators).
As I've said several times before in this kind of conversation, what we need to do is identify specific privacy threats (mechanisms for infringement) and user populations who need protection from them, and then see if we can design a list (and probably MTA) architecture that provides that protection.
Steve
![](https://secure.gravatar.com/avatar/22a09d8e743b6c5ea3a340d7f7f3eaf1.jpg?s=120&d=mm&r=g)
Stephen J. Turnbull wrote:
We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/
The idea is that there is a key for the list, the server decrypts the E-mails and encrypts it for the recipients who have supplied a key. Worked fine with that old version of Mailman 20 years ago.
But even in our quite nerdy environment only about the half of the subscribers submitted a key for the list. (excuses are like 'I want to use grep(1) for fulltext search in my list E-mails') So after the next mailman update we dropped the patch and run unencrypted again.
-- \ J. Dollinger FAW/n Ulm |zeitnot@irc| http://www.home.pages.de/~zeitnot/ \ "What're quantum mechanics?" -- "I don't know. People who / \ repair quantums, I suppose." (Terry Pratchett, Eric) /
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Juergen Dollinger writes:
We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/
Thank you for describing your experience! The people side is always hard. I'm not unhopeful though, but it's going to take work, especially good design.
That's exactly how I would do it, except you wouldn't receive posts until you submitted a key. Having half the copies vulnerable on-the-wire and on-disk would not fill me with warm fuzzy feelings. :-)
I think this could be fairly useful in environments where people are paranoid enough to leave the mail encrypted on disk. But even the DV case that I mentioned -- would it stay encrypted for long if a few of the abusers discovered its existence? It would only take one!
Today I don't think that excuse would fly, machines are fast enough that few email bodies would take noticable time to decrypt, and languages like Python and Perl provide very high quality email processing libraries. p-grep-p would be written real fast, and it would work fast too.
Steve
![](https://secure.gravatar.com/avatar/9edcb608a75e597938e3901ba0d6fbbc.jpg?s=120&d=mm&r=g)
Steven, Juergen, et al,
I had written most of this but interrupted, then Jurgen's email came in, so... this got an edit! If a spot or two seems awkward it's because of available time.
On Mon, 5 Feb 2024, Stephen J. Turnbull wrote:
It's very straight-forward:
Public Key Encryption is used: Subscribers who want encrypted email include their public key in their subscription details, just as they include their name and digest type choices. The list itself, for its reception, uses TLS. The outbound, from list server to subscriber is where "the magic happens," encrypting the outbound to each user using their own public key.
And then Juergen, as if on cue, added:
on Tue, 6 Feb 2024, Juergen Dollinger wrote:
I was unaware of this and I would have latched on with both hands!
Note that 20 years ago people, on whole, were less aware of the issues with unencrypted emails and that HALF DID sign up is rather amazing. Most users 20 years ago had "grown up with" a very friendly internet and remembered those times without perceiving the risks, while the newcomers were clueless to pretty much everything. Therefore the aprox. 50% number is amazing.
HOWEVER, just becasue ONE email list of a group who realized it was there had that experience says NOT A THING about how many who didn't know would love to have a list where users HAD to use encryption to be on the list!
Consider that the safest email is one in which sender and recipient are on the same system, MANY corporate environs would likely LOVE to have the added flexibility and security that could come from having an email list with this capability used for communications with not just employees but their vendors.
It's myopic to see just one's own use case and think it applies across the board.
Moving on, Steve goes on to say:
Over my long and storied 47 year career in computer science I've long noted that the vast majority of users:
Don't know what they really want;
Don't have a clue what's easy and what's hard, and;
Don't hang out on email lists like this one.
(BTW the vast majority of project managers fit this same profile and explains why we get such atrociously bad software sometimes, even from gifted teams; if management is ignorant, it leads to less-than-optimal results, especially with autocratic leadership that doesn't trust their teams or want their creativity or input. But I digress...)
Steve:
Your argument isn't any better.
The a majority of users have no clue that their emails are vulnerable in transit on the internet, much less as a separate risk from their email provider. So if it's your idea that we don't offer people the chance for better and only focus on giving people what they already know they want, progress is ... "suboptimal."
Good.
But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic.
That is abjectly false, Juergen proved it, and not only was it NOT difficult 20 years ago, in the 20 years since then what's fairly easily possible has expanded considerably.
BTW, that one of us doesn't know how such things are done, by the way, doesn't mean it's difficult. I love Will Roger's comment about such things: "Everybody's ignorant, just about different things is all!"
It's no strike against anyone they don't know how things might be accomplished, but something we all need to watch out for is our own false presumption that if we don't see how something can be done it must be hard.
The BIG question here is surely beyond this list's purview: Can we manage to get an easy-to-use mechanism where any given user's public key can be found? We now have at least The Electronic Frontier Foundation, LetsEncrypt, and Proton AG who might well lend some muscle in this venture: Think of a DNS-like system, perhaps even an actual evolution of DNS itself, that permits users to declare their public keys in a publicly findable way. For sites that want to keep user lists private but still do this, perhaps a validation server could be devized with site-specific policies on who gets to know what about a given username@domain entry - think "I want to send encrypted email to user@your.system," and the mail server or some similar server looks at the request and honors it by sending the public key or not.
I posit that such a change would cause an explosion of use of encryption for the simple reason that it's use can then be largely automated and thus remove a huge fraction of the burden from the individual. It would enable FAR more security, writ-large, than is under discussion here. I won't bother you with all of it but just point your brain in pondering the power of a very simple back-and-forth, "I use your key to send you something encrypted, you send it back encrypted with my key telling me what it is and we just validated each other."
IF a list manger like mailman wanted to handle this it surely could! In that instance the broader key management via DNS or DNS-like system is not necessary.
As for users wanting to grep emails, that's a lame excuse: Just leave the email unencrypted in your local folder! That one's born of lazyness not capability. However, using encryption today CAN BE an annoying thing. My goal is to remove the time consuming hassle.
Richard / Steve dialogue:
I've never seen / noticed that. A pointer would be nice!
The MTA decrypts
Then the MTA is an agent-in-the-middle, and an obvious point of attack.
Yawn. Let people decide what their comfort level of risk is. The idea is to ENABLE.
I never said this was only a mailing list issue. We, collectively, need a better infrastructure.
The privacy threat: Unencrypted email in transit on the internet.
Affected user population: All email users.
And yes, MTA is the correct level, though as noted above, an email list CAN help a lot WITHOUT an MTA level "fix".
Regards, Richard
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
richard@karmannghia.org writes:
It's very straight-forward:
C'mon, man, Grandpa knows how to tie his shoes. The construction of such an encrypted list not technically terribly complex---as you said yourself, a SMOC. The problems are describing *who* is the adversary, *what* will they do to invade your privacy, and *how* does the proposed system thwart those threats. You are completely ignoring those questions. And no, "unencrypted mail is a threat" to "everybody" isn't a serious attempt to address them, given that almost everyone is using MTAs that support TLS nowadays.
Subscribers who want encrypted email include their public key in their subscription details,
What about the needs of *posters*, who are *at least* as important as subscribers here, who want to keep *their* posts private? That's why "encryption-optional" lists make no sense to me, except as a proof of concept. And the prescription to greppers to leave their mail folders unencrypted is not comforting to the authors, either.
I see vanishly small added security in an encryption-optional mailing list of the kind Juergen described. As a proof-of-concept, it was a brave experiment that maybe could have led to something. But it didn't.
Round 'em up, man. I listen to the community. I'm listening to you.
So? I think they *do* know a very large fraction of what they want at the level of expressing *requirements* (WIBNI ...). Dealing with what's easy and what's hard is our problem as developers, not theirs. With that knowledge, we can help them refine and prioritize their requirements, and sometimes discover new ones. Convincing them that we understand their requirements and know easy vs. hard is also our problem. And the lack of like-thinking users on mailing lists like this one is a problem for advocates (like you?)
Your definition of "end-to-end" is not the one in common use. A system where an intermediate node decrypts, then reencrypts and forwards, is not "end-to-end encrypted" in any usage I've seen before,
It's really not useful to discuss technical issues if you won't at least use the accepted definitions of such critical terms. You're welcome to argue that given the threats you perceive, it's not an important requirement for an encrypted mailing list. But given the ease which which systems are penetrated these days, I disagree for most purposes I can think of.
Steve
![](https://secure.gravatar.com/avatar/02cc25ec5c6cd5c6a65a6d94817fe815.jpg?s=120&d=mm&r=g)
It appears to me that the author of this message just wants to deposit his spam. The website referenced in the message has nothing at all to do with Mail / Mailman / Computing.
Please don’t feed the trolls...
Christian
Sron Dev schrieb am 28.01.24 um 15:43:
Please let me know which platform you'd like me to elaborate on, and I'll be happy to delve into its security features and how they create a safe environment for email discussions or API interactions, whichever is relevant. https://attitudecaption.com/
participants (9)
-
Christian Buser
-
Dmitri Maziuk
-
Juergen Dollinger
-
Odhiambo Washington
-
Richard
-
richard@karmannghia.org
-
sanjay jangam
-
Sron Dev
-
Stephen J. Turnbull