S-nail

From ArchWiki
Revision as of 12:55, 19 August 2017 by Sdaoden (talk | contribs) (oh, sorry, no bug: adjacent single quotes! And some typo fixes)
Jump to: navigation, search

Arch Linux uses S-nail as its POSIX mailx (the standardized variant of the Unix mail program) incarnation: mail is the user side of the Unix mail system, the system side -- the Mail-Transfer-Agent -- traditionally being sendmail. mail is MIME capable and supports line editing, S/MIME, SMTP, POP3, and more. It can also send directly to external SMTP servers.

Since v14.9.0 and above the syntax of the software slowly drifts towards being shell compatible, now defined macros can take arguments, can return values etc., an error status is available in !... Compose-mode hooks have been introduced, so creation of custom headers is now easy -- we see examples of that below.

Setting up a working environment

The system-wide configuration file (/etc/mail.rc) brings in some useful defaults, therefore sending mail through a locally installed MTA, such as sendmail or postfix, can be as easy as follows:

# echo 'Message body' | mail -d -s 'A subject' -a an_attachment.txt foo1@bar.example 'Foo2 <foo2@bar.example>'

Using the -d debug option results in a sandbox dry-run. A short summary of the most useful command line flags can be reached via -h:

# mail -h

The actually used MTA, like many other behavioral aspects of mail, can be adjusted by setting a variable: mta (fine-tuning via mta-arguments, mta-no-default-arguments, mta-argv0; also see the manual, On sending mail, and non-interactive mode):

# < /etc/passwd LC_ALL=C mail -d -:/ -Ssendwait -Sttycharset=utf8 -Smta=/usr/bin/sendmail -s 'My password file!' -. 'Back <side@book>'
# echo Message was passed successfully: $?

Message delivery is asynchronous, and mail will exit as soon as the prepared message has been passed over to the MTA, only stating whether message preparation was successful (or not). If the variable sendwait is set, however, the exit status reflects that of the started (builtin or not) MTA.

The -. command line option will forcefully terminate option processing and turn on message send mode, therefore preventing possible option injection attacks if, e.g., receiver addresses are passed in via shell variables, as in

# TOYOU="-Sexpandaddr /etc/password"; echo 'Dance Track' | mail -d -s Ubject $TOYOU

Scripts can (and should) detach from environmental shell settings and configuration files in order to create their own and therefore reproducible runtime environment. Usage of any configuration file can be suppressed with the -:/ command line option; And the locale should be forced to the very basic standardized default, LC_ALL=C, though a completely cleaned env(1)ironment may also be an option. Into this runtime variables and settings can be placed reproducibly by using the -S and -X command line options, as shown above. (For best results it should be ensured that the variable ttycharset names the character set that the input data is expected to be in, then.)

Sending messages to file and command "addressees" is possible if the expandaddr option is set:

# echo bla | mail -Sexpandaddr -s test ./mbox.mbox
# echo bla | mail -Sexpandaddr -s test '|cat >> ./mbox.mbox'
# echo bla | mail -Sexpandaddr -s test -

expandaddr can also be given a value, for example to enforce strict address verification, e.g., the following example only allows network addressees. It can be used as is, except for the usual -d debug dry-run, of course.

# echo Body |
#   LC_ALL=C mail -d -:/ -Sv15-compat -Sttycharset=utf8 \
#     -Ssendwait -Snosave \
#     -Sfrom='Me <me@home>' \
#     -Sexpandaddr=fail,-all,+addr \
#     -a somefile.txt \
#     -s Subject \
#      -. '(foo2bar) <foo2@bar.example>' bob@hey.example

The nosave option disables writing dead letters to DEAD in case of errors. The manual sections A starter, On sending mail, and non-interactive mode and On reading mail, and interactive mode could be worth a glance already today.

Configuration files are the user-specific $HOME/.mailrc and the systemwide /etc/mail.rc, the latter of which is subject to the usual ArchLinux update mechanism and therefore volatile and not the right place for modifications.

