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.
