1 W e l c o m e t o S - n a i l / S - m a i l x
2 ===============================================
4 S-nail (later S-mailx) provides a simple and friendly environment for
5 sending and receiving mail. It is intended to provide the functionality
6 of the POSIX mailx(1) command, but is MIME capable and optionally offers
7 extensions for line editing, S/MIME, SMTP and POP3, among others.
8 S-nail divides incoming mail into its constituent messages and allows
9 the user to deal with them in any order. It offers many commands and
10 internal variables for manipulating messages and sending mail. It
11 provides the user simple editing capabilities to ease the composition of
12 outgoing messages, and increasingly powerful and reliable
13 non-interactive scripting capabilities.
15 Please refer to the file INSTALL for build and installation remarks,
16 and to NEWS for release update information. The file THANKS mentions
17 people who have helped improving and deserve acknowledgement.
19 This software originates in the codebase of Heirloom mailx, formerly
20 known as nail, which itself is based upon Berkeley Mail that has
21 a history back to 1978 and which superseded Unix mail, a program that
22 already shipped with First Edition Unix from 1971 -- M. Douglas McIlroy
23 writes in his article "A Research UNIX Reader: Annotated Excerpts from
24 the Programmer's Manual, 1971-1986":
26 MAIL (v1 page 21, v7 page 22)
27 Electronic mail was there from the start. Never satisfied with its
28 exact behavior, everybody touched it at one time or another: to
29 assure the safety of simultaneous access, to improve privacy, to
30 survive crashes, to exploit uucp, to screen out foreign freeloaders,
31 or whatever. Not until v7 did the interface change (Thompson). [.]
41 Our latest release can be downloaded at [1], and the fully cross-
42 referenced manual can also be viewed as HTML online[2].
43 There are browsable git(1) repositories at sdaoden.eu[3] (use [4] for
44 cloning purposes), with mirrors at Sourceforge[5] and repo.or.cz[6].
46 [1] https?://www.sdaoden.eu/downloads/s-nail-latest.tar.{gz,xz}{,.asc}
47 [2] https?://www.sdaoden.eu/code.html#s-mailx
48 [3] https?://git.sdaoden.eu/cgit/s-nail.git
49 [4] https?://git.sdaoden.eu/scm/s-nail.git
50 [5] http://sourceforge.net/projects/s-nail
51 [6] http://repo.or.cz/s-mailx.git
53 We have a mailing list[7] with moderated unsubscribed posting possi-
54 bilities; subscriptions can be managed via web interface[8] (it is
55 a GNU Mailman list, so posting to LISTNAME-request@ and the subject
56 "subscribe" will also do). The Mail Archive archives
57 a browser-accessible and searchable web version[9], and i have sub-
58 scribed the RSS feed that The Mail Archive produces to Gwene.org[10],
61 Commits to the [master], [release/*] and [stable/*] branches are
62 posted to [11], and announcements will also be posted to [12], both
63 are receive-only mailing-lists.
65 [7] s-mailx@lists.sdaoden.eu
66 [8] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx
67 [9] https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/
68 [10] news.gwene.org/gwene.mail.s-mailx
69 [11] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx-commit
70 [12] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-announce
72 Our heraldic animal snailmail.jpg has been found at [+1].
75 [+1] http://cdn.whatculture.com/wp-content/uploads/2009/06/snailmail.jpg
81 A new branch within release/ is created for every release, e.g.,
82 [release/v14.8.10]. History won't be rewritten.
84 These branches consist of one commit, and that commit is signed with
85 an OpenPGP key and used for the signed release tag,
86 vMAJOR.MINOR.UPDATE.ar (.ar for "archive"). The commit as such
87 covers the data modifications that make up a release, i.e., release
88 date fixation, manual preprocessing, removal of data which doesn't
89 make sense in release tarballs, etc.
91 All this is not true for older releases, the new repository layout
92 was introduced after v14.8.10. But it used [timeline] as a source
93 for most references, therefore the signed tag v14.8.7.ar protects
94 all elder references within [release/]:
96 $ git describe --contains heads/release/v1.3.0
99 - [release/latest] and [release/stable]
100 "Symbolic links" to the latest and stable, respectively, release
104 A new branch within stable/ will be created for each new minor
105 version, e.g., [stable/v14.8]. History won't be rewritten.
107 These are the de-facto [master] branches for their respective minor
108 release, which extend for the full lifetime of the said, e.g., the
109 branch [stable/v14.7] has been created once the v14.7.0 release was
110 made, and it extends until the release of v14.7.11, the last v14.7
113 Once the time for a new release has come, the head of such a stable
114 branch will gain a signed commit and a signed stable tag,
115 vMAJOR.MINOR.UPDATE, and then be used as the source for a new branch
118 - [stable/latest] and [stable/stable]
119 "Symbolic links" to the latest and stable, respectively, stable
122 These are possibly what users should track which want to have the
123 newest non-release bugfixes and stable, backward-compatible commits.
124 See below for examples how to accomplish that.
127 Rooted on top of [heirloom]. It gains only stable, but possibly
128 backward-incompatible changes (usually mentioned on the ML), and
129 will be used to create new entries in stable/. It may gain signed
130 commits for sealing purposes from time to time.
131 History won't be rewritten.
134 Rooted on top of [master], this consists of a furious mixture of
135 commits that eventually end up in [master]. Daring users may give
136 this branch a try, but bugs and temporary nonstarters have to be
140 Developer chaos (distributed horror backup - don't use!).
143 This branch contains the test output files. The test itself only
144 tests checksums, the full output is for development reference
147 - [unix-mail,bsd-Mail,timeline]
148 Sketchy efforts to collect the complete history of Unix mail and
149 its successor, BSD Mail. Anything from the pre-nail era has been
150 taken from CSRG and TUHS, for nail and Heirloom mailx i have used
153 The [timeline] branch was the original effort, and it will be
154 continuously extended whenever new releases will be made, but its
155 history won't be rewritten, which is why it is a sketchy effort.
156 The [unix-mail] and [bsd-Mail] branches have been added later, and
157 will hopefully offer the most complete picture possible as time goes
158 by (not taking into account the "nupas" effort of Research Unix,
159 though) -- this means their history may change, but all commits are
160 signed with an OpenPGP key.
163 A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.
165 To create a full clone of the repository, with all the data and history:
166 $ git clone https://git.sdaoden.eu/scm/s-nail.git
168 With a newer git(1), and only tracking the latest stable branch:
169 $ git clone --single-branch --branch=stable/latest \
170 https://git.sdaoden.eu/scm/s-nail.git
172 Or, being selective, also with older git(1)s:
176 $ git remote add origin -t 'release/*' -t stable/stable -t master \
177 https://git.sdaoden.eu/scm/s-nail.git
180 And then, assuming the last had been done:
182 $ # Show all releases
183 $ git log --no-walk --decorate --oneline --branches='release/*' --
184 $ # Check out the latest release, and verify the signature
185 $ git checkout release/latest
186 $ git log --oneline --show-signature --max-count=1 HEAD
187 $ make all && sudo make install
192 - CVE-2004-2771, and CVE-2014-7844.
193 http://seclists.org/oss-sec/2014/q4/1066.
194 Fixed in: v14.7.9 (on day after announcement on oss-sec)
196 Affected all BSD Mail-based codebases.
200 Fixed in: v14.8.16 (on day of disclosure)
202 > vulnerability in the setuid root helper binary
204 > The problem is that an O_EXCL file is created with a user controlled
205 > path because the di.di_hostname and di.di_randstr are never checked.
206 > This means that using s-nail-privsep a normal user can create a file
207 > anywhere on the filesystem, which is a security problem.
212 Unix mail seems to have been written mostly by Ken Thompson.
214 Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
215 March 25, 1978. According to the CSRG commit log authors of BSD mail in
216 the time span 1980-10-08 to 1995-05-01 were, in order of appearance
217 (commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
218 Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
219 Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
220 Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
221 Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
222 and Dave Borman (17). One commit by Charlie Root, 36 by "dist".
224 Official BSD Mail development ceased in 1995 according to the CSRG
225 (Berkeley's Computer Systems Research Group) repository. Mail has then
226 seen further development in open source BSD variants, noticeably by
227 Christos Zoulas in NetBSD.
229 Gunnar Ritter reused that codebase when he started developing nail in
230 February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
231 RedHat and Debian. He added MIME code, network protocol support, and
232 POSIX conformance improvements. In March 2006, he integrated that
233 program into the Heirloom project, renaming it to Heirloom mailx, the
234 development of which ceased in 2008.
236 In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
237 We try to end up as S-mailx.