[Patches] [ python-Patches-572031 ] AUTH method LOGIN for smtplib

[noreply@sourceforge.net]

Patches item #572031, was opened at 2002-06-21 12:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: AUTH method LOGIN for smtplib

Initial Comment:
Unfortunately, my original SMTP auth patch doesn't work
so well in real life. There are two methods to
advertise the available auth methods for SMTP servers:

old-style: AUTH=method1 method2 ...
RFC style: AUTH method1 method2

Microsoft's MUAs are b0rken in that they only
understand the old-style method. That's why most SMTP
servers are configured to advertise their
authentication methods in old-style _and_ new style.
There are also some especially broken SMTP servers like
old M$ Exchange servers that only show their auth
methods via the old style.

Also the (sadly but true) very widely used M$ Exchange
server only supports the LOGIN auth method (I have to
use that thing at work, that's why I came up with this
patch). Exchange also supports some other proprietary
auth methods (NTLM, ...), but we needn't care about these.

My argument is that the Python SMTP AUTH support will
get a lot more useful to people if we also support

1) the old-style AUTH= advertisement
2) the LOGIN auth method, which, although not
standardized via RFCs and originally invented by
Netscape, is still in wide use, and for some servers
the only method to use them, so we should support it

Please note that in the current implementation, if a
server uses the old-style AUTH= method, our SMTP auth
support simply breaks because of the esmtp_features
parsing.

I'm randomly assigning this patch to Barry, because
AFAIK he knows a lot about email handling. Assign
around as you please :-)



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 17:41

Message:
Logged In: YES 
user_id=21627

I cannot understand why the behaviour of MS MUAs is relevant
here at all; smtplib only talks to MTAs (or MSAs).

If MTAs advertise the AUTH extension in the new syntax in
addition to the old syntax, why is it not good to just
ignore the old advertisement? Can you point to  a specific
software package (ideally even a specific host) which fails
to interact with the current smtplib correctly?

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-06-22 05:53

Message:
Logged In: YES 
user_id=85984

A comment on the old-style advertisement.

You say that Microsoft's MUAs only understand the
old-style method.  I haven't found this to be the case.

tmda-ofmipd is an outgoing SMTP proxy that supports
SMTP authentication, and I only use the RFC style
advertisement.  This works perfectly well with MS
clients like Outlook 2000, and Outlook Express 5.
Below is an example of what the advertisement looks
like.

BTW, no disagreement about supporting the old-style
advertisement in smtplib, as I think it's prudent, just 
making a point.

# telnet aguirre 8025
Trying 172.18.3.5...
Connected to aguirre.la.mastaler.com.
Escape character is '^]'.
220 aguirre.la.mastaler.com ESMTP tmda-ofmipd
EHLO aguirre.la.mastaler.com
250-aguirre.la.mastaler.com
250 AUTH LOGIN CRAM-MD5 PLAIN
QUIT
221 Bye
Connection closed by foreign host.


----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-06-21 12:43

Message:
Logged In: YES 
user_id=163326

This also includes a slightly modified version of patch #552605.

Even better would IMO be to add an additional parameter to
base64.encode* and the corresponding binascii functions that
avoids the insertion of newline characters.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470