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

