RE: [PATCH] SMTP Modifications
Date: Wed, 31 Aug 2011 21:30:56 +0100
> > 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
> 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
> 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.
> 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
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-08-31