1.1 --- a/discussion.roff	Tue Jul 10 18:48:32 2012 +0200
     1.2 +++ b/discussion.roff	Tue Jul 10 22:28:10 2012 +0200
     1.3 @@ -2361,99 +2361,99 @@
     1.4  .[
     1.5  neil rickert mhsign mhpgp
     1.6  .]
     1.7 -were included into mmh.
     1.8 -The scripts fit well into the mmh, because they are lightweight and
     1.9 -of style similar to the existing tools.
    1.10 +were included into mmh
    1.11 +.Ci f45cdc98117a84f071759462c7ae212f4bc5ab2e
    1.12 +.Ci 58cf09aa36e9f7f352a127158bbf1c5678bc6ed8 .
    1.13 +The scripts fit well because they are lightweight and
    1.14 +similar of style to the existing tools.
    1.15  Additionally, no licensing difficulties appeared,
    1.16  as they are part of the public domain.
    1.17  .P
    1.18 -The scripts were written for nmh, hence I needed to adjust them according
    1.19 -to the differences of mmh.
    1.20 -For instance, I removed the use of the backup prefix and dropped support
    1.21 -for old PGP features.
    1.22 -.P
    1.23  .Pn mhsign
    1.24  handles the signing and encrypting part.
    1.25  It comprises about 250 lines of shell code and interfaces between
    1.26  .Pn gnupg
    1.27  and
    1.28  the MH system.
    1.29 -It was meant to be invoked at the WhatNow prompt, but in mmh,
    1.30 +It was meant to be invoked manually at the WhatNow prompt, but in mmh,
    1.31  .Pn send
    1.32 -does the job automatically.
    1.33 -Special header fields were introduced to request the action.
    1.34 +invokes
    1.35 +.pn mhsign
    1.36 +automatically
    1.37 +.Ci c7b5e1df086bcc37ff40163ee67571f076cf6683 .
    1.38 +Special header fields were introduced to request this action.
    1.39  If a draft contains the
    1.40  .Hd Sign
    1.41  header field,
    1.42  .Pn send
    1.43 -will sign it.
    1.44 -The key to be used is either chosen automatically or specified by the
    1.45 +will initiate the signing.
    1.46 +The signing key is either chosen automatically or specified by the
    1.47  .Pe Pgpkey
    1.48  profile entry.
    1.49  .Pn send
    1.50 -always signes messages using the PGP/MIME standard, \" REF XXX
    1.51 +always create signatures using the PGP/MIME standard, \" REF XXX
    1.52  but by manually invoking
    1.53  .Pn mhsign ,
    1.54  old-style non-MIME signatures can be created as well.
    1.55 -To sign an outgoing message, the draft needs to contain a
    1.56 +To encrypt an outgoing message, the draft needs to contain an
    1.57  .Hd Enc
    1.58  header field.
    1.59 -Public keys of all recipients are taken from the gnupg keyring or
    1.60 -from an overrides files, called
    1.61 -.Fn pgpkeys .
    1.62 +Public keys of all recipients are searched for in the gnupg keyring and
    1.63 +in a file called
    1.64 +.Fn pgpkeys ,
    1.65 +which contains exceptions and overrides.
    1.66  Unless public keys are found for all recipients,
    1.67 -.Pn send
    1.68 -will refuse to encrypt and send it.
    1.69 +.Pn mhsign
    1.70 +will refuse to encrypt it.
    1.71  Currently, messages with hidden (BCC) recipients can not be encrypted.
    1.72  This work is pending because it requires a structurally more complex
    1.73  approach.
    1.74  .P
    1.75 +.Pn mhpgp
    1.76 +is the companion to
    1.77 +.Pn mhsign .
    1.78 +It verifies signatures and decrypts messages.
    1.79 +Encrypted messages can either be temporarily decrypted for display
    1.80 +or permanently decrypted and stored into the current folder.
    1.81 +Currently,
    1.82 +.Pn mhpgp
    1.83 +needs to be invoked manually.
    1.84 +The integration into
    1.85 +.Pn show
    1.86 +and
    1.87 +.Pn mhstore
    1.88 +to verify signatures and decrypt messages as needs
    1.89 +is planned but not realized yet.
    1.90 +.P
    1.91 +Both scripts were written for nmh, hence they needed to be adjust
    1.92 +according to the differences between nmh and mmh.
    1.93 +For instance, they use the backup prefix no longer.
    1.94 +Further more, compatibility support for old PGP features was dropped.
    1.95 +.P
    1.96  The integrated message signing and encrypting support is one of the
    1.97  most recent features in mmh.
    1.98 -Feedback from users and the experience I will gather myself
    1.99 -will direct the further development of the facility.
   1.100 -It is worthwhile to consider adding
   1.101 +It has not yet had the time to mature.
   1.102 +User feedback and personal experience need to be accumulated to
   1.103 +direct the further development of the facility.
   1.104 +Although the feedback and experience is still missing,
   1.105 +it seems to be worthwhile to consider adding
   1.106  .Sw -[no]sign
   1.107  and
   1.108  .Sw -[no]enc
   1.109  switches to
   1.110  .Pn send ,
   1.111 -to override the corresponding header fields.
   1.112 -The profile entry:
   1.113 +to be able to override the corresponding header fields.
   1.114 +A profile entry:
   1.115  .VS
   1.116  send: -sign
   1.117  VE
   1.118 -.LP
   1.119 -would then activate signing of all outgoing messages.
   1.120 -With the present approach, the line
   1.121 -.VS
   1.122 -Send:
   1.123 -VE
   1.124 -.LP
   1.125 -needs to be added to all message forms to achieve the same result.
   1.126 -Yet, the integration of
   1.127 -.Pn mhsign
   1.128 -into mmh is too recent to have enough experience to decide this
   1.129 -question now.
   1.130 -.P
   1.131 -.Pn mhpgp
   1.132 -is the contrary part to
   1.133 -.Pn mhsign .
   1.134 -It verifies signatures and decrypts messages.
   1.135 -.P
   1.136 -FIXME: Add it to mmh first, then write about it here.
   1.137 -.P
   1.138 -The integration of
   1.139 -.Pn mhpgp
   1.140 -into
   1.141 -.Pn show ,
   1.142 -to automatically verify signatures and decrypt messages as needed,
   1.143 -is a task left open.
   1.144 -.Pn show 's
   1.145 -current structure does not allow such an integration on basis of
   1.146 -the existing code.
   1.147 -Extensive programming work is required. ...  FIXME
   1.148 -
   1.149 +would then activate signing for all outgoing messages.
   1.150 +With the present approach, a
   1.151 +.Hd Send
   1.152 +header component needs to be added to each draft template
   1.153 +to achieve the same result.
   1.154 +Adding the switches would ease the work greatly and keep the
   1.155 +template files clean.
   1.156  
   1.157  
   1.158