Let's frame the threat models. Bulk collection probably does
not include using OS backdoors so the suggestion to use mutt
on BSD isn't wrong, but not necessary to move a step forward.
On Sun, Nov 01, 2015 at 05:39:29PM +0100, ma...@wk3.org wrote:
> I think mail providers should stop accepting starttls opportunisticly,
> but should start requiring it.
Whereas man-in-the-middling SMTP federation connections
(same problem as with XMPP and IRC networks) may be rather
cheap: How do mail servers check certificates? Do they
pin them down? Do they accept anything valid? Do they
ignore certificate validity? What if anything went wrong
during interserver-TLS. Will the end-user ever find out?
Do the new "Received" headers really reflect such info
and how would you explain what certain headers mean to
the end user?.. given the "Received" headers are accurate,
as questioned in previous mail. And then you may bump
into mail providers that use inconsistent certificates
like it happened for us who developed "Certificate Patrol"
to find out that the majority of our potential users can't
handle the frequent amount of questionable https
connections the industry confronts them with, given such
freedoms in the broken X.509 standard TLS is built upon.
Yes, mail providers should require STARTTLS, but it leaves
a dozen insecurities up in the air which are structural
to the very bad protocol standards we have. It's less work
to design a new mail system from scratch than to reduce
the insecurities of SMTP from 31 to 30.
--
E-mail is public! Talk to me in private using encryption:
http://loupsycedyglgamf.onion/LynX/
irc://loupsycedyglgamf.onion:67/lynX
https://psyced.org:34443/LynX/
--
Liberationtech is public & archives are searchable on Google. Violations of
list guidelines will get you moderated:
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe,
change to digest, or change password by emailing moderator at
compa...@stanford.edu.
