The result was several HTTP 500 errors and a relatively generic set of log messages. Actually we weren't always seeing anything in the logs. It was fairly perplexing. When we did get error messages they were like this:
The first part of the solution was to set the application pool for that website to 32 bit. You do this by opening IIS Manager, select Application Pools, select the application pool you're modifying, in the Actions pane click Advanced Settings..., then set Enable 32-Bit Applications to True. After you've done that, reset IIS and try your site. If the site still isn't working, reboot your machine. Apparently Windows isn't all that keen on switching between 64 and 32 bit, so sometimes a reboot is in order. [We had to.]
Maybe that will fix your problems, it didn't for us. In fact, the ODBC error seems to stem from this action. Apparently when you create an ODBC DSN it's only available to 64 bit processes. You have to create the DSN in the 32 bit space by using the 32 bit Data Source Administrator from the SysWOW64 directory [odbcad32.exe].
We still had those pesky JMail errors. The object was created successfully but we were getting File I/O errors. We followed advice that suggested we should copy the DLL to the SysWOW64 directory and register it there. No change. We modified the permissions on the DLL to allow everyone to read and execute it. No change.
What we hadn't thought of yet was to modify permissions on the SMTP pickup folder. We didn't think of this because the test page we'd created had everything but the instantiation commented. Still, this simple change made all the difference. For whatever reason, giving write permission to the IUSR didn't fix this. We tried a few other users before we gave up and just gave all local users write permission to the pickup folder. This did the trick.
Overall this was a royal pain. That's why I stopped to do this quick write up. I hope it helps.