PATH:
usr
/
share
/
doc
/
s-nail
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) provides a simple and friendly environment for sending and receiving mail. It is intended to provide the functionality of the POSIX mailx(1) command, but is MIME capable and optionally offers extensions for line editing, S/MIME, SMTP and POP3, among others. It divides incoming mail into its constituent messages and allows the user to deal with them in any order, offers many commands and variables for manipulating messages and sending mail, as well as line editing, and increasingly powerful scripting capabilities. 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 has been written to replace 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 access 3. Repository layout 4. Security record 5. Authors 1. Where? --------- Our latest release can be downloaded at [1], and the fully cross- referenced manual can also be viewed as HTML online[2]. There are browsable git(1) repositories at sdaoden.eu[3] (use [4] for cloning purposes), with mirrors at Sourceforge[5] and repo.or.cz[6]. [1] https?://ftp.sdaoden.eu/s-nail-latest.tar.{gz,xz}{,.asc} [2] https?://www.sdaoden.eu/code.html#s-mailx [3] https?://git.sdaoden.eu/browse/s-nail.git [4] https?://git.sdaoden.eu/scm/s-nail.git [5] https?://sourceforge.net/projects/s-nail [6] https?://repo.or.cz/s-mailx.git We have a mailing list[7] with moderated unsubscribed posting possi- bilities; subscriptions can be managed via web interface[8] (it is a GNU Mailman list, so posting to LISTNAME-request@ and the subject "subscribe" will also do). We have a browser-accessible and searchable archive[9], and The Mail Archive is so kind and offers it, with all its services, too [10]! For example, i have subscribed the RSS feed that The Mail Archive produces to Gwene.org[11]. And Gmane.org was so kind and took us, we are here[12]. Thanks to all of you! Commits to the [master], [release/*] and [stable/*] branches are posted to [13], and announcements will also be posted to [14], both are receive-only mailing-lists. Note: mailing list related URLs etc. may change after the v14.9.20 release, please look at the web page shall the below not work! [7] s-mailx@lists.sdaoden.eu [8] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx [9] https://lists.sdaoden.eu/pipermail/s-mailx/ [10] https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/ [11] news.gwene.org/gwene.mail.s-mailx [12] news.gmane.org/gmane.mail.s-mailx.general [13] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-mailx-commit [14] https://lists.sdaoden.eu/mailman/listinfo.cgi/s-announce Our heraldic animal snailmail.jpg had been found at [+1]. Thank you! [+1] http://cdn.whatculture.com/wp-content/uploads/2009/06/snailmail.jpg 2. Repository access -------------------- To create a full clone of the repository, with all the data and history: $ git clone https://git.sdaoden.eu/scm/s-nail.git With a newer git(1), and only tracking the latest stable branch: $ git clone --single-branch --branch=stable/latest \ https://git.sdaoden.eu/scm/s-nail.git Or, being selective, also with older git(1)s: $ mkdir s-nail.git $ cd s-nail.git $ git init $ git remote add origin -t 'release/*' -t stable/stable -t master \ https://git.sdaoden.eu/scm/s-nail.git $ 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. Repository layout -------------------- - [release/*] A new branch within release/ is created for every release, for example [release/v14.8.10]. History will not be rewritten. These branches consist of one signed commit, and is used for the signed release tag, vMAJOR.MINOR.UPDATE.ar (.ar for "archive"). The commit as such covers the data modifications that make up a release (release date fixation, manual preprocessing, removal of data which does not make sense in release tarballs, ..). All this is not true for older releases, the new repository layout was introduced after v14.8.10. But it used [timeline] as a source for most references, therefore the signed tag v14.8.7.ar protects all elder references within [release/]: $ git describe --contains heads/release/v1.3.0 v14.8.7.ar~113 - [release/latest] and [release/stable] "Symbolic links" to the latest and stable, respectively, release branches. - [stable/*] A new branch within stable/ will be created for each new minor version, e.g., [stable/v14.8]. History will not be rewritten. These are the de-facto [master] branches for their respective minor release, which extend for the full lifetime of the said, 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/. Packagers who want to include all the bugfixes when they eventually iterate their package can create local "packager releases" with the "grappa" mode of the script mk/make-release.sh. With it, they can track the stable/ branch of desire, and have a [myrelease] branch where the local releases are made. This needs an installed s-nail, git(1), quite some other commands including a C99-capable $CC (see mk/make-release.inc head, section "# Program stuff"), and optionally perl(1). For example: $ git fetch $ git checkout stable/stable $ sh mk/make-release.sh grappa myrel # myrel created as necessary Preparing a release on commit [.] Grappa to be brought from stable/stable to myrel Program version is [.], packager release addition shall be: 2 Is s-nail <v[.]-2> correct? [y/n] y Switched to branch 'myrel' .. $ git commit -S -n -m 'My release [.]-2' - [stable/latest] and [stable/stable] "Symbolic links" to the latest and stable, respectively, 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 (usually mentioned on the ML), and will be used to create new entries in stable/. It may gain signed commits for sealing purposes from time to time. History will not 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 - do not use!) - [test-out] This branch contains the test output files. The test itself only tests checksums, the full output is for development reference purposes only. - [unix-mail,bsd-Mail,timeline] Sketchy efforts to collect the complete history of Unix mail and its successor, BSD Mail. Anything from the pre-nail era has been taken from CSRG and TUHS, for nail and Heirloom mailx i have used release balls. The [timeline] branch was the original effort, and it will be continuously extended whenever new releases will be made, but its history will not be rewritten, which is why it is a sketchy effort. The [unix-mail] and [bsd-Mail] branches have been added later, and will hopefully offer the most complete picture possible as time goes by (not taking into account the "nupas" effort of Research Unix, though) -- this means their history may change, but all commits are signed with an OpenPGP key. - [heirloom] A full git(1) cvsimport of the Heirloom mailx(1) cvs(1) repository that ends with a tag named s-nail. 4. Security record ------------------ - CVE-2004-2771, and CVE-2014-7844. http://seclists.org/oss-sec/2014/q4/1066. Fixed in: v14.7.9 (on day of announcement on oss-sec) Note: Affected all BSD Mail-based codebases. - CVE-2017-5899. Credits: wapiflapi. Fixed in: v14.8.16 (on day of disclosure) P.S.: helper program renamed to -dotlock. Desc.: > vulnerability in the setuid root helper binary > The problem is that an O_EXCL file is created with a user controlled > path because the di.di_hostname and di.di_randstr are never checked. > This means that using s-nail-privsep a normal user can create a file > anywhere on the filesystem, which is a security problem. 5. 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
[+]
..
[-] README
[edit]