William Betts wrote:
> HI Steve,
>
> If libcurl will ditch the entire message because of a failed RCPT TO command
> it should be listed as a bug. If the SMTP session has at least 1 valid
> recipient the transaction should finish. I'll check it out in a bit and see
> if that's the case on my end.
>
> Best Regards,
> William

I haven't messed with curl SMTP (but may eventually), so these comments are
strictly from the peanut gallery:

It seems to me that without a mechanism provide the caller with information
about WHICH address(es) failed, it is appropriate to give up on any failure
and abort the transaction. At best, one could set an option to Allow
Partials which would permit the transaction to proceed as long as at least
one address was accepted. A 'Some Sent' status would result in that case.
This seems generally unsatisfactory though.

Perhaps what is needed is a callback for address successes/failures? The
callback could be called with the address, a Boolean indicating
success/failure and the SMTP RCPT result code & text for any logging the
caller wishes to perform. The callback could do bookkeeping for the caller
then return a continue/fail code to libcurl. The simpleton callback for the
current case would return continue for success and fail for failures. To
allow partials, it would always return continue.

One step further might be to have a callback for providing the addresses in
the first place. It would be called each time libcurl needs the next
address, returning the next address or and end of list indication. The pair
of callbacks, in combination with userdata would make it easy for a program
to feed an address list from an arbitrary source to libcurl and deal with
the results in as simple or complex a way as desired.

FWIW...
Rich

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