All shown examples are upward compatible. To ensure mail acts accordingly too, this variable must be set.

set v15-compat

Wait for the MTA exit status when sending messages, to be able to recognize its errors.

set sendwait

The default directory for saving mails. Unless an absolute path is set this is interpreted relative to HOME. User-specified filenames which start with a + plus-sign refer to paths below this variable.

set folder=mail

More paths of interest: inbox is the user's system mailbox (else MAIL or a system-specific storage, /var/mail/LOGNAME in ArchLinux, are used for this purpose). record is used to save copies of sent messages. DEAD is a standardized variable used to describe a target to dump unsent messages on error, if the save option is set; unfortunately this is not a straight defined content, i.e., it is not a postponing option; a later version of mail may change this. MBOX is the user's secondary mailbox, a standardized target for storage of already read etc. messages (of the system mailbox).

set MBOX=+mbox.mbox record=+sent.mbox DEAD=+dead.mbox
set inbox=+system.mbox

Compressed or otherwise "wrapped" storage can also be used:

filetype  xz 'xz -dc' 'xz -zc'
set record=+sent.mbox.xz

For security reasons mail will actively set a restrictive user-only file mode creation mask (umask(1)), but here we exemplarily inherit the one set in the shell that started mail:

set umask=

Looking at something more e-mailish, let us specify the author of messages sent out. If sending over a local MTA this may be unnecessary, on the other hand specific use cases can be more complicated than that, the manual entries for the -r command line option as well as for the from variable go into more detail.

set from="Your Name <youremail@domain>"

mail needs to know which character sets may be used when sending messages. It deduces the character set of text from the locale(1) environment, from the internal variable ttycharset, to be exact. It is possible to "bend" reality with this variable, as it allows to specify just any input character set environment, as long as that exists; For example, above this has been used to send Unicode/UTF-8 data in a clean and detached script environment (or could, as the example used english text). The input text, supposed to represent ttycharset character data, can optionally be converted to any specified character data.

set sendcharsets=utf-8,iso-8859-1

This says that first of all mail shall try to send data in the UTF-8 character set, but if that fails, it shall try to do so in LATIN-1. What happens is that the text is converted via iconv(1) as necessary. It is also possible to specify

#set sendcharsets-else-ttycharset

This would use sendcharsets if this variable is set, but otherwise uses ttycharset. More details on this in the manual, section Character sets.

When replying to or forwarding a message the comment and name parts of email addresses are removed unless this variable is set.

set fullnames

When replying, do not merge From: and To: of the original message into the new To: header. Instead use the old From: as the new To:, and merge the old To: with addressees found in Cc:. This also works with Reply-To: and Mail-Followup-To: honouring, as below

set recipients-in-cc

When composing a message, start directly into EDITOR:

set editalong

There is the (usual in practice) special support for mailing-lists. Mailing-lists can be made only known, or they can be subscribed to. Subscribing to a list makes mail think that a message posted to the list can be read by the person reading this Wiki anyway, because she or he will get her or his regular copy via the list, for example.

mlist one@alpha.lists.example '^.*@lists\.example$'
mlsubscribe three@lists.example

Politeness dictates that Reply-To: and/or Mail-Followup-To: headers are honoured. And for mailing-list contexts they shall be generated.

set followup-to-honour=ask-yes reply-to-honour=ask-yes
set followup-to

When messages are send any attachments need to be MIME classified, so that a correct Multipurpose Internet Mail Extensions media type can be specified. As a part of this step so-called mime.types(5) files are read, which are often bloated and contain useless entries (without file extension). The variable mimetypes-load-control can be used to specify which files shall be read. But since mail contains a set of builtin media types, not loading any file is often applicable; is this a sufficient list:

# mail -:/ -Smimetypes-load-control -Xmimetype -Xx | less

Creating network connections for SMTP, POP3 or IMAP is possible and should possibly use verified and encrypted communication channels. It is better to be explicit, so here there is T(ransport) L(ayer) S(ecurity) configuration.

