It's so hard to send email programmatically

One look at the subject line, and I'm sure the first word that comes to the minds of the four people who might see this blog is, "Huh?" Sending email isn't hard. Programs do it all the time. Why can't a genius like you figure it out, Yakko?

Well, here's the problem. See, I'm writing a custom Windows application for a client. This application is essentially a database for storing the deposits and withdrawals of a handful of investment companies and their investors. In essence, it's copying what he tracked in spreadsheets. Since I'm moving this from spreadsheet to database, I can implement all new features for him like tracking performance over time, graph them, compare them to market indices, and the big new feature, generate PDF reports and email them instead of printing paper copies one by one.

He runs all of this on a PC in his home office. As such, I made sure I wrote the program to be as small and simple as possible. Sure I considered using SQL Server Express with Reporting Services to generate the reports, but how easy would that be for him to install, or back up the program, or send to his part-time clerk for easy data entry? Small and lightweight were part of my requirements here. And thanks to the .Net framework, I managed to write a pretty decent app, with a SQL Server CE database engine, that would fit on a floppy disk. Not that I could find a floppy disk to put it on anymore, but you get the idea.

The one part of the program that really disappointed me, though, was the email tool. Here I managed to generate these nice-looking PDF reports in real-time (using the PDFSharp library -- they say "the same drawing routines can be used to create PDF documents, draw on the screen, or send output to any printer", and in my experience it really was almost that easy to convert my paper printing code to make a PDF). But how to email them?

While it is true that the .Net framework includes some very simple routines for sending SMTP mail, which I have used before in various client-server, intranet, and web applications, the trick is they work really well if you're using them on a server. Ever send email from a personal computer on a dial-up connection? (Yes, he's still on dial-up; don't ask.) Even if you're on broadband on a static IP, chances are your address is identifiable as an end-user, and there's a very good chance your email will be rejected with prejudice.

Now, he can send out email using his email program of choice. Why? Naturally, because it's configured to use his ISP's email server. Because I want to keep this program as simple as possible, adding email configuration was not in the design; and, I could find no way to query Windows to discover (a) what email program he's using, and (b) what settings that program uses to send email. (I couldn't even be certain I could use the same settings -- he's on MSN; what if it requires SPA?)

When you think about it, it all makes sense. How easy it would be for spammers to write programs to do just that and send email out via a user's ISP's email server, instead of trying to send out from the easily-blockable local address.  If I recall correctly, viruses used to do just that, before email programs had to get better at locking external program access out.

So what do I do? I create a "mailto" link with the appropriate subject and body parameter for every PDF that must get generated (but no attach parameter; although that used to work once upon a time, apparently that got to be too big of a security risk as well, and while some email programs simply ignore it, Outlook will refuse to start and throw an error instead), then delay about 5 seconds (because in some of my test scenarios, if a second "mailto" link was getting processed at just the wrong point of processing of the first one, the second would trigger an error instead of opening a second window). Once all the mail windows were open, an Explorer window would be opened to the folder containing all the PDFs generated, so they could be manually dragged and dropped on the appropriate mail windows.

I ask you: how much does that suck?

Probably the only redeeming point in this is that, at this early stage in the game, manual intervention is desired, so he can see the reports and the messages before they go anywhere. It's going to get old very fast, though...