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) is a mail processing system with a command
   5 syntax reminiscent of ed(1) with lines replaced by messages.
   6 It is intended to provide the functionality of the POSIX mailx(1)
   7 command, but is MIME capable and optionally offers extensions for
   8 line editing, IDNA, MIME, S/MIME, SMTP and POP3.
   9 It is usable as a mail batch language.
  10
  11 Please refer to the file INSTALL for build and installation remarks,
  12 and to NEWS for release update information.  The file THANKS mentions
  13 people who have helped improving and deserve acknowledgement.
  14
  15 This software originates in the codebase of Heirloom mailx, formerly
  16 known as nail, which itself is based upon Berkeley Mail that has
  17 a history back to 1978 and which superseded Unix mail, a program that
  18 already shipped with First Edition Unix from 1971 -- M. Douglas McIlroy
  19 writes in his article "A Research UNIX Reader: Annotated Excerpts from
  20 the Programmer's Manual, 1971-1986":
  21
  22   MAIL (v1 page 21, v7 page 22)
  23     Electronic mail was there from the start. Never satisfied with its
  24     exact behavior, everybody touched it at one time or another: to
  25     assure the safety of simultaneous access, to improve privacy, to
  26     survive crashes, to exploit uucp, to screen out foreign freeloaders,
  27     or whatever. Not until v7 did the interface change (Thompson). [.]
  28
  29 1. Where?
  30 2. Repository layout
  31 3. Authors
  32
  33 1. Where?
  34 ---------
  35
  36 Our latest release can be downloaded at [1,2], and the fully cross-
  37 referenced manual can also be viewed as HTML online[3].
  38 There are browsable git(1) repositories at sdaoden.eu[4] (use [5] for
  39 cloning purposes), with mirrors at Sourceforge[6] and repo.or.cz[7].
  40
  41   [1] https?://www.sdaoden.eu/downloads/s-nail-latest.tar.{gz,xz}{,.asc}
  42   [2] ftps?://ftp.sdaoden.eu/s-nail-latest.tar.{gz,xz}{,.asc}
  43   [3] https?://www.sdaoden.eu/code.html#s-mailx
  44   [4] https?://git.sdaoden.eu/cgit/s-nail.git
  45   [5] https?://git.sdaoden.eu/scm/s-nail.git
  46   [6] http://sourceforge.net/projects/s-nail
  47   [7] http://repo.or.cz/s-mailx.git
  48
  49 We have a mailing list[8] (later: [9]!) with moderated unsubscribed
  50 posting possibilities; subscriptions can be managed via web interface[10];
  51 Gmane added the ML their NNTP archive[11], and The Mail Archive archives
  52 a browser-accessible and searchable web version[12] -- thank you!
  53 Commits to the [master], [release/*] and [stable/*] branches will be
  54 posted to [13], and announcements will also be posted to [14], both are
  55 receive-only mailing-lists.
  56
  57   [8] s-nail-users@lists.sourceforge.net
  58   [9] s-mailx@sdaoden.eu
  59   [10] https://lists.sourceforge.net/lists/listinfo/s-nail-users/
  60   [11] news.gmane.org/gmane.mail.s-nail.user
  61   [12] www.mail-archive.com/s-nail-users@lists.sourceforge.net/maillist.html
  62   [13] s-mailx-commit@sdaoden.eu
  63   [14] s-announce@sdaoden.eu
  64
  65 These and all other mailings-lists at sdaoden.eu are hosted by MLMMJ, so
  66 users can manage their subscriptions by appending keywords to the plain
  67 mailing list address, a +subscribe for subscription, and +unsubscribe
  68 for unsubscription, e.g., s-mailx+subscribe@sdaoden.eu.
  69 Our heraldic animal snailmail.jpg has been found at [+1].
  70 Thank you!
  71
  72   [+1] http://cdn.whatculture.com/wp-content/uploads/2009/06/snailmail.jpg
  73
  74 2. Repository layout
  75 --------------------
  76
  77 - [release/*]
  78     A new branch within release/ is created for every release, e.g.,
  79     [release/v14.8.10].  History won't be rewritten.
  80
  81     These branches consist of one commit, and that commit is signed with
  82     an OpenPGP key and used for the signed release tag,
  83     vMAJOR.MINOR.UPDATE.ar (.ar for "archive").  The commit as such
  84     covers the data modifications that make up a release, i.e., release
  85     date fixation, manual preprocessing, removal of data which doesn't
  86     make sense in release tarballs, etc.
  87
  88     (Whereas all this is not true for older releases, the new repository
  89     layout was introduced after v14.8.10, and used [timeline] as
  90     a source for most references, therefore the signed tag v14.8.7.ar
  91     protects all elder references within [release/]:
  92
  93       $ git describe --contains heads/release/v1.3.0
  94       v14.8.7.ar~113
  95
  96 - [release/latest] and [release/stable]
  97     "Symbolic links" to the latest (stable) release branches.
  98
  99 - [stable/*]
 100     A new branch within stable/ will be created for each new minor
 101     version, e.g., [stable/v14.8].  History won't be rewritten.
 102
 103     These are de-facto the [master] branches for their respective minor
 104     release, which extend for the full lifetime of that, e.g., the
 105     branch [stable/v14.7] has been created once the v14.7.0 release was
 106     made, and it extends until the release of v14.7.11, the last v14.7
 107     update release made.
 108
 109     Once the time for a new release has come, the head of such a stable
 110     branch will gain a signed commit and a signed stable tag,
 111     vMAJOR.MINOR.UPDATE, and then be used as the source for a new branch
 112     in release/.
 113
 114 - [stable/latest] and [stable/stable]
 115     "Symbolic links" to the latest (stable) stable branches.
 116
 117     These are possibly what users should track which want to have the
 118     newest non-release bugfixes and stable, backward-compatible commits.
 119
 120 - [master]
 121     Rooted on top of [heirloom].  It gains only stable, but possibly
 122     backward-incompatible changes (those are usually mentioned on the
 123     mailing-list), and will be used to create new entries in [stable/].
 124     History won't be rewritten.
 125
 126 - [next]
 127     Rooted on top of [master], this consists of a furious mixture of
 128     commits that eventually end up in [master].  Daring users may give
 129     this branch a try, but bugs and temporary nonstarters have to be
 130     dealt with, then.
 131
 132 - [crawl]
 133     Developer chaos (distributed horror backup - don't use!).
 134
 135 - [timeline]
 136     A sketchy effort to collect the complete history of Unix mail and
 137     its successor, BSD Mail.  Anything from the pre-Gunnar Ritter area
 138     is taken from CSRG and other archives, for nail and Heirloom mailx
 139     i've used release balls.
 140
 141 - [heirloom]
 142     A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.
 143
 144 To create a full clone of the repository, with all the data and history:
 145   $ git clone https://git.sdaoden.eu/scm/s-nail.git
 146
 147 With a newer git(1), and only tracking the latest stable branch:
 148   $ git clone --single-branch --branch='stable/latest' \
 149       https://git.sdaoden.eu/scm/s-nail.git
 150
 151 Or, selectively:
 152   $ mkdir s-nail.git
 153   $ cd s-nail.git
 154   $ git init
 155   $ git remote add origin -t 'release/*' -t 'stable/stable' -t master \
 156       https://git.sdaoden.eu/scm/s-nail.git
 157   $ git fetch -v
 158
 159 And then, assuming the last had been done:
 160
 161   $ # Show all releases
 162   $ git log --no-walk --decorate --oneline --branches='release/*' --
 163   $ # Check out the latest release, and verify the signature
 164   $ git checkout release/latest
 165   $ git log --oneline --show-signature --max-count=1 HEAD
 166   $ make all && sudo make install
 167
 168 3. Authors
 169 ----------
 170
 171 Unix mail seems to have been written mostly by Ken Thompson.
 172
 173 Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
 174 March 25, 1978.  According to the CSRG commit log authors of BSD mail in
 175 the time span 1980-10-08 to 1995-05-01 were, in order of appearance
 176 (commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
 177 Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
 178 Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
 179 Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
 180 Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
 181 and Dave Borman (17).  One commit by Charlie Root, 36 by "dist".
 182
 183 Official BSD Mail development ceased in 1995 according to the CSRG
 184 (Berkeley's Computer Systems Research Group) repository.  Mail has then
 185 seen further development in open source BSD variants, noticeably by
 186 Christos Zoulas in NetBSD.
 187
 188 Gunnar Ritter reused that codebase when he started developing nail in
 189 February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
 190 RedHat and Debian.  He added MIME code, network protocol support, and
 191 POSIX conformance improvements. In March 2006, he integrated that
 192 program into the Heirloom project, renaming it to Heirloom mailx, the
 193 development of which ceased in 2008.
 194
 195 In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
 196 We try to end up as S-mailx.
 197
 198 # s-ts-mode