> 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> 

Reply via email to