Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues.
GnuTLS is the "clearer" solution from a license point of view: The client library is LGPL, and it can thus be safely linked to everything that is part of Debian main. This is the main reason why we decided to use GnuTLS for exim4 years ago, so that we do not need to worry about licensing issues when some other library is linked to by exim some time in the future.
On the other hand, my impression gets stronger and stronger that GnuTLS is not ready for prime-time. There is a truckload of interoperability problems with a number of "remote sides". The most prominent issues are TLS aborts when exim4 is SMTP server for some clients, most notably Incredimail and some mobile Phones from Nokia and other vendors. Most of them can be nailed down to misnegotiation of certain ciphers, but exim does currently not allow disabling of some ciphers at run-time, and - even worse - one would need to disable them completely since one cannot judge in advance whether we are facing a client with issues or one without.
The GnuTLS maintainers of both Debian and upstream try being helpful, but I do not see a long-term solution here.
Additionally, nobody upstream knows its way around the GnuTLS related code in exim, which was contributed by Nikos Mavroyanopoulos years ago. So, there is little chance to get GnuTLS-related bugs ironed out from exim.
OpenSSL, on the other hand, does not have these interoperability issues. At least, I haven't heard of any, and the recommended fix for the reporters of GnuTLS related bugs, "recompile exim with OpenSSL" (which the packaging has been supporting for nearly two years now), usually fixes their problems. I am not in a position to judge whether this is caused by people actually testing against OpenSSL, or OpenSSL generally being more tolerant towards strange implementations, or GnuTLS being buggy or poorly written.
However, building exim4 again OpenSSL may post the license issues that convinced us to use GnuTLS in the first place. Exim itself has an OpenSSL exception, and from what I have been told, the MySQL FLOSS License Exception allows linkage to OpenSSL as well. At least, it does now, since historical evidence in the exim4 package either shows that it used to be a license violation to link MySQL and OpenSSL in the past, or that we (the Debian exim4 team) wrongly thought so. On the other hand, if it is illegal to have OpenSSL and "really" GPLled code in the same execution space, we already have that license violation today, brought to us by PostgreSQL, which links against OpenSSL.
ftpmaster has already indicated that they won't consider an exim4 linked against OpenSSL a license violation and that the packages would go through, the packaging can handle the change by virtue of flipping a switch and rebuilding, but I am still not fully convinced that doing so is the right thing from a political and license point of view. I might still need that final nudge by feedback to this blog article, or have my reluctance fed. Please comment.
No, I do not plan to take this to debian-legal; I'd prefer exim4 staying in Debian main.