On Sun, May 27, 2012 at 3:49 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Sun, 27 May 2012, William Betts wrote:
>
> I didn't realize that you could set the helo string like that! I guess
>> there isn't much benefit to it other than I think it looks better. If I had
>> a choice between the two I'd rather use the CURLOPT_MAIL_HELO option. To me
>> it stands out better as to what it does.
>>
>
> But since we now support the path approach it really doesn't make much
> sense to add a second way to provide the same information - the previous
> supported method would still need to be kept...
>
>
 With the patches it will still work the other way as well so nothing would
be broke.

 I'd also like to add in a header and a body option. Those options in my
>> opinion would make it easier to send customized email.
>>
>
> libcurl already allows you to provide whatever you want in the mail. I
> don't think it needs two new ways to offer the same functionality... unless
> perhaps if they somehow provide new abilities or features users would like.
> So feel free to elaborate on what more exactly you're suggesting!

I might be wrong, but from what I've seen the standard way to send the
>> actual body with headers appears to be reading a file in or using a
>> callback.
>>
>
> Yes, that's how it gets done. If not with a callback, how would you pass
> in this information to libcurl?

The file pick works fine for a lot of things, but it introduces bottle
necks on older hardware if you're sending out more than a couple of emails.
If you're developing a mail list manager or some other type of software
that sends email it's really inefficient. You have to write the file, read
the file, then send it. Keeping everything in memory is a much better way
of doing it. This is where the callbacks come in. You can use the callbacks
to get around that, but then you're putting more logic into the callback
than is really necessary. By pointing the option at a variable even if it's
just 1 variable (CURLOPT_MAIL_CONTENTS for example) it simplifies the part
of the program that's interacting with curl. For example signing email.
That really shouldn't be done inside of the callback. I'm not advocating
for removal of the current methods, because they do work for a lot of
people.

>
> I mainly use libcurl with PHP so my line of thought might not really be
>> aligned with that of people who use it with C/C++.
>>
>
> We all have certain objective and goals with what we work on in libcurl. I
> doubt there are two of us having the same set. That's however not a valid
> reason for introducing things that aren't "kosher" libcurl stuff.
>
> PHP/CURL is an entire layer on top of libcurl and if you want new fancy
> things in there you can add them there without them affecting libcurl at
> all. In fact, you can probably even add them on top of PHP/CURL without
> affecting that extension either in the case of these header and body
> options.
>

I agree we shouldn't just add stuff to add stuff. If we did that then it
would become an unwieldy mess. However, I feel what I'm proposing is
beneficial to everyone who uses curl for SMTP and would get more people to
use it that currently don't. I might be wrong, but I don't think it's
possible to add in what I'm talking about directly to the PHP/CURL
extension without modifying libcurl directly.

Best Regards,
William

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-28