zben@umd5.UUCP (09/10/85)
This is a companion article to my recently posted article on ARPA to BitNet
munging. It shows the reverse process - posting a message from a BitNet site
through the gateway to an ARPA recipient.
These are the rules for the BitNet gateway to which I talk and which is
assumed for this example:
The user mail agent (mail program) sends one copy of the message to the
mailer virtual machine on his host. After syntax checking, it in turn
sends one copy of the message to the mailer virtual machine at EACH site.
If two or more users were named at the same site, only ONE copy of the
message is sent to the mailer virtual machine at that site.
The sending is point-to-point within BitNet and is mediated by the RSCS
system, atop which BitNet mail is built, in the same fashion that UUCP
mail is built atop the UUCP/UUX network.
When the mailer virtual machine at a site gets mail from a mailer virtual
machine at another site, it examines the HEADER fields (yuck!) and sends a
copy on to each local user named. It utterly ignores addresses that name
other machines (as the originating mailer sent those separately).
Technical terms:
MUNGE - The act of translation of the syntax and semantics of the fields of
the headers of messages passed across domain boundaries. The aim of
this translation is to make the header comprehensible to mail agents
in the new (destination) domain.
OOBS - This refers to the SMTP out-of-band information that is NOT a part
of the message header at all, but is passed from sending host to
receiving host as part of the SMTP mail interaction.
OURNAME - Any of the various names for the site that is actually running this
software. This includes the primary (official) name and all defined
alias or NIC names.
TO* - Any of the header fields which carry "To:" semantic information.
In my implementation these are: To:, CC:, BCC:, Resent-To:,
Resent-CC:, and Resent-BCC: fields.
The example is the sending of a message from MARY at site SCHOOL to several
people on both ARPA and BitNet. To set the stage, the hypothetical network
configuration is shown here in diagram form.
::
(--------) --------- :: (---------)
( BILL )----| OTHER | ARPA :: BitNet ( MARY )
(--------) --------- domain :: domain (---------)
| :: |
| :: |
(--------) --------- -------- -----------
( BEN )----| ORIG |------------------| HERE |--------| SCHOOL |
(--------) --------- -------- -----------
| :: |
| :: |
(--------) --------- :: (---------)
( MYBOSS )----| ADMIN | :: ( HERBOSS )
(--------) --------- :: (---------)
::
Figure 1: Hypothetical configuration for munging example
---------
Hypothetical commands to mail sending agent at SCHOOL:
send HERBOSS@SCHOOL BEN%ORIG@HERE BILL%OTHER@HERE
Mail sending agent on SCHOOL generates header:
FROM: <MARY@SCHOOL>
TO: <HERBOSS@SCHOOL>, <BEN%ORIG@HERE>, <BILL%OTHER@HERE>
At HERE.ARPA the munging actually gets done. Since there is no out-of-band
information, we must examine the TO* fields of the header.
(1) HERBOSS@SCHOOL
(2) BEN%ORIG@HERE
(3) BILL%OTHER@HERE
(1). As the address is NOT headed by an OURNAME, we do not attempt to
implement the send. The mailer at SCHOOL actually spooled another
copy of the message directly to OURBOSS.
(2). Address is headed by OURNAME "HERE". We implement this send.
(3). Address is headed by OURNAME "HERE". We implement this send.
OUTPUT HEADER (note)
FROM: <@HERE.ARPA:MARY@SCHOOL.BITNET> (i)
TO: <@HERE.ARPA:HERBOSS@SCHOOL.BITNET>, (ii)
<BEN@ORIG.ARPA>, (iii)
<BILL@OTHER.ARPA> (iii)
OUTPUT OUT-OF-BAND INFORMATION
MAIL FROM: <@HERE.ARPA:MARY@SCHOOL.BITNET> (i)
RCPT TO: <BEN@ORIG.ARPA> (iii)
RCPT TO: <BILL@OTHER.ARPA> (iii)
NOTES
(i) FROM: address is rewritten to ARPA syntax, and OURNAME is added.
This also becomes the SMTP OOB return-path information.
(ii) Address is rewritten to ARPA syntax and OURNAME is added. As there
was no leading OURNAME, this address is NOT materialized into an
SMTP OOBS address.
(iii) Address is rewritten to ARPA syntax and OURNAME is REMOVED. As
there WAS a leading OURNAME, this address also becomes part of the
SMTP OOBS information.
Note that this is an incomplete implementation. The version of this software
I am installing tomorrow has an added enhancement. It first looks for a
SENDER: field in the message, if one is found then the SMTP OOB return-path
is taken from the SENDER: field. If no SENDER: field is found, then it
reverts to looking in the FROM: field for this information.
Most of the mail gateway code was developed in this same incremental fashion.
The implementation is not at all polished, full of ad-hoc patches, and clearly
nowhere near a final state. However, this information should give you some of
the concepts and issues involved in mail gateways and header munging.
REFERENCES:
"Simple Mail Transfer Protocol",
Johnathan B. Postel, ARPA RFC 821
"Standard for the Format of Arpa Internet Text Messages",
David H. Crocker, ARPA RFC 822
"Proposed Standard for Message Header Munging",
Marshall T. Rose, ARPA RFC 886
ACKNOWLEGEMENTS:
The author would like to credit Hans Breitenlohner for his modifications to
the Sperry RTP system, which implement physical transfer for messages in a
reasonable way (i.e. *I* don't have to do the EBCDIC-ASCII translation :-),
and to credit Bruce Crabill with the modifications to IBM RSCS to allow the
Sperry mainframe (read Remote Hasp Workstation) to participate in the RSCS
network.
-zben
Ben Cranston <ZBEN@UMD2.ARPA>
<ZBEN@UMDC.BITNET>
<ZBEN@UMD5.UUCP>
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA