[mpop-users] POP3 Authorization using SCRAM-SHA-1 fails

[Steffen Lehmann <mpop@...34... >]

POP3 Authorization using SCRAM-SHA-1 fails, because mpop violates the rules 
according to SASL RFC 4422, Section 3:
"Where the mechanism specifies that the server is to return additional
data to the client with a successful outcome and this field is
unavailable or unused, the additional data is sent as a challenge
whose response is empty. After receiving this response, the server
then indicates the successful outcome."

RFC 5034, Section 4:
"Note that POP3 does not allow for additional data to be sent
with a message indicating a successfull outcome (see Section 3.6 of RFC 4422)."

Hence, the following message sequence according to SASL RFC 4422, Section 3 
applies:

C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange

But mpop behaves as following:

C: AUTH SCRAM-SHA-1  (POP3: command request)
S: +                 (SASL: Initial challenge)
C: biwsb...          (SASL: Initial response; RFC 5802 client-first-message) 
S: + cj01b2t...      (SASL: additional challenge; RFC 5802 server-first-
message)
C: Yz1iaX...         (SASL: additional response; RFC 5802 client-final-message)
S: + dj1mT...        (SASL: additional challenge; RFC 5802 server-final-
message)
C: STAT              (POP3: command request, unexpected here, the server waits 
for the 'Empty Response')

Obviously, mpop takes the RFC 5802 server-final-message incorrectly as 
successful outcome to the "AUTH SCRAM-SHA-1" POP3 command.

The right message sequence must be:

C: AUTH SCRAM-SHA-1  (POP3: command request)
S: +                 (SASL: Initial challenge)
C: biwsb...          (SASL: Initial response; RFC 5802 client-first-message) 
S: + cj01b2t...      (SASL: additional challenge; RFC 5802 server-first-
message)
C: Yz1iaX...         (SASL: additional response; RFC 5802 client-final-message)
S: + dj1mT...        (SASL: additional challenge; RFC 5802 server-final-
message)
C:                   (SASL: Empty Response, CRLF only)
S: +OK Authenticated (POP3: command response)
C: STAT              (POP3: command request)
...

See also RFC 5034, Section 6, Example 3 (that using 'AUTH DIGEST-MD5'), which 
is also using a "Empty Response".

In any case, mpop has to wait for either a "+OK " or "-ERR " line after 
issuing the "AUTH SCRAM-SHA-1" command.
If it receives the SASL challenge containing the RFC 5802 server-final-
message, it has to send a empty response.
There is no statement in RFC5802/RFC4422/RFC5034 which justifies mpop's 
behaviour.
Or, if I am wrong, please let me know.
Does anyone has successfully logged in using mpop with SCRAM-SHA-1 into a 
public POP3 server? Which one?