S-nail (S-mailx) mailer

WORK IN PROGRESS

Not ready for others.

From apt show s-nail.

Description: feature-rich BSD mail(1)
 S-nail 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 and offers (mostly optional)
 extensions for line editing, IDNA, MIME, S/MIME, SMTP and POP3 (and IMAP).
 It is usable as a mail batch language. S-nail is a derivative of Heirloom
 mailx, formerly known as nail, which itself is based upon Berkeley Mail
 that has a history back to the 70s.

(The man page actually warns that the command will be changing to s-mailx, and there will be some compatibility issues although I found for many imap/smtp "accounts" I had already been setting the look-forward v15compat variable. In personal conversation with the current package maintainer, I was told that the switch to the name s-mailx will not be happening until 2021).

Impediments to replacing MFCF mail

• There is no set report to warn you when affecting many messages
• There is no set listcondition=and
• Header display control is not as simple as in MFCF mail
• Nicer default "h" listing in MFCF mail
• Strangely, metamail/mailcap/mime seems easier to do and augment in MFCF mail

Nice default "h" listing in MFCF mail

MFCF mail has the ability to display sender and subject as a shared field, giving a longer subject for shorter senders.

That is...

>N 10428 arpepper@cs.uwaterloo.ca   "Re: ][RT 4/3 summary" Tue Jun  9 12:42  38

set headline="%>%a%m %20f %i"%20S" %16d %3l/%-5o"

gives only an approximation, for familarity.

Hmm. After several years, I only just notice that is well short of 80 characters? Or maybe in a recent modification I changed 28S to 20S?

 N17779 arpepper@cs.uwaterlo "Re: ][RT " 2020-06-09 12:42  43/2283

Some work can be done shortening the date format. The longer size field seems useful for IMAP situations, but the ability to "share" the space for sender and Subject does not seem to be available.

Most "recommended", e.g. default, formats, seem to put the subject last. And it seems some sort of "grow to allowable length" is assumed. This matches e.g. the "ls" command. But is contrary to the likely habits of the few remaining habitual MFCF mail users.

Header display control

I thought header display was more difficult than in MFCF mail.

In fact,

ignore Received
ignore Message-Id
ignore Resent-Message-Id
ignore Status Mail-From
ignore Return-Path
ignore Via
#ignore Date
ignore X-Redirected-From
ignore X-Spam-Level
ignore X-Virus-Scanned
ignore X-Miltered
ignore X-UUID

simply becomes

headerpick type ignore Received
headerpick type ignore Message-Id
headerpick type ignore Resent-Message-Id
headerpick type ignore Status Mail-From
headerpick type ignore Return-Path
headerpick type ignore Via
#headerpick type ignore Date
headerpick type ignore X-Redirected-From
headerpick type ignore X-Spam-Level
headerpick type ignore X-Virus-Scanned
headerpick type ignore X-Miltered
headerpick type ignore X-UUID

But a caveat is that the above so-called blacklist is not in effect until you empty the list controlled by

headerpick type retain

Perhaps via...

unheaderpick type retain from_ date from to cc subject message-id mail-followup-to reply-to

I prefer to blacklist, so that I notice unusual new headers being proffered by strange email.

Metamail/mailcap/mime capability

Strangely, metamail/mailcap/mime seems easier to do and augment in MFCF mail. This is likely relying on an old copy of metamail.

There was a definite bug in s-nail which was fixed between the Ubuntu 18.04 and Ubuntu 20.04 versions. But I have difficulty driving everything from "mailcap" files.

Support for the general-purpose mailcap and mime packages seems have ended in Ubuntu.

Checking documentation for pine ( alpine ) and mutt ( neomutt ) suggest they still try to provide the facility, and we should look at how they do it (especially regarding package dependencies).

• http://alpine.x10host.com/alpine/alpine-info/misc/mime.html
• https://neomutt.org/guide/mimesupport

Using the IMAP-like search facilities

