Hi Dan,

> > If the response from the server is guaranteed to be 550 then we could
> > do "if(smtpcode != 550)" but I'm not sure if that is the case / nor was
> > Daniel when he originally wrote the function.
>
> Since most of the code is broken down into the specific parts, wouldn't
> it be fairly predictable at this point- since SMTP server behavior has
> been well defined by now.

Sorry my example should have read "if(smtpcode == 550)" then fail ;-)

Firstly thank you for the list of error codes. I've gone through this as
well as re-reading the relevant section in RFC-2821 and 5321.

The RFC seems to indicate that only 250, 550 and 503 will be returned for
this command. 503 *should* never be returning to curl as that is a bad
sequence of events, ie. The MAIL command wasn't sent first which isn't
possible in curl.

> Steve, I sent you an off list quick primer on this and server responses.

Reading the list of response codes you sent me though indicates that 251 and
551 may be returned. Given this I am reluctant to change the code to test
against a specific error code - I don't believe it adds anything apart from
a bit of clarity to a programmer who may be reading the code.

Maybe some of the other curl developers could give their views on this and
whether it is worth changing this if statement?
 
> That would be a viable option- if the VRFY command is supported by
> the server that you are working with. Not all servers will support the
> command- as it is considered a bit of a security risk- since it can give
> more information about any given username on a server

If this was implemented as a custom request then it would be the programmers
responsibility to send a meaningful command and interpret the response. If
you as the programmer did:

curl_easy_setopt(handle, CURLE_CUSTOM_REQUEST, "RUBBISH")

Then the server would return a 500, 501 or 502 error and we would return an
appropriate CURLE_* error code in the result from curl_easy_perform().

Given this, if the programmer was to do:

curl_easy_setopt(handle, CURLE_CUSTOM_REQUEST, "VRFY steve")

And the command wasn't supported then I would also expect the same response
and as the programmer then I would just send the email.

If however the command was supported and it returned a 250 or 252 for
example then I would continue to send the email.
If on the other hand the command returned a 553 then I would not send the
email.

> As it is, I would enjoy specific errors, but that's a bit of a
> selfish interest, as I'd love to only have to look to the return
> of the curl_perform() call to determine which part of the
> interaction may have gone awry- since there are distinct parts
> of the transaction with an mail server. Is there some way to get
> more information about any given error that happens?
> I would love to be able to provide some functionality that actually
> tells my user more about what went wrong, rather than
> "something went wrong" if the single smtp error path is chosen.

You can already. I think I mentioned in one of previous emails that I added
the ability for the smtp response code to be read via the
curl_easy_getinfo() command. You will need to upgrade your version of
libcurl (if you haven't done so already) to either 7.25 or 7.26 but then you
can get the response code out after a curl_easy_perform() has returned and
told you that it failed.

So for example:

If(curl_easy_peform(handle) != CURLE_OK)
{
    long response;

    curl_easy_getinfo(handle, CURLINFO_RESPONSE_CODE, response);

    printf("Received %ld response from SMTP server.", response);
}

For more information please see:
http://curl.haxx.se/libcurl/c/curl_easy_getinfo.html

> Well, I suppose that wasn't the most transparent question.
> Basically, some servers will support transfer of UTF-8 encoded
> strings, and some won't. I'm working on some code that ideally
> will be functional worldwide and ideally across all character
> sets- so the ability to send UTF-8 Strings would be the
> minimum- I can work out the external conversion to UTF-8.

Of the top of my head yes it will. I'm pretty sure I do this myself. In
summary I have an Email class that does all the encoding of headers, file
attachments, inline images, plain text and html messages etc... etc... I
convert the string to utf8 when call my setPlainContent() or
setHtmlContent() functions. When I call the generateMessage() function that
then generates the content for curl I encode it using Quoted Printable or
Base64 setting the headers accordingly. Unfortunately, curl doesn't do any
of the encoding for you so you will need to write your own mechanism to
generate the email content buffer to pass to curl. If you need assistance
here, I can send you some email examples.

Kind Regards

Steve

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