1.1 --- a/ch03.roff	Wed Jun 06 18:11:35 2012 +0200
     1.2 +++ b/ch03.roff	Wed Jun 06 18:27:28 2012 +0200
     1.3 @@ -775,7 +775,9 @@
     1.4  .I draft_from
     1.5  masquerading type instructed
     1.6  .Pn post
     1.7 -to use the value of the `From:' header as SMTP envelope sender.
     1.8 +to use the value of the
     1.9 +.Hd From
    1.10 +header field as SMTP envelope sender.
    1.11  Sender addresses could be replaced completely.
    1.12  .Ci b14ea6073f77b4359aaf3fddd0e105989db9
    1.13  Mmh offers a kind of masquerading similar in effect, but
    1.14 @@ -785,17 +787,21 @@
    1.15  by the MTA.
    1.16  In times of pedantic spam checking, an MTA will take care to use
    1.17  sensible envelope sender addresses to keep its own reputation up.
    1.18 -Nonetheless, the MUA can set the `From:' header and thereby propose
    1.19 +Nonetheless, the MUA can set the
    1.20 +.Hd From
    1.21 +header field and thereby propose
    1.22  a sender address to the MTA.
    1.23  The MTA may then decide to take that one or generate the canonical sender
    1.24  address for use as envelope sender address.
    1.25  .P
    1.26  In mmh, the MTA will always extract the recipient and sender from the
    1.27 -message headers (\c
    1.28 +message header (\c
    1.29  .Pn sendmail 's
    1.30  .Sw -t
    1.31  switch).
    1.32 -The `From:' header of the draft may be set arbitrary by the user.
    1.33 +The
    1.34 +.Hd From
    1.35 +header field of the draft may be set arbitrary by the user.
    1.36  If it is missing, the canonical sender address will be generated by the MTA.
    1.37  
    1.38  .U3 "Remaining Options
    1.39 @@ -925,42 +931,62 @@
    1.40  
    1.41  .U2 "Removed support for header fields
    1.42  .P
    1.43 -The `Encrypted' header had been introduced by RFC\^822, but already
    1.44 +The
    1.45 +.Hd Encrypted
    1.46 +header field had been introduced by RFC\^822, but already
    1.47  marked legacy in RFC 2822. It was superseded by FIXME.
    1.48 -Mmh does no more support this header.
    1.49 +Mmh does no more support this header field.
    1.50  .P
    1.51 -Native support for `Face' headers
    1.52 -had been removed, as well.
    1.53 -The feature is similar to the `X-Face' header in its intent,
    1.54 +Native support for
    1.55 +.Hd Face
    1.56 +header fields had been removed, as well.
    1.57 +The feature is similar to the
    1.58 +.Hd X-Face
    1.59 +header field in its intent,
    1.60  but takes a different approach to store the image.
    1.61 -Instead of encoding the image data directly into the header,
    1.62 -the the header contains the hostname and UDP port where the image
    1.63 +Instead of encoding the image data directly into the header field,
    1.64 +the it contains the hostname and UDP port where the image
    1.65  date could be retrieved.
    1.66 -Neither `X-Face' nor the here described `Face' system
    1.67 +Neither
    1.68 +.Hd X-Face
    1.69 +nor the here described
    1.70 +.Hd Face
    1.71 +system
    1.72  \**
    1.73  .FS
    1.74  There is also a newer but different system, invented 2005,
    1.75 -using `Face' headers.
    1.76 -It is the successor of `X-Face' providing colored PNG images.
    1.77 +using
    1.78 +.Hd Face
    1.79 +headers.
    1.80 +It is the successor of
    1.81 +.Hd X-Face
    1.82 +providing colored PNG images.
    1.83  .FE
    1.84  became well used in the large scale.
    1.85  It's still possible to use a Face systems,
    1.86  although mmh does not provide support for any of the different systems
    1.87  anymore. It's fairly easy to write a small shell script to 
    1.88  extract the embedded or fetch the external Face data and display the image.
    1.89 -Own Face headers can be added into the draft template files.
    1.90 +Own
    1.91 +.Hd Face
    1.92 +header field can be added into the draft template files.
    1.93  .P
    1.94 -`Content-MD5' headers were introduced by RFC\^1864. They provide only
    1.95 +.Hd Content-MD5
    1.96 +header fields were introduced by RFC\^1864. They provide only
    1.97  a verification of data corruption during the transfer. By no means can
    1.98  they ensure verbatim end-to-end delivery of the contents. This is clearly
    1.99  stated in the RFC. The proper approach to provide verificationability
   1.100  of content in an end-to-end relationship is the use of digital cryptography
   1.101  (RFCs FIXME). On the other hand, transfer protocols should ensure the
   1.102  integrity of the transmission. In combinations these two approaches
   1.103 -make the `Content-MD5' header field useless. In consequence, I removed
   1.104 +make the
   1.105 +.Hd Content-MD5
   1.106 +header field useless. In consequence, I removed
   1.107  the support for it. By this removal, MD5 computation is not needed
   1.108  anywhere in mmh. Hence, over 500 lines of code were removed by this one
   1.109 -change. Even if the `Content-MD5' header field is useful sometimes,
   1.110 +change. Even if the
   1.111 +.Hd Content-MD5
   1.112 +header field is useful sometimes,
   1.113  I value its usefulnes less than the improvement in maintainability, caused
   1.114  by the removal.
   1.115  
   1.116 @@ -980,9 +1006,11 @@
   1.117  .Pn prompter
   1.118  hadn't been touched lately. Otherwise it's hardly explainable why it
   1.119  still offered the switches
   1.120 -.Sw "-erase \f(CIchr\fP
   1.121 +.Sw -erase
   1.122 +.Ar chr
   1.123  and
   1.124 -.Sw "-kill \f(CIchr\fP
   1.125 +.Sw -kill
   1.126 +.Ar chr
   1.127  to name the characters for command line editing.
   1.128  The times when this had been necessary are long time gone.
   1.129  Today these things work out-of-the-box, and if not, are configured

     2.1 --- a/style	Wed Jun 06 18:11:35 2012 +0200
     2.2 +++ b/style	Wed Jun 06 18:27:28 2012 +0200
     2.3 @@ -345,12 +345,18 @@
     2.4  .de Sw  \" switch
     2.5  .CW "\\$1" "\\$2
     2.6  ..
     2.7 +.de Ar  \" argument
     2.8 +.CW "\f(CI\\$1" "\\$2
     2.9 +..
    2.10  .de Mp  \" man page
    2.11  .I "\\$1" "\\$2
    2.12  ..
    2.13  .de Pe  \" profile entry
    2.14  .CW "\\$1" "\\$2
    2.15  ..
    2.16 +.de Hd  \" mail header field
    2.17 +.CW "\\$1:\&" "\\$2
    2.18 +..
    2.19  
    2.20  .de Ci  \" commit hash ref
    2.21  .ds _t \\$1