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. +----+ +====> | MM | +-------------+ +--------+ +---------+ | +=== | | ==> | Queued mail | | | ==> | network | | | +----+ | disk files | <=== | MMailr | +---------+ | | +--------+ | with some | ===> | | | | | MAISER | =>| fixed name | | | +---------------+ | | +--------+ +-------------+ | | ==> | local mailbox | | | | | +---------------+ | | +----------+ | | | +=======> | MMailbox | <============ | | +---------------+ +========== | | ============> | | ==> | other 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 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 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.