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 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":
  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. 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] and repo.or.cz[6].
  44
  45   [1] https?://www.sdaoden.eu/downloads/s-nail-latest.tar.{gz,xz}{,.asc}
  46   [2] https?://www.sdaoden.eu/code.html#s-mailx
  47   [3] https?://git.sdaoden.eu/cgit/s-nail.git
  48   [4] https?://git.sdaoden.eu/scm/s-nail.git
  49   [5] http://sourceforge.net/projects/s-nail
  50   [6] http://repo.or.cz/s-mailx.git
  51
  52 We have a mailing list[7] (later: [8]!) with moderated unsubscribed
  53 posting possibilities; subscriptions can be managed via web interface[9];
  54 Gmane added the ML their NNTP archive[10], and The Mail Archive archives
  55 a browser-accessible and searchable web version[11] -- thank you!
  56 Commits to the [master], [release/*] and [stable/*] branches will be
  57 posted to [12], and announcements will also be posted to [13], both are
  58 receive-only mailing-lists.
  59
  60   [7] s-nail-users@lists.sourceforge.net
  61   [8] s-mailx@sdaoden.eu
  62   [9] https://lists.sourceforge.net/lists/listinfo/s-nail-users/
  63   [10] news.gmane.org/gmane.mail.s-nail.user
  64   [11] www.mail-archive.com/s-nail-users@lists.sourceforge.net/maillist.html
  65   [12] s-mailx-commit@sdaoden.eu
  66   [13] s-announce@sdaoden.eu
  67
  68 These and all other mailings-lists at sdaoden.eu are hosted by MLMMJ, so
  69 users can manage their subscriptions by appending keywords to the plain
  70 mailing list address, a +subscribe for subscription, and +unsubscribe
  71 for unsubscription, e.g., s-mailx+subscribe@sdaoden.eu.
  72 Our heraldic animal snailmail.jpg has been found at [+1].
  73 Thank you!
  74
  75   [+1] http://cdn.whatculture.com/wp-content/uploads/2009/06/snailmail.jpg
  76
  77 2. Repository layout
  78 --------------------
  79
  80 - [release/*]
  81     A new branch within release/ is created for every release, e.g.,
  82     [release/v14.8.10].  History won't be rewritten.
  83
  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.
  90
  91     (Whereas all this is not true for older releases, the new repository
  92     layout was introduced after v14.8.10, and used [timeline] as
  93     a source for most references, therefore the signed tag v14.8.7.ar
  94     protects all elder references within [release/]:
  95
  96       $ git describe --contains heads/release/v1.3.0
  97       v14.8.7.ar~113
  98
  99 - [release/latest] and [release/stable]
 100     "Symbolic links" to the latest and stable, respectively, release
 101     branches.
 102
 103 - [stable/*]
 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.
 106
 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
 111     update release made.
 112
 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
 116     in release/.
 117
 118 - [stable/latest] and [stable/stable]
 119     "Symbolic links" to the latest and stable, respectively, stable
 120     branches.
 121
 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.
 125
 126 - [master]
 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.
 132
 133 - [next]
 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
 137     dealt with, then.
 138
 139 - [crawl]
 140     Developer chaos (distributed horror backup - don't use!).
 141
 142 - [unix-mail,bsd-Mail,timeline]
 143     Sketchy efforts to collect the complete history of Unix mail and
 144     its successor, BSD Mail.  Anything from the pre-nail era has been
 145     taken from CSRG and TUHS, for nail and Heirloom mailx i have used
 146     release balls.
 147
 148     The [timeline] branch was the original effort, and it will be
 149     continuously be extended whenever new releases will be made, but its
 150     history won't be rewritten, which is why it is a sketchy effort.
 151     The [unix-mail] and [bsd-Mail] branches have been added later, and
 152     will hopefully offer the most complete picture possible as time goes
 153     by (not taking into account the "nupas" effort of Research Unix,
 154     though) -- this means their history may change, but all commits are
 155     signed with an OpenPGP key.
 156
 157 - [heirloom]
 158     A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.
 159
 160 To create a full clone of the repository, with all the data and history:
 161   $ git clone https://git.sdaoden.eu/scm/s-nail.git
 162
 163 With a newer git(1), and only tracking the latest stable branch:
 164   $ git clone --single-branch --branch=stable/latest \
 165       https://git.sdaoden.eu/scm/s-nail.git
 166
 167 Or, being selective, also with older git(1)s:
 168   $ mkdir s-nail.git
 169   $ cd s-nail.git
 170   $ git init
 171   $ git remote add origin -t 'release/*' -t stable/stable -t master \
 172       https://git.sdaoden.eu/scm/s-nail.git
 173   $ git fetch -v
 174
 175 And then, assuming the last had been done:
 176
 177   $ # Show all releases
 178   $ git log --no-walk --decorate --oneline --branches='release/*' --
 179   $ # Check out the latest release, and verify the signature
 180   $ git checkout release/latest
 181   $ git log --oneline --show-signature --max-count=1 HEAD
 182   $ make all && sudo make install
 183
 184 3. Authors
 185 ----------
 186
 187 Unix mail seems to have been written mostly by Ken Thompson.
 188
 189 Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
 190 March 25, 1978.  According to the CSRG commit log authors of BSD mail in
 191 the time span 1980-10-08 to 1995-05-01 were, in order of appearance
 192 (commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
 193 Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
 194 Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
 195 Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
 196 Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
 197 and Dave Borman (17).  One commit by Charlie Root, 36 by "dist".
 198
 199 Official BSD Mail development ceased in 1995 according to the CSRG
 200 (Berkeley's Computer Systems Research Group) repository.  Mail has then
 201 seen further development in open source BSD variants, noticeably by
 202 Christos Zoulas in NetBSD.
 203
 204 Gunnar Ritter reused that codebase when he started developing nail in
 205 February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
 206 RedHat and Debian.  He added MIME code, network protocol support, and
 207 POSIX conformance improvements. In March 2006, he integrated that
 208 program into the Heirloom project, renaming it to Heirloom mailx, the
 209 development of which ceased in 2008.
 210
 211 In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
 212 We try to end up as S-mailx.
 213
 214 # s-ts-mode