2 # NEWS - Release notes for nmh 1.5
5 Welcome to nmh, the new version of the classic MH mail handling
6 system. Long-time MH and nmh users should read carefully the NOTABLE
7 CHANGES section, as there are some subtle but significant changes
8 to the way nmh now behaves. Otherwise, please see the README and INSTALL
9 files for help on getting started with nmh.
15 The following are new features for the 1.5 release of nmh.
17 - Improved performance for TLS encryption of the SMTP protocol.
18 - MH-E and POP support are now always compiled in.
19 - The selection of a locking directory for dot-locking files is now
20 controllable via configure.
21 - fileproc and mhlproc mh-profile are now obeyed by send, rcvdist,
23 - New mh-format instructions have been implemented: %(putlit),
24 %(concataddr), %(myhost), %(myname), %(localmbox). See mh-format(5)
26 - Nmh's idea of the local mailbox is now configurable via a new profile
27 entry, Local-Mailbox. See mh-profile(5) for more details.
28 - comp, forw, and dist now process all component templates through
29 mh-format(5), and now all support new command line arguments -from,
30 -to, -cc, -fcc, and -subject.
31 - burst(1) now supports any valid message delimiter according to RFC 934.
32 - post(8) now requires a From: header in all drafts that it processes;
33 see NOTABLE CHANGES below for more details.
34 - post(8) can now explicitly control the SMTP envelope address either via
35 the Sender: header or the new Envelope-From: header.
36 - The -attach option is now the default for send (using the header
37 Nmh-Attachment) and -attachformat 1 is the default attachment type.
38 - repl and dist now support new switches -atfile and -noatfile to control
39 the creation of the ./@ link to the message being replied or
40 redistributed. The current default is -atfile.
41 - Support (if available) for readline editing and filename completion at
43 - Support for using an external command to filter the body of a message
44 through in mhl. See mhl(1) for more details, specifically, the
45 "format" keyword, the "formatproc" entry in mh-profile(5), and the
46 -fmtproc switch for mhl and repl.
47 - Preliminary support for improved MIME handling when replying to messages!
48 Yes, a long requested feature has a solution. A perl script
49 called replyfilter is available; it is designed to act as a mhl
50 external filter to process MIME messages in a more logical way.
51 It is available in $(srcdir)/docs/contrib/replyfilter or is
52 typically installed as $(prefix)/share/doc/nmh/contrib/replyfilter.
53 See the comments at the top of replyfilter for usage information;
54 it will likely require some adjustment for your site. replyfilter
55 requires the MIME-Tools and MailTools perl modules.
57 ----------------------------
58 OBSOLETE/DEPRECATED FEATURES
59 ----------------------------
61 The following features have either been removed completely or marked
62 as officially deprecated for removal in a future release of nmh.
64 - The creation of the ./@ link to the message being replied or
65 redistributed is deprecated; -noatfile will be the default in the
66 next release. If there are no requests to maintain -atfile it
67 will be removed in a future release.
68 - Old code enabled by the UCI preprocessor definition has been removed.
69 - All configuration options that were formerly only adjustable by editing
70 config.h have either been moved into configure or removed completely.
71 - Support for the built-in ftp client (used when dealing with external-body
72 message parts in MIME messages) has been removed.
73 - The following environment variables are marked as obsolete/deprecated.
74 Support for them will be removed from the next nmh release:
75 MHPOPDEBUG (use -snoop command line switch instead)
76 MM_NOASK (use -nolist and -nopause command line switches instead)
77 NOMHNPROC (use -nocheckmime command line switch instead)
78 FACEPROC (undocumented faceproc feature to be removed)
79 - The hostable option of mts.conf is no longer needed and has been removed.
85 The largest change is that post(8) now requires a From: header in all drafts
88 The impetus for this change has been the evolution of email and client
89 systems. When MH was first developed the norm was to have tightly managed
90 clients that were part of the same domain as a user's email address. This
91 is no longer a valid assumption, and the algorithm used by nmh to determine
92 the user's local mailbox is no longer a reasonable default.
94 Unfortunately, the way that nmh uses the user's local mailbox used to happen
95 very late in the message process; it was handled by post during message
96 submission. If no From: header exists in the current draft post would
97 insert one based on it's idea of the local mailbox, which was frequently
100 After a long discussion within the nmh development community, it was
101 decided that the only reasonable way forward was to move the local mailbox
102 handling up a level and place it under more direct control of the end
103 user. post(8) no longer will try to determine the local mailbox name;
104 it will take that information from the draft message. Thus a From: header
105 is now required in all drafts.
107 As part of these changes, all message composition utilities now process
108 their component files using mh-format. All of the default component
109 files have been modified to include a From: header in them; this will
110 give the user a chance to see nmh's idea of the local mailbox and modify
111 it if desired. The new mh-profile(5) entry Local-Mailbox can be used
112 to adjust the local mailbox name if the system default is not appropriate.
114 So how should end-users adapt to these changes? Here are some suggestions:
116 1) If you use the default component files, everything should basically work
117 the same for you. You should see a From: header in the drafts of your
118 messages. If the address you see in the From: header is incorrect
119 you can change it via the Local-Mailbox profile entry. You can also
120 use the -from switch to change it on a per-command basis.
122 2) If you have custom component files that include a From: header or
123 you perform custom processing on drafts that end up placing a From:
124 header in the draft message, everything should work as before.
126 3) If you have custom component files that do NOT include a From: header
127 then you will have to adapt then to include a From: header. You
128 can either simply hard-code the correct From: header or use the
129 default component files as a guide (see mh-format(5) for more
130 details, specifically the %(localmbox) function).
132 The other significant change is the support for filters in mhl. Included
133 in the distribution is replyfilter, a filter designed for sane processing
134 of MIME messages during replies. Since this isn't as integrated into
135 nmh as we would prefer, it's included in the contrib directory as an
136 optional component. Please try it out and give us feedback.
140 nmh-workers@nongnu.org