On Fri, 12 Dec 2014, Patrick Monnerat wrote: > I have worked on my side too for a much global solution, but I > have a clash now you've committed :-/
I'm guessing from what you've just said about the clash and from your previous email that you've performed this in smtp.c. I think we should take a step back and look at implementing some of this in transfer.c > My version does: > - Proper mapping of LF, CR, CRLF to CRLF. The existing -crlf option could be extended to do this and not just LF characters as it does currently. > - Proper handling of the initial dot. I'm not aware of that issue. Do you mean after the headers or if there are no headers present? If when no headers should that initial dot be stuffed as it isn't proceeded by a CRLF so cannot be interpreted as an end of data line can it? The section on Data Transparency in the RFC would indicate that it should - if so then I believe this can be achieved by setting trailing_crlf to TRUE in smtp_do() and clearing it in Curl_smtp_escape_eob() with an else at line 2371. > - Allocate only when something changes. That could be more efficient and again something that could also be implemented for and be useful to the current conversion performed in transfer.c. > - Two test cases for this. I was going to implement a libcurl test case after my fix but have held off in case one of the tests you have already implemented covers this. > - An additional empty mail bug (currently transmitted as an empty line) fixed. I wasn't aware of an issue here either. Technically I believe this can be fixed by initially setting smtp->eob to 2 in smtp_do(). However, is it standard for .CRLF to terminate the data command when there is no message data? In my mind the RFC is a little ambiguous here especially when you bear in mind that the standard response to the DATA command is typically "354 Start mail input; end with <CRLF>.<CRLF>". > What do we do ? As there are only two weeks until release I think we should: * Hold off on automatic conversion until after the release of 7.40.0 - this gives others time to contribute and assist in the debate about whether this should or shouldn't be done * Push a libcurl test case for the dot stuffing (if you have already implemented one then great if not I will try and come up with one over the next few days) * Verify whether the initial dot issue exists and push a fix if need be * Push a fix for the empty mail bug if need be > Have a good week-end. Cheers - hope you had a good one too. Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
