On Tue, 16 Dec 2003, Thomas Boerkel wrote: > > > I installed open-ssl and then recompiled uw-imap. Still TLS does not work. > > How does it "not work"? > I cannot log in and the only messages I got are those below from Mozilla and > from /var/log/mail.
If I understand your problem report correctly, you can not log in when you connect on port 143. There is no evidence that TLS is not working. Is this correct? > When I connect with telnet, I get this at port 143: > * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS LOGINDISABLED] admnb IMAP4rev1 > 2003.339 at Tue, 16 Dec 2003 08:13:03 +0100 (CET) > Monitoring the communication, it seems that Mozilla does not do STARTTLS. It > only tries "authenticate plain". Can you provide a complete transcript of the session up to (and including) the AUTHENTICATE PLAIN? Did the client do a CAPABILITY command prior to the AUTHENTICATE PLAIN? What indication did the client receive that it was permitted to do an AUTHENTICATE PLAIN? > > > I have activated "Use secure authentication" in Mozilla 1.5, but it says > > > "Login to server blah failed" and I get "AUTHENTICATE PLAIN failure" in > > > /var/log/mail. > > This is authentication, which is a separate issue. > Hm, doesn't that error message mean, that Mozilla tries to do plain > authentication when it should do STARTTLS first? ;-) If the client did AUTHENTICATE PLAIN without any indication from the server of the "AUTH=PLAIN" capability, then the client is broken: it is violating the requirements of the IMAP protocol. A client MUST NOT attempt to negotiate a SASL mechanism that was not advertised in a capability list, either from the capabilities in the greeting or from the results of a CAPABILITY command. > It is not described in the docs, but I tested with another server (monitoring > the communication) that does not send its capabilities and it seems Mozilla > then does "authenticate CRAM-MD5". If the client did AUTHENTICATE CRAM-MD5 without any indication from the server of the "AUTH=CRAM-MD5" capability, then the client is broken: it is violating the requirements of the IMAP protocol. > So, it seems that Mozilla can not do TLS over 143. That may be the case. If so, you should bring up this issue with the developers of Mozilla. > I have now tried to use CRAM-MD5. I enabled it in uw-imap and it correctly > advertises it in the capabilities. Still Mozilla does not start with > "authenticate CRAM-MD5". It seems that Mozilla has problems interpreting the > capabilities. This also sounds like something that you should should bring up with the developers of Mozilla. > If I use CRAM-MD5, can I do login via port 143 then? I don't know. The problem appears to be that Mozilla (or at least the copy of Mozilla that you have) is broken. It is completely unpredictable what broken software will do. Although there may be a problem in the copy of UW imapd that you have, so far the evidence that you've provided indicates that UW imapd is performing correctly according to its design and the IMAP specification. > Can I disable advertising the capabilities in uw-imap? It is an ill-advised strategy to attempt to solve a problem with software that is known to be broken by randomly breaking software that is known to work, and hoping that the resulting combination of broken software will work together. The correct thing to do is to contact the developers of Mozilla, and report the following: 1) Mozilla does not seem to negotiate STARTTLS with a server that advertises it. 2) Mozilla apparently attempts to negotiate SASL authentication mechanisms (such as CRAM-MD5 and PLAIN) when there has been no server authorization of such mechanisms. 3) Mozilla apparently declines to negotiate SASL authentication mechanisms (such as CRAM-MD5 and PLAIN) when there is server authorization of such mechanisms. Unfortunately, these statements are prevarications, because I am interpreting your interpretations of what you observed. It would be better if you could provide actual transcripts of the protocol negotiations. I think that the Mozilla developers would be happier with such transcripts as well; that way they can see for themselves what is going on rather than deal with guesses. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
