wasm-demo/demo/ermis-f/imap-protocol/cur/1600095029.22641.mbox:2,S

67 lines
3.1 KiB
Plaintext

MBOX-Line: From brong at fastmail.fm Tue Mar 18 20:34:06 2014
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun 8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <0327E34F-DD13-4350-A16F-FE621E029FEB@orthanc.ca>
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
<20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
<1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
<08C9B4E3-B0C3-40B3-AF7A-1B29FA09A0C9@orthanc.ca>
<1395195811.7439.96177201.64A35884@webmail.messagingengine.com>
<0327E34F-DD13-4350-A16F-FE621E029FEB@orthanc.ca>
Message-ID: <1395200046.23977.96193797.757C6481@webmail.messagingengine.com>
On Wed, Mar 19, 2014, at 02:00 PM, Lyndon Nerenberg wrote:
> Okay, not completely. I was discouraging against SSL on 993 for one main reason:
>
> If SSL is proven broken, where do we go? Another port for another encryption layer? How does that scale?
Badly, I presume.
> And I think that was the crux of the overall IETF argument against allocating dedicated ports to dedicated SSL versions of the existing protocols. SRV was supposed to mitigate against that, but SRV hasn't taken over the protocol developer community.
Indeed.
> > We don't need a wayback machine to fix the future.
>
> But we need it to fix the past, and that's what you are complaining about.
Not entirely, I'll articulate what I'm complaining about in a moment...
> But how do you propose to solve this in an everlasting manner? Imagine how embarrassed you will be when your grandchildren break your perfect encryption system on their laptops. From the womb.
I've seen an awful lot of "you are gonna need it" (to flip around what the
kids these days call YAGNI) justification for broken stuff in the standards
world. Stuff that's so future-proof and optimised for the 1% cases that it
fails to perform the 99% case here and now adequately.
You see it all the time in standards with low and poor adoption. Optimising
for the edge cases. Case in point the argument against SUBMIT via IMAP and
POP - instead needing a separate authenticated connection for SMTP so that it
can support all the future extensions which might be added to SMTP.
Meanwhile everyone has been in a support nightmare for years. I remember
ISPs with POP before SMTP rubbish to work around the fact that you couldn't
just shove the outbound message up your POP connection.
And I _still_ see issues where SMTP connectivity is blocked but IMAP is working,
and people can't send email from their clients on some networks. Not a total
failure, but a partial failure.
And the "standard fix"? BURL. Instead of converting two possibilities of failure
into a single "it's on or off" it creates a triangle, in which any one of THREE
different interlinks could fail, making things break. Funnily enough, I don't see
very much of it out there.
It's broken for now because of assumed future risks. And that's my problem with
the standards world.
Bron.
--
Bron Gondwana
brong@fastmail.fm