MBOX-Line: From Pidgeot18 at verizon.net  Mon Mar  9 18:15:49 2015
To: imap-protocol@u.washington.edu
From: Joshua Cranmer <Pidgeot18@verizon.net>
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: <CABa8R6t=B-buGCWwME5N6T6xEvr_aPpQVVK70GBNm2WgAa8oBw@mail.gmail.com>
References: <54FAEB94.4070508@lavabitllc.com> <54FBF289.3010202@psaux.com>
	<7164.1425831184@parc.com>
	<1425907661.1215497.237833469.1EDA571D@webmail.messagingengine.com>
	<6506.1425915329@parc.com>	<B03452330F6149E180E449A493F28C2B@gmail.com>
	<CAP1qinZdV1LW6XiWfqfk2A+TC6HsYsAWtT-KSffTNdOFqG_Tjw@mail.gmail.com>
	<7782A916-12BB-488C-BD57-697FDB5D47E2@orthanc.ca>
	<CAP1qinY-d_fpmfwJ=04GUZhAnkZpPxzwMGfVdn8--4z=tJT5_w@mail.gmail.com>
	<B79CBCA4E66D446690A5A91A7A88BA48@gmail.com>
	<CABa8R6t=B-buGCWwME5N6T6xEvr_aPpQVVK70GBNm2WgAa8oBw@mail.gmail.com>
Message-ID: <54FE45C5.2030207@verizon.net>

On 3/9/2015 7:01 PM, Brandon Long wrote:
> We witnessed quite a big portion of cpu involved in un-dot-stuffing 
> smtp (and correcting line endings) and saved quite a bit of that with 
> supporting BDAT.

Yeah, dot-stuffing definitely seems to me to be the slowest and worst 
part of SMTP: if you use BDAT, you could use splice() or similar kernel 
features to just shunt things between sockets and files without needing 
to do immediate inspection. And I'm guessing that almost of the time 
spent having to work with the SMTP protocol itself (as opposed to 
necessary routing or processing logic) is likely to be worrying about 
dot-stuffing, since it's most of the datastream by size and it's not a 
unitary transformation.

> On Mon, Mar 9, 2015 at 4:54 PM, Hoa V. Dinh <dinh.viet.hoa@gmail.com 
> <mailto:dinh.viet.hoa@gmail.com>> wrote:
>
>     Unfortunately, mail servers have to deal with the existing world
>     of emails,
>     where there are charset encoding, MIME encoding, spinning disks
>     and memory.
>

Well, if you're talking about replacing the rfc 5322/MIME format, there 
is certainly a large number of historical warts and issues that could be 
fixed that are completely orthogonal to text versus binary.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150309/25e90d05/attachment.html>
