Larry and others,
I'd like to bring your attention to issue #15014. This issue added arbitrary
auth methods to smtplib, which is a good thing. Implicitly though, a
regression was introduced w.r.t. RFC 4954's optional initial-response for the
AUTH command, for authentication methods that support it.
An example is AUTH PLAIN, which does not require a challenge. It's possible
that SMTP servers are not prepared to handle challenge/responses for
authentication methods that support initial-response, and regressions have
been seen in the wild while testing against Python 3.5. In Python 3.4, AUTH
PLAIN included an initial-response.
After discussion on the issue, RDM and I agreed on a refinement to the
authobject() protocol, such that they would be called first with
challenge=None. If the auth method implemented by the authobject() supports
an initial response, it can return the bytes to be encoded and sent along with
AUTH <METHOD>. If it returns None, then a challenge is required, and the
normal SMTP challenge/response can proceed.
A minor complication is that clients using smtplib might want to force
challenge/response instead of initial-response even for authentication methods
that support the latter. There are various reasons for this, including test
suites (such as Python's own test_smtplib.py).
So I added an optional keyword argument called *initial_response_ok* to
SMTP.auth() and SMTP.login(), with a default value of True. Thus for
authentication methods that support it, smtplib will by default send an
initial-response, but it can easily be overridden. Defaulting to True
restores compatibility with Python 3.4.
Technically, this is a new feature