<APPENDIX ID="zapp.msg-file-format"><?dbhtml filename="zapp-filefmts.html">
<TITLE>Internal File Data Formats</TITLE>

<PARA>
As mentioned, the <EMPHASIS>router</> picks up message files from
a specific directory.
Normally, message file names can be arbitrary valid file names, and indeed
this is convenient when debugging.
However, because the <EMPHASIS>router</> daemon scans its own current
directory, miscellaneous output from the <EMPHASIS>router</> process
may show up in this directory (e.g. profiling data, or core dumps
(unthinkable as that is)).
Furthermore, it is useful to be able to hide files from
the <EMPHASIS>router</> scanning (indeed the <EMPHASIS>router</> may
wish to do so itself).
</PARA>

<PARA>
When the <EMPHASIS>router</> process is scanning for message files then,
it only considers at file names that have a certain format.
Specifically, the message file name must start with a digit.
This method was chosen to accomodate the message file names, as generated
by the standard submission interface library routines, which will be strings
of digits representing the message file's inode number.
</PARA>

<PARA>
A message file contains three sections: the message envelope, the message
header, and the message body (in that order).
he message body is separated from the previous sections by a blank line.
The message body may be empty, and either of the message envelope or
message header may be empty.
The restriction on the latter situation, is that one of those sections
must contain destination information for the message.
</PARA>

<PARA>
The message envelope and the message header have very similar syntax.
The only difference is that while the message header must adhere to RFC822,
the message envelope header fields are terminated by whitespace (`` '')
instead of a colon (``:'').
The semantics of the two message file sections is quite different, and
will be covered later.
</PARA>

<SECT1><TITLE>Envelope Header Lines</TITLE>

<PARA>
The message envelope headers are used to carry meta-information about
the message.
The goal is to carry transport-envelope  information separate from message
(RFC-822) headers, and body.
At first the message starts with a set of envelope headers
(*-prefix denotes optional):
<SCREEN>
 *external \n
 *rcvdfrom %s (%s) \n
 *bodytype %s \n
 *with %s \n
 *identinfo %s \n
<EMPHASIS>Either:</>
   from &lt;%s&gt; \n
<EMPHASIS>Or:</>
   channel error \n
 *envid %s \n
 *notaryret %s \n
<EMPHASIS>Then for each recipient pairs of:</>
 *todsn [NOTIFY=...] [ORCPT=...] \n
 to &lt;%s&gt; \n
<EMPHASIS>Just before the data starts, a magic entry:</>
 env-end \n
</SCREEN>
Then starts the message RFC-822 headers, and below it, the body.
</PARA>

<PARA>
The header fields recognized by ZMailer in the message envelope are:
<VARIABLELIST>
<VARLISTENTRY><TERM>bodytype <EMPHASIS>word</></TERM>
<LISTITEM><PARA>
not used. Compatibility with the <APPLICATION>sendmail</> feature 
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>channel <EMPHASIS>word</></TERM>
<LISTITEM><PARA>
sets the channel corresponding to the message origin(*),
usually as ``channel error''
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>comment <EMPHASIS>string</></TERM>
<LISTITEM><PARA>
arbitrary comment
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>env-end</TERM>
<LISTITEM><PARA>
separator between the envelope and the RFC822 headers
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>env-eof</TERM>
<LISTITEM><PARA>
alias to env-end
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>envid <EMPHASIS>xtext</></TERM>
<LISTITEM><PARA>
ESMTP DSN ENVID value
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>external</TERM>
<LISTITEM><PARA>
keyword indicating the external origin of a message
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>from <EMPHASIS>``address''</></TERM>
<LISTITEM><PARA>
a source address(*)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>fullname <EMPHASIS>``phrase''</></TERM>
<LISTITEM><PARA>
sets the full name of the local sender
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>identinfo <EMPHASIS>``string''</></TERM>
<LISTITEM><PARA>
The SMTP server's ident lookup result, this does not guarantee anything
about the sender though.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>loginname <EMPHASIS>``word''</></TERM>
<LISTITEM><PARA>
requests using this mail id for the local sender
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>notaryret <EMPHASIS>``word''</></TERM>
<LISTITEM><PARA>
ESMTP DSN RET=<EMPHASIS>word</>, either ``FULL'' ``HDRS''
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>rcvdfrom <EMPHASIS>``domain'' (opt comment)</></TERM>
<LISTITEM><PARA>
An optional envelope entry, which sets ``Received:'' header's
``from'' field value.
</PARA>