I found one of the biggest impediments to switching to s-nail was that it seemed difficult to use the search facilities, especially when compared to MFCF mail which had set listcondition=and for its f/string/ search command.

Eventually I put this down to precise but overwhelming documentation in the s-nail man page.

To be specific, they start off with a search which is not at all natural for humans.

So I created my own "quick reference" as follows...

  (criterion)
  (criterion1 criterion2 ... criterionN)      # and
  (or criterion1 criterion2)
  (not criterion)
  (hhh "string")
      hhh is some headers
        bcc, cc, from, subject, to, body, text
  (header name "string")     # general header search
  (larger size)
  (smaller size)
  (before date)      # received   ‘d[d]-Mon-yyyy’ example ‘28-Dec-2012’.
  (on date)          # received
  (since date)       # received
  (sentbefore date)
  (senton date)
  (sentsince date)
  ()    # repeat previous search but cannot be used to add to it

In addition to omitting the confusing first option, I took separate sections for "bcc", etc. and collapsed them into (hhh "string").

The man page begins with the following search, but the above are more useful.

  '("name" "source" "local-part" "domain-part")'

Of course, typing parentheses is still awkward and clumsy for many humans, and the date format remains inflexible awkward and somewhat difficult to remember (though thankfully it uses named months).

Furthermore, between the Ubuntu 18.04 and Ubuntu 20.04 versions, it became a requirement to use "shell quotes" for the entire IMAP-like expression.

Thst is, you must under Ubuntu 20.04 say, for example:

  & f '((from "pepper") (since 01-May-2020))'

Using the IMAP/SMTP auth capabilities for rapidly configurable tests

One of the best features of s-nail for experts (and even the current author too!) is the ability to set up LOTS of sample IMAP and SMTP-AUTH clients.

For instance, assume on your workstation you have created lxc containers u1804mail.lxc, on which you run s-nail, and u1804imapsmtp-01.lxc with u1804imapsmtp-01.lxc capable of doing smtp-auth (and ultimately outbound smtp).

The following configuration in .s=nailrc (or .mailrc ) should allow you to retrieve and send email, assuming you can enable u1804imapsmtp-01.lxc to send email to the internet (possibly by using an ssh tunnel somewhere appropriate).

account container-smtp-out {
        set v15-compat
# set from= should match appropriate values for ultimate actual sending host
        set from="arpepper@somedomain.net"
        set ssl-verify=ignore
        set smtp-auth-user=arpepper
        set hostname=u1804mail.lxc
        set smtp-use-starttls
# set smtp-auth= seems necessary in newer versions
        set smtp-auth=login
        set mta=smtp://arpepper@u1804imapsmtp-01.lxc
}

account container-arpepper {
        set v15-compat
        set ssl-verify=ignore
        set imap-use-starttls
        set smtp-use-starttls
        set smtp-auth-user=arpepper
        set folder="imap://arpepper@u1804imapsmtp-01.lxc"
}

Then, e.g.

arpepper@u1804mail:~$ s-nail -A container-smtp-out arpepper@uwaterloo.ca
Subject: Important work items of relevance

We should discuss some important work items of relevance.


Adrian.
^D
-------
Envelope contains:
From: arpepper@somedomain.net
To: arpepper@uwaterloo.ca
Subject: Important work items of relevance
Send this message [yes/no, or recompose]? yes
arpepper@somedomain.net requires a password: 
arpepper@u1804mail:~$ 

(Authentication is actually to the container).

Other uses in the past have included testing/using incoming and outgoing mail server connections. How those will work in future with the impending moves to proprietary mail access protocols remains to be seen.

Conceptually, it should be possible to set up a proxy implementing the private protocol for retrieval, and offering a public protocol (e.g. privately on an lxc network) for clients.

However, I should list some old sample "accounts" which used to work in the past.

A point is that "accounts" can be trivially replicated and modified, perhaps with revision control, as you test configurations. Later the "accounts" provide an easy way to quickly test the services.

-- Adrian Pepper - 2020-06-20 -- Adrian Pepper - 2020-11-18