# HG changeset patch # User markus schnalke # Date 1338915615 -7200 # Node ID 2e61e0004a8f6012405ad548a7000c9b1de45835 # Parent 0927d38589afa95f8d2fad1ac2c333c6cb0023e7 Rework of existing text. diff -r 0927d38589af -r 2e61e0004a8f ch03.roff --- a/ch03.roff Tue Jun 05 11:15:18 2012 +0200 +++ b/ch03.roff Tue Jun 05 19:00:15 2012 +0200 @@ -12,21 +12,22 @@ .P MH had been considered an all-in-one system for mail handling. The community around nmh has a similar understanding. -In fundamental difference, I believe that mmh should be a MUA but -nothing more. I believe that all-in-one mail systems are not the way -to go. There are excellent specialized MTAs, like Postfix; +In fundamental difference, should be a MUA only. +I believe that all-in-one mail systems are obsolete. +There are excellent specialized MTAs, like Postfix; there are specialized MDAs, like Procmail; there are specialized MRAs, like Fetchmail. I believe it's best to use them instead of -providing the same function ourselves. Doing something well requires to -focus on this particular aspect or a small set of aspects. The more +providing the same function ourselves. Doing something well, requires to +focus on a small set of aspects. The more it is possible to focus, the better the result in this particular -area will be. The limiting resource in Free Software community development -usually is human power. If the low development power is even parted -into multiple development areas, it will hardly be possible to +area will be. Usually, the limiting resource in Free Software +community development is man power. +If the development power is even spread over a large +development area, it becomes more difficult to compete with the specialists in the various fields. This is even increased, given the small community \(en developers and users \(en that MH-based mail systems have. In consequence, I believe that the -available resources should be concentrated at the point where MH is +available resources should be focused to the point where MH is most unique. This is clearly the MUA part. .P The goal for mmh was to remove peripheral parts and stream-line @@ -38,100 +39,121 @@ In contrast to nmh, which also provides mail submission and mail retrieval facilities, mmh is a MUA only. This general difference in the view on the character of nmh -strongly supported the development of mmh. +initiated the development of mmh. Removing the mail transfer facilities had been the first work task -for the mmh project. +in the mmh project. .P The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh. -The facility establishes TCP/IP connections and speaks SMTP to submit +The facility established network connections and spoke SMTP to submit messages for relay to the outside world. -This part is implemented in the +This part was implemented by the .Pn post command. -Demanded by the changes in -emailing, this part of nmh required changes in the last years. -Encrypted connections needed to be supported, hence SASL was introduced +The changes in emailing +demanded changes in this part of nmh in the last years. +Encryption and authetication for network connections +needed to be supported, hence TLS and SASL were introduced into nmh. This added complexity to the nmh without improving it in its core functions. Also, keeping up with recent developments in -this field needs requires development power and specialists. -Mmh cuts this whole facility off and depends on an external MTA instead. +this field requires development power and specialists. +For mmh this whole facility was cut off. +.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 +.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3 +.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b +Instead, mmh depends on an external MTA. The only outgoing interface available to mmh is the .Pn sendmail command. Almost any MTA provides a .Pn sendmail command. -It not, any program can be substituted if it reads the +If not, any program can be substituted if it reads the message from the standard input, extracts the recipient addresses from the message header and does not conflict -with sendmail-specific command line arguments. +with sendmail-specific command line options. .P To retrieve mail, the .Pn inc -command in nmh has the ability to establish TCP/IP connections -and speaks POP3 to retrieve mail from remote servers. -As with mail submission, here encrypted connections are required -today, thus SASL support was added. -As POP3 is superseded by IMAP more and more, support for message -retrieval through IMAP will become necessary to be added soon. -Mmh has no support for retrieving mail from remote locations. -It depends on an external tool to cover this task. -There are two ways for messages to enter mmh's mail storage: -Incorporate them with +command established network connections +and spoke POP3 to retrieve mail from remote servers. +As with mail submission, the network connections required encryption and +authentication, thus TLS and SASL was added. +As POP3 becomes more and more superseded by IMAP, support for message +retrieval through IMAP will become necessary to be added soon, too. +Mmh has dropped the support for retrieving mail from remote locations. +.Ci ab7b48411962d26439f92f35ed084d3d6275459c +Instead, it depends on an external tool to cover this task. +There exist two paths for messages to enter mmh's mail storage: +They can be incorporate with .Pn inc -from the system maildrop, or with +from the system maildrop, or .Pn rcvstore -from the standard input. -In consequence, mmh has not any longer networking code -and thus does no more need to do transfer encryption and authentication. -Two large functional units are removed. +reads them from the standard input. .P With the removal of the MSA and MRA, mmh converted from an all-in-one mail system to being only a MUA. -Following the Unix philosophy, it focuses on one job and to do that well. +Following the Unix philosophy, it focuses on one job and +tries to do that one well. +Not only the programs follow that tenet but also the project itself does so. Now, of course, mmh depends on third-party software. An external MTA/MSA is required to transfer mail to the outside world; an external MRA is required to retrieve mail from remote machines. There exist excellent implementations of such software, -which do this specific task likely much better than the internal -versions of nmh do it. Also, this provides the choice for the best -suiting one of the available implementation. +which do this specific task likely better than the internal +versions had done it. Also, the best suiting programs can be freely chosen. .P As it had already been possible to use an external MSA or MRA, why not keep the internal version for convenience? -If this would question the sense in having a fall-back pager in all -the command line tools, in case +The question whether there is sense in having a fall-back pager in all +the command line tools, for the cases when .Pn more or .Pn less -wouldn't be available, the answer is intuitively seen. -Now, an MSA or MRA is clearly more complex than a text pager, but -still the concept holds: If programs become complex, split them; -if projects become complex, split them. -Complexity is demanded by the problem to solve. Decades ago, -emailing had been small and simple. -(Remember, +aren't available, appears to be ridiculous. +Now, an MSA or MRA is clearly more complex than a text pager, +and not necessarily available but still the concept holds: +design the system orthogonally. +If it is conceptionally more elegant to have the MTA to be a separate tool +\(en as the RFCs propose this split, this is likely the case \(en +then separate. +.P +Further more, if programs become complex, they should be split; +and if projects become complex, they should be split, too. +Essential complexity is defined by the problem. +Decades ago, emailing had been small and simple. +(\c .Pn /bin/mail -had once covered anything there was to email and still had been small.) -As the complexity in emailing increased, MH remainded mostly unchanged. -Nontheless, in nmh the POP server, which the original MH had included, -was removed. Now is the time to take one step further and remove -the MSA and MRA. +had once covered anything there was to email and still had been small +and simple.) +Then the essential complexity of email increased. +Email tools needed to react. +In nmh, for instance, the POP server, which the original MH had included, +was removed. +Now is the time to go one step further and remove the MSA and MRA. Not only does it decrease the code amount of the project, but more important, it removes the whole field of message transfer -with all its implications from the project. +with all its implications for the project. +It removes the need to adjust to any changes concerning network transfer. +This independence is received by depending on an external program +that covers the field. +Today, this is a reasonable exchange. .P -If a project needs some kind of function, there's always the choice -between implementing the the function in the project directly or -depending on a library that provides the function or depending on +To add some kind of function, there's always the choice +among implementing the function in the project directly, +depending on a library that provides the function, or depending on a program that provides the function. Whereas adding the function directly to the project increases the -code size most, it makes the project most independent. -On the other end, interfacing external programs keeps the interface -smallest, but the depencency highest. -Using a library is in the middle. -Adding the function directly to the project is a bad choice for -any function of higher complexity, unless it's not available in other ways. +code size most and requires most maintenance and development work, +it makes the project most independent. +Using libraries or external programs require less +maintenance work. +Programs have the smallest interfaces, providing the most separation +but possibly limiting the information exchange. +External libraries are stronger connected than external programs but +allow better information exchange. +Adding more code to a project does always increase maintenance work. +Implementing complex functions directly in the project will add +a lot of code. This should be avoided if possible. Hence, the dependencies only change in kind, not in their existence. In mmh, library dependencies on .Pn libsasl2 @@ -145,11 +167,12 @@ This made mmh's code base about 12\|% smaller. Reducing the projects code size by such an amount without actually losing function is a convincing argument. +Actually, as external MSAs and MRAs are likely better +than the project's internal version, the user even gains functionality. .P -Users of MH should have not problem to set up an external MSA and MRA. +Users of MH should not have problems to set up an external MSA and MRA. Also, the popular MSAs and MRAs have large communities and a lot of documentation available. -.P Choices for MSAs range from the full-featured .I Postfix over mid-size solutions like @@ -170,25 +193,32 @@ .H2 "Removal of non-MUA Tools .P -Some of nmh's tools were removed from mmh because they didn't -match the main focus of adding to the MUA's task. +Some MH tools were removed because they didn't add to the MUA's job. +It is a design goal of mmh to remove the parts that are rarely used. +The project shall become more stream-lined and focused. +Rarely used and loosely related tools distract from the lean appearance. +They require maintenance work without adding to the core task. +In mmh the following tools are not available anymore: .BU .Pn conflict was removed because it is a mail system maintenance tool. +.Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9 Besides, it even checks .Fn /etc/passwd and .Fn /etc/group for consistency, which has nothing at all to do with emailing. The tool might be useful, but it should not be shipped with mmh. +.\" XXX historic reasons? .BU .Pn rcvtty was removed because its usecase of writing to the user's terminal -on receiving of mail is hardly wanted today. If users like to be -informed of new mail, then using the shell's +on receiving of mail is obsolete. +.Ci 14767c94b3827be7c867196467ed7aea5f6f49b0 +If users like to be +informed of new mail, the shell's .Ev MAILPATH -variable or graphical notifications are likely more -appealing. +variable or graphical notifications are more appealing. Writing directly to a terminals is hardly ever wanted today. If though one wants to have it this way, the standard tool .Pn write @@ -198,100 +228,139 @@ .DE .BU .Pn viamail -was removed when the new attachment system was introduced, because +was removed when the new attachment system was activated, because .Pn forw -could can now the task itself. +could then cover the task itself. +.Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932 The program .Pn sendfiles was rewritten as a shell script wrapper around .Pn forw . +.Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6 .BU .Pn msgchk -was removed, because it lost its usefulness when POP support was removed. +was removed, because it lost its use case when POP support was removed. +.Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe +A call to .Pn msgchk -provides hardly more information than: +provided hardly more information than .DS ls -l /var/mail/meillo .DE -It does separate between old and new mail, but that's merely a detail -and can be done with -.Pn stat (1) +though it distinguished between old and new mail. +This detail information and can be retrieved with +.Pn stat (1), too. A very small shell script could be written to output the information -in a convenient way, if truly necessary. -As mmh's inc only incorporates mail from the user's local maildrop +in a similar way, if truly necessary. +As mmh's +.Pn inc +only incorporates mail from the user's local maildrop and thus no data transfers over slow networks are involved, -there's hardly need to check for new mail before incorporating it. +there's hardly any need to check for new mail before incorporating it. .BU .Pn msh -was removed because the tool was in conflict with the -philosophy of MH. It provided an interactive shell to access the -features of MH. One major feature of MH is being a tool chest. -.Pn msh -wouldn't be just another shell, tailored to the needs of mail -handling, but one large program to have the MH tools built in. -It's main use was for accessing Bulletin Boards, which have seized to +was removed because the tool was in conflict with the philosophy of MH. +.Ci 916690191222433a6923a4be54b0d8f6ac01bd02 +It provided an interactive shell to access the features of MH, +but it wasn't just a shell, tailored to the needs of mail handling. +Instead it was one large program that had several MH tools built in. +This conflicts with the major feature of MH of being a tool chest. +.Pn msh 's +main use case had been accessing Bulletin Boards, which have seized to be popular. .P Removing .Pn msh , -together with the truly obsolete code relicts +together with the truly archaic code relicts .Pn vmh and .Pn wmh , saved more than 7\|000 lines of C code \(en about 15\|% of the project's original source code amount. -Having the same functionality in less code (with equal readability, -of course) is an advantage. +.P +Having less code (with equal readability, of course) +for the same functionality is an advantage. Less code means less bugs and less maintenance work. -If +As .Pn rcvtty and .Pn msgchk are rarely used and can be implemented in different ways, then why should one keep them? +Removing them stream-lines mmh. .Pn viamail 's use case is now partly obsolete and partly covered by .Pn forw , -hence there's no reason to still have -.Pn viamail -around. +hence there's no reason to still maintain it. .Pn conflict -is not related with the mail client, and +is not related to the mail client, and .Pn msh conflicts with the basic concept of MH. -Both tools could still be useful, but not as part of mmh. +Theses two tools might still be useful, but they should not be part of mmh. .P -It is a design goal of mmh to remove those parts that are rarely used. -The project shall become more stream-lined. -Rarely used and loosely related tools distract from the lean appearance. -They require maintenance cost without adding to the core task. -Therefore they were removed. +Finally, there's +.Pn slocal . +.Pn slocal +is an MDA and thus not directly MUA-related. +Conceptionally, it should be removed. +But +.Pn slocal +provides rule-based processing of messages, like filing them into +different folders, which is otherwise not available in mmh. +Further more, +.Pn slocal +does neither pull dependencies nor a whole new technical area +into the project. +(See section XXX for the removing of the ndbm dependency.) +Still, +.Pn slocal +accounts for about 1\|000 lines of code that need to be maintained. +As +.Pn slocal +is almost self-standing, it should be split off into a separate project. +This would cut the strong connection between the MUA mmh and the MDA +.Pn slocal . +The MDA would become an alternative to +.I procmail , +as it would no longer be the need to install a complete MH system, too. +Likewise, mmh users could decide to use +.I procmail +without having a second, unused MDA (\c +.Pn slocal ) +installed. +That's conceptionally the best solution. +Yet, +.Pn slocal +is not removed, +but as its existence does not affect the rest of mmh, +it can be removed at any time. -.H2 "Merge of \f(CWshow\fP and \f(CWmhshow\fP +.H2 "\fLshow\fP and \fPmhshow\fP .P Since the very beginning \(en already in the first concept paper \(en .Pn show had been MH's message display program. .Pn show -found out which pathnames the relevant messages had and invoked +mapped message numbers and sequences to files and invoked .Pn mhl -then to have the content formated. -With the advent of MIME, this approach wasn't sufficient anymore. +to have the files formated. +For MIME, this approach wasn't sufficient anymore. MIME messages can consist of multiple parts, some of which aren't directly displayable, and text content might be encoded in foreign charsets. .Pn show 's -simple approach and +understanding of messages and .Pn mhl 's limited display facilities couldn't cope with the task any longer. .P -Instead of extending these tools, additional ones were written from scratch +Instead of extending these tools, additional tools were written from scratch and then added to the MH tool chest. Doing so is encouraged by the tool chest approach. The new tools could be added without interfering -with the existing ones. This is great. The ease of adding new tools -even made MH the first MUA to implement MIME. +with the existing ones. This is an advantage. The ease of adding new tools +made MH the first MUA to implement MIME. +.\" XXX ref .P First, the new MIME features were added in form of the single program .Pn mhn . @@ -307,9 +376,13 @@ which replaced the .Cl "mhn \-show call. +It was capable to display a MIME message appropriately. .P -From then on, two message display tools were part of nmh. -Because it should not require user actions to invoke the right tool +From then on, two message display tools were part of nmh: +.Pn show +and +.Pn mhshow . +Because the user should not need to invoke the right tool whether the message uses MIME or not, .Pn show was extended to automatically hand the job over to @@ -317,10 +390,6 @@ if displaying the message would be beyond .Pn show 's abilities. -For convenience, -.Pn show -would still display MIME messages if they contained only a single text -part. In consequence, the user would invoke .Pn show (possibly through @@ -335,16 +404,20 @@ (There was also a switch for .Pn show to never invoke -.Pn mhshow .) +.Pn mhshow . +.Pn show +was able to display MIME messages if they contained only a single text +part.) .P Having two similar tools for essentially the same task is redundant. -Both programs needed to be developed syncronously as they were -used as a single tool by the user. Thus they needed to act in a -similar way to not distract the user. +The development of both programs needed to be in sync, +to ensure that the programs behaved in a similar way, +because they were used like a single tool. +Different behavior would have surprised the user. .P Today, non-MIME messages are rather seen to be a special case of MIME messages, than MIME messages are seen to be an extension to -original mail. +original email. As .Pn mhshow had already be able to display non-MIME messages, it was natural @@ -353,24 +426,28 @@ in favor of using .Pn mhshow exclusively. +This decision followed the idea of orthogonal design. +For convenience, +.Pn mhshow +was then renamed to +.Pn show . .Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 -This decision follows the idea of orthogonal design. .P -To allow this replacement, +To prepare for this transition, .Pn mhshow was reworked to behave more like .Pn show first. -Section XXX describes this rework from a different perspective. +(Section XXX describes this rework from a different perspective.) Once the tools behaved similar, the replacing became a natural decision. In mmh, .Pn show is the one single message display program again, but it handles MIME messages as well as non-MIME messages. -There's only one program to maintain and users don't need to deal +Now, there's only one program to maintain, and users don't need to deal with the existance of two display programs. .P -Though, there's one reason why removing the old +There's one reason why removing the old .Pn show hurts: It had been such a simple program. Its lean elegance is missing to @@ -383,24 +460,22 @@ .H2 "Removal of Configure Options .P -Choice is a double-edged sword. -It allows customization and thus better suiting solutions, -but that comes with costs. -First, there is the cost of code complexity to have choice. -Second, there is the cost of less tested setups, because there are +Customization is a double-edged sword. +It allows better suiting setups, but not for free. +There is the cost of code complexity to be able to customize. +There is the cost of less tested setups, because there are more possible setups and especially corner-cases. -Third, there is the cost of choice itself. -The code complexity affects the developers. +And, there is the cost of choice itself. +The code complexity directly affects the developers. Less tested code affects both, users and developers. -The problem of choice affects the users, for once simply by having to -choose but also by complexer interfaces that require more documentation. +The problem of choice affects the users, for once by having to +choose, but also by complexer interfaces that require more documentation. Whenever options add little advantages, they should be considered for removal. -.P I have reduced the number of project-specific configure options from fifteen to three. -.U3 "Mail Transfer Facility Options +.U3 "Mail Transfer Facilities .P With the removal of the mail transfer facilities five option vanished: .IP \f(CW--with-mts=[smtp|sendmail]\fP @@ -417,8 +492,9 @@ .U3 "Backup Prefix .P -The default backup prefix, i.e. the string that was prepended to message -filenames to tag them as deleted, had been the comma `\f(CW,\fP'. +The backup prefix is the string that was prepended to message +filenames to tag them as deleted. +By default it had been the comma character `\f(CW,\fP'. There was a configure option to change the default to the hash symbol `\f(CW#\fP': .CW --with-hash-backup . @@ -439,31 +515,31 @@ .Pe backup-prefix , which allows to specify an arbitrary string as backup prefix. .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086 -This did not remove the choice but moved it to a location where +Profile entries are the common method to change mmh's behavior. +This change did not remove the choice but moved it to a location where it suited better. -Profile entries are the common method to change mmh's behavior. -The name of the -.Fn .mh-sequences , -for instance, is specified there, too. -Moving the specification of the backup prefix there, appears to be right. -Eventually, the new trash folder obsoleted the concept of the +.P +Eventually, however, the new trash folder obsoleted the concept of the backup prefix completely. (Well, there still are corner-cases to remove until the backup prefix can be layed to rest, eventually.) .\" FIXME: Do this work in the code! + +.U3 "Editor and Pager .P The two configure options .CW --with-editor=EDITOR .CW --with-pager=PAGER were used to specify the default editor and pager at configure time. Doing so at configure time made sense in the Eighties, -when the available editors and pagers varied more across different systems. -Today, the situation is much more homegenic. +when the set of available editors and pagers varied much across +different systems. +Today, the situation is more homegeneic. The programs .Pn vi and .Pn more -can be expected to be available anywhere on every Unix system, +can be expected to be available on every Unix system, as they are specified by POSIX since two decades. (The specifications for .Pn vi @@ -484,14 +560,13 @@ .Pe editor and .Pe moreproc -profile entries, which allowed the user to change the default -by personal preference. +profile entries, which allowed the user to override the system defaults. Later, the concept was reworked to respect the standard environment variables .Ev VISUAL and .Ev PAGER -if they were set. +if they are set. Today, mmh determines the editor to use in the following order, taking the first available and non-empty item: .IP (1) @@ -510,7 +585,9 @@ Command .Pn vi . .P -The pager to use is deteminded in the following order, +.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b +.P +The pager to use is deteminded in a similar order, also taking the first available and non-empty item: .IP (1) Environment variable @@ -527,18 +604,16 @@ Command .Pn more . .P -.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e .P -The new behavior confirms better to the common behavior on Unix -systems, as +By respecting the .Ev VISUAL /\c .Ev EDITOR and .Ev PAGER -are respected. -Additionally, the new approach is more uniform and -without surprise for users. +environment variables, +the new behavior confirms better to the common style on Unix systems. +Additionally, the new approach is more uniform and clearer to users. .U3 "Locale .P @@ -548,7 +623,7 @@ support. .Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9 -.U3 "\fLslocal\fP Supress Duplicates +.U3 "ndbm .P .Pn slocal is an MDA included in mmh. @@ -559,11 +634,13 @@ yet it remains being part of mmh. This is likely to change in the future. Already, -.Pn slocal was stripped down. +.Pn slocal +was stripped down. It used to depend on .I ndbm , a database library. -The database is used to store the message ids of all messages delivered. +The database is used to store the `\fLMessage-ID\fP's of all +messages delivered. This enables .Pn slocal to suppress delivering the same message to the same user twice. @@ -582,6 +659,7 @@ .P By removing the suppress duplicates feature of .Pn slocal , +.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf the dependency on .I ndbm was removed and 120 lines of complex autoconf could be saved. @@ -596,46 +674,46 @@ .Sw --disable-mhe was removed when the mh-e support was reworked. Mh-e is the Emacs front-end to MH. -It requires MH to act different in some minor ways. -The configure option could switch the extension off. -After removing support for old versions of mh-e, +It requires MH to provide minor additional functions. +The +.Sw --disable-mhe +configure option could switch these extensions off. +After removing the support for old versions of mh-e, only the .Sw -build -switches for +switches of .Pn forw and .Pn repl -are left to be mh-e-specific. -They are now always available because they add little code and complexity. -This change was first done in nmh and thereafter merged into mmh. -The interface changes in mmh require mh-e to be adjusted to use mmh -as the back-end. This requires minor changes to mh-e, though removing -the -.Sw -build -switches would require larger adjustments. -The +are left to be mh-e extensions. +They are now always built in because they add little code and complexity. +In consequence, the .Sw --disable-mhe -configure option was removed and the remaining support for mh-e is always -built in. +configure option was removed .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643 Removing the option removed a second code setup that would have needed to be tested. +This change was first done in nmh and thereafter merged into mmh. +.P +The interface changes in mmh require mh-e to be adjusted in order +to be able to use mmh as back-end. +This will require minor changes to mh-e, but removing the +.Sw -build +switches would require more rework. .U3 "Masquerading .P The configure option .Sw --enable-masquerade -could take up to three items: draft_from, mmailid, username_extension. +could take up to three arguments: +`draft_from', `mmailid', and `username_extension'. They activated different types of address masquerading. All of them were implemented in the SMTP-speaking .Pn post -command. -Mmh no longer speaks SMTP and the replacing -.Pn spost -command no longer does MTA jobs like this one. -Because address masquerading is an MTA's task and mmh does not cover -this field anymore, the funtion needs to be implemented in the -external MTA used. +command, which provided an MSA. +Address masquerading is an MTA's task and mmh does not cover +this field anymore. +Hence, true masquerading needs to be implemented in the external MTA. .P The .I mmailid @@ -645,7 +723,7 @@ .I username to .I fakeusername -mapping, based on the value of the password file's GECOS field. +mapping, based on the password file's GECOS field. The man page .Mp mh-tailor(5) described the use case as being the following: @@ -658,21 +736,21 @@ ``First [Middle] Last '' .P As mmh sends outgoing mail via the local MTA only, -it is the best location to do such global rewrites. +the best location to do such global rewrites is there. Besides, the MTA is conceptionally the right location because it does the reverse mapping for incoming mail (aliasing), too. -The masquerading set up there is set up once for all +Further more, masquerading set up there is readily available for all mail software on the system. +Hence, mmailid masquerading was removed. .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f .P The .I username_extension -masquerading type did not replace the username but could append a suffix -to it. -The suffix needed to be specified by the +masquerading type did not replace the username but would append a suffix, +specified by the .Ev USERNAME_EXTENSION -environment variable. -It provided support for the +environment variable, to it. +This provided support for the .I user-extension feature of qmail and the similar .I "plussed user @@ -680,31 +758,32 @@ The decision to remove this username_extension masquerading was motivated by the fact that .Pn spost -hadn't supported it. -.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9_username_extension -Mmh now provides a more general, though in this case less convenient, -kind of masquerading. +hadn't supported it already. +.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9 +Username extensions are possible in mmh, but less convenient to use. +.\" XXX format file %(getenv USERNAME_EXTENSION) .P The .I draft_from masquerading type instructed .Pn post to use the value of the `From:' header as SMTP envelope sender. -This allowes to replace the sender address completely. +Sender addresses could be replaced completely. .Ci b14ea6073f77b4359aaf3fddd0e105989db9 -Mmh now offers a kind of masquerading similar in effect, but +Mmh offers a kind of masquerading similar in effect, but with technical differences. -As mmh does not transfer messages itself, the local MTA has full control -over the sending address. Any masquerading mmh introduces may be reverted -by the MTA. In times of pedantic spam checking, an MTA will likely do so -to keep its own reputation up. -Nonetheless, the MUA can set the `From:' header and thus propose -a sender address to be used to the MTA. +As mmh does not transfer messages itself, the local MTA has final control +over the sender's address. Any masquerading mmh introduces may be reverted +by the MTA. +In times of pedantic spam checking, an MTA will take care to use +sensible envelope sender addresses to keep its own reputation up. +Nonetheless, the MUA can set the `From:' header and thereby propose +a sender address to the MTA. The MTA may then decide to take that one or generate the canonical sender address for use as envelope sender address. .P In mmh, the MTA will always extract the recipient and sender from the -headers (\c +message headers (\c .Pn sendmail 's .Sw -t switch). @@ -716,10 +795,10 @@ Two configure options remain in mmh. One is the locking method to use: .Sw --with-locking=[dot|fcntl|flock|lockf] . -Removing all other methods except the portable dot locking and having -that as default is appealing, but requires deeper investigation into the -topic. -The other, +The idea of removing all methods except the portable dot locking +and having that one as the default is appealing, but this change +requires deeper technical investigation into the topic. +The other option, .Sw --enable-debug , compiles the programs with debugging symbols and does not strip them. This option is likely to stay.