<PARA>
This should <EMPHASIS>only</> be used on messages that are originated
thru ``trusted'' mechanisms, and especially <EMPHASIS ROLE="BOLD">not</>
be used when the message is originated by some John Doe in the system.
(E.g. this is reserved for <EMPHASIS>smtpserver</> and friends, not
 for arbitary users.)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>to <EMPHASIS>``address-list''</></TERM>
<LISTITEM><PARA>
Normal recipient address list; usually used in form of listing
one address in angle braces:
<SCREEN>
  to &lt;user@somewhere&gt;
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>todsn <EMPHASIS>``phrase''</></TERM>
<LISTITEM><PARA>
ESMTP DSN recipient parameters.
Note: this must be before the recipient ``to'' line for which
this gives the extra parameters.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>user <EMPHASIS>``local-part''</></TERM>
<LISTITEM><PARA>
Optional envelope entry telling who the message originating user
was.   The system is extremely suspicuous on this entry, and will
check it against system account database, unless the spool file
owner uid is known to belong to trusted users.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>verbose <EMPHASIS>``filename''</></TERM>
<LISTITEM><PARA>
This optional envelope entry tells the router, what filename
the sending client expects the subsystems to use as a feedback
channel for reports concerning the file.
</PARA>

<PARA>
This ``<EMPHASIS>filename</>'' is located into
<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/public/</>
directory, and has been preopened by the same uid as has created
the message spool file.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>via <EMPHASIS>``word''</></TERM>
<LISTITEM><PARA>
An optional envelope entry that will define ``Received:'' header's
optional ``via'' tag telling what physical transport mechanism was
used.
</PARA><PARA>
Usually this entry is <EMPHASIS>not</> used.
(For an exceptions, see <EMPHASIS>rmail</> and
 <EMPHASIS>listexpand</> utility.)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>with <EMPHASIS>``word''</></TERM>
<LISTITEM><PARA>
An optional envelope entry that will define ``Received:'' header's
optional ``with'' tag telling what protocol was used.
</PARA><PARA>
Unlike RFC-822 tells, ZMailer supports only one ``with'' instance.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>
</PARA>

<PARA>
The (*)'s beside the descriptions indicate this is a privileged field.
That is, the action will only happen if ZMailer trusts the owner of the
message file (*Note Security: security.). 
As with a normal RFC822 header, other fields are allowed (though they
will be ignored), and case is not significant in the field name.
The <EMPHASIS>router</> will do appropriate checks for the fields that
require it.
</PARA>

<PARA>
With this knowledge, we can now appreciate the minimal message file:
<SCREEN>
  --------------------
  to bond
   
  --------------------
</SCREEN></PARA>

<PARA>
This will cause an empty message to be sent to <EMPHASIS>bond</>.
A slightly more sophisticated version is:
<SCREEN>
  --------------------
  from m
  to bond
  via courier
  env-end
  From: M
  To: Bond
  Subject: do get a receipt, 007!
     
  You are working for the Government, remember?
  --------------------
</SCREEN></PARA>

<PARA>
Notice that there is no delimiter between the message envelope and the
message header.  A more sophisticated example in the same vein:
<SCREEN>
  --------------------
  from ps/d-ops
  to &lt;007@sis.mod.uk&gt;
  env-end
  From: M &lt;d-ops@sis.mod.uk&gt;
  Sender: Moneypenny &lt;ps/d-ops@sis.mod.uk&gt;
  To: James Bond &lt;007@sis.mod.uk&gt;
  Subject: where are you???!
  Classification: Top Secret
  Priority: Flash
     
  We have another madman on the loose.  Contact "Q" for usual routine.
  --------------------
</SCREEN>
</PARA>

