cURL / Mailing Lists / curl-library / Single Mail


RE: SMTP recipient issues

From: Steve Holme <>
Date: Fri, 8 Jun 2012 22:42:37 +0100

Hi Dan,

> Alright ya'll. I may have found another issue, but maybe it's
> just me. Arising from the loop idea that was brought up as a
> temporary workaround- if curl_slist_free_all is called and I
> loop around and add a recipient to the same slist I just free
> all'ed, it creates an infinitely linked list- so you need to
> append to a NULL slist (see attached example).

I've not explicitly tried using the same recipient list myself as I've
wrapped the sending of an email into my own function that I pass a curl
handle into it so I can reuse the connection but my function uses its own
recipient list as I pass the to address in as a C++ std::string ;-)

> Could someone tell me why the value from curl_easy_perform()
> on an invalid address returns CURLE_LOGIN_DENIED and verify
> that it is unique from invalid login information? It seems to me
> that this is probably not an accurate error code, since to my
> limited understanding of mail servers, it is possible to be required
> to Login to a mail server to send mail. (though this would also
> prevent the recipient from receiving the email in question- it
> would just be more difficult to trace the real problem with
> sending that email)

This is by no means an excuse, and without checking the last years' worth of
changes I cannot be 100% sure, but as far as my memory serves... it's always
been like that :-/

I've started to change some of the error codes, for example in the version
of curl that you're using, EHLO and HELO failures will return
CURLE_LOGIN_DENIED but in more recent versions, curl_easy_peform() will
return CURL_REMOTE_ACCESS_DENIED instead ;-) However, I haven't found a
suitable error code for an invalid email address from curl.h - however, I
have added the ability in more recent versions to be able to return the smtp
response code by using curl_easy_getinfo() and that should return 550 (or
similar) in your case.

Please feel free to take a look at the header file and see if there is
another CURLE_* error code that you think would be more appropriate (maybe
CURLE_SEND_ERROR) as I agree that it is very misleading! I think we also
need to review the error codes for a failed MAIL command and DATA command as
well (currently CURLE_LOGIN_DENIED and CURLE_RECV_ERROR respectively - If
anything the latter should be CURLE_SEND_ERROR as we are sending data).

Alternatively if Daniel does mind us adding new SMTP specific error codes we
could add CURLE_SMTP_MAIL_ERROR and CURLE_SMTP_RCPT_ERROR and change the
data failed to be CURLE_SEND_ERROR.

> By the way- thanks for your attention to the last issue. I appreciate it.

Your welcome and I do value your input here.


List admin:
Received on 2012-06-08