RFC 4616 about SASL PLAIN:

   The mechanism consists of a single message, a string of [UTF-8]
   encoded [Unicode] characters, from the client to the server.  The
   client presents the authorization identity (identity to act as),
   followed by a NUL (U+0000) character, followed by the authentication
   identity (identity whose password will be used), followed by a NUL
   (U+0000) character, followed by the clear-text password.  As with
   other SASL mechanisms, the client does not provide an authorization
   identity when it wishes the server to derive an identity from the
   credentials and use that as the authorization identity.
[...]
   The authorization identity (authzid), authentication identity
   (authcid), password (passwd), and NUL character deliminators SHALL be
   transferred as [UTF-8] encoded strings of [Unicode] characters.


That's one of the reasons why AUTHINFO SASL is better than AUTHINFO USER.  It also allows whitespaces (a few news servers do not parse well whitespaces in user names or passwords after AUTHINFO USER/PASS -- imagine " test" with a leading space).  Solved with SASL.