<PARA>
If the <EMPHASIS>Classification:</> header is paid attention to in ZMailer,
this requires that the <EMPHASIS>router</> recognize it in the message
header, and take appropriate action.
In general the <EMPHASIS>router</> can extract most of the information in
the message header, and make use of it if the information is lacking in
the envelope.
The envelope headers in the above message are superfluous, since the same
information is contained in the message header.
Using the following envelope headers would be exactly equivalent to using
the ones shown above (assuming the local host is <EMPHASIS>sis.mod.uk</>):
<SCREEN>
  --------------------
  From Moneypenny &lt;ps/d-ops@sis.mod.uk&gt;
  To James Bond &lt;007@sis.mod.uk&gt;
  ...
  --------------------
</SCREEN></PARA>

<PARA>
ZMailer will extract the appropriate address information from whatever the
field values are, as long as they obey the defined syntax (indicated in the
list of recognized envelope fields above).
ZMailer will complain in case of unexpected errors in the envelope headers.
</PARA>

<PARA>
The message body is not interpreted by ZMailer itself.
As far as the <EMPHASIS>router</> is concerned, it can be arbitrary data.
However, certain <EMPHASIS>Transport Agents</> may require limitations on
the message body data.
For example, the SMTP only deals with ASCII data with a small guaranteed
line length.
</PARA>


</SECT1>

<SECT1><TITLE>Message Control File</TITLE>

<PARA>
A message control file is a file created by the <EMPHASIS>router</> to
contain all the information necessary for delivery of a message submitted
in a corresponding message file.
It is interpreted by the <EMPHASIS>scheduler</>, which needs to know
at all times which messages are pending to go where, and how.
It is also interpreted by one or more <EMPHASIS>Transport Agents</>,
possibly concurrently, that extract the delivery information relevant
to their purpose.
</PARA>

<PARA>
The concurrency aspect means that the <EMPHASIS>Transport Agents</> must
cooperate on a locking protocol to ensure that delivery to a particular
destination is attempted by only one <EMPHASIS>Transport Agent</> at a time,
and a status protocol to ensure unique success or failure of delivery for
each destination.
There are potentially many ways to implement such protocols, but, in
the spirit of simplicity, ZMailer uses a control file as a form of shared
memory.
Specific locations within each control file are reserved for flags that
indicate a specific state for their associated destination address.
The rest is taken care of by the I/O semantics when multiple processes
update the same file.
</PARA>

<PARA>
Apart from necessary envelope and control information, a control file also
contains the new message header for the message, which contains the header
addresses as rewritten by the <EMPHASIS>router</>.
Since a message may have several destinations with incompatible address
format requirements, there may be several corresponding groups of message
headers.
This will be illustrated by the sample control file shown in the following
subsection.
</PARA>


<SECT2><TITLE>Format</TITLE>

<PARA>
A control file consists of a sequence of fields.
Each field starts at the beginning of a line
(i.e. at byte 0 or after a Newline), and is identified by the appearance of
a specific character in that location.
This id character is normally followed by a byte containing a tag value
(semaphore flag), followed by the field value.
</PARA>

<PARA>
Here is a simple control file produced by a test message, just before it
was removed by the Scheduler:
<SCREEN>
  --------------------
  i 24700
  o 72
  l &lt;88Jan10.003129est.24700@bay.csri.toronto.edu&gt;
  e Rayan Zachariassen &lt;rayan&gt;
  s local - rayan
  r+local - rayan 2003
  m
  Received: by bay.csri.toronto.edu id 24700; Sun, 10 Jan 88 00:31:29 EST
  From:   Rayan Zachariassen &lt;rayan&gt;
  To:     rayan, rayan@ephemeral
  Subject: a test
  Message-Id: &lt;88Jan10.003129est.24700@bay.csri.toronto.edu&gt;
  Date:   Sun, 10 Jan 88 00:31:24 EST
  
  s local - rayan@bay.csri.toronto.edu
  r+smtp ephemeral.ai.toronto.edu rayan@ephemeral.ai.toronto.edu 2003
  m
  Received: by bay.csri.toronto.edu id 24700; Sun, 10 Jan 88 00:31:29 EST
  From:   Rayan Zachariassen &lt;rayan@csri.toronto.edu&gt;
  To:     rayan@csri.toronto.edu, rayan@ephemeral.ai.toronto.edu
  Subject: a test
  Message-Id: &lt;88Jan10.003129est.24700@bay.csri.toronto.edu&gt;
  Date:   Sun, 10 Jan 88 00:31:24 EST
  
  --------------------