SSL (Secure Sockets Layer) a.k.a. its successor TLS (Transport Layer Security) are protocols which aid in securing communication by providing a safely initiated and encrypted network connection. A central concept to SSL/TLS is that of certificates: as part of each network connection setup a (set of) certificates will be exchanged, and by using those the identity of the network peer can be cryptographically verified. SSL/TLS works by using a locally installed pool of trusted certificates, and verifying the connection peer succeeds if that provides a certificate which has been issued or is trusted by any certificate in the trusted local pool.

The local pool of trusted so-called CA (Certification Authority) certificates is usually delivered with the used SSL/TLS library (e.g., OpenSSL), and will be selected automatically. It is also possible to create and use an own pool of trusted certificates. If this is desired, set ssl-ca-no-defaults to avoid using the default certificate pool, and point ssl-ca-file and/or ssl-ca-dir to a trusted pool of certificates. A certificate cannot be more secure than the method its CA certificate has been retrieved with.

On ArchLinux the core system provides an extensive set of certificates which are subject to the usual update mechanisms. Use those, and exclusively, do not load the OpenSSL shipped certificate list; be specific and use the TLS certificate set (see update-ca-trust(8)).

#set ssl-ca-dir=/etc/ssl/certs
set ssl-ca-file=/etc/ssl/certs/ca-certificates.crt
set ssl-ca-no-defaults

When creating a secured connection, require strict security checks.

set ssl-verify=strict

Before we continue here the existence of "variable chains" has to be revealed. For many mail variables which relate to network connections (or, say, URLs), there is not only the plain var, but also var-HOST and var-USER@HOST variants thereof. This allows more specific specifications of, e.g., password variables:

set password='fallback password'
set password-bakery.exam.ple='bred and butter'
set password-spa.exam.ple='oildrops keep falling'
set password-postmaster@spa.exam.ple='service now closed'

mail offers multiple ways to feed user credentials into it, variable chains are one of them and often the easiest solution. The manual section On URL syntax and credential lookup makes known the others.

Tip: Note: in cases when USER (and PASS) are specified as part of an URL they must be URL-percent-encoded: mail offers the urlcodec command which does this for you:
# printf 'urlcodec encode USER PASS\nx\n' | mail -#
Tip: Do not forget that printf(1) as well as mail are subject to locale settings:
# # In UTF-8:
# printf 'urlcodec encode SPAß\nx\n' | mail -#
  SPA%C3%9F
# # In ISO-8859-1:
# printf 'urlc e SPAß\nx\n' | mail -#
  SPA%DF

It depends on the used protocol whether encrypted communication is possible, and which configuration steps have to be taken to enable it. Some protocols, e.g., POP3S, are implicitly encrypted, others, like POP3, can upgrade a plain text connection if so requested: POP3 offers STLS, which will be used if the variable pop3-use-starttls (a variable chain) is set:

shortcut encpop1 pop3s://pop1.exam.ple

shortcut encpop2 pop3://pop2.exam.ple
set pop3-use-starttls-pop2.exam.ple

set mta=smtps://smtp.exam.ple:465
set mta=smtp://smtp.exam.ple smtp-use-starttls

Normally that is all there is to do, however plenty of knobs exist to adjust settings shall the necessity or desire arise. E.g., it is possible to fine-tune certificate verification via ssl-ca-flags. Also interesting may be the possibility to configure the allowed ssl-protocols that a communication channel may use: whereas in the past hints of how to restrict the set of protocols to highly secure ones were indicated, as of the time of this writing the allowed protocols, or at least the allowed ssl-cipher-list, may need to become relaxed in order to be able to connect to some servers. Do not support protocols other than TLS v1.2, the newest standard:

set ssl-protocol=-ALL,+TLSv1.2

But if a server fails this, only this very server should be relaxed. Again variable chains offer a quick solution to this problem.

set ssl-protocol-bakery.exam.ple=-ALL,+TLSv1.2,+TLSv1.1

E.g., the following example settings allows connection of a Lion which uses OpenSSL 0.9.8za from June 2014:

