[Python-bugs-list] [ python-Bugs-498572 ] smtplib.py AUTH mechanism
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 15 Apr 2002 13:03:34 -0700
Bugs item #498572, was opened at 2002-01-02 11:04
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470
Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mauro Cicognini (mcicogni)
Assigned to: Barry Warsaw (bwarsaw)
Summary: smtplib.py AUTH mechanism
Initial Comment:
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
----------------------------------------------------------------------
>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 16:03
Message:
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!
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-02 22:28
Message:
Logged In: YES
user_id=6380
Would you mind submitting a patch?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470