</SCREEN>
</PARA>

<PARA>
The id character values are defined in
the <FILENAME CLASS="HEADERFILE">mail.h</> system header file,
which currently contains:
<SCREEN>
#define _CF_MESSAGEID   'i'     /* inode number of file containing message */
#define _CF_BODYOFFSET  'o'     /* byte offset into message file of body */
#define _CF_BODYFILE    'b'     /* alternate message file for new body */
#define _CF_SENDER      's'     /* sender triple (channel, host, user) */
#define _CF_RECIPIENT   'r'     /* recipient n-tuple, n &gt;= 3 */
#define _CF_DSNRETMODE  'R'     /* DSN message body return control */
#define _CF_XORECIPIENT 'X'     /* one of XOR set of recipient n-tuples */
#define _CF_RCPTNOTARY  'N'     /* DSN parameters for previous recipient */
#define _CF_DSNENVID    'n'     /* DSN 'MAIL FROM&lt;&gt; ENVID=XXXX' data */
#define _CF_ERRORADDR   'e'     /* return address for error messages */
#define _CF_DIAGNOSTIC  'd'     /* diagnostic message for ctlfile offset */
#define _CF_MSGHEADERS  'm'     /* message header for preceeding recipients */
#define _CF_LOGIDENT    'l'     /* identification string for log entries */
#define _CF_OBSOLETES   'x'     /* message id of message obsoleted by this */
#define _CF_VERBOSE     'v'     /* log file name for verbose log (mail -v) */
#define _CF_TURNME      'T'     /* trigger scheduler to attempt delivery now */
#define _CF_RCVFROM     'F'     /* Where-from we are coming ? */               
</SCREEN>
</PARA>

<PARA>
There is one field per line, except for <CONSTANT>_CF_MSGHEADERS</> which
has some special semantics described below.
The following describes the fields in detail:

