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 3.6.
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
auth methods.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
