junpengruan <632077...@qq.com> added the comment:
Hi Pandu, thanks for your reply!
I have read the RFC4954 you mentioned and agree that the server shouldn't react
like this. Then I notice that this RFC's publication date is 2007 and the
server I use is published in 2003, that's maybe the reson
Pandu E POLUAN added the comment:
> I am using Magic Winmail Server2.4(build 0530) as a SMTP server, which
> appears dont support initial_response, so I set initial_response_ok=False and
> got this Error. currently I catch this error and ignore it to evade program
> failed, it works fine. Is
Pandu E POLUAN added the comment:
A stronger case is the "Formal Syntax" on
https://tools.ietf.org/html/rfc4954#page-13 :
> continue-req= "334" SP [base64] CRLF
> ;; Intermediate response to the AUTH
> ;; command.
>
Pandu E POLUAN added the comment:
Technically, that is not the fault of smtplib.SMTP
The standard for SMTP AUTH specifies that characters following "334 " MUST be
Base64 encoded.
See https://tools.ietf.org/html/rfc4954#page-4 , 3rd paragraph:
> A server challenge is sent as a 334 reply with
New submission from junpengruan <632077...@qq.com>:
Hi
I think there is a bug when initial_response_ok=False and using AUTH PLAIN, the
server will response like:
--
C: AUTH PLAIN
S: 334 ok. go on
--
and it's not base64 encoding, while in the auth() it will base64
