"Fossies" - the Fresh Open Source Software Archive

Member "s-nail-14.9.11/README" (8 Aug 2018, 10249 Bytes) of package /linux/misc/s-nail-14.9.11.tar.xz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "README": 14.9.6_vs_14.9.7.

    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 won't 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 doesn't
   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 won't 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 - [stable/latest] and [stable/stable]
  122     "Symbolic links" to the latest and stable, respectively, stable
  123     branches.
  124 
  125     These are possibly what users should track which want to have the
  126     newest non-release bugfixes and stable, backward-compatible commits.
  127     See below for examples how to accomplish that.
  128 
  129 - [master]
  130     Rooted on top of [heirloom].  It gains only stable, but possibly
  131     backward-incompatible changes (usually mentioned on the ML), and
  132     will be used to create new entries in stable/.  It may gain signed
  133     commits for sealing purposes from time to time.
  134     History won't be rewritten.
  135 
  136 - [next]
  137     Rooted on top of [master], this consists of a furious mixture of
  138     commits that eventually end up in [master].  Daring users may give
  139     this branch a try, but bugs and temporary nonstarters have to be
  140     dealt with, then.
  141 
  142 - [crawl]
  143     Developer chaos (distributed horror backup - don't use!).
  144 
  145 - [test-out]
  146     This branch contains the test output files.  The test itself only
  147     tests checksums, the full output is for development reference
  148     purposes only.
  149 
  150 - [unix-mail,bsd-Mail,timeline]
  151     Sketchy efforts to collect the complete history of Unix mail and
  152     its successor, BSD Mail.  Anything from the pre-nail era has been
  153     taken from CSRG and TUHS, for nail and Heirloom mailx i have used
  154     release balls.
  155 
  156     The [timeline] branch was the original effort, and it will be
  157     continuously extended whenever new releases will be made, but its
  158     history won't be rewritten, which is why it is a sketchy effort.
  159     The [unix-mail] and [bsd-Mail] branches have been added later, and
  160     will hopefully offer the most complete picture possible as time goes
  161     by (not taking into account the "nupas" effort of Research Unix,
  162     though) -- this means their history may change, but all commits are
  163     signed with an OpenPGP key.
  164 
  165 - [heirloom]
  166     A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.
  167 
  168 To create a full clone of the repository, with all the data and history:
  169   $ git clone https://git.sdaoden.eu/scm/s-nail.git
  170 
  171 With a newer git(1), and only tracking the latest stable branch:
  172   $ git clone --single-branch --branch=stable/latest \
  173       https://git.sdaoden.eu/scm/s-nail.git
  174 
  175 Or, being selective, also with older git(1)s:
  176   $ mkdir s-nail.git
  177   $ cd s-nail.git
  178   $ git init
  179   $ git remote add origin -t 'release/*' -t stable/stable -t master \
  180       https://git.sdaoden.eu/scm/s-nail.git
  181   $ git fetch -v
  182 
  183 And then, assuming the last had been done:
  184 
  185   $ # Show all releases
  186   $ git log --no-walk --decorate --oneline --branches='release/*' --
  187   $ # Check out the latest release, and verify the signature
  188   $ git checkout release/latest
  189   $ git log --oneline --show-signature --max-count=1 HEAD
  190   $ make all && sudo make install
  191 
  192 3. Security record
  193 ------------------
  194 
  195 - CVE-2004-2771, and CVE-2014-7844.
  196   http://seclists.org/oss-sec/2014/q4/1066.
  197   Fixed in: v14.7.9 (on day of announcement on oss-sec)
  198 
  199   Affected all BSD Mail-based codebases.
  200 
  201 - CVE-2017-5899.
  202   Credits: wapiflapi.
  203   Fixed in: v14.8.16 (on day of disclosure)
  204 
  205     > vulnerability in the setuid root helper binary
  206 
  207     > The problem is that an O_EXCL file is created with a user controlled
  208     > path because the di.di_hostname and di.di_randstr are never checked.
  209     > This means that using s-nail-privsep a normal user can create a file
  210     > anywhere on the filesystem, which is a security problem.
  211 
  212 4. Authors
  213 ----------
  214 
  215 Unix mail seems to have been written mostly by Ken Thompson.
  216 
  217 Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
  218 March 25, 1978.  According to the CSRG commit log authors of BSD mail in
  219 the time span 1980-10-08 to 1995-05-01 were, in order of appearance
  220 (commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
  221 Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
  222 Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
  223 Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
  224 Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
  225 and Dave Borman (17).  One commit by Charlie Root, 36 by "dist".
  226 
  227 Official BSD Mail development ceased in 1995 according to the CSRG
  228 (Berkeley's Computer Systems Research Group) repository.  Mail has then
  229 seen further development in open source BSD variants, noticeably by
  230 Christos Zoulas in NetBSD.
  231 
  232 Gunnar Ritter reused that codebase when he started developing nail in
  233 February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
  234 RedHat and Debian.  He added MIME code, network protocol support, and
  235 POSIX conformance improvements. In March 2006, he integrated that
  236 program into the Heirloom project, renaming it to Heirloom mailx, the
  237 development of which ceased in 2008.
  238 
  239 In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
  240 We try to end up as S-mailx.
  241 
  242 # s-ts-mode