set ssl-protocol-LION=ALL,-SSLv3,-TLSv1
set ssl-cipher-list-LION=TLSv1.2:!aNULL:!eNULL:\
      ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:\
      DHE-RSA-AES256-SHA:@STRENGTH

The OpenSSL program ciphers(1) can be used and should be referred to when creating a custom cipher list.

To send messages via the built-in SMTP (Simple Mail Transfer Protocol) client to an external SMTP server, several options have to be set or adjusted. With password already defined as above it can be as easy as

set user=lada  mta=smtp://bakery.exam.ple smtp-use-starttls

or

set mta=smtp://lada@bakery.exam.ple smtp-use-starttls

or, also, with user and password in the URL:

set mta=smtp://lada:bred%20and%20butter@bakery.exam.ple smtp-use-starttls

More obfuscation:

# mail -:/ -Semptystart
mail version v14.9.3.  Type `?' for help
/var/spool/mail/steffen: 0 messages
No more mail.
? set my_user=lada my_pass=bred%20and%20butter
? wysh set mta=smtp://${my_user}:${my_pass}@bakery.exam.ple smtp-use-starttls
? echo $mta;xit
smtp://lada:bred%20and%20butter@bakery.exam.ple

The wysh command modifier will no longer be necessary in v15. This works as such, immediately:

# echo Hesse |
  LC_ALL=C mail -d -:/ -Sv15-compat -Ssendwait \
    -Smta=smtp://lada:bred%20and%20butter@bakery.exam.ple -Ssmtp-use-starttls \
    -s test -. hey@you

Often the smtp-auth variable needs to be set in addition. And it may be necessary to set the hostname and/or smtp-hostname variables if mta and from (if set) use different hostnames, there is an example managing this problem below.

It is convenient to create accounts which bundle settings for some, well, account. An account can be activated from the command line via mailx -A name, or by calling account name from within mail. Here is a real life example of a very huge free mail provider, to be stored in the personal $HOME/.mailrc:

account XooglX {
  set user=... password=... \
    from="... <an@exam.ple>" \
    hostname=gmail.com \
    mta=smtps://smtp.gmail.com:465 \
    pop3-no-apop
  shortcut myimap imaps://imap.gmail.com
  commandalias goimap file myimap
  shortcut mypop pop3s://pop.gmail.com
  commandalias gopop file mypop
}

This should be ready for a command sequence like the following

# echo test1-body.| mail -A XooglX -s test1-subject my-XooglX-address
# mail -Semptystart
mail version v14.9.3.  Type `?' for help
/var/spool/mail/steffen: 0 messages
No more mail.
? account XooglX
? set debug
? mail my-XooglX-address
Subject: test2-subject
test2-body.
~.
? goimap
...
? xit
Tip: If you have enabled two-step authentication in Gmail, and you have added an application specific password for S-nail, you will want to use that password rather than your regular Gmail password, which may work without enabling the otherwise necessary "less secure apps".

And here is a pretty large free mail provider which does not allow sending mails if there is a domain name mismatch on the SMTP protocol level and therefore needs the adjustments mentioned above:

account XandeX {
  set user=... password=... \
    from="... <an@exam.ple>" \
    hostname=yandex.com smtp-hostname= \
    mta=smtps://smtp.yandex.com:465 \
    pop3-keepalive=55
  shortcut myimap imaps://imap.yandex.com
  commandalias goimap file myimap
  shortcut mypop pop3s://pop.yandex.com
  commandalias gopop file mypop
}

