> Ugly, I know. This is the one downside to using libcurl for outbound
>SMTP: it doesn't have the ability to fetch back the *actual* error
>message sent back by the remote server; it only gives back the numeric
>code (550). But it reduced thousands of lines of code, that we were
>having trouble maintaining, down to a few screenfuls, and added a bunch
>of features that were built into the library.
While re-reading the libcurl documentation to see if there is any way around
this omission in their API, I came across a particularly ugly way of capturing
the remote server's error messages, and am giving it some consideration.
The libcurl API has a debug mode you can turn on, which spits all of the
protocol chatter out to stderr. It also has a callback hook that lets you
do send the debug messages to a user-supplied function instead of stderr.
We could theoretically abuse this function to capture the responses to SMTP
commands, ignore all transmitted data (so we don't re-capture the entire message
being sent out), and then filter for lines beginning with the numeric SMTP
response (such as 550) that the library *did* return to us.
Like I said ... it's ugly. But it's 100% permitted by the API, doesn't resort
to using undocumented calls, and it's way better than maintaining our own
protocol handler.
<Trump voice> "Believe me. I know protocol handlers. libcurl has the best
protocol handlers." </Trump voice>