<VARIABLELIST>
<VARLISTENTRY><TERM>i</TERM><LISTITEM><PARA>
This field identifies the message file corresponding to this control file.
It is the name of the message file in the <EMPHASIS>QUEUE</> directory
(<FILENAME CLASS="DIRECTORY">$<VARNAME>POSTOFFICE</>/queue/</>).
This is typically the same as the inode number for that file, but need not be.
It is used by <EMPHASIS>Transport Agents</> when copying the message body,
and by the <EMPHASIS>Scheduler</> when unlinking the file after all
the destination addresses have been processed.
For example:
<SCREEN>
  i 21456
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>o</TERM><LISTITEM><PARA>
Specifies the byte offset of the message body in the message file.
It is used by <EMPHASIS>Transport Agents</> in order to copy
the message body quickly, without parsing the message file.
For example:
<SCREEN>
  o 466
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>b</TERM><LISTITEM><PARA>
Alternate message file for new body.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>e</TERM><LISTITEM><PARA>
Gives an address to which delivery errors should be sent.
The address must be an RFC822 mailbox.
For example:
<SCREEN>
  e "Operations Directorate" &lt;d-ops@sis.mod.uk&gt;
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>l</TERM><LISTITEM><PARA>
The field value is an uninterpreted string which should prefix all log
messages and accounting records associated with this message.
This value is typically the message id string.
For example:
<SCREEN>
  l &lt;88Jan6.103158gmt.24694@sis.mod.uk&gt;
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>s</TERM><LISTITEM><PARA>
This field specifies an originator (sender) address triple, in the
sequence: previous channel, previous host, return address.
It remains the current sender address until the next instance of this field.
Since there can only be one sender of a message, multiple instances of
the field will correspond to different return address formats as
produced by the <FUNCTION>crossbar</> algorithm in the <EMPHASIS>router</>.
For example:
<SCREEN>
  s smtp sis.mod.uk @lab.sis.mod.uk:q@deadly-sun.lab.sis.mod.uk
  s uucp sisops lab.sis.mod.uk!deadly-sun.lab.sis.mod.uk!q
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>r</TERM><LISTITEM><PARA>
This field specifies a destination (recipient) address triple, in the
sequence: next channel, next host, address for next host.
Optional information to be passed to the <EMPHASIS>Transport Agent</>
may be placed after the mandatory fields; this currently refers to
the delivery privilege of the destination address.
Since the optional values of this field are only interpreted by the
<EMPHASIS>Transport Agent</>, changes in what the <EMPHASIS>router</>
writes must be coordinated with the code of the <EMPHASIS>Transport Agents</>
that might interpret this field.
For example:
<SCREEN>
  r local - bond 0
  r uucp uunet sisops!bond -2
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>R</TERM><LISTITEM><PARA>
DSN message body return control.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>X</TERM><LISTITEM><PARA>
One of XOR set of recipient n-tuples.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>N</TERM><LISTITEM><PARA>
DSN parameters for previous recipient.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>n</TERM><LISTITEM><PARA>
DSN <COMPUTEROUTPUT>MAIL FROM&lt;&gt; ENVID=XXXX</> data.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>m</TERM><LISTITEM><PARA>
Apart from a message body, a <EMPHASIS>Transport Agent</>
needs the message headers to construct the message it delivers.
These message headers are stored as the value of this field.
Since message headers obviously can span lines, the syntax for
this field is somewhat different than for the others.
The field id is immediately followed by a newline, which is followed
by a complete set of message headers.
These are terminated (in the usual fashion) by an empty line, which also
terminates this field.
In the following example, the last line of text is followed by an empty line,
after which another field may start:
<SCREEN>
  m
  From: M
  To: Bond
  Subject: do get a receipt, 007!
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>d</TERM><LISTITEM><PARA>
This field is <EMPHASIS>not</> written by the <EMPHASIS>router</>.
t is written by the <EMPHASIS>Scheduler</> or <EMPHASIS>transport agents</>
to remember errors associated with specific addresses.
The field value has two parts, the first being the byte offset in the control
file of the destination (recipient) address causing the error, and the rest
of the line being an error message.
The <EMPHASIS>Transport Agents</> discover these errors and report them
to the <EMPHASIS>Scheduler</>.
The <EMPHASIS>Scheduler</> will collect them and report them to
the error return address (if any) after all the destinations have been
processed.
For example:
<SCREEN>
  d 878 No such local user: 'bond'.
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>x</TERM><LISTITEM><PARA>
Message id of message obsoleted by this.
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>v</TERM><LISTITEM><PARA>
Log file name for verbose log (<USERINPUT>mail -v</>):
<SCREEN>
 v ../public/v_some_magic_tmpfile
</SCREEN>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>T</TERM><LISTITEM><PARA>
Trigger scheduler to attempt delivery now. (ETRN)
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>F</TERM><LISTITEM><PARA>
Where-from we are coming ?               
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST>
</PARA>

<PARA>
It should be noted, that in sender and recipient fields the first two field
values (channel and host) cannot contain embedded spaces, but the third
field value (the address) may.
Therefore, in the presence of extra fields, parsing within
<EMPHASIS>Transport Agents</> must be cautious and not assume that
an address does not contain spaces.
</PARA>

<PARA>
As mentioned, the second byte of most fields are used for concurrency
control and status indication.
This tag byte can contain several values that indicate current or previous
activity.
The fields where this is relevant are the destination (recipient) address
and diagnostic fields.
The tag values are defined in the ``mail.h' file mentioned previously, as
follows:
<SCREEN>
  #define _CFTAG_NORMAL ' ' /* what the router sets it to be */
  #define _CFTAG_LOCK   '~' /* that line is being processed, lock it */
  #define _CFTAG_OK     '+' /* positive outcome of processing */
  #define _CFTAG_NOTOK  '-' /* something went wrong */
  #define _CFTAG_DEFER  _CFTAG_NORMAL /* try again later */
</SCREEN>
</PARA>

<PARA>
The extract above is self-explanatory.
</PARA>

<PARA>
A message control file will normally contain a preamble that specifies
information about the associated message file, the message body offset, an
error return address, and a log entry tag.
After this comes a repeated sequence of: sender address field,
recipient address fields, and the message header corresponding
to these recipients.
After as many of these groups as are necessary, any diagnostic fields
will be appended to the end of the control file.
The restrictions on the sequence of addresses and message headers, are
that a sender address field must precede any recipient address field,
and a recipient address field must (immediately) precede any message header
field, and no sender or recipient addresses may follow the last message
header field.
</PARA>