Storing passwords in $HOME/.mailrc is usually not a good idea, but if it is done that way appropriate user-only permissions via chmod 0600 $HOME/.mailrc are desirable. mail supports loading of files via pipes (e.g., source "date), so user credentials may be loaded from encrypted files like that. It also supports the traditional login information .netrc files, and as an extension supports loading them via pipes so that encrypted .netrc files can be used. So then let us modify the account to perform .netrc lookups,

account XandeX {
  set netrc-lookup netrc-pipe='gpg -qd ~/.netrc.gpg' \
    from="... <an@exam.ple>" \
    hostname=yandex.com smtp-hostname= \
    mta=smtps://smtp.yandex.com:465 \
    pop3-keepalive=55
  shortcut myimap imaps://imap.yandex.com
  commandalias goimap file myimap
  shortcut mypop pop3s://pop.yandex.com
  commandalias gopop file mypop
}

place the user and password in $HOME/.netrc,

machine *.yandex.com login USER password PASS

and encrypt this storage to the wanted ~/.netrc.gpg:

# gpg -e .netrc
# eval `gpg-agent --daemon --pinentry-program=/usr/bin/pinentry-curses --max-cache-ttl 99999 --default-cache-ttl 99999`

This example is now functional because there is no ambiguity, only one user for *.yandex.com will be found; An explicit set user=... in an account definition will remove ambiguities from other cases. It is also possible to specify only the password in .netrc, reading the manual section On URL syntax and credential lookup should show the complete picture.

# echo test-body | mail -vv -A XandeX -s test-subject ex@am.ple

In mail the implicit account null exists. This may be interesting for testing purposes, to ensure that no variable settings established in an account exist once the account has been left.

# mail -X'account XooglX;varshow mta;\acc null;echo $mta;xit'                                               
set mta=smtps://smtp.gmail.com:465
/usr/sbin/sendmail

Option localization (as via the localopts command) is implicitly enabled in all accounts.

It is very common or even necessary to inject some text in newly generated messages, for example signatures or a fortune cookies. With mail this can be realized in a(n increasing) number of ways. For example, if there is only some text to inject at the head or bottom of a message, setting some variables seems to be the easiest solution.

wysh set message-inject-head=$'And love.\nLove will tear us apart.\n'
set message-inject-tail='--Bye.'

Again, the wysh command modifier will no longer be necessary in v15.

Entire files are best included by using on-compose-splice hooks (later versions will add more options). These hooks can do anything a user could do interactively. The shell hook is done quickly:

set on-compose-splice-shell="read splice_protocol_version; cat ~/.mysig"

Even better is possibly using normal compose mode commands to accomplish the same.

wysh set on-compose-splice-shell=$'read s_p_v; echo \'~< ~/.mysig\' '

or

wysh set on-compose-splice-shell=$'read s_p_v; echo \'~<! fortune\' '

or the maybe strange

wysh set on-compose-splice-shell=$'read s_p_v;\
  i=`cat ~/.mysig`;\
  echo \'~:set message-inject-tail=\'\"${i}\"\
'

Most of this does not really need the shell, normal mail macros can also be used.

define h_ocs {
  read s_p_v;echo '~<! cat ~/.mysig'
}
set on-compose-splice=h_ocs

There are exactly two options to automatically create custom headers. One is the variable customhdr.

wysh set customhdr='OpenPGP: id=MYID; url=https://MYURL'

Multiple headers can be separated with commas, commas in header bodies need to be escaped by a reverse solidus:

wysh set customhdr='Head-1: A\, B and C    , Head-2: D\,e and F'

The other option is again on-compose-splice. In conjunction with the command escape ~^ that has been especially designed for automated use cases via the splice hooks, message headers and attachments can be controlled completely. This includes creation of custom headers. For example, here is a complicated version which uses the reverse solidus command modifier to avoid commandalias expansion (what you see is what you get) and creates an OpenPGP header unless the message already contains one (it thus has been explicitly added before by the interactive user). With error checking.

\set on-compose-splice=h_ocs
\define h_ocs {
  \read splice_protocol_version
  # Read current list of header
  \echo '~^header list'
  \read hl
  # Create a one-byte substring of $hl, and store it in variable "es"
  \vput vexpr es substr "$hl" 0 1
  \if [ "$es" != 2 ]
     \echoerr 'ocs: cannot list headers'; \echo '~x'; \xit
  \end
  # Is there already an OpenPGP header?  Case-insensitively!
  \if [ "${hl}" @i!% ' openpgp' ]
    \echo '~^header insert OpenPGP id=MYID; url=https://MYURL'
    \read es
    \vput vexpr es substr "$es" 0 1
    \if [ "$es" != 2 ]
      \echoerr 'Cannot insert OpenPGP: header'
      \echo '~x'
      # (no xit, macro finishs anyway)
    \end
  \end
}

Interactive usage of mail is possible, and increasingly so. It has a wide-glyph aware command line editor with history capabilities and coloured message display support. There are two bits of need to configure it before this is a bit of fun. First of all it has to start up even if the initially opened mailbox is empty.

set emptystart

Looking at messages in the PAGER, so that they do not scroll by.

 set crt=0

Having a prompt that shows the error status may be nice, too:

wysh set prompt='?\${?}!\${!}/\${^ERRNAME}[\${account}#\${mailbox-display}]? '

Again, the wysh command modifier will no longer be necessary in v15. More entries for the history, that shall persist in between sessions.

set history-gabby history-file=~/.mailhist

Command aliases make living easier, sometimes.

commandalias ls !ls -latro

As do shortcuts, which will be looked up whenever a filename is expected.

shortcut mymbo %:+mbox.mbox \
         myrec +sent.mbox

When printing messages, show only some headers, not all. Most often it is easier to retain the desired instead of to ignore the unwanted. Print will ignore retain and ignore lists, and Show will display raw message content.

retain date from to cc subject

While here, configure which headers shall be contained when forwarding messages,

headerpick  forward  retain  subject date from to cc

and which shall be ignored when saving messages.

headerpick  save  ignore  ^Original-.*$ ^X-.*$

mail can try to improve MIME experience by generating a counter-evidence of what messages contain.

set mime-counter-evidence=0xE

It could display HTML parts inline, nicer than what the builtin viewer can achieve, that is to say.

#set pipe-text/html='@* lynx -stdin -dump -force_html'

The command list prints all available commands. Typing ? X' tries to expand X and print a help string; since mail allows abbreviations of all commands this is sometimes handy, e.g.: ? h, ? he and ? hel. The command help will print a short summary of the most frequent used commands, more so if the variable verbose is set. Doing so can be encapsulated in a macro, e.g., here is something handy:

define __xv {
  # Before v15: need to enable sh(1)ell-style on _entire_ line!
  localopts yes; wysh set verbose; ignerr eval "${@}"; return ${?}
}
commandalias xv '\call __xv'

To be used like, e.g.,:

xv help set

Context-dependent key bindings can be established.

\bind base a,b,c echo key bindings in mail!

Successively typing the three characters a, b and c will now echo something.

\bind base $'\e',d mle-snarf-word-fwd
\bind base $'\e',$'\c?' mle-snarf-word-bwd
\bind base $'\e',f mle-go-word-fwd
\bind base $'\e',b mle-go-word-bwd

Colours can be used, for example for the prompt.

\colour 256 mle-prompt fg=red
\colour iso mle-prompt fg=red
\colour mono mle-prompt ft=bold

When starting into interactive mode a summary of the content of the initially opened mailbox is printed, as via the headers command. In the header display messages are given numbers (starting at 1) which uniquely identify messages. Messages can be printed with the print command, or short: p Whereas p honours retained (or ignored) list of headers to be displayed, the Print command will not and display all headers; the Show command will print raw message content.

By default the current message (dot) is printed, but just like with many other commands it is possible to specify lists of messages, as is documented in the manual section Specifying messages. E.g., p:u will display all unread messages, p. will print the dot, p 1 5 will print the messages 1 and 5 and p- and p+ will print the last and the next message, respectively. Simply typing RETURN in an empty line acts like next (n), and thus prints the next message.

The command from is nice for an overview, e.g., f '@<@arch linux' will print the header summary of all messages that contain the string arch linux in some message header, whereas f '@arch linux' will only match those with arch linux in their subject. Quoting is necessary when there is whitespace in search expressions.

  • file and File open a new mailbox, the latter in readonly mode
  • newmail (dependent on the mailbox, checks for new mail and) prints a listing of new messages
  • he (headers) reprints the message list
  • z- z+ z0 z$ scroll through the header display
  • folders shows a listing of mailboxes under the currently set folder
  • r replies to all addressees of the given message(s)
  • R replies to the sender of the given message(s)
  • Lreply "mailing-list" reply to the given message(s)
  • move or mv moves (a) message(s)
  • un)flag marks (a) message(s) as (un)flagged
  • new marks (a) message(s) unread
  • seen marks (a) message(s) read
  • P prints (a) message(s) with all headers
  • p prints (a) message(s) and all non-ignored headers.
  • show prints the raw message of content of (a) message(s)

