[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
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
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
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
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
