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, probably in Ubuntu 20.04, 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.

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.

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.

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 precise, 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 parantheses 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).

-- Adrian Pepper - 2020-06-08