Composition is started by typing mail user@host or by replying to a message. If editalong is set you then enter the EDITOR of choice. Otherwise, or after you have left the EDITOR, you will find yourself in the native editor, where many operations can be performed using command escapes (short help available via ~?). Of particular interest is ~@, which either allows interactive editing of the attachment list, or, when given arguments, to add a(n) (shell-token and optionally comma-separated list of) additional attachment(s), as well as ~^, which is a multiplexer command which offers some control about the message, e.g., to create custom headers.

To send the mail, signal EOT with Ctrl+d or type ~. on its own line.

Using S/MIME

Assuming there is the private S/MIME key and signed certificate available already, using S/MIME is very simple.

# cat private-key.pem signed-certificate.pem > ~/pair.pem
# chmod 0400 ~/pair.pem

The following goes to $HOME/.mailrc.

set smime-sign-cert=~/pair.pem \
    smime-sign-message-digest=SHA256 \
    smime-sign

Note S/MIME always works relative to the setting of the variable from. For signing and decryption purposes it is possible to use password-protected keys, and the pseudo-host(s) USER@HOST.smime-cert-key for the private key (and USER@HOST.smime-cert-cert for the certificate stored in the same file) will be used for performing any necessary password lookup, therefore the lookup can be automatized via the mechanisms described in On URL syntax and credential lookup.

