smtplib.py AUTH mechanism

[mcicogni]

BPO	498572
Nosy	@gvanrossum, @warsaw
Files	smtplib.py.patch: Here's the patch. I'd say "trivial change" is even more than it's worth... I just inserted a space in the RE.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/warsaw'
closed_at = <Date 2002-04-15.20:03:34.000>
created_at = <Date 2002-01-02.16:04:52.000>
labels = ['library']
title = 'smtplib.py AUTH mechanism'
updated_at = <Date 2002-04-15.20:03:34.000>
user = 'https://bugs.python.org/mcicogni'

bugs.python.org fields:

activity = <Date 2002-04-15.20:03:34.000>
actor = 'barry'
assignee = 'barry'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2002-01-02.16:04:52.000>
creator = 'mcicogni'
dependencies = []
files = ['278']
hgrepos = []
issue_num = 498572
keywords = []
message_count = 3.0
messages = ['8565', '8566', '8567']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'barry', 'mcicogni']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue498572'
versions = ['Python 2.2']

[mcicogni]

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

[gvanrossum]

Logged In: YES
user_id=6380

Would you mind submitting a patch?

[warsaw]

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!