Re: [Extra] draft-ietf-extra-imap4rev2-04 review

"Chris Newman" <> Tue, 26 March 2019 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F82412029A for <>; Tue, 26 Mar 2019 01:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TFWlHhOdKCKc for <>; Tue, 26 Mar 2019 01:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE56C12025C for <>; Tue, 26 Mar 2019 01:46:13 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x2Q8hpFC160559; Tue, 26 Mar 2019 08:46:12 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=ksNrLn/xgH5EAMWpqebRDFHV5hHQMwuApNMbAllaeUA=; b=x8DUtTk32l1z/tn2ZiMuSW1ElqnPBEWzQvi8WJqMUZDeA+dKskGT2smlwnRsvVji36Ej BBnC3v+YntALp+vaTrtWtVZyATVtNoksdwD/GXRxGh0vJv+1Z0bXqfglZNu5wjhRkACj 9m/xPyPKIq+/mrPtJO0suG4ncFnrMXtrUuCJgaHkfyCPOwZplrHMmz/X26fCwZp1B/iD 6kUmXdvg+qdO6u8rQ93pIojNmLNjrWdtiuZpsSK0tFV6XeOJILzdk191PdwkvDn3Ruo9 Jqln9NGhRaTmiA8DsXOWY4N2AqfwUzJq1jO7gsi36SrQFx6sE4Wfd3cxT9u5otpASbXN eQ==
Received: from ( []) by with ESMTP id 2re6g0ry4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Mar 2019 08:46:12 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x2Q8k5I9026740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Mar 2019 08:46:07 GMT
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id x2Q8k0ww011273; Tue, 26 Mar 2019 08:46:00 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Mar 2019 01:46:00 -0700
From: "Chris Newman" <>
To: "Timo Sirainen" <>
Date: Tue, 26 Mar 2019 09:45:57 +0100
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9206 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903260066
Archived-At: <>
Subject: Re: [Extra] draft-ietf-extra-imap4rev2-04 review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Mar 2019 08:46:45 -0000

On 25 Mar 2019, at 13:04, Timo Sirainen wrote:
>> 3.4.  Logout State
>>    A server MUST NOT unilaterally close the connection without 
>> sending
>>    an untagged BYE response that contains the reason for having done 
>> so.
> Also already in RFC 3501, but this MUST NOT has to be violated 
> sometimes. For example otherwise it would allow client to FETCH a 
> large message and keep reading it very very slowly over days, and 
> server wouldn't be allowed to disconnect it, because it can't send BYE 
> in the middle of the large mail literal.

Another example is if a client gets hung up (or goes silently offline) 
during a TLS negotiation. The server has to eventually timeout the 
connection but it would be semantically wrong to send a "* BYE" since 
there's no data channel. One case where this happened was when our SSL 
stack dropped support for an SSLv2-compatible hello (allowed by RFC 
6176), but some very old client kept sending such a hello (prohibited by 
RFC 6176). Incidentally, SSLv2 is completely incompatible with SSLv3 so 
the client sends something that's not sufficient to complete an SSLv3 
packet so both ends get stuck waiting until one side hangs up.

>> 5.1.  Mailbox Naming
>> servers MAY accept a de-normalized UTF-8 mailbox name and convert it 
>> to Net-Unicode prior to mailbox creation).
> and:
>> Some server implementations
>>    are fully case-sensitive in ASCII range; others preserve case of a
>>    newly-created name but otherwise are case-insensitive; and yet 
>> others
>>    coerce names to a particular case.
> This seems rather difficult from client's point of view. It CREATEs a 
> mailbox, but the client can't find it anymore because it changed. 
> Seems to me it would be less strange if the server simply failed the 
> CREATE entirely.

I had mistakenly thought this as well until I encountered the real-world 
situation. There are widely deployed mail clients that do not normalize 
Unicode when sending it to the server for mailbox names and also behave 
very badly from a UI perspective if CREATE fails. I tried an 
implementation which rejected CREATE when the client used a name in 
violation of 5198 and a customer insisted I provide a way to allow 
invalid names.

> If this is allowed for CREATE, is such conversion done for 

I doubt this is necessary in practice. Most clients will take what they 
get from LIST responses and use that. Clients also have to deal well 
with SELECT/EXAMINE/APPEND failures because of reality.

> What about LIST "" <non-normalized name> - would it return the 
> normalized name?

I doubt most clients use that form of list, so I wouldn't implement that 
unless necessary.

		- Chris