Hi Yang,

> > How would you like me to proceed with this, [...]
>
> You will surely have noticed that the NTLM code has
> been reorganized into something which will better
> resist future expansion and reuse.

I did see all your refactoring efforts over the weekend - you were certainly
busy ;-)

> I would also like to have the SMTP/IMAP/POP3 authentication
> stuff refactored out from protocol specific source code files
> into a 'nearly' protocol agnostic source code file.

I agree - it would be really good to do this.

> But given the details that need to be addressed, this is
> something that has to be done out of feature freeze period,
> and additionally I've run out of refactoring energy for some time.

Yes - I agree and I am only too happy to work with you to achieve this.

> Relative to the ability to allow the user to choose not to send
> the initial-response along with the authenticate command...
> Have you come across a server which goes crazy if the
> initial-response is provided on the same line as the
> authenticate command respecting max command line size?

I've not witnessed it personally, as I've only been testing against MS
Exchange, although I did find it really useful when writing and testing my
SMTP-NTLM modifications. Additionally, strictly speaking the RFC does state
that the initial-response is optional and as such I thought it would be
really good for libcurl to support this, that way being as flexible as
possible and supporting as many SMTP servers as possible as well.

> I'm asking this for the simple reason that if we expose this capability,
> it has to be implemented and work the same with all authentication
> mechanisms which support sending an initial-response along with
> the authenticate command. Otherwise it would be a rather broken
> capability flag that would fool user into believing that it works
> where it should.

Indeed. I read the other RFCs for the other protocols that you posted and I
think we can implement it across these as well. I would also like to add
NTLM support to some of the other protocols so this is something that I am
willing to take a look at, at some point in the future, unless someone else
would like to give us a helping hand ;-) I'm sure you'll appreciate that I'm
focused on SMTP at the moment as that is where I need the NTLM
functionality.

> I'm not against allowing the existence of CURL_SASL_AUTH_NO_IR
> bit, what I'm saying is that if it exists it must at least work with
> all SASL mechanisms.

Definitely.

> It is actually a feature on its own. And as such, it deserves its
> own patch no matter if the feature is introduced before or
> after allowing NTLM for SMTP and other protocols.
>
> Thanks for your patience,

No problem. What are your thoughts about getting NTLM support into SMTP for
v7.22.0 now?

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-08-31