RFC976 日本語訳

Network Working Group                                    Mark. R. Horton
Request for Comments: 976                              Bell Laboratories
                                                           February 1986

ワーキンググループのマークをネットワークでつないでください。 R。 コメントを求めるホートン要求: 976 ベル研究所1986年2月

                 UUCP Mail Interchange Format Standard

UUCPは置き換え形式規格を郵送します。

Status of This Memo

このメモの状態

   In response to the need for maintenance of current information about
   the status and progress of various projects in the ARPA-Internet
   community, this RFC is issued for the benefit of community members.
   The information contained in this document is accurate as of the date
   of publication, but is subject to change. Subsequent RFCs will
   reflect such changes.

状態に関する現行情報のメインテナンスとARPA-インターネットコミュニティでの様々なプロジェクトの進歩の必要性に対応して、このRFCは共同体のメンバーの利益のために発行されます。 本書では含まれた情報は、公表の日付現在、正確ですが、変化を被りやすいです。 その後のRFCsはそのような変化を反映するでしょう。

   This document defines the standard format for the transmission of
   mail messages between machines in the UUCP Project.  It does not
   address the format for storage of messages on one machine, nor the
   lower level transport mechanisms used to get the data from one
   machine to the next.  It represents a standard for conformance by
   hosts in the UUCP zone.  Distribution of this memo is unlimited.

このドキュメントはUUCP Projectのマシンの間のメール・メッセージの伝達のために標準書式を定義します。 それは移送機構が1台のマシンから次までデータを得るのに使用した1台のマシン、および下のレベルにおけるメッセージのストレージのために形式を扱いません。 それはUUCPゾーンにホストによる順応の規格を表します。 このメモの分配は無制限です。

1.  Introduction

1. 序論

   This document is intended to define the standard format for the
   transmission of mail messages between machines in the UUCP Project.
   It does not address the format for storage of messages on one
   machine, nor the lower level transport mechanisms used to get the
   data from one machine to the next.  We assume remote execution of the
   rmail command (or equivalent) as the UUCP network primitive
   operation.

このドキュメントがUUCP Projectのマシンの間のメール・メッセージの伝達のために標準書式を定義することを意図します。 それは移送機構が1台のマシンから次までデータを得るのに使用した1台のマシン、および下のレベルにおけるメッセージのストレージのために形式を扱いません。 UUCPが原始の操作をネットワークでつなぐとき、私たちはrmailコマンド(または、同等物)のリモート実行を仮定します。

   The general philosophy is that, if we were to invent a new standard,
   we would make ourselves incompatible with existing systems.  There
   are already too many (incompatible) standards in the world, resulting
   in ambiguities such as a!b@c.d which is parsed a!(b@c.d) in the old
   UUCP world, and (a!b)@c.d in the Internet world.  (Neither standard
   allows parentheses, and in adding them we would be compatible with
   neither.  There would also be serious problems with the shell and
   with the UUCP transport mechanism.)

一般的な哲学は私たちが新しい規格を発明するなら自分達を既存のシステムと非互換にするだろうということです。あまりに多くの(非互換)の規格が世界に既にあって、a!( b@c.d )は古いUUCP世界で分析されて、 a!b@c.d などのあいまいさをもたらして、どれがあるかは(a!b)@c.dはインターネットの世界で分析されました。 (どちらの規格も括弧を許容しません、そして、それらを加える際に、私たちはどちらも互換性があるでしょう。 また、シェルとUUCP移送機構には深刻な問題があるでしょう。)

   Having an established, well documented, and extensible family of
   standards already defined by the ARPA community, we choose to adopt
   these standards for the UUCP zone as well.  (The UUCP zone is that
   subset of the community connected by UUCP which chooses to register
   with the UUCP project.  It represents an administrative entity.)
   While the actual transport mechanism is up to the two hosts to
   arrange, and might include UUCP, SMTP, MMDF, or some other facility,
   we adopt RFC-920 (domains) and RFC-822 (mail format) as UUCP zone
   standards.  All mail transmitted between systems should conform to

ARPA共同体に規格の確立して、よく記録されて、広げることができるファミリーを既に定義させて、私たちは、また、UUCPゾーンのこれらの規格を採用するのを選びます。 (UUCPゾーンはUUCPプロジェクトとともに記名するのを選ぶUUCPによってつなげられた共同体のその部分集合です。 それは管理実体を表します。) 実際の移送機構は、アレンジする2人のホストまであって、UUCP、SMTP、MMDF、またはある他の施設を含むかもしれませんが、私たちはUUCPゾーン規格としてRFC-920(ドメイン)とRFC-822(メール書式)を採用します。 システムの間に伝えられたすべてのメールが従うべきです。

Horton                                                          [Page 1]

