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

87 lines
3.2 KiB
Plaintext

MBOX-Line: From blong at google.com Mon Mar 9 17:01:16 2015
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
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: <B79CBCA4E66D446690A5A91A7A88BA48@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>
Message-ID: <CABa8R6t=B-buGCWwME5N6T6xEvr_aPpQVVK70GBNm2WgAa8oBw@mail.gmail.com>
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.
OTOH, I don't think IMAP parsing has been a large CPU issue for us,
partially because with LITERAL we already skip through the larger data
pieces.
Brandon
On Mon, Mar 9, 2015 at 4:54 PM, Hoa V. Dinh <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.
>
> Lots of those operation have to happen until every users of emails move to
> anything else than email.
> That said, spinning disks and memory might be still around.
>
> Also, I actually think that the text protocol is neglectable in term of
> CPU usage (and that?s also a subjective assessment), compare to let?s say
> indexing of emails for search.
>
> --
> Hoa V. Dinh
>
> On Monday, March 9, 2015 at 4:44 PM, Imants Cekusins wrote:
>
> Is your measurement data and methodology for this available online
> anywhere?
>
>
> this is a subjective assessment. Email servers are way too busy for
> what they deliver. I believe it is for these reasons:
>
> Parsing takes time. So does transfer decoding and charset conversion,
> unwrapping text, dot stuffing.
>
> It can be reduced to:
> no case conversion for commands; no parsing for commands even: a
> simple switch case statement suffice;
>
> no parsing for CRLF, empty line or DOT CRLF; actually, no content
> parsing at all is necessary for transmission;
>
> no transfer encoding / decoding (it is transferred as binary);
>
> no charset decoding: a single encoding is applied to the entire (text
> part of) the message.
>
>
> Simply from pragmatic point of view: if these tasks need not to be
> done, server is less busy and can process higher throughput.
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150309/02939ddd/attachment.html>