descriptionA mail processing system intended to provide the functionality of the POSIX mailx(1) command
homepage URL
repository URL
last changeFri, 24 Mar 2017 14:10:03 +0000 (24 15:10 +0100)
last refreshMon, 27 Mar 2017 03:33:30 +0000 (27 05:33 +0200)
content tags
W e l c o m e  t o  S - n a i l / S - m a i l x

S-nail (later S-mailx) is a mail processing system with a command
syntax reminiscent of ed(1) with lines replaced by messages.
It is intended to provide the functionality of the POSIX mailx(1)
command, but is MIME capable and optionally offers extensions for
line editing, IDNA, MIME, S/MIME, SMTP and POP3.
It is usable as a mail batch language.

Please refer to the file INSTALL for build and installation remarks,
and to NEWS for release update information.  The file THANKS mentions
people who have helped improving and deserve acknowledgement.

This software originates in the codebase of Heirloom mailx, formerly
known as nail, which itself is based upon Berkeley Mail that has
a history back to 1978 and which superseded Unix mail, a program that
already shipped with First Edition Unix from 1971 -- M. Douglas McIlroy
writes in his article "A Research UNIX Reader: Annotated Excerpts from
the Programmer's Manual, 1971-1986":

  MAIL (v1 page 21, v7 page 22)
    Electronic mail was there from the start. Never satisfied with its
    exact behavior, everybody touched it at one time or another: to
    assure the safety of simultaneous access, to improve privacy, to
    survive crashes, to exploit uucp, to screen out foreign freeloaders,
    or whatever. Not until v7 did the interface change (Thompson). [.]

1. Where?
2. Repository layout
3. Authors

1. Where?

Our latest release can be downloaded at [1,2], and the fully cross-
referenced manual can also be viewed as HTML online[3].
There are browsable git(1) repositories at[4] (use [5] for
cloning purposes), with mirrors at Sourceforge[6] and[7].

  [1] https?://{gz,xz}{,.asc}
  [2] ftps?://{gz,xz}{,.asc}
  [3] https?://
  [4] https?://
  [5] https?://

