#3582: smtp_auth_sasl: error base64-decoding server response
------------------------+---------------------------------------------------
 Reporter:  tczengming  |       Owner:  mutt-dev      
     Type:  defect      |      Status:  infoneeded_new
 Priority:  major       |   Milestone:                
Component:  mutt        |     Version:  1.5.21        
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by brendan):

  * status:  new => infoneeded_new


Comment:

 This SMTP server appears to be in violation of the RFC:
 {{{
 [2012-05-22 14:13:00] 4< 334 VXNlcm5hbWU6
 529b9177-52e3-4e81-a5e4-a21fdf2ced48
 }}}
 The bit after the base64 should not be there. From RFC 4954:
 {{{
 continue-req    = "334" SP [base64] CRLF
                         ;; Intermediate response to the AUTH
                         ;; command.
                         ;; This non-terminal complies with
                         ;; syntax defined by Reply-line [SMTP].
 }}}
 also from that RFC:
   A server challenge is sent as a 334 reply with the text part
   containing the [BASE64] encoded string supplied by the SASL
   mechanism.  This challenge MUST NOT contain any text other
   than the BASE64 encoded challenge.
 ...
   If the server cannot [BASE64] decode any client response, it
   MUST reject the AUTH command with a 501 reply (and an enhanced
   status code of 5.5.2).  If the client cannot BASE64 decode any
   of the server's challenges, it MUST cancel the authentication
   using the "*" response.  In particular, servers and clients
   MUST reject (and not ignore) any character not explicitly
   allowed by the BASE64 alphabet, and MUST reject any sequence
   of BASE64 characters that contains the pad character ('=')
   anywhere other than the end of the string (e.g., "=AAA" and
   "AAA=BBB" are not allowed).

 This doesn't leave a lot of room to adapt to this particular buggy server
 while remaining RFC-compliant ourselves. Options might be to set
 smtp_authenticators="PLAIN" or if that also doesn't work, to use SASL
 initial response (I'm not sure whether we don't already do that with PLAIN
 though).

 Please try setting `smtp_authenticators="PLAIN"` and report on how that
 worked out.

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3582#comment:2>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

Reply via email to