docs/master

diff discussion.roff @ 166:f102dcc06bb9

s/digital cryptography/signing and encryption/
author markus schnalke <meillo@marmaro.de>
date Tue, 10 Jul 2012 09:58:30 +0200
parents ea6eec1722d1
children 277eeb5ba223
line diff
     1.1 --- a/discussion.roff	Tue Jul 10 00:03:31 2012 +0200
     1.2 +++ b/discussion.roff	Tue Jul 10 09:58:30 2012 +0200
     1.3 @@ -1769,7 +1769,7 @@
     1.4  But it can not ensure verbatim end-to-end delivery of the contents
     1.5  [RFC\|1864].
     1.6  The proper approach to verify content integrity in an
     1.7 -end-to-end relationship is the use of digital cryptography.
     1.8 +end-to-end relationship is the use of digital signatures.
     1.9  .\" XXX (RFCs FIXME).
    1.10  On the other hand, transfer protocols should detect corruption during
    1.11  the transmission.
    1.12 @@ -2341,13 +2341,12 @@
    1.13  
    1.14  
    1.15  
    1.16 -.H2 "Digital Cryptography
    1.17 +.H2 "Signing and Encrypting
    1.18  .P
    1.19 -Nmh offers no direct support for digital cryptography,
    1.20 -i.e. digital signatures and message encryption.
    1.21 +Nmh offers no direct support for digital signatures and message encryption.
    1.22  This functionality needed to be added through third-party software.
    1.23 -In mmh, the functionality should be included because digital
    1.24 -cryptography is a part of modern email and likely used by users of mmh.
    1.25 +In mmh, the functionality should be included because it
    1.26 +is a part of modern email and likely wanted by users of mmh.
    1.27  A fresh mmh installation should support signing and encrypting
    1.28  out-of-the-box.
    1.29  Therefore, Neil Rickert's