We have a mailing list[8] (later: [9]!) with moderated unsubscribed
posting possibilities; subscriptions can be managed via web interface[10];
Gmane added the ML their NNTP archive[11], and The Mail Archive archives
a browser-accessible and searchable web version[12] -- thank you!
Commits to the [master], [release/*] and [stable/*] branches will be
posted to [13], and announcements will also be posted to [14], both are
receive-only mailing-lists.


These and all other mailings-lists at are hosted by MLMMJ, so
users can manage their subscriptions by appending keywords to the plain
mailing list address, a +subscribe for subscription, and +unsubscribe
for unsubscription, e.g.,
Our heraldic animal snailmail.jpg has been found at [+1].
Thank you!


2. Repository layout

- [release/*]
    A new branch within release/ is created for every release, e.g.,
    [release/v14.8.10].  History won't be rewritten.

    These branches consist of one commit, and that commit is signed with
    an OpenPGP key and used for the signed release tag, (.ar for "archive").  The commit as such
    covers the data modifications that make up a release, i.e., release
    date fixation, manual preprocessing, removal of data which doesn't
    make sense in release tarballs, etc.

    (Whereas all this is not true for older releases, the new repository
    layout was introduced after v14.8.10, and used [timeline] as
    a source for most references, therefore the signed tag
    protects all elder references within [release/]:

      $ git describe --contains heads/release/v1.3.0

- [release/latest] and [release/stable]
    "Symbolic links" to the latest (stable) release branches.

- [stable/*]
    A new branch within stable/ will be created for each new minor
    version, e.g., [stable/v14.8].  History won't be rewritten.

    These are de-facto the [master] branches for their respective minor
    release, which extend for the full lifetime of that, e.g., the
    branch [stable/v14.7] has been created once the v14.7.0 release was
    made, and it extends until the release of v14.7.11, the last v14.7
    update release made.

    Once the time for a new release has come, the head of such a stable
    branch will gain a signed commit and a signed stable tag,
    vMAJOR.MINOR.UPDATE, and then be used as the source for a new branch
    in release/.

- [stable/latest] and [stable/stable]
    "Symbolic links" to the latest (stable) stable branches.

    These are possibly what users should track which want to have the
    newest non-release bugfixes and stable, backward-compatible commits.

- [master]
    Rooted on top of [heirloom].  It gains only stable, but possibly
    backward-incompatible changes (those are usually mentioned on the
    mailing-list), and will be used to create new entries in [stable/].
    History won't be rewritten.

- [next]
    Rooted on top of [master], this consists of a furious mixture of
    commits that eventually end up in [master].  Daring users may give
    this branch a try, but bugs and temporary nonstarters have to be
    dealt with, then.

- [crawl]
    Developer chaos (distributed horror backup - don't use!).

- [timeline]
    A sketchy effort to collect the complete history of Unix mail and
    its successor, BSD Mail.  Anything from the pre-Gunnar Ritter area
    is taken from CSRG and other archives, for nail and Heirloom mailx
    i've used release balls.

- [heirloom]
    A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository.

To create a full clone of the repository, with all the data and history:
  $ git clone

With a newer git(1), and only tracking the latest stable branch:
  $ git clone --single-branch --branch='stable/latest' \

Or, selectively:
  $ mkdir s-nail.git
  $ cd s-nail.git
  $ git init
  $ git remote add origin -t 'release/*' -t 'stable/stable' -t master \
  $ git fetch -v

And then, assuming the last had been done:

  $ # Show all releases
  $ git log --no-walk --decorate --oneline --branches='release/*' --
  $ # Check out the latest release, and verify the signature
  $ git checkout release/latest
  $ git log --oneline --show-signature --max-count=1 HEAD
  $ make all && sudo make install

3. Authors

Unix mail seems to have been written mostly by Ken Thompson.

Berkeley Mail was (according to def.h) developed by Kurt Shoens, dated
March 25, 1978.  According to the CSRG commit log authors of BSD mail in
the time span 1980-10-08 to 1995-05-01 were, in order of appearance
(commit count): Kurt Shoens (379), Kirk McKusick (50), Carl Smith (16),
Bill Bush (2), Eric Allman (6), Craig Leres (43), Sam Leffler (51),
Ralph Campbell (21), Serge Granik (28), Edward Wang (253),
Donn Seeley (1), Jay Lepreau (3), Jim Bloom (1), Anne Hughes (2),
Kevin Dunlap (34), Keith Bostic (253), Mike Karels (1), Cael Staelin (6)
and Dave Borman (17).  One commit by Charlie Root, 36 by "dist".

Official BSD Mail development ceased in 1995 according to the CSRG
(Berkeley's Computer Systems Research Group) repository.  Mail has then
seen further development in open source BSD variants, noticeably by
Christos Zoulas in NetBSD.

Gunnar Ritter reused that codebase when he started developing nail in
February 2000, and incorporated numerous patches from OpenBSD, NetBSD,
RedHat and Debian.  He added MIME code, network protocol support, and
POSIX conformance improvements. In March 2006, he integrated that
program into the Heirloom project, renaming it to Heirloom mailx, the
development of which ceased in 2008.

In 2012 Steffen (Daode) Nurpmeso adopted the codebase as S-nail.
We try to end up as S-mailx.

# s-ts-mode
2 days ago Steffen (Daode... Fix n_addrspec_with_guts(): normalize addresses without... master
4 days ago Steffen (Daode... *on-compose-leave*: allow *autob?cc* from within
5 days ago Steffen (Daode... Fix loop-stop when searching | pipe indicator for ...
10 days ago Steffen (Daode... FIX `headerpick' lookup for "ignore" slot (sic)!
2017-02-08 Steffen (Daode... b64_decode_part(): fix possible assertion (size must...
2017-02-08 Steffen (Daode... send.c:sendpart(): iconv(3) when `write'ing to a file!
2017-01-28 Steffen (Daode... privsep.c: and just verify the box is also in CWD ...
2017-01-27 Steffen (Daode... FIX privsep.c vulnerability, II (forgot hostname!)...
2017-01-27 Steffen (Daode... THANKS: wapiflapi
2017-01-27 Steffen (Daode... FIX privsep.c, yes, vulnerability (wapiflapi)..
2017-01-21 Steffen (Daode... fix brainos of [44ff5125] (TLS/SSL: make...
2017-01-19 Steffen (Daode... FIXes for [0ede309c] (Rudely fix the RFC 5322 dot-atom..)
2017-01-14 Steffen (Daode... head.c:a_head_idna_apply(): FIX IDNA result length...
2017-01-14 Steffen (Daode... Fix "~^ header show|insert": do not print/recognize...
2017-01-12 Steffen (Daode... FIX [1c4b8c918] (Address struct name memory usage....
2017-01-11 Steffen (Daode... FIX false rebase back for new variable handling..
8 weeks ago Bump S-nail ("Copris...
8 weeks ago v14.8.16 Bump S-nail v14.8.16 ("Copris lunar...
2 months ago Bump S-nail ("Scarabaeu...
2 months ago v14.8.15 Bump S-nail v14.8.15 ("Scarabaeus...
2 months ago v14.9.0-pre3 Bump S-nail v14.9.0-pre3, 2016...
3 months ago steffen-pgp-pub My OpenPGP key: steffen@sdaoden...
4 months ago v14.9.0-pre2 Bump S-nail v14.9.0-pre2, 2016...
5 months ago Bump S-nail, 2016-10-20
5 months ago v14.8.14 Bump S-nail v14.8.14, 2016-10-20
5 months ago Bump S-nail, 2016-10-19
5 months ago v14.8.13 Bump S-nail v14.8.13, 2016-10-19
5 months ago Bump S-nail, 2016-10-05
5 months ago v14.8.12 Bump S-nail v14.8.12, 2016-10-05
5 months ago Bump S-nail, 2016-10-03
5 months ago v14.8.11 Bump S-nail v14.8.11, 2016-10-03
6 months ago v14.9.0-pre1 v14.9.0 ("Crow"), 201?-??-??
2 days ago crawl
2 days ago next
2 days ago master
8 weeks ago stable/v14.8
8 weeks ago stable/stable
8 weeks ago stable/latest
8 weeks ago timeline
8 weeks ago release/v14.8.16
8 weeks ago release/stable
8 weeks ago release/latest
2 months ago release/v14.8.15
5 months ago release/v14.8.14
5 months ago release/v14.8.13
5 months ago release/v14.8.12
5 months ago release/v14.8.11
7 months ago release/v14.8.10