As the successor organisation to QUALCOMM's Eudora business units, we pledged from the date of our establishment to support our "legacy" users as far as realistically feasible. Our chief goal was to remedy the most frequently cited problems encountered when running Eudora 18.104.22.168 fourteen years after support ended. Several improvements were planned in fulfilment of this goal, both in public and internally.
At the very outset, we at Team HERMES set out to create a true descendant of Eudora 7 suitable for all modern business and educational communication. Until we're finished, you can use this, our transitional package.
Make no mistake, this is the ultimate in set-it-and-forget-it software patches. In one easy-to-installincludes everything you need to begin or continue using classic Eudora to-day. It includes our SSL Extensions (see below), the dependencies necessary to make them work, new root certificates, foreign-language dictionaries, and more.
Our most notable ongoing effort to discharge our pledge is HERMSSL: the HERMES Secure Sockets Layer Extensions for Eudora. Before its release in September of 2018, receiving mail from a secure server in Eudora entailed either the creation of a secure 'tunnel' with external software or the wholesale abandonment of the notion of security. Both were unacceptable choices; secure tunnelling requires a level of knowledge not typical of the average computerist, while insecure communication is a bad idea for reasons that are surely manifest.
Nevertheless, several influential Web sites promoted the latter approach, while the Eudora community was generally helpful in teaching the use of stunnel to new users.
QUALCOMM Eudora has always been the non plus ultra of electronic mail software, and eMail itself is essentially a mature technology. Trying to improve on Eudora, irrespective of our good intentions, would be much like gilding refined gold or painting lilies white. You can't mess with perfection.
That said, in the world of technology, there is no such thing as an island. In response to ever-shrinking global borders, foreign-language handling has had to improve; with cyberattacks growing apace, so has security—and this is just the tip of the metaphorical iceberg. If we want an eMailer that can keep up with these changes, it will have to be by the sweat of brows and with much elbow grease.
For example, clients communicate with secure servers using a protocol (essentially, a computer-to-computer "language") known initially as Secure Sockets Layer and subsequently as Transport Layer Security. The last version released during Eudora's lifetime was SSL 3; the latest version is TLS 1.2, with 1.3 forthcoming.
While ordinary practice in such cases of mismatch is to use the latest version understood on both ends, serious flaws were discovered that led to SSL versions 2 and 3 being withdrawn entirely; thus, if the client 'spoke' only SSL version 3, it would be unable to 'shake hands' with the server and communication would by necessity be insecure.
Another issue arises with so-called 'root certificates'. Even if client and server 'speak' TLS version 1.3, the client needs to know that it can safely trust the identifying token (certificate) passed to it during the 'handshake'. This has a real-world parallel: if you ask someone for I.D., and he hands you a British driving licence, you first need to know what Great Britain is and what a driving licence is. A computer's equivalent of this knowledge is called a root certificate store; while it's quite simple to compile this information, it needs to be kept up-to-date frequently.
There is also the fact that the majority of commercial eMail traffic essentially consists of self-contained Web pages, roughly equivalent to printed letterhead; naturally, the Hypertext Markup Language continually evolves to accommodate this and other things (particularly, as always, security). In Eudora, so-called 'styled text' isn't rendered directly, but rather with the assistance of Microsoft Trident, a product that was phased out long ago.
Internationalisation is probably the biggest stumbling block of them all. To a computer, the English letters, Arabic figures, some punctuation, and space are internally represented by the numbers 0-127 inclusive; this arrangement has been pretty much universal since the 1980's. In former times, foreign letters and special punctuation were assigned the numbers 128-255; this, however, was most definitely not universal, with different so-called 'code pages' for different groups of languages. This worked well enough, but only if both parties spoke the same single language and set their computer up accordingly. Embedding, for example, Greek text in a Czech document was nothing short of a nightmare.
With bilingual text growing in importance, an enormous, universal code page called Unicode or UTF-8 was introduced. It is notable in that it's a variable-width code page. To understand this idea, think of a document as a table with cells of equal size. Characters in an old-school (ASCII) document would fit in exactly one cell. In a Unicode document, though, characters can span across one to four cells. A program that expects strictly one character to a cell would understandably get very confused!
Finally, there is the matter of code that does not belong to us, resulting in 'holes' where parts of Eudora used to be. While some of these 'holes' can be filled, there remains some code that would be cost-prohibitive to use, or is unavailable for any price. This includes in particular the indexing search, which is the private property of X1 Corp. While a replacement might be found at Copernic, this would almost certainly be too expensive to justify.
From the above, one can see that bringing Eudora up to date is a complex, multi-faceted problem that requires creative thinking and detailed analysis to solve.
It has become apparent that the complicated situation previously described is best handled through a two-pronged approach: incremental patches as far as reasonably practical, followed by a full product release. It has also been judged expedient to release a bundle of Eudora 7.1 and all available patches for set-it-and-forget-it installation.
Eudora/W uses an off-the-shelf cryptographic tool called OpenSSL to handle SSL and TLS connexions, but wraps it in a custom dynamic link library called QCSSL; with Eudora being proprietary, closed-source software, QCSSL could not be kept in step with newer OpenSSL versions. This is no longer the case, and thus we could create a new QCSSL.DLL that leverages a modern version of OpenSSL.
This introduced a dependency into the mix; because it's written in a modern version of C++, the new QCSSL silently fails to work unless a sufficiently new Microsoft Visual C++ Redistributable is installed. We distribute this file with our patch (the HERMES SSL Extensions) so you don't have to look for it.
Updating Eudora's root certificate store is a trivial operation; we simply need to download it from here in PEM format, then convert it to CER format using a command of the form
$ openssl x509 -outform der -in your-cert.pem -out your-cert.crt
The bigger challenge is keeping it up to date; fortunately, the root certificates most commonly used in practice do not change on a monthly or even yearly basis. If a new certificate does 'pop up', you are advised to exercise his due diligence and manually trust it if necessary.
In addition, QUALCOMM Eudora in its heyday was shareware requiring a registration key. This isn't a difficult obstacle (which is why it wasn't set out above), because QUALCOMM released an unlocking key at its end of life, but it would be nice if new installations of Eudora came pre-registered.
The above solutions were feasible to implement in patch form; the computerist has a choice of a zipped archive for manual installation (that is, the HERMES SSL Extensions) or an automated, set-it-and-forget-it Eudora installer (the HERMES Transitional Package).
Distributing fixes to the rest of Eudora's obsolescence, however, will not be so simple. Both the HTML renderer and the spell checker take the form of so-called dynamic link libraries, and as such are nominally separate software. That said, Sentry (the old spell checker, written by Wintertree) and Trident (the old HTML renderer, written by Microsoft) link to Eudora in ways radically different to Hunspell and Chromium, respectively.
Meanwhile, Unicode support is a whole new feature, one upon which a significant amount of labour must be expended. Unicode support is naturally resident within the application itself.
The long and the short of it is that bringing the latter three features into HERMES Mail will mean a full, major-version upgrade (that is, from 7.1 to 8.0). Given the troubled development cycle thus far, it would make no sense to put a firm shipping target onto Mail 8, but before Christmas 2019 would appear to be probable.
Accordingly, we advise all persons and institutions using QUALCOMM Eudora 22.214.171.124 and older not to delay migration in hopes of a later incremental update. If you are a system administrator for an institution, please note that the level of staff re-training required will be zero-to-minimal. We strongly suggest that you migrate to HERMES Mail 8.0 at the earliest possible opportunity.