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