Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: Anpengwang Anpengwang@263.net)
Translation time: 2001-5-24
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must
Keep the translation and copyright information of this document.
NetWork Working Group Mark. R. Horton
Request for Comments: 976 Bell Laboratories
February 1986
UUCP mail exchange format
(RFC976 UUCP MAIL Interchange Format Standard)
Memorandum state
In order to adapt to the current situation of the status and progress of the ARPA online different projects, special community members are released
This RFC. The content of this document is accurate as the date of the release is accurate, but the purpose is to further improve. Subsequent RFC
Will reflect these improvements.
This document defines the standard format of passing the mail message between the two machines in the UUCP project. This article does not involve a single platform
The storage format of the machine on the machine does not include a machine to get the underlying transmission mechanism of data from another machine. This article
The standards that should follow the host in the UUCP area. The distribution of this memorandum is not limited.
table of Contents
Introduction 1
2. Basis 2
2.1 Hybrid Addresses 2
2.2 Transmission 3
2.3 Batch SMTP 3
2.4 Envelope 4
2.5 Mail Routing 5
3. Algorithm 5
4. Example 6
5. Conclusion 7
6. Refer to 8
1 Introduction
The purpose of this article is to define the standard format of the transmitted message message between the host in the UUCP project, no discussion
The storage format on a machine does not involve a machine to obtain the underlying transmission mechanism of data from another machine. we
Assume that the remote execution of the RMAIL (or equivalent) command is the basic operation of the UUCP network.
One basic law is: If we try to invent a new standard, it is usually not compatible with existing systems. world
There is already too many (contradictory) standards, causing confusion, such as A !b@c.d, in accordance with the old UUCP standard
Released as A! (B@c.d), and in the world of Internet is (A! B) @ C.D. (Both standards do not support parentheses, otherwise
It can be compatible. The shell and UUCP transmission mechanism also have a serious problem).
The ARPA community has defined clear and scalable standard families with perfect documents, and we also choose these standards.
The should be used in the UUCP area. (UUCP zone is a subset of communities that use uucp connections and registration to UUCP projects, representatives
A management entity. Because the actual transmission mechanism depends on the arrangement of two hosts, UUCP, SMTP,
NMDF or other tools, we choose RFC920 (domain) and RFC822 (mail format) as the standard of the UUCP area
quasi. These two standards should be followed by mail transmission between all systems. In addition, if the ARPA community has changed him later
Our standards, we will also modify our standards to ensure compatible with it to provide a reasonable software upgrade time. This article details the explanation of RFC822 and RFC920 in the UUCP world, explaining how to encode envelope and
How to make UUCP search path in the hybrid realization environment.
2. Foundation
The message can be divided into two parts: envelope and message itself. Envelope includes information required by mail transport services, message packages
Includes information useful to the transceiver. The message is divided into the head and the main body. Sometimes the intermediate host changes the message (if added by Received)
Line), but unless the gateway needs to change the transmission format, the middle host generally does not modify the message itself. In the UUCP world,
Envelopes include "destination address" (usually behave as an RMAIL command) and "source address" (usually by the first line of the message)
Or initial lines, starting with "from" or "> from", also known as "from line"). RFC32 header
The line (including "from:" and "to:") as part of the message is the text of the message body itself.
UUCP uses a short mask name in the transportation layer and below, such as "UCBVAX". We put this short name "6 characters"
Name, because any UUCP is implemented at least the first six characters are valid. (Some put the top 7 or the first 14
The characters are considered valid, but we must use the lowest general standard. UUCP name can be longer than 6 characters, but before
6 must vary. The name of the RFC920 domain, such as "UCBVAX BERKELEY.EDU" called "Domain Name". These two names
It is different. Size is considered to be different for 6-character names, but it is considered to be the same for the domain name. 6-character name
Plus ".uucp", such as "Ubcvax.uucp" in the past as a reference to the domain format of the host using a 6-character name.
With the support of histological domain, such as "UCBVAX.BERKELRY.EDU", this type of name is gradually eliminated.
2.1 Hybrid Addresses
In the UUCP world mainly uses two email address syntax: "A! B! C! User" used by old uucp software (finished
The full path) format indicates the route that transmits the mail to the destination address; follow the RFC822 "User @ Domain" language
Law format. Most of the cases can determine the type of address according to a given address. But for @ 侧 侧 "" a! "
Mixed addresses, such as A! B @ c, there is confusion: that is, it can be interpreted as (a! B) @ C.D, or it can be interpreted as a! (B@c.d). This
Both explanations are meaningful, the former is used for RFC822, the latter is a factual standard for UUCP software.
Due to the confusion brought by the mixing address, we recommend that all transportation layer software should avoid using mixing at any time.
address. Purely complete address syntax can be used to clarify this confusion, the first explanation in the upper example can be written as "C.D! A! B",
The second explanation is written as "a! C.d! B". We recommend that all implementations use this "full domain" syntax unless they are indeed
Really know what to run on the next machine.
According to the RFC822 and AT & T messaging system, we recommend all hosts that allow the hybrid address to adopt (A! B) @ C.D
This explanation is explained.
2.2 Transmission
Because many UUCP domains do not support SMTP, we define the way "Remote Execution" in the transport mechanism.
basically. The command to "Remote Execute" should be read with its standard output information: Rmail User @ Domain .... parameter
User @ Domain must comply with RFC920 and RFC822. Allows multiple address parameters to send the same message
The transmission time can be saved when multiple recipients.
Another way is "Rmail Domain! User", "Domain" contains at least one comma and does not include "!". This representation can be accurately interpreted as user @ domain, which can transmit messages through old UUCP hosts without
The heart address is changed. The "User" string can contain any characters other than "@", which is forbidden to be because it is impossible
Determine how the middle host handles it. (It is also recommended to avoid using "%", some hosts will regard "%" as the synonym of "@"
word. However, if the transmission path contains hosts that do not understand the domain, the following format is possible:
Rmail a! b! c! Domain! User
The domain should include at least one comma, thus can be separated from the 6-character UUCP site name. (There are no functions in single-layer domain.
Point, you should add additional commodities at the end, such as Mark.horton@att, "att.! Mark.horton". Put! Format
The interpreter changed to @ format should delete the tail group - if any. We don't want such cases, unless
Local network uses addresses like User @ Host.
Simple application can only use the Domain! User syntax (not user @ Domian), because this way to 3
The gateway (see section 3.5) is also safe.
2.3 Batch SMTP
Compliance with standard implementations may choose to support a protocol called "batch SMTP". SMTP (simple mail
Transfer Protocol) is the standard mail transfer protocol of the ARPA community (RFC821), BitNet and Mailnet also use this association.
. Because SMTP is designed to interactively, make a series of commands to batch execution on wholesale to remote machines.
can. One advantage of BSMTP is that UNIX shell does not participate in the interpretation of the message, so that the electronic information can contain spaces.
And special characters such as parentheses (these characters will be very common in the X.400 address).
In order to make UNIX support BSMTP, the standard host should explain the user's mail command "B-SMTP" as
Batch SMTP (we use "B-SMTP" instead of "BSMTP" because the latter conflicts with a login name). because
Many mail systems handle the logo that contains a single functions as a "file tail", and SMTP uses a comma to use it as required
The file tail flag, in order to distinguish between the header, we add a special "#" in each row of BSMTP. Email
A simple way to achieve this in the system is to include the following alias:
B-SMTP: "| EGREP '^ #' | SED 'S / ^ # //' | / usr / lib / sendmail -bs"
This allows the command to the SMTP interpreter. Better solutions must also check the error and feed back the error message
Send a sender.
The following example illustrates a BSMTP message sent from Seismo.css.gov to cbosgd.att.com. This
An example is a file that is passed to the command "RMAIL B-SMTP" via the UUCP connection. Note RFC- 822 Message is located in DATA
Between the lines and teasings (the last line). Envelope information is passed in Mail from and RCPT TO. Transmission system
The name is in the Helo line. The actual envelope information (with "#" is overlooked, not necessarily
appear.
From foo! bar sun jan 12 23:59:00 1986 Remote from Seismo Date:
Tue, 18 Feb 86 13:07:36 EST
From: mark@sucbvax.berkeley.edu
Message-id: <8602181807.aa10228 @ mark @ ucbvax.berkeley.edu> to: b-smtp@cbosgd.att.com
#Helo seismo.css.gov
#Mail from:
#Rcpt to:
#Data
#Date: Tue, 18 Feb 86 13:07:36 EST
#From: mark@sucbvax.berkeley.edu
# Message-ID: <8602181807.AA10228 @ mark @ ucbvax.berkeley.edu> #to:
Mark@cbosgd.att.com
#
#This is a sample message.
#.
#Quit
2.4 Envelope (Envelope)
The standard input of the command should start with a separate line: from Domain! User Date Remote from system start, then
Tight the header and message main body with RFC822 format. There may be other from travels before this line - these lines
It can be increased, and each system will increase by the message. "System Field" may also be stacked into a single line,
"User" string contains many "!". "From" may have ">" characters in front of "FROM". Generally speaking, these "letters
The seal information should follow the same agreement as the old UUCP mail. The main difference is when the system name is compact writing
If the old way is A! B! C! Mysys! Me, new way of writing is changed to A! B! C! Mysys! Domain! ME, where "Domain"
At least one comma symbol is included, "MySys" is usually a 6-character uucp name called "Domain". in case
"Domain!" Is redundant, you can be omitted in the envelope - source path or destination address - omitted.
If you need to package the information into only one from line, the receiving system may drop the excess "from_" line.
It puts "Path! Domain! User" and "Envelope" - including the address of the message sender, may also generate a new one
For example, RECEIVED or SENT-BY, which saves forwarding date and forwarding system - send out together. (Not recommended
With Received, because such rows may be added to other systems before they really increase the row, while other systems
Universally, there may be a Received line. The Sent-BY line is similar to the ReceiveD line, but the date does not need to be changed.
The RFC822 format is not advocated to increase the row in advance by the system mentioned by the name. )
If the receiving system continues to forward the message to another system, it will add an from line in front, give
The same user @ domain address as the sender and adds its own system name. If the receiving system saves the message to the local letter
In the box, it is recommended to generate an from row and save the date before the message (using the same format, because some email reading
The reader is sensitive to this format) instead of using the "Remote from System" syntax format.
Note: If the intermediate system is in the User @ domain syntax format address - whether it is an envelope or a message body - before
Increase the text such as "System!", It does not meet this standard and RFC822 specification.
2.5 mail routing
In order to properly send emails, sometimes you need to understand what software has run or comply with the intermediate system.
What agrees. We used to try to minimize the amount of information, but support for subdomains may need to be in different bars.
Different methods are used under section. In order to predict the behavior of other systems, we divide the host into three categories. These three categories include: a class of only the old UUCP "!" Path. We envisage the host to understand the local username: "rmail user" and finished
The full path "Rmail Host1! Host2! User", but we don't make more assumptions for the host. If there is no about a certain
Any information on the host, we can use it as a first type of treatment without problems, because we are not right
It handles the hybrid address for any assumption.
The two-class old uucp "!" Path and 4.2BSD format domain parsing. We assume that in addition to having a class of hosts
Ok, you can also understand the "Rmail User @ domain", where "Domain" is located outside the UUCP area but the Lord
The machine can be identified. The second class host does not have to understand "Domain! User", nor does it require a router. Compliance with RFC920
The standard non-UUCP domain is considered a class two host, even if it is also possible to identify "Host! User".
The three categories have all the features of a class and two-class host. In addition, the three-class host can also send a remote host
UUCP mail and can understand the syntax "Ramil Domain! User as described above." All connected to uucp
The gateway must be a third class.
This document describes the features that the three types of hosts must have. One class and two-class host already exist and will continue to be quite
For a long period of time, it is considered "outdated system" and will eventually upgrade to the status of the 3-class host.
3. Algorithm
The algorithm for delivering messages via UUCP connection to address user @ domain can be overview:
a. If the actual format of the address is @ domain1: user @ Domain2, put "Domain1" instead of
"Domain2" is retained as "doamin", and the complete format is read as "Domain1! Domain2! User".
b. Determine the most clear part of the "Domain" that can be identified locally, record "D:", which should be
"Domain" suffix. This work can be done by scanning a table, and the entry is from special to one.
The sequential order, the comparison entry and "Domain" check whether the entry matches the tail of "Domain".
For example, for the address mark@osgd.cb.att.com, if the local host can identify "uucp" and "att.com",
Then D should be "att.com". The last item of the table is an empty string, which matches the domain that is completely unrecognized.
c. View basic table entry (FOUND TABLE Entry) looking for gateway name (g :) and UUCP to g! "
Path "R:". G does not have to be connected directly to the local host, but should be considered a gateway for connection domain D. (Correct
At a given D, G and R on different hosts may have different values, but g is usually the same)
d. Find "next hop" host N, N, which is always connected directly to the local host.
e. If you may determine the type of G and N.
f. Establish an appropriate target string S that can be explained (see below).
g. Pass the message and the target information S to N.
If the environment includes other types of networks that do not use uucp "!", There may be additional
Information, such as use. Path information may be replaced with special letters of that network in other environments
interest.
The first item in the table mentioned in the above second step (b) is generally very accurate, and the well-known path can be directly constructed.
No need to travel through the domain tree. The domain tree is only used for the following case: there is no more detailed information; the amount of information is small; the default
The path is the best choice. This information can be written in the table if there is a better path. If the host has a lot of information
Transfer to the second host, it is generally desirable to establish a direct UUCP connection between the two hosts and establish a corresponding entry to directly pass the message, even if the two hosts are in different domains. The construction of the path table should be the largest traffic
Keep the shortest and cheapest path.
Here is a number of tips for the structure of the target string n (the sixth step F). If the send site is determined, the next hop is
Three types of hosts, then "Envelope Recipient" information (RMail s parameters) can use domain "!" Format
(Host.com! User, you can also use the domain "@" format (user@host.com). If the next hop is not three types of hosts,
Or if you send a site that you can't be determined, you should use "!" Format as much as possible, because you can't predict how the next hop will process mixed
Match address.
If the known gateway is a third class, you can use the domain "!" Format, but if the send site cannot determine its type, or
The target string is completely matched (not with a parent domain), you should use 6 characters "!" Format "R! User",
Such as "Dumbhost! Host! User". If the gateway seems to be actually a gateway of a sub-domain, it matches a parent domain (eg
Address User@host.gateway.com, did not find host.gateway.com but found GATEWAY.com,
Assume it as a third class. This can be safely used in a certain extent
Dumbhost! domain! host.domain.com! User paths. If there is a direct connection to the target host, you can
Use User @ Domain or Domain! User two syntax formats.
The host that meets this standard is three types of hosts, and all sub-domain gateways must be three types of hosts.
4. Example
Suppose host a.d.com sends an email to host C. D.com. The 6-character names of the two hosts are aname
And DNAME, the middle host BNAME.
User input: mail user@c.d.com
The user interface generates a file and uses the command (such as sendmail user@c.d.com The contents of the document are as follows: Date: 9 Jan 1985 8:39 EST From: myname@a.d.com (my name) Subject: Sample Message To: user@c.d.com This is a name message The transmission mechanism finds the path to c.d.com, but did not find in the database; so looking for D.com, find its road The path is BName! DNAME!% S, and found that c.cd.com is three-class hosts. Then join C. D.COM! User, get a road Vault BNAME! DNAME! C. D.COM! User. (If the path of C. D.COM is found to be BName! CNAME!% S, result path BNAME! CNAME! The domain in User will be ignored because which type of target host is not confirmed. ) The transmission mechanism prepares an from line and passes it to UUX: UUX - BNAME! RMAIL DNAME! C. D.com! User < File2, file2 includes: From a.d.com! User Wed Jan 9 12:43:35 1985 Remote from aname date: 9 Jan 1985 8:39 EST From: myname@a.d.com (my name) Subject: Sample Messageto: User@c.d.com This is a name message (Note the empty line of the message tail - at least one blank line.) This will cause the b host execute command: Rmail DNAME! C. D.COM! USER. B Prepare its own from line and continue to forward mail: UUX - DNAME! RMAIL C. D.COM! User From nuucp Wed Jan 9 12:43:35 1985 Remote from Bname> from A. D.com! User Wed Jan 9 11:21:48 1985 Remote from Aname Date: 9 Jan 1985 8:39 EST From: myname@a.d.com (my name) Subject: Sample Message To: user@c.d.com This is a name message C Host execution command: rmail c.d.com! User and compress the FROM line, then save the message to the local - may Use the same format: From BName! Aname! A.d.com! User Wed Jan 9 12:43:35 1985 Date: 9 Jan 1985 8:39 EST From: myname@a.d.com (my name) Subject: Sample Message To: user@c.d.com This is a name message 5 Conclusion The host that meets this standard can accept all the formats: Rmail Localuser (excluding "!", "%", "@") Rmail Hosta! Hostb! User (User does not include "!", "%", "@") Rmail User @ domain (there is only a promise in the domain ".") Rmail Domain! User (at least one comma in the domain ".") Rmail Domain.! User (there is no dot in the domain) The envelope section of the message should follow the existing agreement to use the "!" Path. The head of the message (Word: Row, such as Date:, from:, to: and subject :) must comply with RFC822 specification. All the address must be @ formula. The original site should ensure that the address is in line with RFC822, and cannot require forwarding sites or gateways to convert the address into legitimate. RFC822 address. (The same forwarding site or gateway must not transform the legal RFC822 address user @ domain Compliance with the address of RFC822 Gateway! User @ Domain, even if you want to forward it to a Class of UUCP hosts. ) 6. Reference [1] Postel, J., "SIMPLE Mail Transfer Protocol", RFC-821, USC / INFORMATION SCIENCES Institute, August, 1982. [2] CROCKER, D., "Standard for the format of arpa internet text Messages, RFC-822, Department of Electrical Engineering, University of DelaWare, August, 1982. [3] Postel, J., And J. K. Reynolds, "Domain Requirements", RFC-920, USC / INFORMATION sciences Institute, October, 1984. RFC976 UUCP MAIL Interchange Format Standard UUCP Switching Format 1 RFC Document Chinese Translation Program
