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