--- a/discussion.roff	Tue Jul 10 18:48:32 2012 +0200
+++ b/discussion.roff	Tue Jul 10 22:28:10 2012 +0200
@@ -2361,99 +2361,99 @@
 .[
 neil rickert mhsign mhpgp
 .]
-were included into mmh.
-The scripts fit well into the mmh, because they are lightweight and
-of style similar to the existing tools.
+were included into mmh
+.Ci f45cdc98117a84f071759462c7ae212f4bc5ab2e
+.Ci 58cf09aa36e9f7f352a127158bbf1c5678bc6ed8 .
+The scripts fit well because they are lightweight and
+similar of style to the existing tools.
 Additionally, no licensing difficulties appeared,
 as they are part of the public domain.
 .P
-The scripts were written for nmh, hence I needed to adjust them according
-to the differences of mmh.
-For instance, I removed the use of the backup prefix and dropped support
-for old PGP features.
-.P
 .Pn mhsign
 handles the signing and encrypting part.
 It comprises about 250 lines of shell code and interfaces between
 .Pn gnupg
 and
 the MH system.
-It was meant to be invoked at the WhatNow prompt, but in mmh,
+It was meant to be invoked manually at the WhatNow prompt, but in mmh,
 .Pn send
-does the job automatically.
-Special header fields were introduced to request the action.
+invokes
+.pn mhsign
+automatically
+.Ci c7b5e1df086bcc37ff40163ee67571f076cf6683 .
+Special header fields were introduced to request this action.
 If a draft contains the
 .Hd Sign
 header field,
 .Pn send
-will sign it.
-The key to be used is either chosen automatically or specified by the
+will initiate the signing.
+The signing key is either chosen automatically or specified by the
 .Pe Pgpkey
 profile entry.
 .Pn send
-always signes messages using the PGP/MIME standard, \" REF XXX
+always create signatures using the PGP/MIME standard, \" REF XXX
 but by manually invoking
 .Pn mhsign ,
 old-style non-MIME signatures can be created as well.
-To sign an outgoing message, the draft needs to contain a
+To encrypt an outgoing message, the draft needs to contain an
 .Hd Enc
 header field.
-Public keys of all recipients are taken from the gnupg keyring or
-from an overrides files, called
-.Fn pgpkeys .
+Public keys of all recipients are searched for in the gnupg keyring and
+in a file called
+.Fn pgpkeys ,
+which contains exceptions and overrides.
 Unless public keys are found for all recipients,
-.Pn send
-will refuse to encrypt and send it.
+.Pn mhsign
+will refuse to encrypt it.
 Currently, messages with hidden (BCC) recipients can not be encrypted.
 This work is pending because it requires a structurally more complex
 approach.
 .P
+.Pn mhpgp
+is the companion to
+.Pn mhsign .
+It verifies signatures and decrypts messages.
+Encrypted messages can either be temporarily decrypted for display
+or permanently decrypted and stored into the current folder.
+Currently,
+.Pn mhpgp
+needs to be invoked manually.
+The integration into
+.Pn show
+and
+.Pn mhstore
+to verify signatures and decrypt messages as needs
+is planned but not realized yet.
+.P
+Both scripts were written for nmh, hence they needed to be adjust
+according to the differences between nmh and mmh.
+For instance, they use the backup prefix no longer.
+Further more, compatibility support for old PGP features was dropped.
+.P
 The integrated message signing and encrypting support is one of the
 most recent features in mmh.
-Feedback from users and the experience I will gather myself
-will direct the further development of the facility.
-It is worthwhile to consider adding
+It has not yet had the time to mature.
+User feedback and personal experience need to be accumulated to
+direct the further development of the facility.
+Although the feedback and experience is still missing,
+it seems to be worthwhile to consider adding
 .Sw -[no]sign
 and
 .Sw -[no]enc
 switches to
 .Pn send ,
-to override the corresponding header fields.
-The profile entry:
+to be able to override the corresponding header fields.
+A profile entry:
 .VS
 send: -sign
 VE
-.LP
-would then activate signing of all outgoing messages.
-With the present approach, the line
-.VS
-Send:
-VE
-.LP
-needs to be added to all message forms to achieve the same result.
-Yet, the integration of
-.Pn mhsign
-into mmh is too recent to have enough experience to decide this
-question now.
-.P
-.Pn mhpgp
-is the contrary part to
-.Pn mhsign .
-It verifies signatures and decrypts messages.
-.P
-FIXME: Add it to mmh first, then write about it here.
-.P
-The integration of
-.Pn mhpgp
-into
-.Pn show ,
-to automatically verify signatures and decrypt messages as needed,
-is a task left open.
-.Pn show 's
-current structure does not allow such an integration on basis of
-the existing code.
-Extensive programming work is required. ...  FIXME
-
+would then activate signing for all outgoing messages.
+With the present approach, a
+.Hd Send
+header component needs to be added to each draft template
+to achieve the same result.
+Adding the switches would ease the work greatly and keep the
+template files clean.