Re: non-standard ProxyAuth extension?

Chris Newman <[email protected]> Wed, 04 Sep 2002 13:04:02 -0700
Newsgroups gmane.ietf.imapext,gmane.ietf.vpim
Message-ID <[email protected]>
I concur 100% with Mark's opinion.  Use RFC 2595's PLAIN mechanism instead, 
which is more widely implemented.

                - Chris

begin  quotation by Mark Crispin on 2002/9/4 11:05 -0700:
> The inferences that can be drawn from my comment may be the closest to an
> answer that there is.  ProxyAuth was suggested by Netscape 5 years ago.
> It was soundly denounced at the time as a flawed (security issues,
> filesystem dependencies) and unnecessary (SASL provides a superior
> mechanism that is multiprotocol as well) idea.  As far as I can tell, the
> document never went beyond draft 00.
>
> It can be inferred that only Netscape ever implemented it (assuming that
> they did, and that it is still in the Netscape server).  Since there is
> no reason to implement it, it can be inferred that there will be no new
> implementations.
>
> That, in turn, leads to the inference that it is not "common"; or at
> least no more "common" than the Netscape server.
>
> I've been contacted by VPIM folks from time to time about deploying my
> server with VPIM clients.  Given that the UW server does not implement
> ProxyAuth, I infer that the VPIM community does not depend upon it.  This
> inference is strengthed by the fact that ProxyAuth is *not* one of the
> things which the VPIM community has asked the IMAP community to work on.
>
> Given the architectural flaws (including security design flaws) in
> ProxyAuth, this all should be quite enough to declare ProxyAuth to be
> dead, and not to be used or implemented.
>
> On Wed, 04 Sep 2002 13:27:03 -0400, Tony Hansen wrote:
>> Mark, I don't disagree. However, I still need my questions answered.
>> Mark Crispin wrote:
>> > I don't see any reason to implement ProxyAuth now that we have a
>> > superior mechanism in SASL.
>