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.

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.

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.)

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.

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.

"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 :)

Sounds reasonable, I will propose a patch soon. Thanks!

I'm closing this as won't fix since smtpd.py is deprecated and will likely not get any future development.  Please see aiosmtpd as a much better third party replacement.