For years, I’ve endorsed the idea that using a simple low-level protocol was far easier to troubleshoot and maintain than the high-level, proprietary and hidden-from-view COM interfaces that were all the rage in the Windows world, hence, “SMTP Good, MAPI Bad.”
Laura and I support a vertical-niche application in use around the country. Each of the installations runs Visual FoxPro 7 as a LAN-based application and sends faxes via email using MaxEmail, rather than supporting their own in-house faxing system. On a regular basis, one of our clients will change email providers, so the settings for email are stored in a separate file for easy update.
“Easy,” though, is a relative term. More email providers are requiring authentication before allowing outgoing emails, a reasonable precaution against spam. However, each installation of SMTP AUTH we have run up against has a slightly different variation on how authentication is done, and invariably, email stops until we analyze, debug and modify our code to support the new variation.
I’ve used the free BLAT command-line tool with it’s -debug switch to allow me to witness the actual conversation that takes place between email client and server to determine the details of where the conversation is breaking down and how to fix it. Open Source rocks! BLAT rocks!
In this last case, the new email provider’s SMTP AUTH required a user name (“bob”) and not an email address (“bob@example.com”) as the user name. The previous SMTP AUTH interfaces were comfortable with the same name for email address and user name. Laura tweaked the code and we got the client back up and running.
UPDATE: Thanks to Alex Feldstein for the pointer. In fact, we too are using Rick Strahl’s wwIPStuff, now renamed West Wind Client Tools as the machanism within the application to send SMTP mails. We’ve just used the standalone BLAT for its great low-level debugging facilities and ease of use from the commandline to figure out what to tell wwIPStuff to do.