README

   1 W e l c o m e  t o  S - n a i l / S - m a i l x
   2 ===============================================
   3
   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.
  14
  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.
  18
  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 has been written to replace Unix mail,
  22 a program that already shipped with First Edition Unix from 1971 --
  23 M. Douglas McIlroy writes in his article "A Research UNIX Reader:
  24 Annotated Excerpts from the Programmer's Manual, 1971-1986":
  25
  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). [.]
  32
  33 1. Where?
  34 2. Repository access
  35 3. Repository layout
  36 4. Security record
  37 5. Authors
  38
  39 1. Where?
  40 ---------
  41
  42 Our latest release can be downloaded at [1], and the fully cross-
  43 referenced manual can also be viewed as HTML online[2].
  44 There are browsable git(1) repositories at sdaoden.eu[3] (use [4] for
  45 cloning purposes), with mirrors at Sourceforge[5] and repo.or.cz[6].
  46
  47   [1] https?://ftp.sdaoden.eu/s-nail-latest.tar.{gz,xz}{,.asc}
  48   [2] https?://www.sdaoden.eu/code.html#s-mailx
  49   [3] https?://git.sdaoden.eu/cgit/s-nail.git
  50   [4] https?://git.sdaoden.eu/scm/s-nail.git
  51   [5] http://sourceforge.net/projects/s-nail
  52   [6] http://repo.or.cz/s-mailx.git
  53
  54 We have a mailing list[7] with moderated unsubscribed posting possi-
  55 bilities; subscriptions can be managed via web interface[8] (it is
  56 a GNU Mailman list, so posting to LISTNAME-request@ and the subject
  57 "subscribe" will also do).  We have a browser-accessible and searchable
  58 archive[9], and The Mail Archive is so kind and offers it, with all its
  59 services, too [10]!  For example, i have subscribed the RSS feed that
  60 The Mail Archive produces to Gwene.org[11].  And Gmane.org was so kind
  61 and took us, we are here[12].  Thanks to all of you!
  62
  63 Commits to the [master], [release/*] and [stable/*] branches are
  64 posted to [13], and announcements will also be posted to [14], both
  65 are receive-only mailing-lists.
  66
  67   [7] s-mailx@lists.sdaoden.eu
  68   [8] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx
  69   [9] https://lists.sdaoden.eu/pipermail/s-mailx/
  70   [10] https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/
  71   [11] news.gwene.org/gwene.mail.s-mailx
  72   [12] news.gmane.org/gmane.mail.s-mailx.general
  73   [13] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx-commit
  74   [14] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-announce
  75
  76 Our heraldic animal snailmail.jpg has been found at [+1].
  77 Thank you!
  78
  79   [+1] http://cdn.whatculture.com/wp-content/uploads/2009/06/snailmail.jpg
  80
  81 2. Repository access
  82 --------------------
  83
  84 To create a full clone of the repository, with all the data and history:
  85
  86   $ git clone https://git.sdaoden.eu/scm/s-nail.git
  87
  88 With a newer git(1), and only tracking the latest stable branch:
  89
  90   $ git clone --single-branch --branch=stable/latest \
  91       https://git.sdaoden.eu/scm/s-nail.git
  92
  93 Or, being selective, also with older git(1)s:
  94
  95   $ mkdir s-nail.git
  96   $ cd s-nail.git
  97   $ git init
  98   $ git remote add origin -t 'release/*' -t stable/stable -t master \
  99       https://git.sdaoden.eu/scm/s-nail.git
 100   $ git fetch -v
 101
 102 And then, assuming the last had been done:
 103
 104   $ # Show all releases
 105   $ git log --no-walk --decorate --oneline --branches='release/*' --
 106   $ # Check out the latest release, and verify the signature
 107   $ git checkout release/latest
 108   $ git log --oneline --show-signature --max-count=1 HEAD
 109   $ make all && sudo make install
 110
 111 3. Repository layout
 112 --------------------
 113
 114 - [release/*]
 115     A new branch within release/ is created for every release, e.g.,
 116     [release/v14.8.10].  History will not be rewritten.
 117
 118     These branches consist of one commit, and that commit is signed with
 119     an OpenPGP key and used for the signed release tag,
 120     vMAJOR.MINOR.UPDATE.ar (.ar for "archive").  The commit as such
 121     covers the data modifications that make up a release, i.e., release
 122     date fixation, manual preprocessing, removal of data which does not
 123     make sense in release tarballs, etc.
 124
 125     All this is not true for older releases, the new repository layout
 126     was introduced after v14.8.10.  But it used [timeline] as a source
 127     for most references, therefore the signed tag v14.8.7.ar protects
 128     all elder references within [release/]:
 129
 130       $ git describe --contains heads/release/v1.3.0
 131       v14.8.7.ar~113
 132
 133 - [release/latest] and [release/stable]
 134     "Symbolic links" to the latest and stable, respectively, release
 135     branches.
 136
 137 - [stable/*]
 138     A new branch within stable/ will be created for each new minor
 139     version, e.g., [stable/v14.8].  History will not be rewritten.
 140
 141     These are the de-facto [master] branches for their respective minor
 142     release, which extend for the full lifetime of the said, e.g., the
 143     branch [stable/v14.7] has been created once the v14.7.0 release was
 144     made, and it extends until the release of v14.7.11, the last v14.7
 145     update release made.
 146
 147     Once the time for a new release has come, the head of such a stable
 148     branch will gain a signed commit and a signed stable tag,
 149     vMAJOR.MINOR.UPDATE, and then be used as the source for a new branch
 150     in release/.
 151
 152     Packagers who want to include all the bugfixes when they eventually
 153     iterate their package can create local "packager releases" with the
 154     "grappa" mode of the script mk/make-release.sh.  With it, they can
 155     track the stable/ branch of desire, and have a [myrelease] branch
 156     where the local releases are made.  This needs an installed s-nail,
 157     git(1), quite some other commands including a C99-capable $CC (see
 158     mk/make-release.inc head, section "# Program stuff"), and optionally
 159     perl(1).  For example:
 160
 161       $ git fetch
 162       $ git checkout stable/stable
 163       $ sh mk/make-release.sh grappa myrel # myrel created as necessary
 164       Preparing a release on commit [.]
 165       Grappa to be brought from stable/stable to myrel
 166       Program version is [.], packager release addition shall be: 2
 167       Is s-nail <v[.]-2> correct? [y/n] y
 168       Switched to branch 'myrel'
 169       ..
 170       $ git commit -S -n -m 'My release [.]-2'
 171
 172 - [stable/latest] and [stable/stable]
 173     "Symbolic links" to the latest and stable, respectively, stable
 174     branches.
 175
 176     These are possibly what users should track which want to have the
 177     newest non-release bugfixes and stable, backward-compatible commits.
 178     See below for examples how to accomplish that.
 179
 180 - [master]
 181     Rooted on top of [heirloom].  It gains only stable, but possibly
 182     backward-incompatible changes (usually mentioned on the ML), and
 183     will be used to create new entries in stable/.  It may gain signed
 184     commits for sealing purposes from time to time.
 185     History will not be rewritten.
 186
 187 - [next]
 188     Rooted on top of [master], this consists of a furious mixture of
 189     commits that eventually end up in [master].  Daring users may give
 190     this branch a try, but bugs and temporary nonstarters have to be
 191     dealt with, then.
 192
 193 - [crawl]
 194     Developer chaos (distributed horror backup - do not use!).
 195
 196 - [test-out]
 197     This branch contains the test output files.  The test itself only
 198     tests checksums, the full output is for development reference
 199     purposes only.
 200
 201 - [unix-mail,bsd-Mail,timeline]
 202     Sketchy efforts to collect the complete history of Unix mail and
 203     its successor, BSD Mail.  Anything from the pre-nail era has been
 204     taken from CSRG and TUHS, for nail and Heirloom mailx i have used
 205     release balls.
 206
 207     The [timeline] branch was the original effort, and it will be
 208     continuously extended whenever new releases will be made, but its
 209     history will not be rewritten, which is why it is a sketchy effort.
 210     The [unix-mail] and [bsd-Mail] branches have been added later, and
 211     will hopefully offer the most complete picture possible as time goes
 212     by (not taking into account the "nupas" effort of Research Unix,
 213     though) -- this means their history may change, but all commits are
 214     signed with an OpenPGP key.
 215
 216 - [heirloom]
 217     A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.
 218
 219 4. Security record
 220 ------------------
 221
 222 - CVE-2004-2771, and CVE-2014-7844.
 223   http://seclists.org/oss-sec/2014/q4/1066.
 224   Fixed in: v14.7.9 (on day of announcement on oss-sec)
 225   Note: Affected all BSD Mail-based codebases.
 226
 227 - CVE-2017-5899.
 228   Credits: wapiflapi.
 229   Fixed in: v14.8.16 (on day of disclosure)
 230   P.S.: helper program renamed to -dotlock.
 231   Desc.:
 232     > vulnerability in the setuid root helper binary
 233
 234     > The problem is that an O_EXCL file is created with a user controlled
 235     > path because the di.di_hostname and di.di_randstr are never checked.
 236     > This means that using s-nail-privsep a normal user can create a file
 237     > anywhere on the filesystem, which is a security problem.
 238
 239 5. Authors
 240 ----------
 241
 242 Unix mail seems to have been written mostly by Ken Thompson.
 243
 244 Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
 245 March 25, 1978.  According to the CSRG commit log authors of BSD mail in
 246 the time span 1980-10-08 to 1995-05-01 were, in order of appearance
 247 (commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
 248 Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
 249 Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
 250 Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
 251 Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
 252 and Dave Borman (17).  One commit by Charlie Root, 36 by "dist".
 253
 254 Official BSD Mail development ceased in 1995 according to the CSRG
 255 (Berkeley's Computer Systems Research Group) repository.  Mail has then
 256 seen further development in open source BSD variants, noticeably by
 257 Christos Zoulas in NetBSD.
 258
 259 Gunnar Ritter reused that codebase when he started developing nail in
 260 February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
 261 RedHat and Debian.  He added MIME code, network protocol support, and
 262 POSIX conformance improvements. In March 2006, he integrated that
 263 program into the Heirloom project, renaming it to Heirloom mailx, the
 264 development of which ceased in 2008.
 265
 266 In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
 267 We try to end up as S-mailx.
 268
 269 # s-ts-mode