Issue 498572: smtplib.py AUTH mechanism (original) (raw)

Currently the AUTH implementation within smtplib.py does not fully comply to RFC 2554. This RFC explicitly states on page 7:

auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] *(CRLF [base64]) CRLF

Therefore, after the AUTH token there must be an ASCII blank.

However, the ESMTP features parsing code uses a RE that will match any alphanumeric string, stopping at the first non-alphanumeric character (smtplib.py, line 394):

 '(?P<feature>[A-Za-z0-9][A-Za-z0-9\-]*)'

and will also match, for example, "AUTH=LOGIN", which it shouldn't.

This poses a problem when trying to authenticate against an iPlanet Messaging Server MTA, which responds to EHLO with

... (other features) AUTH PLAIN LOGIN STARTTLS AUTH=LOGIN

and obviously the second AUTH token "feature list" overwrites the first (we get just ['=LOGIN'], which isn't really useful in any case).

I suppose the MTA isn't telling the MUA a second set of AUTH features, but merely letting the MUA know that it may insert the AUTH=<...> parameter on the MAIL FROM command (see the same RFC 2554, section 5, page 4). Anyway, the RFC mandates for a space between the AUTH token and the implemented authentication mechanism list, so this should not be a problem in the first place (smtplib.py could just ignore the improperly-constructed feature line).

By the way, the AUTH LOGIN mechanism is iPlanet-Netscape proprietary, so the only well-known method to use in this case would be PLAIN.

This "bug" is trivial to fix (just add a space as the last character of the RE) but I don't know about other ESMTP service extensions, which may ask for characters other than space as delimiters. However, I don't know of any existing ESMTP extensions not using the ASCII blank as a token separator, so I think the aforementioned correction could be put in place.

Thank you, Mauro Cicognini Siosistemi S.p.A., Italy

Logged In: YES user_id=12800

Actually, the relevant RFC is 1869 which describes ESTMP. This RFC requires that there be an ASCII space between ehlo-keyword and the ehlo-param(eters). Furthermore, `=' is not a valid character in an ehlo-keyword so I believe a response line that starts

250-AUTH=LOGIN

is non-conformant to the RFC and should be ignored. Your patch isn't quite right though, since the trailing space will not exist if there are no ehlo-params for the ehlo-keyword. I'll check in a proper fix though, thanks!