Hi William,

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.

My own opinion is that I think an option like you suggested is a lot cleaner
(although I would recommend a better name as it would be used by both EHLO
and HELO commands and really represents the client address / hostname) and
like I said in my previous email, passing this address in the URL is a bit
of a hack. However I didn't write the original SMTP implementation for curl
and as such we are where we are - I can only thank those that did write it
as it was a good starting point! However, we *might* want to consider
replacing the URL with a CURLOPT_MAIL_CLIENT option for a major update in
curl such as v8.00 ;-)

> > > 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.

As you already mentioned I wouldn't recommend using the file mechanism for
medium or large scale applications. The callbacks however do work very well
and allow you the programmer to either pass data to libcurl from memory or
by reading a file a block at a time - for other protocols that may accept
large files sending a block at a time is very important. With SMTP it is a
little more tricky as files have to be encoded and may have to be split
across several messages.

However, I have considered implementing the data sending similar to HTTP and
have the header and body sent separately. You could then specify all the
headers, such as To, From, Subject, Date, Content-Type etc... as you would
for a HTTP upload. However, the problem here (as I see it. mainly because I
don't know the HTTP protocol too well) is that an email can have a header
and a body, that body then can contain sub messages which themselves can
have a header and a body. Those sub messages can also contain sub messages
which again have a header and body :-(

For example an email with two file attachments, inline images and
alternative content such as plain text and html would contain a body with a
"Mixed" sub message. That sub message would then contain three other sub
messages, one for the "Related" sub message and two for the encoded file
attachments. The "Related" sub message would then contain another sub
message for the email content and a number of messages for each of the
encoded inline images. The content sub message is implemented as an
"Alternative" message with sub messages for the plain text and html content
(I hope I have that correct from memory!!).

However, we could look at having all the encoding done inside of libcurl...
if that is the direction Daniel wants to take the project, so you as the
programmer would simply specify the initial headers, possibly some plain
text body, some html body, maybe rich text content, the optional preamble
and epilogues, a list of inline images and some file attachments. This is
all stuff I have had to write recently for my project and it does seem a
little daft to have everyone who uses libcurl do exactly that. However, how
much does libcurl do for the application programmer who wants to upload a
file by HTTP or FTP?

Anyway, just my two pennies worth for a Monday morning ;-)

Kind Regards

Steve

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