This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: binascii.Error raised in smtplib when initial_response_ok=False
Type: behavior Stage:
Components: email Versions: Python 3.9, Python 3.8, Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, junpengruan, pepoluan, r.david.murray
Priority: normal Keywords:

Created on 2021-04-27 07:57 by junpengruan, last changed 2022-04-11 14:59 by admin.

Messages (5)
msg392039 - (view) Author: junpengruan (junpengruan) Date: 2021-04-27 07:57
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 decode the resp(here is "ok, go on") which will cause a binascii.Error:

Traceback (most recent call last):
  File "/usr/lib/python3.6/smtplib.py", line 644, in auth
    challenge = base64.decodebytes(resp)
  File "/usr/lib/python3.6/base64.py", line 553, in decodebytes
    return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

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 there better way to fix this problem?

Thanks!
msg393059 - (view) Author: Pandu E POLUAN (pepoluan) * Date: 2021-05-06 06:22
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 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.

Servers that send non-BASE64-encoded text after "334 " IMO is violating the standards.
msg393060 - (view) Author: Pandu E POLUAN (pepoluan) * Date: 2021-05-06 06:25
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.
>                         ;; This non-terminal complies with
>                         ;; syntax defined by Reply-line [SMTP].

Nothing else besides base64 is allowed; after "334 " it MUST be either <base64> or <nothing>.
msg393061 - (view) Author: Pandu E POLUAN (pepoluan) * Date: 2021-05-06 06:28
> 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 there better way to fix this problem?

I suggest either of:

(1) Contacting the makers of the software, to force Base64-encoding for "334 " replies, or

(2) If the text following "334 " is customizable, Base64-encode them yourself, then use the base64-encoded text as the customized "334 " response.
msg393172 - (view) Author: junpengruan (junpengruan) Date: 2021-05-07 07:37
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 why I meet this problem, Maybe I should just evade this problem for my own program and close this bug?
History
Date User Action Args
2022-04-11 14:59:44adminsetgithub: 88115
2021-05-07 07:37:31junpengruansetmessages: + msg393172
2021-05-06 06:28:59pepoluansetmessages: + msg393061
2021-05-06 06:25:12pepoluansetmessages: + msg393060
2021-05-06 06:22:34pepoluansetnosy: + pepoluan
messages: + msg393059
2021-04-27 07:57:58junpengruancreate