Even with bug 1631198 fixed, the sender's key, e.g. the one used for creating a signature, might be unavailable.
Based on existing Enigmail code, I've implemented additional mechanism to assist the user.
Even without having the key yet, we can obtain the ID of the key used to create the signature. The only way to reliably way search by key ID is by using a key server.
How do we invite the user to search for the missing key? We can reconsider how to present that, but to get started, I used a notification line at the bottom of the email, saying "Message was signed with a key that you don't have yet", and a button "Search Internet…"
What happens if the key is found? With our approach to give the user control, I think we should use the usual "do you want to import" question, and when imported, show the summary of what happened.
While workin on that, I noticed a detail, which I had missed in the past.
The "successfully imported" dialog contains a link "Details", which opens the key details dialog, the one which also allows the user to configure the acceptance of the key.
I think this is great. But I think that needs to be more discoverable. Right now, the one word link "Details" is easily missed (at least I missed it previously).
So, I've made two changes to that confirmation dialog: Replaced the text "Details" with the longer text "View Details and manage Key Acceptance" and moved it to the bottom. Because this text is shown in blue as a hyperlink, it's much more noticeable.
Also, there was a big green checkmark in that dialog. I think that's distracting, it gives the impression "everything's done", which is no longer correct - because after importing completed, the user should consider what to do with this new key (review and configure acceptance). To avoid the distraction, I've removed the green checkmark.
Now, an email might be encrypted, only, not signed. And it might be missing a key attachment. I think we should offer the user a mechanism to search the Internet for the sender's public key. (Enigmail did this in the past with a button on the top.) I have an alternative suggestion, with an initial implementation. When clicking any recipient in an email, we currently show a right click popup menu. I've added a menu entry "Search Internet for OpenPGP Key". When clicked, we'll check two places: Using the WKD mechanism on the mail provider's server (for those servers that offer it), and it that fails, we'll search a keyserver (keys.openpgp.org). Again, contrary to what Enigmail did in the past, the user needs to manually confirm importing of the found key (to ensure the user is aware and has control), and also the import success report (with the option to open details and configure the acceptance).
This required a change to the keyserver.jsm code, to support downloading without immediate importing. (I need to change the remaining keyserver mechanisms to support that, too. For now, it's implemented for the vks mechanism only, but can easily merged over to the others.)
As a ride along, I've completely removed the hidden status element in the mail reader header area (which we hid in bug 1624939 comment 7). Instead, the code prints the details of the verification as a debug statement on the console (until we have implemented the detailed feedback in secondary UI, message security info).