Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication

[Hector Santos <hsantos@xxxxxxxxxxxxxx>]

Frank Ellermann wrote:
> Lisa Dusseault wrote:
>
> > Any comments on the document, its intended publication status or current
> > implementation status, are welcome.
>
> It won't surprise anybody that I don't like DIGEST-MD5, and consider the
> idea to make it mandatory for POP3 as completely wrong.  None of the POP3
> servers I know support SASL, let alone DIGEST-MD5.

Our POP3 server supports implicit SSL (port 995), SASL including DIGEST-MD5.

c:> telnet mail.winserver.com 110

+OK Wildcat! POP3 Server v6.1.451.10 ready <long-challenge-string>
AUTH
+OK list of supported mechanisms follows
CRAM-MD4
DIGEST-MD5
LOGIN
PLAIN
.

Now, have I ever come across a client using DIGEST-MD5?  No, not that I 
recall.  If I recall its mainly LOGIN or PLAIN for Windows or MAC based 
MUAs or CRAM-MD5 for EUDORA or typically Mozilla based MUAs. I believe 
Windows OE also looks for a proprietary AUTH NTLM mechanism.

> The syntax as is allows AUTH mech =<crlf>base64<crlf>crlf>base64<crlf>
>
> 4: How does the server determine the end of an <initial-response> ?

Ironically, this might explain what we saw recently.  We recently came 
across an issue where we needed to do a correction in our SASL logic for 
our SMTP and POP3 servers. Didn't analyzed it in detail, but it seem to 
be related to the network behavior of PDA devices where this information 
comes in two packets or commands:

In short it seems they were sending:

  PKT1:  AUTH mechanism<CRLF>
  PKT2:  base64<crlf>
  PKT3:  <crlf>
  PKT4:  base64<crlf>

or

  PKT1:  AUTH mechanism<CRLF>
  PKT2:  base64
  PKT3:  <crlf>
  PKT4:  base64<crlf>

We had to check and read for possible extra 2 <CRLF> bytes after the 
initial client buffer (PKT2) was read.  This was a behavior only seen 
with certain PDA or Smartphone POP3 client software.

---
HLS