ホートン[1ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   those two standards.  In addition, should the ARPA community change
   these standards at a later time, we intend to change our standards to
   remain compatible with theirs, given a reasonable time to upgrade
   software.

それらの2つの規格。 さらに、ARPA共同体が後でこれらの規格を変えるなら、私たちは彼等のものと互換性があったままで残るために規格を変えるつもりです、ソフトウェアをアップグレードさせる妥当な時間を考えて。

   This document specifies an interpretation of RFC-822 and RFC-920 in
   the UUCP world.  It shows how the envelope should be encoded, and how
   UUCP routing is accomplished in an environment of mixed
   implementations.

このドキュメントはUUCP世界でRFC-822とRFC-920の解釈を指定します。 それは、封筒がどのようにコード化されるべきであるか、そして、UUCPルーティングが複雑な実装の環境でどのように達成されるかを示します。

2.  Basics

2. 基礎

   Messages can be divided into two parts: the envelope and the message.
   The envelope contains information needed by the mail transport
   services, and the message contains information useful to the sender
   and receiver.  The message is divided into the header and the body.
   Sometimes an intermediate host will add to the message (e.g. a
   Received line) but, except in the case of a gateway which must
   translate formats, it is not expected that intermediate hosts will
   change the message itself.  In the UUCP world, the envelope consists
   of the "destination addresses" (normally represented as the argument
   or arguments to the rmail command) and the "source path" (normally
   represented in one or more lines at the beginning of the message
   beginning either "From " or ">From ", sometimes called "From_
   lines".)  The RFC-822 header lines (including "From:" and "To:") are
   part of the message, as is the text of the message body itself.

メッセージを2つの部品に分割できます: 封筒とメッセージ。 封筒はメール輸送サービスで必要である情報を含んでいます、そして、メッセージは送付者と受信機の役に立つ情報を含んでいます。メッセージはヘッダーとボディーに分割されます。 時々、中間的ホストはメッセージ(例えば、Received系列)に加えるでしょうが、書式を翻訳しなければならないゲートウェイに関するケースを除いて、中間的ホストがメッセージ自体を変えないと予想されます。 UUCP世界では、封筒が「送付先アドレス」(rmailへの議論か議論が命令するように通常、表される)と「ソース道」から成る、(通常、メールの文頭の始めに1つ以上の系列で表される、「」 「>From」時々「_系列」と呼ばれて、 RFC-822ヘッダー系列(「From:」と「To:」を含んでいる)はメッセージの一部です、メッセージ本体自体のテキストのように。

   UUCP uses short host names, such as "ucbvax", at and below the
   transport layer.  We refer to these names as "6 letter names",
   because all implementations of UUCP consider at least the first 6
   letters significant.  (Some consider the first 7 or the first 14
   significant, but we must use the lowest common denominator.) UUCP
   names may be longer than 6 characters, but all such names much be
   unique in their first 6 letters.  RFC-920 domain names, such as
   "ucbvax.Berkeley.EDU", are called "domain names." The two names are
   different.  Upper and lower case are usually considered different in
   6 letter names, but are considered equivalent in domain names.  Names
   such as "ucbvax.UUCP", consisting of a 6 letter name followed by
   ".UUCP", previously were domain style references to a host with a
   given 6 letter name.  Such names are being phased out in favor of
   organizational domain names such as "ucbvax.Berkeley.EDU"

UUCPはトランスポート層において"ucbvax"などと、トランスポート層の下に短いホスト名を使用します。 私たちは「6つの音名」とこれらの名前を呼びます、UUCPのすべての実装が、少なくとも最初の6手紙が重要であると考えるので。 (或るものは、最初の7か最初の14がかなりであると考えますが、私たちは最小公分母を使用しなければなりません。) しかし、6より長いキャラクタ、そのようなすべての名前がそれらの最初の6個の手紙でユニークであったなら、UUCP名はそうするかもしれません。 "ucbvax.Berkeley.EDU"などのRFC-920ドメイン名は「ドメイン名」と呼ばれます。 2つの名前が異なっています。 上側の、そして、より低いケースは、6つの音名において異なると通常考えられますが、ドメイン名で同等であると考えられます。 以前に、".UUCP"によって従われた6手紙名から成る"ucbvax.UUCP"などの名前は与えられた6手紙名をもっているホストがドメインスタイル言及でした。 そのような名前は"ucbvax.Berkeley.EDU"などの属性型ドメイン名を支持して段階的に廃止されています。

Horton                                                          [Page 2]

ホートン[2ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

2.1  Hybrid Addresses

2.1 ハイブリッドアドレス

   There are (among others) two major kinds of mailing address syntax
   used in the UUCP world.  The a!b!c!user ("bang paths") is used by
   older UUCP software to explicitly route mail to the destination.  The
   user@domain ("domain") syntax is used in conformance to RFC-822.
   Under most circumstances, it is possible to look at a given address
   and determine which sort of address it is.  However, a hybrid address
   with a ! to the left of an @, such as a!b@c, is ambiguous: it could
   be interpreted as (a!b)@c.d or a!(b@c.d).  Both interpretations can
   be useful.  The first interpretation is required by RFC-822, the
   second is a de-facto standard in the UUCP software.

UUCP世界で使用されるアドレス構文を主要な2種類の郵送するのがあります(特に)。 a!b!c!ユーザ(「衝撃音経路」)は、より古いUUCPソフトウェアによって使用されて、明らかにメールを目的地に発送します。 user@domain (「ドメイン」)構文は順応にRFC-822に使用されます。 ほとんどの状況で、与えられたアドレスを見て、どの種類のアドレスを決定するかは可能です。 しかしながら、ハイブリッドが扱う、a!@の左に、 a!b@c としてのそのようなものはあいまいです: (a!b)@c.としてそれを解釈できました。dかa!( b@c.d 。) 両方の解釈は役に立つ場合があります。 最初の解釈はRFC-822によって必要とされて、2番目はUUCPソフトウェアのデファクト規格です。

   Because of the confusion surrounding hybrid addresses, we recommend
   that all transport layer software avoid the use of hybrid addresses
   at all times.  A pure bang syntax can be used to disambiguate, being
   written c.d!a!b in the first case above, and a!c.d!b in the second.
   We recommend that all implementations use this "bang domain" syntax
   unless they are sure of what is running on the next machine.

混乱の周辺のハイブリッドアドレスのために、私たちは、すべてのトランスポート層ソフトウェアがいつもハイブリッドアドレスの使用を避けることを勧めます。 純粋な衝撃音構文はあいまいさを除くのにおいて使用されている場合があります、書かれたc.d! a!最初のケース上のbと、a!c.d! 2番目のbであり。 私たちは、それらが次のマシンで動いていることが確かでない場合すべての実装がこの「衝撃音ドメイン」構文を使用することを勧めます。

   In conformance with RFC-822 and the AT&T Message Transfer
   Architecture, we recommand that any host that accepts hybrid
   addresses apply the (a!b)@c.d interpretation.

RFC-822とAT&T Message Transfer Architectureとの順応では、私たちは再指図します。ハイブリッドアドレスを受け入れるどんなホストも(a!b)@c.d解釈を適用します。

2.2  Transport

2.2 輸送

   Since SMTP is not available to much of the UUCP domain, we define the
   method to be used for "remote execution" based transport mechanisms.
   The command to be "remotely executed" should read

SMTPがUUCPドメインの大部分に利用可能でないので、私たちはベースの「リモート実行」移送機構に使用されるべきメソッドを定義します。「離れて実行されるべき」コマンドは読むべきです。

      rmail user@domain ...

rmail user@domain …

   with the message on the standard input of the command.  The
   "user@domain" argument must conform to RFC-920 and RFC-822.  More
   than one address argument is allowed, in order to save transmission
   costs for multiple recipients of the same message.

コマンドの標準の入力に関するメッセージで。 " user@domain "議論はRFC-920とRFC-822に従わなければなりません。 1つ以上のアドレス議論が、同じメッセージの複数の受取人のためにトランスミッションがコストであることを貯蓄するために許容されています。

   An alternative form that may be used is

使用されるかもしれない選択方式はそうです。

      rmail domain!user

rmailドメイン!ユーザ

   where "domain" contains at least one period and no !'s.  This is to
   be interpreted exactly the same as user@domain, and can be used to
   transport a message across old UUCP hosts without fear that they
   might change the address.  The "user" string can contain any
   characters except "@".  This character is forbidden because it is
   unknown what an intermediate host might do to it. (It is also

以上、そして、「ドメイン」が少なくとも1つを含むところでは、いいえ まさに user@domain として同じようにこれを解釈することになっています、そして、年取ったUUCPホストの向こう側に彼らがアドレスを変えるかもしれないという恐れなしでメッセージを輸送するのに使用できます。 「ユーザ」ストリングは"@"を除いたどんなキャラクタも含むことができます。 中間的ホストがそれに何をするかが、未知であるので、このキャラクタは禁じられます。 (また、それはそうです。

Horton                                                          [Page 3]

ホートン[3ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   recommended that the "%" character be avoided, since some hosts treat
   "%" as a synonym for "@".) However, to route across hosts that don't
   understand domains, the following is possible

何人かのホストが"@"のために「%」を同義語として扱うので、「%」キャラクタが避けられることを勧めました。) しかしながら、ホストの向こう側にそれを発送するには、ドメインを理解しないでください、そして、以下は可能です。

      rmail a!b!c!domain!user

rmail a b!c!ドメイン!ユーザ

   A "domain" can be distinguished from a 6 letter UUCP site name
   because a domain will contain at least one period.  (In the case of
   single level domains with no periods, a period should be added to the
   end, e.g. Mark.Horton@att becomes "att.!Mark.Horton".  A translator
   from ! to @ format should remove a trailing dot at the end of the
   domain, if one is present.) We don't expect this to happen, except
   for local networks using addresses like "user@host".

ドメインが少なくとも1回の期間を含むので、6手紙UUCPサイト名と「ドメイン」を区別できます。 (期間のないただ一つの平らなドメインの場合では、期間が終わりに加えられるべきであり、例えば、 Mark.Horton@att が「att Mark.Horton」になる、翻訳者、@に、形式はドメインの端で引きずっているドットを移すべきです、1つが存在しているなら) 私たちは、" user@host "のようなアドレスを使用する企業内情報通信網以外に、これが起こると予想しません。

   A simple implementation can always generate domain!user syntax
   (rather than user@domain) since it is safe to assume that gateways
   are class 3 (Classes are explained in section 3.5).

ゲートウェイがクラス3であると仮定するのが安全であるので(クラスはセクション3.5で説明されます)、簡単な実装はいつもドメイン!ユーザ構文( user@domain よりむしろ)を生成することができます。

2.3  Batch SMTP

2.3 バッチSMTP

   Standard conforming implementations may optionally support a protocol
   called "Batch SMTP".  SMTP (Simple Mail Transfer Protocol) is the
   ARPA community standard mail transfer protocol (RFC-821). It is also
   used on BITNET and Mailnet.  While SMTP was designed to be
   interactive, it is possible to batch up a series of commands and send
   them off to a remote machine for batch execution.  This is used on
   BITNET, and is appropriate for UUCP.  One advantage to BSMTP is that
   the UNIX shell does not get involved in the interpretation of
   messages, so it becomes possible to include special characters such
   as space and parentheses in electronic messages.  (Such characters
   are expected to be popular in X.400 addresses.)

標準の従う実装は任意に「バッチSMTP」と呼ばれるプロトコルをサポートするかもしれません。 SMTP(シンプルメールトランスファプロトコル)はARPA生活環境水準メール転送プロトコル(RFC-821)です。 また、それはBitnetとMailnetで使用されます。 SMTPはインタラクティブ、それが一連のコマンドでバッチに可能であるということであり、バッチ実行のためのリモートマシンにそれらを送るように設計されましたが。 これは、Bitnetの上で使用されて、UUCPに、適切です。 BSMTPの1つの利点はUNIXシェルがメッセージの解釈にかかわらないので電子メッセージにスペースや括弧などの特殊文字を含んでいるのが可能になるということです。 (そのようなキャラクタがX.400アドレスでポピュラーであると予想されます。)

   To support BSMTP on UNIX, a conforming host should arrange that mail
   to the user "b-smtp" is interpreted as Batch SMTP commands.  (We use
   b-smtp instead of bsmtp because bsmtp might conflict with a login
   name.) Since many mail systems treat lines consisting of a single
   period as an "end of file" flag, and since SMTP uses the period as a
   required end of file flag, and to strip off headers, we put an extra
   "#" at the beginning of each BSMTP line.  On a sendmail system, an
   easy way to implement this is to include the alias

UNIXの上でBSMTPをサポートするために、従っているホストはユーザ"b-smtp"にそのメールをアレンジするべきです。Batch SMTPコマンドとして、解釈されます。 (bsmtpがログイン名と衝突するかもしれないので、私たちはbsmtpの代わりにb-smtpを使用します。) 多くのメールシステムが「ファイルの終り」旗としてただ一つの期間から成る系列を扱って、SMTPが必要なファイルの終り旗と、ヘッダーの片に期間を費やすので、私たちはそれぞれのBSMTP系列の始めに付加的な「#」を置きます。 sendmailシステムの上では、これを実装する簡単な方法は別名を含むことです。

      b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"

b-smtp: "|egrep'^#'| 'sedのもの/^#//'| "/usr/lib/sendmail -bs"

   which will feed the commands to an SMTP interpreter.  A better
   solution would appropriately check for errors and send back an error
   message to the sender.

SMTPインタプリタにコマンドを提供するでしょう。 より良いソリューションは、適切にエラーを確認して、送付者にエラーメッセージを返送するでしょう。

Horton                                                          [Page 4]

ホートン[4ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   An example BSMTP message from seismo.CSS.GOV to cbosgd.ATT.COM is
   shown here.  This sample is the file shipped over the UUCP link for
   in put to the command "rmail b-smtp".  Note that the RFC- 822 message
   is between the DATA line and the period line.  The envelope
   information is passed in the MAIL FROM and RCPT TO lines.  The name
   of the sending system is in the HELO line.  The actual envelope
   information (above the # lines) is ignored and need not be present.

seismo.CSS.GOVからcbosgd.ATT.COMまでの例のBSMTPメッセージはここに示されます。 このサンプルはコマンド"rmail b-smtp"につけられたコネのためにUUCPリンクの上に出荷されたファイルです。 DATA系列と期間の系列の間には、RFC822メッセージがあることに注意してください。 封筒情報はMAIL FROMとRCPT TO系列で通過されます。 HELO系列には送付システムの名前があります。 実際の封筒情報(#系列を超えた)は、無視されて、存在している必要はありません。

      From foo!bar Sun Jan 12 23:59:00 1986 remote from seismo Date:
      Tue, 18 Feb 86 13:07:36 EST
      From: mark@ucbvax.Berkeley.EDU
      Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> To:
      b-smtp@cbosgd.ATT.COM

foo!から、seismo日付:からリモートな状態で1986年1月12日日曜日23時59分0秒を禁じてください。 火曜日、1986年2月18日の東部標準時13時7分36秒From: mark@ucbvax.Berkeley.EDU メッセージイド: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU>To: b-smtp@cbosgd.ATT.COM

      #HELO seismo.CSS.GOV
      #MAIL FROM:<mark@ucbvax.Berkeley.EDU>
      #RCPT TO:<mark@cbosgd.ATT.COM>
      #DATA
      #Date: Tue, 18 Feb 86 13:07:36 EST
      #From: mark@ucbvax.Berkeley.EDU
      #Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> #To:
      mark@cbosgd.ATT.COM
      #
      #This is a sample message.
      #.
      #QUIT

#HELO seismo.CSS.GOV#が FROM:<mark@ucbvax.Berkeley.EDU に郵送する、gt;、#RCPT TO:<mark@cbosgd.ATT.COM 、gt;、#データ#日付: 火曜日、1986年2月18日東部標準時13時7分36秒#From: mark@ucbvax.Berkeley.EDU #メッセージイド: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU>#To: mark@cbosgd.ATT.COM 、##これはサンプルメッセージです。 #. #やめてください。

2.4  Envelope

2.4 封筒

   The standard input of the command should begin with a single line

コマンドの標準の入力は単線で始まるべきです。

      From domain!user date remote from system

ドメイン!ユーザから、システムをリモートにさかのぼってください。

   followed immediately by the RFC-822 format headers and body of the
   message.  It is possible that there will be additional From_ lines
   preceding this line - these lines may be added, one line for each
   system the message passes through.  It is also possible that the
   "system" fields will be stacked into a single line, with many !'s in
   the "user" string.  The ">" character may precede the "From".  In
   general, this is the "envelope" information, and should follow the
   same conventions that previous UUCP mail has followed.  The primary
   difference is that, when the system names are stacked up, if
   previously the result would have been a!b!c!mysys!me, the new result
   will be a!b!c!mysys!domain!me, where domain will contain at least one
   period, and "mysys" is often the 6 letter UUCP name for the same

RFC-822形式ヘッダーとメッセージ欄はすぐに、支えます。 この系列に先行する追加From_系列があるのは、可能です--これらの系列は加えられるかもしれません、メッセージが通り抜ける各システムあたり1つの系列。 また、「システム」分野が単線に積み重ねられるのも、可能です、多くのものが「ユーザ」ストリングにある状態で。 ">"キャラクタは“From"に先行するかもしれません。 一般に、これは、「封筒」情報であり、前のUUCPメールが続いたのと同じコンベンションに続くべきです。 プライマリ違いはそれです、システム名が積み重ねられるとき、以前に結果がaであるなら!b!c!mysys!私、新しい結果はaになるでしょう!しばしばb!c!mysys!ドメイン!私、ドメインがどこに少なくとも1回の期間を含むだろうか、そして、および"mysys"は同じくらいのための6手紙UUCP名です。

Horton                                                          [Page 5]

ホートン[5ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   system named by "domain".  If the "domain!" is redundant, it may be
   omitted from the envelope, either in the source path or in the
   destination address.

「ドメイン」によって指定されたシステム。 「ドメイン!」が余分であるなら、それは封筒、ソース道または送付先アドレスで省略されるかもしれません。

   The receiving system may discard extra "From_" lines if it folds the
   information into a a single From_ line. It passes the
   path!domain!user along as the "envelope" information containing the
   address of the sender of the message, and possibly preserves the
   forwarding date and system in a newly generated header line, such as
   Received or Sent-By.  (Adding Received using this information is
   discouraged, since the line appears to have been added on a different
   system than the one actually adding it.  That other system may have
   actually included a Received line too! The Sent-By line is similar to
   Received, but the date need not be converted into RFC-822 format, and
   the line is not claimed to have been added by the system whose name
   is mentioned.)

_が立ち並んでいるという独身のFromへの情報を折り重ねるなら、受電方式は「_」付加的な系列を捨てるかもしれません。 それは、メッセージ送信者のアドレスを含む「封筒」情報としてドメイン!ユーザを経路にずっと向かわせて、ことによると新たに生成しているヘッダー系列で推進日付とシステムを保持します、Receivedや近くSentのように。 (この情報を使用することでReceivedを加えるのはお勧めできないです、系列が実際にそれを加えるものより異系統で加えられるように見えるので。 その他のシステムは実際にReceived系列も含んだかもしれません! 日付はRFC-822形式に変換される必要はありません、そして、近くSent系列はReceivedと同様ですが、台詞は名前が言及されるシステムによって加えられると主張されません。)

   If the receiving system passes the message along to another system,
   it will add a "From_" line to the front, giving the same user@domain
   address for the sender, and its own name for the system.  If the
   receiving system stores the message in a local mailbox, it is
   recommended that a single "From_" line be generated at the front of
   the message, keeping the date (in the same format, since certain mail
   reading programs are sensitive to this format), and not using the
   "remote from system" syntax.

受電方式が別のシステムにメッセージを伝えると、「_」系列を前部に加えるでしょう、送付者のための同じ user@domain アドレス、およびシステムのためのそれ自身の名前を与えて。 受電方式が地方のメールボックスの中のメッセージを保存するなら、「_」ただ一つの系列がメッセージの前部で生成されるのは、お勧めです、日付(同じ形式では、あるメール以来、読み込みプログラムはこの形式に機密である)を守って、「システムからリモート」構文を使用しないで。

   Note - if an intermediate system adds text such as "system!" to the
   front of a "user@domain" syntax address, either in the envelope or
   the body, this is a violation of this standard and of RFC-822.

注意--中間システムが" user@domain "構文アドレスの前部への「システム!」などのテキストを加えるなら、封筒かボディーでは、これはこの規格とRFC-822の違反です。

2.5  Routing

2.5 ルート設定

   In order to properly route mail, it is sometimes necessary to know
   what software a destination or intermediate machine is running, or
   what conventions it follows.  We have tried to minimize the amount of
   this information that is necessary, but the support of subdomains may
   require that different methods are used in different situations.  For
   purposes of predicting the behavior of other hosts, we divide hosts
   into three classes. These classes are:

適切にメールを発送するために、目的地か中間的マシンがどんなソフトウェアを動かしているか、そして、またはそれがどんなコンベンションに続くかを知るのが時々必要です。 私たちはこの必要な情報の量を最小にしようとしましたが、サブドメインのサポートは、異なったメソッドが異なった状況で使用されるのを必要とするかもしれません。 他のホストの振舞いを予測する目的のために、私たちはホストを3つのクラスに分割します。 これらのクラスは以下の通りです。

   Class 1   old-style UUCP ! routing only.  We assume that the host
             understands local user names:

クラス1古いスタイルUUCP!ルーティング専用。 私たちは、ホストがローカルのユーザ名を理解していると思います:

                  rmail user

rmailユーザ

Horton                                                          [Page 6]

ホートン[6ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

             and bang paths

そして、経路をどんとたたいてください。

                  rmail host1!host2!user

rmail host1!host2!ユーザ

             but we assume nothing more about the host.  If we have
             no information about a host, we can treat it as class 1
             with no problems, since we make no assumptions about
             how it will handle hybrid addresses.

しかし、私たちはホストに関してそれ以上何もを仮定します。 ホストの情報が全くないなら、私たちは問題なしでクラス1としてそれを扱うことができます、私たちがそれがどうハイブリッドアドレスを扱うかに関する仮定を全くしないので。

   Class 2   Old style UUCP ! routing, and 4.2BSD style domain
             parsing.  We assume the capabilities of class 1, plus
             the ability to understand

クラス2OldはUUCP!ルーティング、および4.2BSDスタイルドメイン構文解析を流行に合わせます。 私たちは、能力がクラス1と、そしゃく力であると思います。

                  rmail user@domain

rmail user@domain

             if the "domain" is one outside the UUCP zone which
             the host knows about.  Class 2 hosts do not necessarily
             understand domain!user or have routers.  Hosts in non-

「ドメイン」がホストが知っているUUCPゾーンの外の1であるなら。 クラス2のホストには、必ずドメイン!ユーザを理解しているというわけではないか、またはルータがあるというわけではありません。 中のホスト、非

             UUCP RFC-920 domains are considered class 2, even though
             they may not understand host!user.

彼らはホスト!ユーザを理解しないかもしれませんが、UUCP RFC-920ドメインはクラス2であると考えられます。

   Class 3   All class 1 and 2 features are present.  In addition,
             class 3 hosts must be able to route UUCP mail for hosts
             that are not immediately adjacent and also understand
             the syntax

クラス3Allクラス1と2機能は存在しています。 追加、3人のホストがそうしなければならないクラスでは、すぐに、隣接していなくて、また構文を理解しているホストへのUUCPメールを発送できてください。

                  rmail domain!user

rmailドメイン!ユーザ

             as described above.  All gateways into UUCP must be
             class 3.

上で説明されるように。 UUCPへのすべてのゲートウェイがクラス3であるに違いない。

   This document describes what class 3 hosts must be able to process.
   Classes 1 and 2 already exist, and will continue to exist for a long
   time, but are viewed as "older systems" that may eventually be
   upgraded to class 3 status.

このドキュメントは、クラス3のホストが何を処理できなければならないかを説明します。 クラス1と2は、既に存在していて、長い間存続しますが、結局クラスにアップグレードするかもしれない「より古いシステム」3状態として見なされます。

3.  Algorithm

3. アルゴリズム

   The algorithm for delivering a message to an address "user@domain"
   over UUCP links can be summarized as follows:

以下の通りUUCPリンクの上のアドレス" user@domain "に伝言をもたらすためのアルゴリズムをまとめることができます:

      a.  If the address is actually of the form @domain1:user@domain2,
          the "domain" used for the remainder should be "domain1"
          instead of "domain2", and the bang form reads
          domain1!domain2!user.

a。 アドレスが@domain1: 実際にフォーム user@domain2 のものであるなら、残りに使用される「ドメイン」がものであるべきである、「「フォームがdomain1!domain2!ユーザに読み込むdomain2"、および衝撃音」の代わりにdomain1"

Horton                                                          [Page 7]

ホートン[7ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

      b.  Determine d: the most specific part of "domain" that is
          recognized locally.  This part will be a suffix of "domain".
          This can be done by scanning through a table with entries that
          go from specific to general, comparing entries with "domain"
          to see if the entries are at the tail of "domain".  For
          example, with the address "mark@osgd.cb.att.com", if the local
          host recognizes "uucp" and "att.com", d would be "att.com".
          The final entry in the table will be the null string, matching
          any completely unrecognized domain.

b。 dを決定してください: 局所的に認識される「ドメイン」の最も特定の部分。 この部分は「ドメイン」の接尾語になるでしょう。 特定であるのから一般まで行くエントリーがあるテーブルを通してスキャンすることによって、これができます、エントリーが「ドメイン」のテールにあるかを確認するために「ドメイン」とエントリーを比べて。 例えば、アドレス" mark@osgd.cb.att.com "で、ローカル・ホストが"uucp"と"att.com"を認識するなら、dは"att.com"でしょう。 テーブルの最終記入はどんな完全に認識されていないドメインにも合っているヌルストリングになるでしょう。

      c.  Look in the found table entry for g: the name of the
          "gateway", and for r: a UUCP !-style route to reach g.  G is
          not necessarily directly connected to the local host, but
          should be viewed as a gateway into the d domain.  (The values
          of g and r for a given d may be different on different hosts,
          although g will often be the same.)

c。 見つけるところでgのためのテーブル項目を見てください: 「ゲートウェイ」、およびrのための名前: UUCPスタイル!はgを範囲に発送します。 Gは、必ず直接ローカル・ホストに接されるというわけではありませんが、ゲートウェイとしてdドメインに見なされるべきです。 (当然のことdのためのgとrの値は異なったホストで異なるかもしれません、gがしばしば同じになるでしょうが。)

      d.  Look at the beginning of r to find the "next hop" host n. N
          will always be directly connected to the local host.

d。 rの始めを見て、「次のホップ」がホストnであることがわかってください。 Nはいつも直接ローカル・ホストに接されるでしょう。

      e.  Determine, if possible, the class of g and n.

e。 できれば、gとnのクラスを決定してください。

      f.  Create an appropriate destination string s to be interpreted
          by n.  (See below.)

f。 適切な目的地ストリングsを作成して、nによって解釈されてください。 (以下を見てください。)

      g.  Pass the message off to n with destination information s.

g。 目的地情報sでnにメッセージをそらしてください。

      In an environment with other types of networks that do not use
      UUCP !  parsing, the table will probably contain additional
      information, such as which type of link to use.  The path
      information may be replaced in other environments by information
      specific to the network.

UUCP!構文解析を使用しない他のタイプのネットワークがある環境で、テーブルはたぶん追加情報を含むでしょう、どのタイプのリンクを使用するのなどように。 他の環境で経路情報をネットワークに特定の情報に取り替えるかもしれません。

      The first entries in the table mentioned in part (b) are normally
      very specific, and allow well known routes to be constructed
      directly instead of routing through the domain tree.  The domain
      tree should be reserved for cases where no better information is
      available, or where traffic is very light, or where the default
      route is the best available.  If a better route is available, that
      information can be put in the table.  If a host has any
      significant amount of traffic sent to a second host, it is
      normally expected that the two hosts will set up a direct UUCP
      link and make an entry in their tables to send mail directly, even
      if they are in separate domains.  Routing tables should be
      constructed to try to keep paths short and inexpensive for as much
      traffic as possible.

テーブルの初記入は、(b)が、通常、非常に特定であり、よく知られているルートが直接ドメイン木を通したルーティングの代わりに構成されるのを許容すると一部言及しました。 ドメイン木は、より良い情報がないのが利用可能であるか、トラフィックが非常に軽いか、デフォルトルートが利用可能な最善であるケースのために予約されるべきです。 より良いルートが利用可能であるなら、その情報をテーブルに入れることができます。 ホストがどんなかなりの量のトラフィックも2番目のホストに送らせるなら、通常、2人のホストがダイレクトUUCPリンクをセットアップして、直接メールを送るために彼らのテーブルに記帳すると予想されます、それらが別々のドメインにあっても。 経路指定テーブルは、できるだけ多くのトラフィックに短く安価に経路を保とうとするために組み立てられるべきです。

Horton                                                          [Page 8]

ホートン[8ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

      Here are some hints for the construction of the destination string
      n (step f above.) The "envelope recipient" information (the
      argument(s) to rmail) may be in either domain ! form
      (host.com!user) or domain @ form (user@host.com) as long as the
      sending site is sure the next hop is class 3.  If the next hop is
      not class 3, or the sending site is not sure, the ! form should be
      used, if possible, since it is hard to predict what the next hop
      would do with a hybrid address.

ここに、目的地ストリングnの構造のためのいくつかのヒントがあります(上のfを踏んでください。)。 「封筒受取人」情報(rmailへの議論)がどちらのドメインにもあるかもしれません!送付サイトが次のホップがクラス3であることを確信している限り、(host.com!ユーザ)かドメイン@フォーム( user@host.com )を形成してください。 次のホップがクラス3でない送付サイトが確かでないならフォームは使用されるべきです、できれば、次のホップがハイブリッドアドレスですることを予測しにくいので。

      If the gateway is known to be class 3, domain ! form may be used,
      but if the sending site is not sure, and the entire destination
      string was matched in the lookup (rather than some parent domain),
      the 6 letter ! form should be used: r!user, for example:
      dumbhost!host!user.  If the gateway appears to actually be a
      gateway for a subdomain, e.g. because a parent domain was matched,
      (such as the address user@host.gateway.com, where host.gateway.com
      was not found but gateway.com was) it can be assumed to be at
      class 3.  This allows routes such as
      dumbhost!domain!host.domain.com!user to be used with a reasonable
      degree of safety.  If a direct link exists to the destination
      host, the user@domain syntax or the domain!user syntax may be
      used.

送付サイトは確かではありません、そして、全体の目的地ストリングはルックアップ(何らかの親ドメインよりむしろ)で合わせられました、6手紙!ゲートウェイがクラス3であることが知られているなら、ドメイン!フォームは使用されるかもしれなくて、フォームが使用されるべきであるかどうかをそうされます: r!例えば、ユーザ、: dumbhost!ホスト!ユーザ。 例えば、親ドメインが合わせられたのでゲートウェイがサブドメインのための実際にゲートウェイであるように見えるなら、クラス3にあると思うことができます。 これは、dumbhost!ドメイン!host.domain.com!ユーザなどのルートが妥当な度合いの安全と共に使用されるのを許容します。 直リンクが存在しているなら、あて先ホスト、 user@domain 構文またはドメインに、ユーザ構文は使用されるかもしれません。

      All hosts conforming to this standard are class 3, and all
      subdomain gateways must be class 3 hosts.

この規格に従うすべてのホストがクラス3です、そして、すべてのサブドメインゲートウェイがクラス3のホストであるに違いありません。

4.  Example

4. 例

   Suppose host A.D.COM sends mail to host C.D.COM.  Let's suppose that
   the 6 letter names for these hosts are aname and dname, and that the
   intermediate host to be routed through has name bname.

ホストA.D. COMがホストC. D. COMにメールを送ると仮定してください。 これらのホストのための6つの音名がanameとdnameであり、発送される中間的ホストが名前bnameを持っていると思いましょう。

   The user on A types

Aのユーザはタイプします。

      mail user@c.d.com

メール user@c.d.com

   The user interface creates a file such as

ユーザーインタフェースはあれほど状態でファイルを作成します。

      Date:  9 Jan 1985   8:39 EST
      From: myname@A.D.COM (My Name)
      Subject: sample message
      To: user@c.d.com

日付: 1985年1月9日の東部標準時8時39分From: myname@A.D.COM (私の名前)Subject: サンプルメッセージTo: user@c.d.com

      This is a sample message

これはサンプルメッセージです。

   and passes it to the transport mechanism with a command such as

aがあるメカニズムが命令する輸送にそれを通過します。

Horton                                                          [Page 9]

ホートン[9ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

      sendmail user@c.d.com < file

sendmail user@c.d.com 、lt;、ファイル

   The transport mechanism looks up a route to c.d.com.  It does not
   find c.d.com in its database, so it looks up d.com, and finds that
   the path is bname!dname!%s, and that c.d.com is a class 3 host.
   Plugging in c.d.com!user, it gets the path bname!dname!c.d.com!user.
   (If it had found c.d.com with path bname!cname!%s, it would have
   omitted the domain from the resulting path: bname!cname!user, since
   it is not sure whether the destination host is class 1, 2, or 3.)

移送機構はc.d.comにルートを調べます。 それは、それがd.comを見上げて、データベースでc.d.がcomであることがわからないで、経路がbname!dname!%sであり、c.d.comが3が接待するクラスであることがわかります。 c.d.com!ユーザのプラグを差し込んで、それは経路bname!dname!c.d.com!ユーザを得ます。 (経路bname!cname!%sでc.d.がcomであることがわかったなら、結果として起こる経路: bname!cname!ユーザからドメインを省略したでしょうに、確実に、あて先ホストがクラス1、2、または3であるかどうかということでないので。)

   It prepends a From_ line and passes it to uux:

それは、From_系列をprependsして、それをuuxに通過します:

      uux - bname!rmail dname!c.d.com!user < file2

uux--bname!rmail dname!c.d.com!ユーザ<file2

   where file2 contains

file2が含むどこ

      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 message
      To: user@c.d.com

1985年1月9日水曜日12時43分35秒のA.D. COM!ユーザからリモートである、aname日付: 1985年1月9日の東部標準時8時39分From: myname@A.D.COM (私の名前)Subject: サンプルメッセージTo: user@c.d.com

      This is a sample message

これはサンプルメッセージです。

   (Note the blank line at the end of the message - at least one blank
   line is required.) This results in the command

(メッセージの終わりで空白行に注意してください--少なくとも1つの空白行が必要です。) これはコマンドをもたらします。

      rmail dname!c.d.com!user

rmail dname!c.d.com!ユーザ

   running on B.  B prepends its own from line and passes the mail
   along:

B.B prependsの上で作業して、系列とパスからのそれ自身は以下に沿ったメールです。

      uux - dname!rmail c.d.com!user < file3

uux--dname!rmail c.d.com!ユーザ<file3

   where file3 contains

file3が含むどこ

      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

aname日付:から1985年1月9日水曜日11時21分48秒のリモートな状態でbname>From A.D. COM!ユーザからリモートな1985年1月9日水曜日12時43分35秒をnuucpします。 1985年1月9日の東部標準時8時39分From: myname@A.D.COM (私の名前)Subject: サンプルメッセージTo: user@c.d.com

      This is a sample message

これはサンプルメッセージです。

Horton                                                         [Page 10]

ホートン[10ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   The command

コマンド

      rmail c.d.com!user

rmail c.d.com!ユーザ

   is run on C, which stacks the From_ lines

走行がCにありますか?(それは、From_系列を積み重ねます)。

      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

bname!aname!西暦のCOM!ユーザ、1985年1月9日水曜日12時43分35秒日付: 1985年1月9日の東部標準時8時39分From: myname@A.D.COM (私の名前)Subject: サンプルメッセージTo: user@c.d.com

      This is a sample message

これはサンプルメッセージです。

   and stores the message locally, probably in this same format.

そして、局所的で、たぶんこの同じことのメッセージがフォーマットする店。

5.  Summary

5. 概要

   Hosts conforming to this standard should accept all of the following
   forms:

この規格に従うホストは以下のフォームのすべてを受け入れるべきです:

      rmail localuser               (no !%@ in user)
      rmail hosta!hostb!user        (no !%@ in user)
      rmail user@domain             (only . in domain)
      rmail domain!user             (at least 1 . in domain)
      rmail domain.!user            (in case domain has no dots)

rmail localuser (no !%@ in user) rmail hosta!hostb!user (no !%@ in user) rmail user@domain (only . in domain) rmail domain!user (at least 1 . in domain) rmail domain.!user (ドメインにはドットが全くないといけないので)

   The "envelope" portion of the message ("From_" lines) should conform
   to existing conventions, using ! routing.  The "heading" portion of
   the message (the Word: lines such as Date:, From:, To:, and Subject:)
   must conform to RFC-822.  All header addresses must be in the @ form.
   The originating site should ensure that the addresses conform to
   RFC-822, since no requirement is placed on forwarding sites or
   gateways to transform addresses into legal RFC-822 format.  (Such
   forwarding sites and gateways should NOT, however, change a legal
   RFC-822 address such as user@domain into an illegal RFC-822 address
   such as gateway!user@domain, even if forwarding to a class 1 UUCP
   host.)

ルーティングを使用して、メッセージ(「_」は立ち並んでいる)の「封筒」部分は既存のコンベンションに従うべきです。 メッセージ(Word: 日付:や、From:や、To:や、Subject:などの線)の「見出し」部分はRFC-822に従わなければなりません。 すべてのヘッダーアドレスが@フォームにあるに違いありません。 送信側サイトは、アドレスがRFC-822に従うのを確実にするべきです、要件が全くアドレスを法的なRFC-822形式に変えるために推進サイトかゲートウェイに置かれないので。 (しかしながら、1人のUUCPホストをクラスに送っても、そのような推進サイトとゲートウェイは user@domain などの法的なRFC-822アドレスを gateway!user@domain などの不法なRFC-822アドレスに変えるはずがありません。)

6.  References

6. 参照

   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
        USC/Information Sciences Institute, August, 1982.

[1] ポステル、J.、「簡単なメール転送プロトコル」、RFC-821、科学が1982年8月に設けるUSC/情報。

   [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", RFC-822, Department of Electrical Engineering,
        University of Delaware, August, 1982.

[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC-822、電気工学の部、デラウエア大学(1982年8月)。

Horton                                                         [Page 11]

ホートン[11ページ]

RFC 976                                                    February 1986
UUCP Mail Interchange Format Standard

RFC976 1986年2月のUUCPメール置き換え形式規格

   [3]  Postel, J., and J. K. Reynolds, "Domain Requirements", RFC-920,
        USC/Information Sciences Institute, October, 1984.

[3] USC/情報科学が1984年10月に設けるポステル、J.とJ.K.レイノルズ、「ドメイン要求性」、RFC-920。

Horton                                                         [Page 12]

ホートン[12ページ]