It is quite clear that PGP can be integrated into mail user agents not originally designed for that purpose. The truly excellent work done by the authors of the Elm, Emacs and exmh packages is proof of that. The users of those packages find that PGP is easy to use in a manner that is perfectly natural in that context. It is equally clear that the majority of email users are not so fortunate, and that varying degrees of effort will be required to bring their tools up to the standards of the first three. Those MUAs for which source code or an API is easily available, such as Pine, should be straightforward though possibly laborious to bring up to full functionality. It is likely that some commercial mailers, such as OpenVMS MAIL, are likely to prove difficult to integrate fully. Even these utilities are not hopeless, however, as long as they provide hooks which can be used (or abused!) to call external programs in a few useful contexts such as composing and viewing a message.
We recommend that UKERNA commission workers to integrate PGP fully into
those mailers for which source code is available. The outstanding
candidate is Pine. We also recommend that UKERNA commission workers to
integrate PGP into those mailers which are not quite so amenable but are
in widespread use and which existing attempts at integration have
demonstrated that it is possible to a large extent. The prime
candidates in this class are Pegasus and Eudora. The final class of
popular mailers (we ignore those used only by a tiny minority) are those
which are closed commercial products. Some suppliers may be amenable to
requests from UKERNA to make hooks available and/or publish an API so
that PGP may be added alongside their product. We recommend that this
be given serious consideration. An alternative approach would be to
follow the leads shown by Private Idaho and privtool: to create a
wrapper which calls the underlying mailer or to write an emulation of a
popular mailer. Neither of these is completely satisfactory. The
wrapper approach requires that the user learns another interface, hardly
a characteristic of the ideal invisible software. The second, while
superficially much more attractive also has problems. Not only may
there be messy arguments over copyright of interfaces, re-writing a
complex tool from scratch is a lengthy and expensive process --- not
least because the emulation has to be extremely precise for it to become
popular. We feel that we are not able to give concrete recommendations
on how to procede with these closed commercial mailers, other than to
suggest that the subject be investigated more deeply in the near future.