Hacking SSL support into smtpop.dll

In one of our applications, we use smtpop.dll to retrieve email from a POP3 mailbox. Today, we had to connect to a mailbox that supports only SSL, while smtpop.dll does not work with SSL.

Our code to retrieve email is behind a fa├žade, so I expected that it would be easy to replace smtpop.dll with another mail framework. However, I found out that the interface mimicked that of smtpop.dll closely instead of presenting a broader abstraction; that is, the interface has methods that map one-to-one to those of the POP3Client class of smtpop.dll. We tried an adapter implementation based on the interface to translate calls to the replacement mail classes, but we encountered difficulties during the spikes, mostly because of the state of the code.

The solution I went for was to decompile smtpop.dll, examine how it worked internally, and derive a new class from it. It turned out that the only two methods that needed changing were Open and Quit .

Unfortunately, the methods of class POP3Client are not virtual. But, luckily for us, some of the class members are of protected visibility and so accessible in the derived class. I rewrote the Open and Quit methods as “new” methods, which means that they are not polymorphic. This also forces us to replace usage of POP3Client with Pop3ClientWithSsl everywhere in the code. But, at least, we have some respite before we have to implement a cleaner solution.

Leave a Reply