The verify command verifies S/MIME messages, but S/MIME decryption and verification is solely based upon OpenSSL for now, which only supports messages with a simplicistic MIME structure. Sorry.

The manual contains a more complete overview in Signed and encrypted messages with S/MIME as well as a more telling step-by-step example in S/MIME step by step.

Workaround missing OpenPGP support

S-nail does not yet support OpenPGP. However, using a macro it is possible to at least automatically verify inline --clearsigned messages, and using command ghosts their usage becomes handy: e.g., use the following in resource file and you will be able to verify a clearsigned message by just typing V:

 define V {
    \localopts yes; \wysh set pipe-text/plain=$'@*#++=@\
       < "${MAILX_FILENAME_TEMPORARY}" awk \
             -v TMPFILE="${MAILX_FILENAME_TEMPORARY}" \'\
          BEGIN{done=0}\
          /^-----BEGIN PGP SIGNED MESSAGE-----/,/^$/ {\
             if(done++ != 0)\
                next;\
             print "--- GPG --verify ---";\
             system("gpg --verify " TMPFILE " 2>&1");\
             print "--- GPG --verify ---";\
             print "";\
             next;\
          }\
          /^-----BEGIN PGP SIGNATURE-----/,/^-----END PGP SIGNATURE-----/ {\
             next;\
          }\
          {print}\
          \;\
       print
 }
 define RK {
   !printf 'Key IDs to gpg --recv-keys: ';\
     read keyids;\
     gpg --recv-keys ${keyids};
 }
 commandalias V '\'call V
 commandalias RK '\call RK'

Using an IMAP mailbox

The following is only a quick hint, it is also possible to define folder and inbox to point to IMAP server folders, for example. Internationalised names are supported.

set v15-compat
# or many servers will expire the session
set imap-keepalive=240
set imap-cache=~/.imap_cache
# You may want to define shortcuts to folders, for example:
shortcut myimap "imaps://USER:PASS@server:port"
set inbox=myimap

See also