docs/master
changeset 60:6a92e0208de0
Wrote about the removal of the mail transfer facilities.
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Fri, 01 Jun 2012 15:33:37 +0200 |
parents | cd50590902d3 |
children | 058afce2a138 |
files | ch03.roff |
diffstat | 1 files changed, 114 insertions(+), 5 deletions(-) [+] |
line diff
1.1 --- a/ch03.roff Fri Jun 01 12:42:52 2012 +0200 1.2 +++ b/ch03.roff Fri Jun 01 15:33:37 2012 +0200 1.3 @@ -9,8 +9,6 @@ 1.4 1.5 .H1 "Stream-lining 1.6 1.7 - 1.8 -.H2 "Removal of non-MUA Tools 1.9 .P 1.10 MH had been considered an all-in-one system for mail handling. 1.11 The community around nmh has a similar understanding. 1.12 @@ -31,6 +29,120 @@ 1.13 available resources should be concentrated at the point where MH is 1.14 most unique. This is clearly the MUA part. 1.15 .P 1.16 +The goal for mmh was to remove peripheral parts and stream-line 1.17 +it for the MUA task. 1.18 + 1.19 + 1.20 +.H2 "Removal of Mail Transfer Facilities 1.21 +.P 1.22 +In contrast to nmh, which also provides mail submission and mail retrieval 1.23 +facilities, mmh is a MUA only. 1.24 +.P 1.25 +The MSA is called ``Message Transfer Service'' (MTS) in nmh. 1.26 +The facility establishes TCP/IP connections and speaks SMTP to submit 1.27 +messages for relay to the outside world. 1.28 +This part is implemented in the 1.29 +.Pn post 1.30 +command. 1.31 +Demanded by the changes in 1.32 +emailing, this part of nmh required changes in the last years. 1.33 +Encrypted connections needed to be supported, hence SASL was introduced 1.34 +into nmh. This added complexity to the nmh without improving it in 1.35 +its core functions. Also, keeping up with recent developments in 1.36 +this field needs requires development power and specialists. 1.37 +Mmh cuts this whole facility off and depends on an external MTA instead. 1.38 +The only outgoing interface available to mmh is the 1.39 +.Pn sendmail 1.40 +command. 1.41 +Almost any MTA provides a 1.42 +.Pn sendmail 1.43 +command. 1.44 +It not, any program can be substituted if it reads the 1.45 +message from the standard input, extracts the recipient addresses 1.46 +from the message header and does not conflict 1.47 +with sendmail-specific command line arguments. 1.48 +.P 1.49 +To retrieve mail, the 1.50 +.Pn inc 1.51 +command in nmh has the ability to establish TCP/IP connections 1.52 +and speaks POP3 to retrieve mail from remote servers. 1.53 +As with mail submission, here encrypted connections are required 1.54 +today, thus SASL support was added. 1.55 +As POP3 is superseded by IMAP more and more, support for message 1.56 +retrieval through IMAP will become necessary to be added soon. 1.57 +Mmh has no support for retrieving mail from remote locations. 1.58 +It depends on an external tool to cover this task. 1.59 +There are two ways for messages to enter mmh's mail storage: 1.60 +Incorporate them with 1.61 +.Pn inc 1.62 +from the system maildrop, or with 1.63 +.Pn rcvstore 1.64 +from the standard input. 1.65 +.P 1.66 +In consequence, mmh includes neither networking nor SASL code anymore. 1.67 +Two large separate functional units are removed. 1.68 +They account for about XXX lines of code and XXX libraries. 1.69 +.P 1.70 +With the removal of the MSA and MRA, mmh converted from an all-in-one 1.71 +mail system to the core: the MUA. 1.72 +Following the Unix philosophy, it focuses on one job and to do that well. 1.73 +Now, of course, mmh depends on third-party software. 1.74 +An external MTA/MSA is required to transfer mail to the outside world; 1.75 +an external MRA is required to retrieve mail from remote machines. 1.76 +There exist excellent implementations of such software, 1.77 +which do this specific task likely much better than the internal 1.78 +versions of nmh do it. Also, this provides the choice for the best 1.79 +suiting one of the available implementation. 1.80 +.P 1.81 +As it had already been possible to use an external MSA or MRA, 1.82 +why not keep the internal version for convenience? 1.83 +If this would question the sense in having a fall-back pager in all 1.84 +the command line tools, in case 1.85 +.Pn more 1.86 +or 1.87 +.Pn less 1.88 +wouldn't be available, the answer is intuitively seen. 1.89 +Now, an MSA or MRA is clearly more complex than a text pager, but 1.90 +still the concept holds: If programs become complex, split them; 1.91 +if projects become complex, split them. 1.92 +Complexity is demanded by the problem to solve. Decades ago, 1.93 +emailing had been small and simple. 1.94 +(Remember, 1.95 +.Pn /bin/mail 1.96 +had once covered anything there was to email.) 1.97 +As the complexity in emailing increased, MH remainded mostly unchanged. 1.98 +Nontheless, in nmh the POP server, which the original MH had included, 1.99 +was removed. Now is the time to take one step further and remove 1.100 +the MSA and MRA. 1.101 +Not only does it decrease the code amount of the project, 1.102 +but more important, it removes the whole field of message transfer 1.103 +with all its implications from the project. 1.104 +.P 1.105 +Users of MH are usually able to set up an external MSA and MRA. 1.106 +Also, the popular MSAs and MRAs have large communities and a lot 1.107 +of documentation available. 1.108 +.P 1.109 +Choices for MSAs range from the full-featured 1.110 +.I Postfix 1.111 +over mid-size solutions like 1.112 +.I masqmail 1.113 +and 1.114 +.I dma 1.115 +to small forwarders like 1.116 +.I ssmtp 1.117 +and 1.118 +.I nullmailer . 1.119 +Choices for MRAs include 1.120 +.I fetchmail , 1.121 +.I getmail , 1.122 +.I mpop 1.123 +and 1.124 +.I fdm . 1.125 + 1.126 + 1.127 + 1.128 +.H2 "Removal of non-MUA Tools 1.129 +.P 1.130 Several of nmh's tools were removed from mmh because they didn't 1.131 match the main focus of adding to the MUA's task. 1.132 .P 1.133 @@ -99,9 +211,6 @@ 1.134 .Pn wmh , 1.135 saved more than 7\|000 lines of C code \(en a major achievement. 1.136 1.137 -.U2 "Removal of the MTS 1.138 -.P 1.139 - 1.140 1.141 .H2 "mhshow show Merge 1.142 .P