All mail is entered into the MMDF mail transport environment
through the submit program.
While it can be called directly from a user's terminal,
access to submit is most
conveniently performed through a program such as
submit permits considerable flexibility with respect to
batching multiple submissions, response and error handling, and
address source specification.
Multiple submissions modes
Terminate after one submission, such as is carried out by the
Specified by passing any initialization
information in the submit invocation line (that is, the
Permit multiple message submissions, as is done by the SMTP channel.
The initialization information is
given as the first input line, for each submission.
The format of this information is the same for both modes.
Response and error handling modes
Accept input until error or end-of-message, but
terminate on any error.
This is called ``non-protocol mode''.
This mode is mandatory when using Multiple submissions mode #1.
Notify result for each segment and continue.
This is called ``protocol mode''.
During it, each address produces a status reply and the message
text produces a reply.
The domain of the term segment depends on the error.
Simple addressing errors cause rejection only of the erroneous
address. Other errors may cause rejection of the entire message,
but permit submission of following messages.
Messages can now be submitted with a null return address in protocol mode
Formerly, a null address for either the return address or a recipient
address resulted in the silent termination of address-list processing. This
caused a serious problem, because in verify-address mode the caller will expect
a response to each address. If the caller passed a null address, it would
result in a protocol lockup as the caller waited forever for a response while
submit had moved on to expecting the message text. A null recipient address
is not valid and should result in an explicit error, and a null return address
is the standard indication that a return is not desired if the mail cannot be
delivered. For example, execmail '' would hang.
Address-list parsing is now
terminated only by a !,
as per the submit specification. For the sake of old
programs that incorrectly used an empty address line to terminate the address
list, a new submit option, e, causes submit to revert to the old
behavior. Setting SUBMIT_EMPTY_ADDR_TERM=1
in the environment before executing submit is
equivalent to passing the e option.
The only known example of this is mush, when built
to use submit directly.
To make mush use this option without recompiling it, put this line in the
global Mushrc file:
To make mush use this option without recompiling it, put this line
in the mush global .Mushrc. file:
set sendmail='/usr/mmdf/bin/submit -mlnre'
Addresses extracted from components of the message text.
Common when non-protocol mode
is also in force for the Interaction and the Verification option.
Explicit address list given ahead of message text.
Common when the second modes apply for the other options (protocol mode).
Both of the above (extracted and explicit addresses).
A message's initialization information is specified through a
single string, passed either in the process-invocation argument
list or in the first line of submit
input. Hence, the string
may be terminated either by a null or newline. Spaces and tabs
in the line are ignored, unless part of a literal. Specification
is only required for non-defaults.
for the ``Via'' or
reject on error
trust, disclaim on error
no trust (disclaim)
add Sender: field
Address list source
extract from components
both (extract and
abort on invalid
report on each address
leave for daemon
deliver local now
deliver netmail now
user will watch
send to submitter
send to ``Sender:''
do not return
do not send warnings
enable delay channel
don't use delay
not delay channel
as per msglog
as per msglog
Literals shown as characters, followed by an ellipsis,
followed by an asterisk (for example x...), represent a string.
The first character specifies the nature of the setting.
The value for the setting is placed between that character
and the asterisk. The value may be any string not
containing an asterisk, null, or newline. The values for
settings x and g are comma-separated lists of
strings. These strings may not contain asterisks, nulls,
newlines, or commas.
Specific comments on each option:
This is used when the calling program is interfacing with
another distribution system, effecting relaying. The literal
after the i specifies the channel the
message is coming from.
The h may be used, in conjunction with i, to
specify the source host. The literal is the name of the host.
Normally, a message that does not correctly identify its sender is rejected.
Anyone may send mail with any author specified, but they must use either the
u or t setting to bypass
authentication. However, these settings may cause
MMDF to include, in the Source-Info: component, a statement noting the absence
of authentication. The u setting always adds this statement; the t setting
only adds it if the user is not authorized (not root
or mmdf) and the message
header does not not correctly identify the sender.
The relay channels are run under the mmdf uid in order to gain authorization
such that the Source-Info: components is not added.
The determination of whether a message correctly identifies its sender is based
on the most authoritative From or Sender field. For the purpose of this test,
a plain Sender is taken to be more authoritative than a plain From. If a
Resent-, Remailed-, or Redistributed- version of either a From or Sender field
is given, it is taken to be more authoritative than the plain version of
either. All such "Re" headers are taken to be equally authoritative, and the
last one seen in the header (the one furthest down in the header) is taken to
be most authoritative. To determine whether a message correctly identifies its
sender, the local-address part of the most authoritative sender is looked up in
the password file to map it to a uid, and that uid is compared to the invoking
user's uid. If the uids match and the hostname part of the address is a name
for the local system, the message correctly identifies its sender.
The S setting tells MMDF to use
a Sender: field instead of a Source-Info:
field, and also causes conflicting Sender: fields in the submitted header to be
elided. This allows submission programs to send mail with a 'From:' field that
does not match the identity of the invoking user without having to be
privileged and without having a Source-Info: field added.
In addition to the action explained above, Source-Info:
can directly receive text, from the user, through the f
setting. The value string is replicated on a separate
line in the field.
Address list source
An explicit list has one address per line. When x or
g are specified, they list the names of message
components, such as To: and CC:, which are to be
searched for addresses.
Normally, any illegal address will cause the entire
message to be rejected. In v (verify) mode, the
acceptability of each message is reported and
encountering an illegal address does not abort
Mail may be delivered only to a recipient's mailbox (file).
An immediate attempt causes a special
process to be forked and it will attempt to process the indicated
mail immediately. (The n setting does not allow more
granularity, for historical reasons.) Otherwise, the
system's background daemon will get to it eventually.
The daemon also handles mail that initially could not be
delivered/relayed. A channel's descriptor structure (in
or the runtime tailor file)
specifies a channel as being Active, Passive,
or Background. Only the first is processed by any request
for immediate delivery. The second indicates a Post
Office Box-style channel. The third limits the channel
to processing by the background
daemon, which may be necessary for restricting access to special channels,
such as dial-out telephones.
If an immediate attempt is requested, the user may elect
to watch its progress.
and its children will report assorted aspects of their activity. If a quiet
attempt is requested,
returns as soon as
submission is completed. That is, a quiet attempt is
If the invoker of submit is not to receive return mail
(for example, notification of delivery failure) then the next
input line (the first, if settings are specified in the
call), contains an address that should receive the
notification. It is not validated. If either the r
or the s switch is given,
will not read a line for the return address. If no return
mail should be sent, the return address line should be
empty (should consist of a newline only). If the q
switch is given, a return address is read from the next
line of input and the message is not passed to the remote
system. The purpose is to determine who sent the message while
viewing the MMDF queue.
The S switch indicates to use a Sender: field instead
of a Source-Info: field, and also causes conflicting Sender: fields in the
submitted header to be elided. This allows submission programs to send mail
with a From: field that does not match their identity without having to be
Returned mail contents
Normally, a copy of the entire message is sent with a
delivery-failure notice. Using the c switch causes a
citation, comprising the message header and first three
non-blank lines of the body, to be sent.
If more than listsize addresses are specified, for a message,
citation-only is automatically set. listsize defaults to 12
and can be specified using the MLISTSIZE parameter (see
In addition, no warning
message is sent for addresses which take a long time to process
(a site dependent value); the final failure notice is always
sent if there are addresses that are never fully processed.
Normally MMDF will send a non-delivery warning if a message has
been undelivered after a small period (typically 12 to 72 hours,
depending on the site). Deliver attempts continue until a
timeout period is reached. This is typically after 3 to 10 days,
depending on the site.
Delay channel usage
The delay channel is used to process mail submissions that could not be
queued because necessary nameserver information was unavailable
and therefore an authoritative decision on the validity of the address
was not possible.
If the d option is specified, use of the delay channel is
prohibited. If the nameserver fails, an error is returned, rather
than a conditional OK.
Delay channel indicator
This option is intended only to be used by the delay channel itself
to indicate to submit that the invoking process
is the delay channel.
This option implies the d option above.
By default, MMDF uses a short timeout algorithm. This is suitable for
user interface programs which do not want to wait a long time for dead
nameservers. The k option allows a different timeout to be set.
The value given is the number of seconds to wait for the nameserver
lookup to complete.
The W option causes submit to print a detailed
description of its activities
on file descriptor 2. It will indicate, for each
addressee, the channel and addresses queued.
This can generate a great deal of output if a mailing list is
encountered, so it should be used with caution.
The L option allows the specification of an alternate logging file
The string following the L should be the name of the logfile
to be used.
It can be terminated by a ``'' or the end of the arguments.
This option is only available to the root or mmdf users.
The V option allows the setting of the logging level at runtime.
The string following the V should be one of the valid MMDF
logging level strings such as FTR or BST.
It can be terminated by a ``'' or the end of the arguments.
This option is only available to the root or mmdf users.
The U option allows the specification of a uid other
than that of the invoking process.
This option is used for access control.
When U is used, submit will call
to change the real uid to the specified id,
so this option is only available to root.
The following augmented BNF characterizes submit's input
(file descriptor zero) format:
Addresses are expected to conform to the ARPANET mail standard
known as RFC 822, available from the Network Information Center
at SRI International.
submit (and MMDF in general) also continues to support
RFC 733 style mail for compatibility with earlier mail systems.
In addition to those in RFC 822, the following address
delimiters are recognized within the local part of addresses
(in order of precedence):
@ % ! .
The ``!'' delimiter is interpreted as ``host!user'' while the others are
interpreted as ``user?host''.
For example, the address ``a.b!user%c@localhost'' would be queued for
``a.b!user@c''. The address ``a.b!user@localhost'' would be queued for
``firstname.lastname@example.org''. The address ``user.a@localhost'' would be queued for ``user@a''.
Note that recognition of the ``.'' delimiter is a site-selectable option.
Also, addresses may be indirectly referenced, through a file
specification of the form:
``<filename'' or ``:include:filename''
where the angle-bracket must be the first non-blank character of
the specification (to distinguish it from the ``<...>'' usage, above).
Addresses in the file may be separated by commas or newlines.
Phases involve Invocation (Invoke), data sent into submit
via its file descriptor zero (To), data returned from submit
via its file descriptor one (From), iteration back to the specified phase
(Loop), and process exit value (Exit).
Simple, single-message command:
Parameters, ``-mlrxto,cc'', indicate that the
message is to be sent to recipients' mailboxes,
local mail should be sent immediately, return
mail goes to the submitter, and addresses are to
be extracted from the To: and cc:
The entire message.
Process return value, in wait(&val), indicating submission status.
Standard, multi-message protocol:
Initialization information line. A typical
user program might have ``mlrv'', indicating the
message is to be sent to mailboxes, local mail
sent immediately, return mail goes to the
sender, and each address verification is to be
reported. A relay program might have
``mlntviVGR.BRL.MIL,'' with ``mlv'' as above and the
other settings indicating that mail for non-local
channels is to be sent immediately, the
author information is to be trusted, and the
``Received:'' component should cite the mail as being
relayed via Internet host VGR.BRL.MIL.
One address, terminated by a newline ('\n').
Status character, from mmdf.h,
plus human-oriented text plus newline.
Back to (c). Terminate with address line having
only an exclamation mark (!), with newline.
Message text, in Internet RFC 822 format.
Multi-line, terminated by null ('\0').
Status character, text, newline.
Back to (b). Terminate with initialization line
having only a null, without newline.
When MMDF is used in conjunction with the DARPA domain nameserver
system, configure a ``delay'' channel to allow
queuing of addresses that fail verification temporarily due
to nameserver failures (unavailability).
Two other special channels that can be configured are
the ``badusers'' and ``badhosts'' channels.
Mail to unknown users or unknown hosts will be queued to
these channels if they are configured.
The bad channels have no special code associated with them.
The channel configuration should reference whatever table and
program is necessary to reach a smarter host that can
deliver or forward the mail.
The channel should have the ``host='' parameter set to this
The channel names given above are reserved.
The badusers channel has two confstr parameters,
keepdomain and defdomain. Setting keepdomain=1
tells the channel to not strip
the original domain from a recipient address. Setting
will set an explicit default domain; this should be set to whatever domain name
the host that mail is being forwarded expects to see.
If only defdomain is
given, all messages transferred through the badusers channel will get the given
domain. If both are given, recipient addresses that include a domain will keep
it, while those that do not include a domain will get the default domain.
The following, excerpted from MMDF source, lists the exit values.
/* Reply Codes for MMDF
* Based on: "Revised FTP Reply Codes", by Jon Postel & Nancy Neigus Arpanet
* RFC 640 / NIC 30843, in the "Arpanet Protocol Handbook", E. Feinler
* and J. Postel (eds.), NIC 7104, Network Information Center, SRI
* International: Menlo Park, CA. (NTIS AD-A0038901)
* Actual values are different, but scheme is same. Codes must fit into
* 8-bits (to pass on exit() calls); fields are packed 2-3-3 and interpreted
* as octal numbers.
* Basic format:
* 0yz: positive completion; entire action done
* 1yz: positive intermediate; only part done
* 2yz: Transient negative completion; may work later
* 3yz: Permanent negative completion; you lose forever
* x0z: syntax
* x1z: general; doesn't fit any other category
* x2z: connections; truly transfer-related
* x3z: user/authentication/account
* x4x: mail
* x5z: file system
* 3-bit z field is unique to the reply. In the following,
* the RP_xVAL defines are available for masking to obtain a field.
/*************** FIELD DEFINITIONS & BASIC VALUES ***************** */
/* Field 1: Basic degree of success (2-bits) */
* Octal constant values are used for this field to avoid problems with sign
* extension of char constant values with high bit set.
#define RP_BTYP 0200 /* good vs. bad; on => bad */
#define RP_BVAL 0300 /* basic degree of success */
#define RP_BOK 0000 /* went fine; all done */
#define RP_BPOK 0100 /* only the first part got done */
#define RP_BTNO 0200 /* temporary failure; try later */
#define RP_BNO 0300 /* not now, nor never; you lose */
#define RP_CSYN ' 00' /* purely a matter of form */
#define RP_CGEN ' 10' /* couldn't find anywhere else for it */
#define RP_CCON ' 20' /* data-transfer-related issue */
#define RP_CUSR ' 30' /* pertaining to the user */
#define RP_CMAI ' 40' /* specific to mail semantics */
#define RP_CFIL ' 50' /* file system */
#define RP_CLIO ' 60' /* local i/o system */
/* Field 3: Specific value for this reply (3-bits) */
#define RP_SVAL ' 07' /* specific value of reply */
/********************* SPECIFIC SUCCESS VALUES ******************** */
#define rp_gval(val) ((ret_t) (val))
/* get the entire return value */
/* The next three give the field's bits, within the whole value */
#define rp_gbval(val) (rp_gval (val) & RP_BVAL)
/* get the basic part of return value */
#define rp_gcval(val) (rp_gval (val) & RP_CVAL)
/* get the domain part of value */
#define rp_gsval(val) (rp_gval (val) & RP_SVAL)
/* get the specific part of value */
/* The next three give the numeric value withing the field */
#define rp_gbbit(val) ((rp_gval (val) >> 6) & 03)
/* get the basic part right-shifted */
#define rp_gcbit(val) ((rp_gval (val) >> 3 ) & 07)
/* get the domain part right-shifted */
#define rp_gsbit(val) (rp_gval (val) & 07)
/* get the specific part right-shifted */
/* The following works with SIGNED or UNSIGNED chars! */
#define rp_isgood(val) (! rp_isbad(val))
/* is return value positive? */
#define rp_isbad(val) (rp_gval(val) & 0200)
/* is return value negative? */
Numerous. Generally under the MMDF login directory.