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