Network Working Group Mark Crispin (PANDA PROGRAMMING)
Request for Comments rrr March 1985
INTRODUCTION
This document describes the format of queued mail between a
mail composition process on the TOPS-20 operating system and
MMailr, the TOPS-20 mail delivery process. Furthermore, it
describes the interfaces used by MMailbox, the mailbox
lookup/validition tool and the various mailsystem modules which
invoke it.
A simple model of a mailsystem conforming to this
specification is presented below. For simplicity's sake, I will
use the following program names as generic terms: MM refers to
any user mail composition process, MMailr refers to the mail
delivery process, MMailbox refers to the mailbox database, and
MAISER refers to a mail server for some network.
There are, of course, other modules and paths which I have
chosen to omit. In the interests of space, other mail
composition processes (e.g. Hermes) were omitted, as were the
disk files used by MMailbox and the myriad possibilities for
networks. The picky might also claim that there should be a path
between MAISER and the networks.
The more interesting question is why there is no path
between MAISER and MMailbox. This was to demonstrate a point. I
consider MAISER to be a "mail composition" process, with the
"user" being some mail delivery agent at another entity over some
network. As such, it really should be the same box as MM. It
is, however, totally optional for a mail composition process to
validate mailboxes with MMailbox. When MMailr processes a queued
message, it will validate the mailboxes itself with MMailbox, and
if the validation fails it will "return to sender". It is
therefore not unreasonable for MAISER to accept all incoming mail
and let MMailr do the work. A local mail composition process
with a real user on it may want to validate addresses so the user
is given immediate warning about misspellings. Neither scheme is
explicitly required by the model, and it is left up to the
implementor and the site to decide which scheme fits their
environment best. There are advantages and disadvantages to
both.
Since MMailr implements a "return to sender" functionality,
the mail delivery process itself has a mailbox (MAILER). At
times messages may end up going to MAILER; for example, failed
mail where the sender could not be determined or where the
returned message itself is returned as undeliverable. Because of
this, MAILER as a destination mailbox typically goes to some
human "postmaster" who will try to make sense of what happened
and notify the appropriate people. The function of a
"postmaster" becomes especially important in the model where some
mail composition process accepts mail without validation and so
unvalidated mail enters the mailer queues.
THE INTERFACE
The name of a new queued mail file being written by a mail
composition process is
MAILQ:[--QUEUED-MAIL--].NEW-ddddddtttttt-nnnnnn-Jjj.-1;P770000
where ddddddtttttt is the value returned by the GTAD% JSYS in
octal, nnnnnn is the name of the originating process, and jj is
the job number of the originating process. This name is selected
to guarantee name uniqueness, which is required when multiple
simultaneous processes are writing to the same directory with
similar file names. Additional fields are permissible; e.g. a
multi-process mail server program may want to add -Fff at the end
where ff is the relative fork number of the process writing the
job. The -1 generation number is a last guarantee of uniqueness
(note that due to deficiencies in the TOPS-20 monitor -1 is not
adequate in itself to guarantee uniqueness by multiple versions
when, say, the extension is null). The ;P770000 simply
guarantees privacy of queued mail. For example, a queued mail
file actually created by the SMTP server at Score was:
MAILQ:[--QUEUED-MAIL--].NEW-130566732316-MAISER-J16.1
The -1 when specifying the name to GTJFN% became generation 1 on
the disk.
All other extensions are presently reserved by MMailr for
its internal purposes. As of this writing, the NETWORK extension
is used by the mailer to handle new queue requests with network
recepients, and the RETRANSMIT extension is used for mail which
could not be delivered immediately and has been requeued. As a
matter of fact, the actual extension used by MMailr for looking
at new queued requests is NEW*, but following the convention
listed above is required to avoid possible conflicts.
The MAILQ: logical name points to a system-wide directory
for queued mail to reside. If MAILQ: is not defined, then queued
mail should be written on the user's login directory and the
corresponding bit set in MAIL:MAILER.FLAGS. This bit is
determined by treating this file as a bit vector numbering from
the highest order bit in each word down; the bit number to be set
corresponds to the right half of the user's user number. For
example, user number 500000,,50 would translate into bit 50
octal, 40 decimal, which would be bit 4 (1B4) in the second word
of the file. The MAILER.FLAGS functionality is NOT supported and
may be removed without notice at any time.
The general structure of these files is a (possibly empty)
series of keyword lines, followed by some destination
specifications, followed by (possibly empty) data. ASCII
formfeed (014 octal, referred to as <FF> or ^L below) is used as
a mark delimiting various elements of the message envelope. All
lines are terminated with an ASCII carriage-return line feed
sequence (015 012 octal, referred to as <CRLF> below).
Keyword lines are indicated by an equals sign (=, 075 octal)
immediately following the form feed. Following this indicator is
the keyword name. If any arguments are present, a colon (:, 072
octal) follows the keyword name and then the arguments appear.
Unless explicitly stated below, if a keyword accepts arguments
then those arguments are required.
The following keywords and arguments are defined. Note that
all references to domains should also be interpreted as including
the traditional ARPANET-style host names. This is to help
software and humans which haven't adapted to the brave new world
of domains yet.
Keyword name Arguments
------------ ---------
AFTER date-and-time
This keyword indicates the first time at which to attempt to
transmit this message. This is used to have messages which
are intentionally delayed, such as "reminders".
DEQUEUE date-and-time
This keyboard specifies the time at which the queue request
will be removed from the queue and returned as undeliverable
if there are still any pending receipts. Normally, this is
set by the mailer, which establishes the dequeue time as a
site-selectable time subsequent to the initial queueing (this
is three days as distributed).
DELIVERY-OPTIONS [MAIL/SEND/SOML/SAML]
This keyword specifies the type of service of this message.
If not specified MAIL is assumed. In outgoing SMTP
negotiations the mailer will attempt to use the specified
delivery option, but if the SMTP receiver does not support
that option the mailer will attempt it again using MAIL.
Not implemented yet: if one of the sending options is
specified and the recepient is local, the message is delivered
to the user's terminal rather than in a mail file.
DISCARD-ON-ERROR
If this keyword is specified then no attempt is made to
notify the sender if the message is undeliverable; instead
the message is discarded silently. This is used by the
mailer for its notifications, which periodically get bounced
back due to a bogus sender address specified by the sender.
NOTIFY date-and-time
This keyword specifies the next time at which the sender of
the message is notified if delivery is still pending. Once a
notification has been made, subsequent notifications are sent
at one-day intervals until the dequeue time. Normally, this
keyword is set by the mailer, which establishes the notify
time as one day subsequent to the initial queueing.
NET-MAIL-FROM-HOST domain-host-name-string
This keyword specifies the remote host that invoked the
network server. It is used by the mail delivery process
as part of its return address computation when a Return-Path
is not available. It also provides some level of
authentication for mail, at least to authenticate the origin
of a message.
This keyword is for the exclusive use of the SMTP server and
must NOT be provided by user programs. It is documented here
only for completeness.
Examples:
^L=NET-MAIL-FROM-HOST:SU-SCORE
^L=NET-MAIL-FROM-HOST:F.ISI.ARPA
RETURN-PATH domain-return-path-string
This keyword specifies the return path, as given by the SMTP
user process. It is used by the mail delivery process as an
address to send delivery failure reports to; it also is used
in figuring out the return path for any mail the mail delivery
process must relay to another site.
This keyword is for the exclusive use of the SMTP server and
must NOT be provided by user programs. It is documented here
only for completeness.
A destination specification is a group of lines where the first
line is "^L domain-host-name-string-path", and the subsequent lines
are simply the user part of the mailboxes at that destination.
A domain-host-name-string-path, is a sequence of
domain-host-name-string's separated by commas.
