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
