--- a/discussion.roff	Sat Jul 07 14:41:35 2012 +0200
+++ b/discussion.roff	Sat Jul 07 18:41:47 2012 +0200
@@ -2301,9 +2301,115 @@
 
 .H2 "Digital Cryptography
 .P
-Signing and encryption.
+Nmh offers no direct support for digital cryptography,
+i.e. digital signatures and message encryption.
+This functionality needed to be added through third-party software.
+In mmh, the functionality should be included because digital
+cryptography is a part of modern email and likely used by users of mmh.
+A fresh mmh installation should support signing and encrypting
+out-of-the-box.
+Therefore, Neil Rickert's
+.Pn mhsign
+and
+.Pn mhpgp
+scripts
+.[
+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.
+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
-FIXME
+.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,
+.Pn send
+does the job automatically.
+Special header fields were introduced to request the 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
+.Pe Pgpkey
+profile entry.
+.Pn send
+always signes messages 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
+.Hd Enc
+header field.
+Public keys of all recipients are taken from the gnupg keyring or
+from an overrides files, called
+.Fn pgpkeys .
+Unless public keys are found for all recipients,
+.Pn send
+will refuse to encrypt and send it.
+Currently, messages with hidden (BCC) recipients can not be encrypted.
+This corner-case requires a more complex solution.
+Covering it is left to do.
+.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
+.Sw -[no]sign
+and
+.Sw -[no]enc
+switches to
+.Pn send ,
+to override the corresponding header fields.
+The 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
+
+