There is bug in PLAIN mechanism's of smtplib. The generated base64 string fail when the password start with numbers. As long as I could find, the error occur in method encode_plain. Using the null character (\0) in hexadecimal representation (\x00) seems to fix the problem.

Origin of the problem:

        def encode_plain(user, password):
            return encode_base64("\0%s\0%s" % (user, password), eol="")

Proposed fix:

        def encode_plain(user, password):
            return encode_base64("\x00%s\x00%s" % (user, password), eol="")

Current result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\0user\0123foo", eol="")
'AHVzZXIKM2Zvbw=='
>>> f = base64.decodestring('AHVzZXIKM2Zvbw==')
>>> f
'\x00user\n3foo'

Expected result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\x00user\x00123foo", eol="")
'AHVzZXIAMTIzZm9v'
>>> f = base64.decodestring('AHVzZXIAMTIzZm9v')
>>> f
'\x00user\x00123foo'

There's no bug here.  You've misunderstood how the literal \0 syntax works.  Perhaps this will clarify things:

  >>> list('\0123')
  ['\n', '3']
  >>> list('\x00123')
  ['\x00', '1', '2', '3']
  >>>

The SASL protocol says that the encoded base64 should be formed from:

null + login + null + password

The smtplib is not doing it, instead its "converting" the \012 (\0 + 2 first chars from password) in the char "\n", and it's right in the python way to see the things, it's not the bug reported here. The bug is a patch to change the null character representation from \0 to \x00 (using the hexadecimal representation) in the encode_base64 call to prevent the "conversion" and generate the right base64 encoded string.

It doesn't matter whether \0 or \x00 is used.  They mean the same thing.  Maybe this is the example I should have given:

  >>> list('\0%s' % ('12',))
  ['\x00', '1', '2']
  >>> list('\x00%s' % ('12',))
  ['\x00', '1', '2']
  >>>

Got your point. Sorry.