Issue #15014 - SMTP AUTH initial-response (beta exception requested)
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 even though it addresses a regression in Python 3.5. Assuming a positive response by RDM or anybody else who would like to review the patch, I'd like to get a beta release exemption for the change. Patch on the issue includes implementation, test, and docs. Cheers, -Barry
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
On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:
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.
I generally like the approach that initially added with issue #15014. This is a subtle corner of the RFC and an unexpected regression from Python 3.4. Cheers, -Barry
On 8 July 2015 at 05:12, Barry Warsaw <barry@python.org> wrote:
On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:
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.
I generally like the approach that initially added with issue #15014. This is a subtle corner of the RFC and an unexpected regression from Python 3.4.
That strikes me as just the kind of not-quite-as-finished-as-we-thought case that the beta cycle is designed to flush out, so the minor further enhancement sounds like a good idea to me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jul 09, 2015, at 08:47 PM, Nick Coghlan wrote:
That strikes me as just the kind of not-quite-as-finished-as-we-thought case that the beta cycle is designed to flush out, so the minor further enhancement sounds like a good idea to me.
Cool. RDM provided some good feedback in the review, so I'll be committing this at some point today. Cheers, -Barry
participants (3)
-
Barry Warsaw -
Nick Coghlan -
Terry Reedy