37 lines
1.7 KiB
Plaintext
37 lines
1.7 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Sun Mar 8 03:34:58 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <25599.1425793832@parc.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com>
|
|
<CAKHUCzzirU0YEQ02n1zEypZCvUJ+0dU0CuPxT=ZnowTk_R6jOg@mail.gmail.com>
|
|
<54FB22EB.7090707@lavabitllc.com> <8701.1425748438@parc.com>
|
|
<54FB3E1F.3020909@lavabitllc.com> <25599.1425793832@parc.com>
|
|
Message-ID: <42edfcce-7703-4d8f-8c50-03f1704335dd@gulbrandsen.priv.no>
|
|
|
|
Bill Janssen writes:
|
|
> But what I'm doing is an MTA-to-MTA protocol; what you're looking at is
|
|
> an MUA-MTA protocol, like IMAP. On the other hand, in my design the MUA
|
|
> *is* the MTA, so perhaps there's no difference.
|
|
|
|
In Ladar's case there ought not to be any difference... I hereby define
|
|
end-to-end encrypted mail that's encrypted by the sender rather than a
|
|
third party, is handled by zero or more third parties en route, and is then
|
|
decrypted at the last possible moment before the point where the recipient
|
|
wants to thread or search the mail.
|
|
|
|
Lots of people disagree with that definion, and want to keep the mail
|
|
encrypted at the point where it's threaded and searched. Folly, say I. Do
|
|
that, and either the processing or the encryption has to be hobbled.
|
|
|
|
In your design, the thread and seach functions are moved very close to the
|
|
human recipient, which may be expensive in terms of bandwidth and storage,
|
|
but for Ladar, that's just the price of proper encryption. It's not a
|
|
drawback of your design when compared to other possibilities that also
|
|
encrypt properly.
|
|
|
|
Arnt
|
|
|