On Fri, 27 Nov 2009, Patrick Monnerat wrote:

> I started attempting to implement SMTP(S) months ago, but the work is
> stalled since then due to lack of time, and some libcurl procedures used
> have been altered too much to resurrect this work :-( In this attempt, I
> just noted that libcurl cannot do the job of a real SMTP server transmitter.
> In particular, it cannot retry temporary errors (like the ones caused by
> greylisting) after some delay. As a consequence, I think libcurl should be
> used only as a simple transmitter, like the ones you can find in any mail
> client, and thus connect to a predefined (in URL?) forwarder MTA rather than
> trying to process DNS MX records.

Oh yes, that's the kind of operation I'm thinking about too (and how it
currently is getting designed). Errors will be returned back like for other
protocols, so even temporary errors will be handled that way and then the app
would need to re-try later or however it wants to deal with them.

And figuring out which server to use (DNS MX etc) is out of libcurl's scope.

> That is why I rejected the "mailto" URL schema and started implementing a
> very simple URL (smtp[s]://[user[:password]@]host[:port]) in addition with
> two more CURLOPTs: CURLOPT_MAIL_SENDER (char *) and CURLOPT_MAIL_RECIPIENTS
> (struct curl_slist *).

Exactly. Those two options seem like good ones for me as well (my current code
sends MAIL FROM and RCPT TO to a set of hard-coded names and that might be bit
limited! ;-P)

> I'm really glad you decided to step into SMTP !

Thanks! (This work is sponsored by a company.)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html