Hi Steve, thanks for your response!

> Whilst most people use SMTP to send email, it is a two way protocol
> that can transfer data from the server to the client (for example:
> the VRFY, EXPN and HELP commands) as well as from the client to the
> server. In its infancy the SMTP code was always assuming it was in
> upload mode, as it only supported the MAIL command during a transfer,
> whilst most other protocols that upload data to the server require
> the CURLOPT_UPLOAD flag to be set.

Understood. Thanks for the explanation.

>> Unfortunately we have libcurl clients in the wild that relied on
>> the old behaviour -- they did not set CURLOPT_UPLOAD -- and while
>> it would be _possible_ to upgrade all of them, it would also be
>> prohibitively expensive.
>
> I am right in thinking that you are upgrading your libcurl shared
> library or dll but not your application that calls it?

Yes, that's correct. We deploy a shared version of libcurl that is used
across multiple client applications.

>> 1) Can anyone provide guidance on how we might safely revert this
>> behavior in our copy of 7.37.1? [...]
>
> Hopefully, I can... as I tend to maintain the email protocols here in
> curl ;-)
>
> You can ensure that smtp_perform() always calls smtp_perform_mail() -
> a 5 line code change including the comments.

Excellent; that's about what we expected. Am I correct in saying that by
patching in this way, we'll be effectively crippling the new command
support (VRFY, et al)?

We're currently working on getting permission to post patches up to the
list (we have at least one other one in the works), so hopefully I'll be
able to post this one as a sanity check soon.

>> Put another way: How do I ensure that our current libcurl client
>> code (HTTP, SMTP, or otherwise) does not contain other bugs of this
>> nature, so that we won't break in the future because of a missing
>> CURLOPT?
>
> I'm not entirely sure I'm the best person to answer the whole of this
> question and as such may require Daniel's and others' input for some
> of this - especially as I've only been involved with curl for 3 years
> myself.

Sure, I understand. It looks like Daniel's already replied as well, so
I'll take that discussion to that part of the thread (looks like that
reply will have to wait until tomorrow though).

> However, I can say that we try to not break compatibility, this was
> technically a bug and as such the examples on the website were also
> at fault :( For example: If you use the curl command line utility
> with --libcurl to generate sample source code you will note it
> explicitly calls curl_easy_setopt(hnd, CURLOPT_UPLOAD, 1L) even with
> versions prior to 7.34.0.

Hm, that's interesting. I wasn't aware that curl generated sample code
-- we might have to consider using that as a sort of "baseline"
comparison to make sure we have the bare minimum list of CURLOPTs.

Thanks again for your (extremely quick!) input.

Jacob Champion
LabVIEW R&D
National Instruments
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-20