I think this should be considered a bug fix.  While it is true that we are handling something that is a "more advanced" feature of the smpt protocl than what we are (currently) formally supporting in the module, the reality is that if one uses smtplib to communicate with a foreign mail server, you currently get unhandleable errors even if the library sticks to the currently supported RFC level.  I think that the fact that smtplib does the wrong then when it receives an unexpected error code followed by a connection close is a bug in smtplib regardless of what RFC level we are talking about.

In fact, this is one instance of a larger problem.  I have also seen a server that returns a 451 error code at the end of a data command *and then disconnects*.  I think that is out of spec even with the newer RFCs, but it is something that happens in the real world and so we should handle it.

The general problem in smtplib is that it does an rset on error, and if the other end has closed the connection, the rset raises a ServerDisconnectedError, masking the error code that the server actually reported.  This also should be fixed.

Clearly for 421 we should be doing a close and not an rset, and I think we may as well go ahead and do that even if we haven't upgraded the library to fully comply with the newer RFC yet, especially since we've got a patch here.  It is not a publicly visible API change, so I don't think the "new feature" rule needs to be applied strictly.  Correctly handling the case of rset finding the socket already closed would also have fixed this bug, and we should make that fix as well, since it seems that servers may unexpectedly close the connection after any error.