It was discovered that the FTP client implementation in the Networking component of Python failed to correctly handle user inputs. 
A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Python application if it could make it access a specially crafted FTP URL.

See 
http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html

and https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3533

I upload the patch for this issue.

One of the purposes of the JDK patch is to prevent '\ r' and '\ n' from being inserted into the ftp command. In particular, it seems to assume that if another malice command is inserted after '\ n', the possibility of such an attack will be opened at a later time.
IMO, I think that we can block '\ r \ n' and '\ n' at the same time by blocking only '\ n'. Although '\ r' allows

'\ r' -> '\r'
'\ n' -> '\n'

I suggest to close this as a duplicate. The pull request itself looks like the right direction to me, but let’s not split the discussion up more than necessary.

The relevant discussion of this bug is happening in https://github.com/python/cpython/pull/1214.

New changeset 2b1e6e9696cb433c0e0da11145157d54275d119f by Giampaolo Rodola (Dong-hee Na) in branch 'master':
bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214)
https://github.com/python/cpython/commit/2b1e6e9696cb433c0e0da11145157d54275d119f

Reopening as it needs backports for 2.7, 3.3, 3.4, 3.5 and 3.6.

What about rejecting also NUL byte?

I closed bpo-29606 as a duplicate of this bug.

Just FYI, if the backports to 3.5, 3.4, and 3.3 happen *really* fast, we *might* be able to get them into the current round of releases, if Larry approves for 3.5.4 final and 3.4.7 final.  If the 3.3 backport doesn't happen soon, 3.3 will reach end of life without it.

Okay, I will send backport today.

New changeset a4e774f86224cd8c997deaa4e71312cf1a7b023c by Ned Deily (Dong-hee Na) in branch '3.3':
[3.3] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) (#2885)
https://github.com/python/cpython/commit/a4e774f86224cd8c997deaa4e71312cf1a7b023c

New changeset 19b2890014d3098147d16475c492a47a43893768 by Ned Deily (Dong-hee Na) in branch '3.5':
[3.5] [security] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) (#2887)
https://github.com/python/cpython/commit/19b2890014d3098147d16475c492a47a43893768

New changeset 8c2d4cf092c5f0335e7982392a33927579c4d512 by Victor Stinner (Dong-hee Na) in branch '3.6':
[3.6] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) (#2886)
https://github.com/python/cpython/commit/8c2d4cf092c5f0335e7982392a33927579c4d512

@corona10: Cool, 3.3, 3.5, 3.6 and master are fixed. Would you mind to create also backports for 2.7 and 3.4, please?

> What about rejecting also NUL byte?

I don't it would make any difference at this point.

Victor> What about rejecting also NUL byte?
Giampaolo Rodola'> I don't it would make any difference at this point.

I asked because I read that filenames containing newlines can be escaped using \n\0. So it seems like "embedded" NUL bytes have a special semantic in FTP.
http://bugs.python.org/issue29606#msg292677

I have no opinion on NUL bytes. It's just that I saw them mentionned somewhere in the discussion, but I failed to see a rationale to accept or reject them.

AFAIK its only use case is to escape \r and \n.

New changeset e5eae474c431af2880a68f6329840b9288fc4bc1 by Victor Stinner (Dong-hee Na) in branch '2.7':
[2.7] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) (#2894)
https://github.com/python/cpython/commit/e5eae474c431af2880a68f6329840b9288fc4bc1

New changeset 2a5a26c87e82c7d9a348792891feccd1b5e9a769 by larryhastings (Dong-hee Na) in branch '3.4':
[3.4] bpo-30119: fix ftplib.FTP.putline() to throw an error for a illegal command (#1214) (#2893)
https://github.com/python/cpython/commit/2a5a26c87e82c7d9a348792891feccd1b5e9a769