[Mailman-Users] Re: Security features of Mailman
rich...@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. > 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! [...] > It's myopic to see just one's own use case and think it applies > across the board. Round 'em up, man. I listen to the community. I'm listening to you. > Over my long and storied 47 year career in computer science I've long > noted that the vast majority of users: > > 1) Don't know what they really want; > 2) Don't have a clue what's easy and what's hard, and; > 3) Don't hang out on email lists like this one. 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?) > > 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. 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 -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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. > 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. 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! > 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') 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 -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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: 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 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: 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. 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: 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. Over my long and storied 47 year career in computer science I've long noted that the vast majority of users: 1) Don't know what they really want; 2) Don't have a clue what's easy and what's hard, and; 3) 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: 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. 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." 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. 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
[Mailman-Users] Re: Security features of Mailman
Stephen J. Turnbull wrote: > 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. 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) / -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@mail-archive.com
[Mailman-Users] Re: Security features of Mailman
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). rich...@karmannghia.org writes: > [M]y 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. [...] > 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. 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. > 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. 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. > 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. 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. > One would imagine that in a properly architected system designed to > encrypt various email headers, the design would account for > email-list-pertinent options. 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
[Mailman-Users] Re: Security features of Mailman
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: 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. 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. > 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. 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. 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
[Mailman-Users] Re: Security features of Mailman
On Tue, 30 Jan 2024, Dmitri Maziuk wrote: On 1/30/24 07:47, Stephen J. Turnbull wrote: rich...@karmannghia.org writes: ... > 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. Whereas anyone who thinks their encrypted-in-transit e-mails are in any way secure on gmail servers, is delusional. Google gives FBI access to mailboxes, and they won't ever tell you because gag orders (google it). Dima 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 -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
On 1/30/24 07:47, Stephen J. Turnbull wrote: rich...@karmannghia.org writes: ... > 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. Whereas anyone who thinks their encrypted-in-transit e-mails are in any way secure on gmail servers, is delusional. Google gives FBI access to mailboxes, and they won't ever tell you because gag orders (google it). Dima -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
rich...@karmannghia.org writes:
> ...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.
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).
> 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,
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.
> 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.
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!)
> 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.
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.
> 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!
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
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
Christian Buser via Mailman-Users writes: > Please don’t feed the trolls... I don't have time to visit trolly websites, either. Lucky me, this time! :) :) :) -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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/ > -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
On Mon, 29 Jan 2024, Dmitri Maziuk wrote: Given what a sentence like "ensur[ing] a safe environment for email discussions" means in the current US political climate, when I see something like that, I killfile the sender. IJS, Dima Oh Gawd, Dima, sensorship vs spying?! I missed that entirely! -eye-roll- Richard -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
On 1/29/24 09:39, rich...@karmannghia.org wrote: 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" ... Given what a sentence like "ensur[ing] a safe environment for email discussions" means in the current US political climate, when I see something like that, I killfile the sender. IJS, Dima -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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-develop...@python.org or mailman-us...@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 -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
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/ -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Security features of Mailman
On Tue, Jan 16, 2024 at 8:54 PM sanjay jangam wrote: > 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 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] -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@mail-archive.com
