[Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)
tjreedy at udel.edu
Tue Jul 7 20:53:08 CEST 2015
On 7/7/2015 1:52 PM, Barry Warsaw wrote:
> 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
From what you said above, this is not an independent new feature, in
that you would not have proposed it without the prior patch, but rather,
in effect, an amendment to the original patch, to make the combined
effect what the original patch should have been.
> even though it addresses a regression in Python 3.5.
The main purpose of releases after feature freeze is to text and fix
bugs and regressions in added features. The alternative fix would be to
revert enough of the additions to avoid the regression, and defer such
To me, the main question is whether you are sure that your proposal is
the right fix, or whether you might reasonably do something different
(with the new arguments) if changes were reverted for the present and
you two took more time to think about the problem. My impression is
that the latter is unlikely because the problem is inherent in the new
Terry Jan Reedy
More information about the Python-Dev