Are we talking about TLS on the IANA registerd port 993/TCP or are we talking about STARTTLS over a potentially clear text port 143/TCP ?
Thank you for clarifying. Randall On Thu, 30 May 2002, Mark Crispin wrote: : OK, I'm trying to digest all of this. : : It seems clear to me that TLS+AUTH=PLAIN will be a solution, and will be : required of all IMAP server implementations. I have not seen any : objection to either "TLS+AUTH=PLAIN is a solution" or "TLS+AUTH=PLAIN is : required of all server implementations." : : What is under debate is whether or not TLS+AUTH=PLAIN is *the* solution. : : Is a client is required to implement TLS+AUTH=PLAIN? : : If the answer is "yes", we have the option of declaring the problem : solved, put it in the document, and submit to IESG. : : If the answer is "no", then we must select one or more AUTH=xxx methods : that are MANDATORY for server implementation. A client, on the other : hand, only needs to implement one of the server-mandatory methods. : : After careful consideration, I have concluded that if Kerberos (GSSAPI and : KERBEROS_V4) is not suitable, then CRAM-MD5 and DIGEST-MD5 are also : unsuitable. Like Kerberos, CRAM-MD5 and DIGEST-MD5 make demands upon the : server's authentication capabilities that some servers may be unable to : fufill. Kerberos requires the services of a KDB, and CRAM-MD5 and : DIGEST-MD5 require the server to have a plaintext equivalent of the : password. : : Modern operating systems store passwords in a one-way encrypted form. If : a server implementation is required to use the host operating system's : userids and passwords (particularly if a system call is needed to log in), : then CRAM-MD5 and DIGEST-MD5 are unimplementable. : : This, by itself, indicates to me that we should rule out making either : CRAM-MD5 or DIGEST-MD5 be mandatory to implement on a server. : : I therefore recommend to the group that we declare that: : . *the* solution is TLS+AUTH=PLAIN : . TLS+AUTH=PLAIN is mandatory to implement on both client and server : . the problem is solved : and abandon alternatives. : : -- Mark -- : : http://staff.washington.edu/mrc : Science does not emerge from voting, party politics, or public debate. : :