python / cpython

The Python programming language
https://www.python.org
Other
63.01k stars 30.17k forks source link

binascii.Error raised in smtplib when initial_response_ok=False #88115

Open f9198015-a00c-4298-8eb8-ad037aff25c1 opened 3 years ago

f9198015-a00c-4298-8eb8-ad037aff25c1 commented 3 years ago
BPO 43949
Nosy @warsaw, @bitdancer, @pepoluan

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['3.8', 'type-bug', '3.7', 'expert-email', '3.9'] title = 'binascii.Error raised in smtplib when initial_response_ok=False' updated_at = user = 'https://bugs.python.org/junpengruan' ``` bugs.python.org fields: ```python activity = actor = 'junpengruan' assignee = 'none' closed = False closed_date = None closer = None components = ['email'] creation = creator = 'junpengruan' dependencies = [] files = [] hgrepos = [] issue_num = 43949 keywords = [] message_count = 5.0 messages = ['392039', '393059', '393060', '393061', '393172'] nosy_count = 4.0 nosy_names = ['barry', 'r.david.murray', 'pepoluan', 'junpengruan'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue43949' versions = ['Python 3.6', 'Python 3.7', 'Python 3.8', 'Python 3.9'] ```

f9198015-a00c-4298-8eb8-ad037aff25c1 commented 3 years ago

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!

80667b33-050d-42cb-a682-e64fd74352fa commented 3 years ago

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.

80667b33-050d-42cb-a682-e64fd74352fa commented 3 years ago

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>.

80667b33-050d-42cb-a682-e64fd74352fa commented 3 years ago

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.

f9198015-a00c-4298-8eb8-ad037aff25c1 commented 3 years ago

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?