33 lines
1.4 KiB
Plaintext
33 lines
1.4 KiB
Plaintext
MBOX-Line: From blong at google.com Wed Jan 15 13:07:45 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Email charset statistics
|
|
In-Reply-To: <6a420a96-0755-48c3-b8d7-f208c6de14a1@gulbrandsen.priv.no>
|
|
References: <52D5D84D.6070208@verizon.net>
|
|
<6a420a96-0755-48c3-b8d7-f208c6de14a1@gulbrandsen.priv.no>
|
|
Message-ID: <CABa8R6vUg2RFxEobH9u+1pBxJ5C7u991EL9es2BBWJ3=ZGWpyw@mail.gmail.com>
|
|
|
|
On Wed, Jan 15, 2014 at 12:13 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no
|
|
> wrote:
|
|
|
|
> On Wednesday, January 15, 2014 2:08:47 AM CEST, Brandon Long wrote:
|
|
>
|
|
>> It also makes the downgrade part of RFC5738 look pretty silly, as I
|
|
>> imagine almost every IMAP server is basically doing the same thing today,
|
|
>> sending 8bits blindly, assuming the headers were 7bit clean. It seems like
|
|
>> implementing RFC5738 makes your server break more messages than it fixes.
|
|
>>
|
|
>
|
|
> Yes, but why are you doing 5738 instead of 6855?
|
|
|
|
|
|
Didn't remember the exact rfc and did a quick search to find it. Yes, I
|
|
meant 6855... which really could use more information on how its different
|
|
from 5738, as I look at both right now. 6855 just says it obsoletes 5738.
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140115/cea73807/attachment.html>
|