Remove historic CRAM-MD5 mechanism

[Neustradamus]

Can you remove CRAM-MD5 from the code?

• https://github.com/search?q=repo%3Apython%2Fcpython+cram-md5&type=code

It is unsecure:

• https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00
• https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00

Thanks in advance.

Linked PRs

• gh-107675:Deprecate historic auth mechanism CRAM-MD5 from smtplib #107911
• gh-107675:Deprecate historic auth mechanism login_cram_md5 #107912

[Agent-Hellboy]

if salted CRAM solves the problem then I can try to implement it.

[Agent-Hellboy]

response from the Gmail server, I guess very few servers must be responding(configured) with CRAM-MD5

{'size': '35882577', '8bitmime': '', 'auth': ' LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH', 'enhancedstatuscodes': '', 'pipelining': '', 'chunking': '', 'smtputf8': ''}

are XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH being handled from imaplib these days, and do we just need to remove CRAM-MD5 from smtplib?

If salted CRAM solves the problem then I can try to implement it.

I guess not required, we can share a PLAIN password over SSL.

do we need to remove it from imaplib as well?
https://github.com/python/cpython/blob/71a7c96ffeb0d7fef06be3e57468896e030967a5/Lib/imaplib.py#L617C1-L631C78

[Neustradamus]

@Agent-Hellboy: Yes it can be removed from all, IMAP/SMTP and other places:

• https://github.com/search?q=repo%3Apython%2Fcpython+cram-md5&type=code

Please note that LOGIN has been replaced by PLAIN but PLAIN can not be used without a secure connection.

[Agent-Hellboy]

Sure, I will raise a PR to remove these instances and will update the docs.

[AA-Turner]

@Agent-Hellboy -- if there is consensus to remove these algorthims (none exists currently) we will need to go through the standard deprecation process (see PEP-387), which would be to deprecate now (Python 3.13) and remove any functionality no earlier than Python 3.15. Please could you update your pull requests to note the deprecation, but not remove any functionality?

(Note as before, the removal of these algorthims hasn't been agreed yet, but if removal is agreed we would need to deprecate first).

A

[Agent-Hellboy]

if there is consensus to remove these algorthims (none exists currently) we will need to go through the standard deprecation process (see PEP-387), which would be to deprecate now (Python 3.13) and remove any functionality no earlier than Python 3.15

sure, I will read the PEP and make the changes in PR.

(Note as before, the removal of these algorthims hasn't been agreed yet, but if removal is agreed we would need to deprecate first).

I will post this in the discourse to see if people agree, if not I will close the PR

[hugovk]

For reference, the Discourse topic:

https://discuss.python.org/t/should-we-deprecate-the-historic-cram-md5-mechanism-from-smtplib-and-imaplib/31556?u=hugovk