This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: (SMTPChannel): implement enhanced status codes
Type: enhancement Stage: resolved
Components: email, Library (Lib) Versions: Python 3.5
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: barry, lpolzer, r.david.murray
Priority: normal Keywords:

Created on 2013-11-21 10:59 by lpolzer, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (8)
msg203610 - (view) Author: Leslie P. Polzer (lpolzer) Date: 2013-11-21 10:59
ESMTP status messages (of the form "xab x.y.z test") can be added easily to the current status message strings emitted by the SMTP server and channel classes. They are not harmful if the user's server only intends to support plain HELO-SMTP

I will provide a patch within due time unless someone disagrees.
msg203622 - (view) Author: Leslie P. Polzer (lpolzer) Date: 2013-11-21 12:15
The contents of "conn" are already stored by asyncore's "socket" attribute, so there doesn't seem to be a need to keep it around. We should deprecate its usage and refer the user to the "socket" attribute.

Furthermore I suggest renaming the "conn" argument to "socket" to make its semantics clearer.
msg204361 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-11-25 16:50
Are you referring to implementing rfc 3463 and rfc 5248 insofar as they are applicable?  That seems useful.  I don't see anything in the RFC about the 'xab x.y.z text' form of the message, though.  Where is that documented?  IMO these messages should only be emitted if we got an ELHO...actually I would expect there to be an extension keyword associated with this, but I don't see one in the RFC.

The conn argument is a separate issue.  (And probably should not change for backward compatibility reasons.  Also, it doesn't have to be a socket, although it would indeed be unusual if it wasn't.)
msg204371 - (view) Author: Leslie P. Polzer (lpolzer) Date: 2013-11-25 17:39
Sorry for the confusion, the second comment (#msg203622) should actually have been a separate ticket.

Since you'd like to preserve "conn" I will just change the title of this ticket.
msg204384 - (view) Author: Leslie P. Polzer (lpolzer) Date: 2013-11-25 19:39
I am indeed referring to the enhanced status codes proposed in RFC 3463. This would just entail adding information to the status codes, converting them from the format "<simple status code> <human-readable string>" to "<simple status code> <enhanced status code> <human-readable string>".

In this it doesn't seem necessary to differentiate by HELO/EHLO; neither is it demanded by the standard nor does it result in an incompatible form of traditional HELO status messages. HELO clients should just interpret the first three digits and regard the rest as part of the human readable informal section.
msg204396 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-11-25 20:24
"Should" and "do" are different, though.  I wouldn't be at all surprised to find legacy code that did look at the text string part of the message.  Particularly test code, which is a place that smtpd gets used commonly.

Which probably means that what we really need is a keyword argument to the SMTPServer constructor (analogous to data_size_limit) that indicates whether or not enhanced status codes are enabled, and have it be off by default.  If desired, we could then issue a warning that enhanced status codes will be enabled by default in 3.6.  That kind of process is our usual backward-compatibility dance.  In this particular instance we could go one step farther and add a deprecation warning in 3.6 that the ability to set enhanced status codes off will go away in 3.7.  If anybody remembers to carry through on it :)
msg204514 - (view) Author: Leslie P. Polzer (lpolzer) Date: 2013-11-26 18:42
Sounds reasonable, I will propose a patch soon. Thanks!
msg309757 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2018-01-10 00:57
I'm closing this as won't fix since is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.
Date User Action Args
2022-04-11 14:57:53adminsetgithub: 63878
2018-01-10 00:57:15barrysetstatus: open -> closed
resolution: wont fix
messages: + msg309757

stage: resolved
2013-11-26 18:42:46lpolzersetmessages: + msg204514
2013-11-25 20:24:55r.david.murraysetmessages: + msg204396
versions: + Python 3.5, - Python 3.4
2013-11-25 19:39:58lpolzersetmessages: + msg204384
2013-11-25 17:39:01lpolzersetmessages: + msg204371
title: (SMTPChannel): get rid of "conn" attribute -> (SMTPChannel): implement enhanced status codes
2013-11-25 16:50:05r.david.murraysetmessages: + msg204361
2013-11-21 12:15:45lpolzersetmessages: + msg203622
title: implement ESMTP status messages -> (SMTPChannel): get rid of "conn" attribute
2013-11-21 10:59:58lpolzercreate