The server next extracts the second entry in the recipient-route
field of the MRCP command and resolves its address relative to the
domain established by the first entry.  If the second entry specifies
an explicit domain, then that overrides the first entry.  If not and
the first entry specifies a domain, then that domain is effective.
However, if the first entry specifies the server's host, it may not be
apparent which domain is intended.  For instance, consider the
following two MRCP commands:
 
Internet Name Domains                               PAGE   5



MRCP to:<@COMSAT,Mills@HOST> and 
MRCP to:<@INTELPOST,Mills@HOST> ,

where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct
mailboxes on different hosts.  A receiving host supporting forwarders
for both COMSAT and INTELPOST can then preserve this distinction and
forward correctly using the above rules.

     Now let the forwarder host have the name FORWARDER in both the
COMSAT and INTELPOST domains and consider its options when receiving
the command

MRCP to:<@FORWARDER,Mills@HOST> .

The forwarder is being asked simply to relay within the domain of the
sender; however, it belongs to more than one domain! The obvious way
to resolve this issue would be to forbid the use of implicit domains,
as represented by Mills@HOST, and require the full internet mailbox
names Mills.HOST@COMSAT or Mills.HOST@INTELPOST.  It is also possible
to dis-ambiguate the domain by inspecting the first entry of the
sender-route field of the MAIL command (see below).

6.  Source and Return Routing

     In the RFC-780 model, routes can be specified in the
recipient-route field of the MRCP command and in the sender-route
field of the MAIL command.  In point of fact, neither the
recipient-route or sender-route is necessary if the originator
specifies standard internet mailbox names.  So long as the routes,
when used, consist only of domain names, there is no conflict with the
current RFC-780 specification.  If for some reason forwarding must be
done via other hosts, then the use of a complete and unambigous syntax
like .@ is required in order to avoid problems like that
described above.

     The present RFC-780 specification requires the receiver to
construct a name for the sender and insert this at the beginning of
the sender-route.  Presumably, the only information it has to
construct this name is the internet address of the sender.  Consider
the case, as in the example above, where multiple domains are
supported by a single server on a particular host.  If hosts receiving
a message relayed via that server were to map its address into a name,
there would be no way to determine which domain was intended.  We
conclude that the sending host must update the sender-route as well as
the recipient-route.  It does this simply by copying the first entry
in the recipient-route as received as the new first entry in the
sender-route.
 
Internet Name Domains                               PAGE   6



7.  Editing the RFC-733 Header

     Every effort should be made to avoid editing the RFC-733 header,
since this is an invasive procedure requiring extensive analysis.  It
is expected that newly developed mail systems will be aware of the
standard internet mailbox syntax and ensure its use everywhere in the
RFC-733 and RFC-780 fields.  On the occasions where this is not
possible, such as in many current ARPANET hosts, the necessary editing
should be performed upon first entry to the internet mail system from
the local mail system.  This avoids the problems mentioned above and
simplifies reply functions.

     In the case of ARPANET hosts, the editing operations assume that
all names in the form @, where  is the name
of a domain, are unchanged.  Names in the form @,
where  is the name of a host in the ARPA domain, are transformed
to the form .@ARPA.  Anything else is an error.
Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder
might optionally transform .@ARPA to @
in order to reduce the forwarder traffic when local mail systems are
available.  Similar situations might exist elsewhere.

8.  Concluding Remarks

     This memorandum is intended to stimulate discussion, not simulate
it. 
-------