My apologies, I did not think about the possibility of an English issue.  I was reacting to the "security report speak", which I find often makes a security issue sound worse than it is :)  Thank you for reporting this problem, and I do think we should fix it.

My posting was directed at the severity of the issue, since it was potentially holding up a release.  My point about the example is that without an example of code that could reasonably be expected to use user input in a call that could inject newlines, we can treat this as a low priority issue.  If we had a proposed example of such code, then the priority would be higher.  If it was an example of such code "in the wild", then it would be quite high :)

The reason I'm saying we should have an example in order to consider it higher priority is that I cannot see *any* likelihood that this would be a problem in practice.  Let me explain.

putcmd is an *internal* interface.  If we look at the commands that call putcmd or docmd, the only ones that pass extra data that aren't pretty obviously safe (ie: not clearly sanitized data) are rcpt and mail[*].  In both cases the item of concern is optionslist.  optionslist is a list of *SMTP server options*.  This is not data that is reasonably taken from user input, it is data provided *by the programmer*.

[*] I did double check to make sure that email.utils.parseaddr sanitizes both \r and \r, just to be sure :)

Therefore this is *not* a significant security issue.  But as I said, we should take the "defense in depth" approach and apply the check in putcmd as you recommend.  I just don't think it needs to hold up a release.