</SECT2>
</SECT1>

<SECT1><TITLE>Scheduler and Transport Agent Protocol</TITLE>

<PARA>
The transport agent interface follows a master-slave model,
where the TA informs the scheduler that it is ready for the work,
and then the scheduler sends it one job  description, and waits
for diagnistics.
Once the job is finished, the TA notifies the scheduler that it is
ready for a new job.
</PARA>

<PARA>
A short sample session looks like this:
<SCREEN>
<EMPHASIS>(start the transport agent)</>
#hungry                <EMPHASIS>--&gt; (TA to scheduler)</>
spoolid \t hostspec    <EMPHASIS>&lt;-- (scheduler to TA)</>
diagnostics            <EMPHASIS>--&gt; (TA to scheduler)</>
#hungry                <EMPHASIS>--&gt; (TA to scheduler)</>
...</SCREEN></PARA>

<PARA>
Normal diagnostic output is of the form:
<SCREEN>
  id / offset \t notarydata \t status message
</SCREEN>
where:
<VARIABLELIST>
<VARLISTENTRY><TERM>id</TERM><LISTITEM><PARA>
is the inode number of the message file,
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>offset</TERM><LISTITEM><PARA>
is a byte offset within its control file where the address
being  reported on  is kept,
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>notarydata</TERM><LISTITEM><PARA>
is a <EMPHASIS>Ctrl-A</> separated tuple is delivery-status-notification
information for  the message, 
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>status</TERM><LISTITEM><PARA>
is one of:<EMPHASIS>ok, ok2, ok3, error, error2, deferred, retryat</>
</PARA></LISTITEM></VARLISTENTRY>

<VARLISTENTRY><TERM>message</TERM><LISTITEM><PARA>
is descriptive text associated with the report.
The text is terminated by a linefeed.
</PARA></LISTITEM></VARLISTENTRY>
</VARIABLELIST></PARA>

<PARA>
Any other format (as might be produced by subprocesses) is passed
to standard output for logging in the scheduler log.
The <EMPHASIS>retryat</> response will assume the first word of the text
is a numeric parameter, either an incremental time in seconds if prefixed
by ``+'', or otherwise an absolute time in seconds since UNIX epoch.
</PARA>

<PARA>
The exit status is a code from
<FILENAME CLASS="HEADERFILE">&lt;sysexits.h&gt;</>.
</PARA>

</SECT1>


<SECT1><TITLE>Database File Formats</TITLE>



<SECT2><TITLE>Aliases File</TITLE>


<SCREEN>
  postmaster: root
  postoffice: root
  MAILER-DAEMON: root
  mailer:     postmaster
  postmast:   postmaster
  
  proto:  postmaster
  sync:   postmaster
  sys:    postmaster
  daemon: postmaster
  bin:    postmaster
  uucp:   postmaster
  ingress: postmaster
  audit:  postmaster

  autoanswer: "|@MAILBIN@/autoanswer.pl"

  nobody: /dev/null
  no-one: /dev/null
  junk-trap: /dev/null

  #test-gw: "|/..."
  #test.gw: "|/..."
</SCREEN>

<PARA>
Doing expansion lists in <APPLICATION>sendmail</>(8) style is not suggested,
although we certainly can do it.
There is a better mechanism in the ZMailer to handle simple feats like
these that <APPLICATION>sendmail</>(8) systems do by placing the file
containing recipient addresses into the directory 
<FILENAME CLASS="DIRECTORY">$<VARNAME>MAILVAR</>/lists/</>.
This directory must have protection of 2775 or stricter, and the listfile
must have protection of 664 or stricter for *-request/owner-*/*-owner
auto-aliases to work. &mdash; but to <APPLICATION>sendmail</> style lists:
<SCREEN>
  listname: "/usr/lib/sendmail -fowner-listname listname-dist"
  owner-listname: root # Well, what would you suggest for a sample ?
  listname-owner: owner-listname
  listname-request: root
  listname-dist: ":include:/dev/null"
</SCREEN>
</PARA>
</SECT2>
</SECT1>
</APPENDIX>
