PGP can be a rather unfriendly program, especially to those uncomfortable with using a command line in the MS-DOS or Unix tradition. Even to those users who are happy with a command line interface, it is undoubtedly inconvenient to have to compose mail into a file, run PGP on the result and finally include the encrypted information into a message using the MUA's import facility in order to send secure email. Reading incoming mail is just as arduous if it has first to be saved to a file and then decrypted outside the MUA. If only this method is supported, secure email will tend only to be used for ``special'' messages.
The ideal would be for PGP to be virtually invisible to the email user. The MUA would itself decrypt incoming email and check signatures, displaying the result for the user. It would fetch the public key required for signature checking, either from the user's public keyring or from some on-line key service. Outgoing mail would be automatically signed, if required, and encrypted in the public keys of the recipients. Again, any needed public keys would be fetched rapidly and invisibly if they were not available on the user's keyring.
This ideal is unlikely to be achievable, even in principle. For a start, signing and decrypting require access to the user's private key. This is normally kept encrypted to protect it from compromise, so the user is asked for a passphrase --- violating the invisibility requirement. The passphrase could be requested at the beginning of a session and be kept in memory or in a file. This may be acceptable to some users on some systems. However, this solution carries the risk that the passphrase becomes visible to third parties if they can examine memory and/or disk storage. That risk may be unacceptable. Additional problems arise when a necessary public key cannot be obtained. For signature checking this might not be important: the user can be informed that the signature could not be checked because the key was unavailable. When a recipient's key cannot be found, however, we may be in a quandary. All the obvious solutions are flawed: rejecting the mail and bouncing it to the sender is not very friendly; sending it out unencrypted removes all security and even the half-way solution of encrypting and mailing to those keys which can be found and rejecting it for the others begs the question of how email may be sent to those without keys.
The ideal is impossible to achieve for another, practical, reason. There are a large number of MUAs in use in the JANET community, and not all of them are amenable to modification, either because of their structure or because their source code is not available. Further, although a MUA might be modifiable in principle, it may be used by so few people that the required effort could not be justified.
If the ideal cannot be achieved, a compromise must be sought. We must accept that the user will be required to do more to send and receive secure email than insecure email. We must find ways of coping with missing keys and we must permit users to store private key passphrases if they wish to take the risk but we should minimise that risk and inform the users that they are taking a risk. Those MUAs which are difficult to modify will have to be inelegant; those which are impossible to modify must either be circumvented (perhaps by intercepting the incoming and outgoing email streams before or after the MUA gets a chance) or the user will have to use PGP on external files.