Ubuntu Manpage: post - deliver an nmh message

Provided by: nmh_1.7.1~RC3-1build1_amd64

NAME

       post - deliver an nmh message

SYNOPSIS

       /usr/lib/mh/post [-help] [-version] [-alias aliasfile] [-filter filterfile] [-nofilter]
            [-format | -noformat] [-mime | -nomime] [-msgid | -nomsgid] [-messageid localname |
            random] [-verbose | -noverbose] [-watch | -nowatch] [-width columns] [-mts smtp |
            sendmail/smtp | sendmail/pipe] [-sendmail program] [-server servername] [-port
            portname/number] [-sasl] [-nosasl] [-saslmech mechanism] [-user username] [-tls]
            [-initialtls] [-notls] file

DESCRIPTION

post is the default program called by send to deliver the message in file to local and
remote users. In fact, most of the features attributed to send in its manual page are
performed by post, with send acting as a relatively simple preprocessor. Thus, it is post
which parses the various header fields, appends a “Date:” line, and interacts with the
mail transport system. post will not normally be called directly by the user, but can be
replaced by the user with a postproc profile component that will have file as its final
argument. See mh-profile(5) for more information on postproc.

post searches the “To:”, “cc:”, “Bcc:”, “Fcc:”, and “Resent-xxx:” header lines of the
specified message for destination addresses, checks these addresses for validity, and
formats them so as to conform to ARPAnet Internet Message Format protocol, unless the
-noformat flag is set. This will normally cause “@local-site” to be appended to each
local destination address, as well as any local return addresses. The -width columns
switch can be used to indicate the preferred length of the header components that contain
addresses.

If a “Bcc:” field is encountered, its addresses will be used for delivery, and the “Bcc:”
field will be removed from the message sent to sighted recipients. The blind recipients
will receive an entirely new message with a minimal set of headers. Included in the body
of the message will be a copy of the message sent to the sighted recipients. If -filter
filterfile is specified, then this copy is filtered (re-formatted) by mhl prior to being
sent to the blind recipients. Alternately, if the -mime switch is given, then post will
use the MIME rules for encapsulation.

The -alias aliasfile switch can be used to specify a file that post should read aliases
from. More than one file can be specified, with each being preceded by -alias. In any
event, the primary alias file is read first.

The -msgid switch indicates that a “Message-ID:” or “Resent-Message-ID:” field should be
added to the header.

The -messageid switch selects the style used for the part appearing after the @ in
“Message-ID:”, “Resent-Message-ID:”, and “Content-ID:” header fields. The two acceptable
options are localname (which is the default), and random. With localname, the local
hostname is used. With random, a random sequence of characters is used instead. Note
that the -msgid switch must be enabled for this switch to have any effect.

The -verbose switch indicates that the user should be informed of each step of the
posting/filing process.

The -watch switch indicates that the user would like to watch the transport system's
handling of the message (e.g., local and “fast” delivery).

Under normal circumstances, post uses the “From:” line in the message draft as the
identity of the originating mailbox. A “From:” line is required in all message drafts.
By default the message composition utilities such as comp, repl and mhmail will
automatically place a “From:” line in the message draft. There are two ways to override
this behavior, however. Note that they apply equally to “Resent-From:” lines in messages
sent with dist.

The first way is to supply a “Sender:” line. The value of this field will be used as the
originating mailbox identity when submitting the message to the mail transport system. If
multiple addresses are given in the “From:” line, a “Sender:” line is required. If an
“Envelope-From:” line is supplied when multiple addresses are given in the “From:” line, a
“Sender:” header will be generated using the value of the “Envelope-From:” line, if the
“Envelope-From:” line is not blank.

The second way is to supply a “Envelope-From:” line. The value of this field will be used
as the originating mailbox identity when submitting the message to the mail transport
system. This will override both the value of the “From:” line and a “Sender:” line (if
one is supplied). The “Envelope-From:” line is allowed to have a blank value; if the
value is blank, then the mail transport system will be instructed to not send any bounces
in response to the message. Not all mail transport systems support this feature.

The mail transport system default is defined in /etc/nmh/mts.conf but can be overridden
here with the -mts switch.

If nmh is using sendmail/pipe, as its mail transport system, the -sendmail switch can be
used to override the default sendmail program.

If nmh is using the SMTP MTA, the -server and -port switches can be used to override the
default mail server and port. The default server is set with servers in
/etc/nmh/mts.conf, and the default port is submission, 587.

If nmh has been compiled with SASL support, the -sasl and -nosasl switches will enable and
disable the use of SASL authentication with the SMTP MTA. Depending on the SASL mechanism
used, this may require an additional password prompt from the user (but the netrc file can
be used to store this password, as described in mh-profile(5). The -saslmech switch can
be used to select a particular SASL mechanism, and the -user switch can be used to select
an authorization userid to provide to SASL, other than the default. The credentials
profile entry in mh-profile(5) describes the ways to supply a username and password.

If SASL authentication is successful, nmh will attempt to negotiate a security layer for
session encryption. Encrypted data is labelled with `(sasl-encrypted)' and `(sasl-
decrypted)' when viewing the SMTP transaction with the -snoop switch. Base64-encoded data
is wrapped with `b64<>'. (Beware that the SMTP transaction may contain authentication
information either in plaintext or easily decoded base64.)

If nmh has been compiled with TLS support, the -tls and -initialtls switches will require
the negotiation of TLS when connecting to the SMTP MTA. The -tls switch will negotiate
TLS as part of the normal SMTP protocol using the STARTTLS command. The -initialtls will
negotiate TLS immediately after the connection has taken place, before any SMTP commands
are sent or received. Encrypted data is labelled with `(tls-encrypted)' and `(tls-
decrypted)' when viewing the SMTP transaction with the -snoop switch. Base64-encoded data
is wrapped with `b64<>'. (Beware that the SMTP transaction may contain authentication
information either in plaintext or easily decoded base64.) The -notls switch will disable
all attempts to negotiate TLS.

If port 465 is specified and none of the TLS switches were enabled, -initialtls will be
implied if TLS support was compiled in. Though port 465 for SMTPS (SMTP over SSL) was
deregistered by IANA in 1998, it is still used for that service.

post filters out header lines with names beginning with “Nmh-” (case insensitive) from the
message draft. Those lines are reserved for internal nmh use.

FILES

       /etc/nmh/mts.conf          nmh mts configuration file
       /etc/nmh/MailAliases       global nmh alias file
       /usr/bin/mh/refile         Program to process Fcc:s
       /usr/lib/mh/mhl            Program to process Bcc:s

PROFILE COMPONENTS

       post does not consult the user's .mh_profile

DEFAULTS

       `-alias' defaults to /etc/nmh/MailAliases
       `-format'
       `-nomime'
       `-nomsgid'
       `-messageid localname'
       `-noverbose'
       `-nowatch'
       `-width 72'
       `-nofilter'

CONTEXT

       None

BUGS

       “Reply-To:”  fields  are  allowed  to  have  groups  in  them  according  to  the  RFC 822
       specification, but post won't let you use them.