RFC1429 日本語訳

Network Working Group                                          E. Thomas
Request for Comments: 1429                    Swedish University Network
                                                           February 1993

コメントを求めるワーキンググループE.トーマスの要求をネットワークでつないでください: 1429 スウェーデンの大学ネットワーク1993年2月

                      Listserv Distribute Protocol

リストサーブはプロトコルを分配します。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo specifies a subset of the distribution protocol used by the
   BITNET LISTSERV to deliver mail messages to large amounts of
   recipients.  This protocol, known as DISTRIBUTE, optimizes the
   distribution by sending a single copy of the message over heavily
   loaded links, insofar as topological information is available to
   guide such decisions, and reduces the average turnaround time for
   large mailing lists to 5-15 minutes on the average. This memo
   describes a simple interface allowing non-BITNET mailing list
   exploders (or other bulk-delivery scripts) to take advantage of this
   service by letting the BITNET distribution network take care of the
   delivery.

このメモはBitnetリストサーブによって使用される、多量の受取人にメール・メッセージを送る分配プロトコルの部分集合を指定します。 DISTRIBUTEとして知られているこのプロトコルは大いに積み込まれたリンクの上にメッセージのただ一つのコピーを送ることによって、分配を最適化します、位相的な情報が平均してそのような決定を誘導するために利用可能であり、大きいメーリングリストのために平均したターンアラウンドタイムを5-15分まで減少させる限り。 このメモはBitnet流通機構に配送の世話をさせることによって非Bitnetメーリングリスト発破器(または、他の大量の配送スクリプト)がこのサービスを利用できる簡単なインタフェースについて説明します。

Introduction

序論

   Running a mailing list of 1,000 subscribers or more with plain
   "sendmail" while keeping turnaround time to a reasonable level is no
   easy task. Due mostly to its limited bandwidth in the mid-80's,
   BITNET has developed an efficient bulk delivery protocol for its
   mailing lists. Originally introduced in 1986, this protocol was
   refined little by little and now carries 2-6 million mail messages a
   day. In fact, this distribution mechanism implements a general-
   purpose delivery service which can be used by any user of BITNET or
   the Internet. Thus, a simple solution to the "sendmail" turnaround
   problem is to wrap the message and recipient list in a DISTRIBUTE
   envelope and pass it to a BITNET server for delivery.  This may not
   be the best possible solution, but it has the advantage of being easy
   to implement.

ターンアラウンドタイムを妥当な水準に保っている間、明瞭な"sendmail"で1,000人以上の加入者のメーリングリストを走らせるのは、楽な仕事ではありません。 ほとんど80年代の半ばにおける限られた帯域幅に当然です、Bitnetはメーリングリストのために効率的な大量の配送プロトコルを開発しました。 1986年に元々導入していて、このプロトコルは、少しずつ洗練されて、今、1日あたり2-600万のメール・メッセージを運びます。 事実上、この分配メカニズムはBitnetかインターネットのどんなユーザも使用できる一般的な目的デリバリ・サービスを実行します。 したがって、"sendmail"ターンアラウンド問題の簡単な解決は、DISTRIBUTE封筒でメッセージと受取人リストを包装して、配送のためのBitnetサーバにそれを通過することです。 これは可能な限り良い解決策でないかもしれませんが、それには、実行するのが簡単であることの利点があります。

   In this document we will use the term "production" to refer to the
   normal operation of the mailing list (or bulk delivery application)
   you want to pipe through the DISTRIBUTE service. That is, the
   "production" options are those you should specify once everything is
   tested and you are confident that the setup is working to your

本書では私たちは、DISTRIBUTEサービスで運ぶあなたが欲しいメーリングリスト(または、大量の配送アプリケーション)の通常の操作について言及するのに「生産」という用語を使用するつもりです。 すなわち、「生産」オプションがすべてがいったんテストされるとあなたが指定するべきであり、セットアップが働くと確信しているそれらである、あなた

Thomas                                                          [Page 1]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[1ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

   satisfaction. In contrast, "test" and "debug" options can be used to
   experiment with the protocol but should not be used for normal
   operation because of the additional bandwidth and CPU time required
   to generate the various informational reports.

満足。 対照的に、「テスト」と「デバッグ」オプションはプロトコルを実験するのに使用できますが、追加帯域幅のために通常の操作に使用するべきではありません、そして、CPU時間が様々な情報のレポートを作るのが必要です。

   Finally, it should be noted that the DISTRIBUTE protocol was
   developed to address a number of issues, some of them relevant only
   to BITNET, and has evolved since 1986 while keeping a compatible
   syntax. For the sake of brevity, this RFC describes only a small
   subset of the available options and syntax. This is why the syntax
   may appear unnecessarily complicated or even illogical.

最終的に、コンパチブル構文を保っている間、DISTRIBUTEプロトコルが多くの問題を記述するために開発されて、1986年以来発展していることに注意されるべきです。それらのいくつかが問題のためにBitnetだけに関連しています。 簡潔にするために、このRFCは利用可能なオプションと構文の小さい部分集合だけについて説明します。 これは構文が不必要に複雑であるか不合理にさえ見えるかもしれない理由です。

1. Selecting an entry point into the DISTRIBUTE backbone

1. DISTRIBUTE背骨にエントリー・ポイントを選択します。

   The first thing you have to do is to find a suitable site to submit
   your distributions to. For testing, and for testing ONLY, you can
   use:

あなたの配を提出する適当なサイトを見つけるために、あなたがしなければならない最初のことはあります。 テストして、テストするだけために、あなたは以下を使用できます。

                         LISTSERV@SEARN.SUNET.SE

LISTSERV@SEARN.SUNET.SE

   For production use, however, you should select a DISTRIBUTE site in
   your topological vicinity: it would make no sense to pass your
   distributions from California to a server in Sweden if most of your
   recipients are in the US. If your organization is connected to BITNET
   and your BITNET system is part of the DISTRIBUTE backbone, this ought
   to be your best bet. Otherwise you will want to contact someone
   knowledgeable about BITNET (or the author of this RFC if you have no
   BITNET users). Make sure to run through the following checklist
   before sending any production traffic to the site in question:

しかしながら、生産使用のために、あなたはあなたの位相的な接近のDISTRIBUTEサイトを選択するべきです: あなたの受取人の大部分が米国にあるなら、それはスウェーデンでのあなたのカリフォルニアからサーバまでの配を通過する意味に全くならないでしょう。 あなたの組織がBitnetに接続されて、あなたのBitnetシステムがDISTRIBUTE背骨の一部であるなら、これはあなたの最善の策であるべきです。 さもなければ、あなたはBitnetに関して博識なだれかに連絡したくなるでしょう(このRFCの作者には、Bitnetユーザが全くあなたであるならいません)。 どんな生産交通も問題のサイトに送る前に、以下のチェックリストについて必ずざっと調べてください:

   a. Do you have good connectivity to the host in question? Does the
      host, in general, have decent BITNET connectivity? There are still
      a few sites that insist on using 9.6k leased lines for BITNET in
      spite of having T1 IP access. You will want to avoid them.

a。 あなたは問題のホストに良い接続性を持っていますか? 一般に、ホストには、きちんとしたBitnetの接続性がありますか? まだ、T1 IPアクセサリーを持っていますが、Bitnetに9.6k専用線を使用すると主張するいくつかのサイトが、あります。 あなたはそれらを避けたくなるでしょう。

   b. Send mail to the server with "show version" in the message body
      (not in the subject field, which is ignored). Is the server running
      version 1.7f or higher? If so, it should not have given you the
      following warning,

b。 「ショーバージョン」がメッセージ本体(無視される対象の分野でないところの)にある状態で、メールをサーバに送ってください。 サーバ走行バージョンは、1.7fかそれとも、より高いですか? そうだとすれば、それは以下の警告をあなたに与えるべきではありませんでした。

        >>> This server is configured to use PUNCH format for mail <<<

このサーバが構成される>>>はメール<<<にパンチ形式を使用します。

      which means that messages with lines longer than 80 characters
      cannot be handled properly. If the software version is less than
      1.7f, the warning will not be present; instead, check the first
      (bottom) "Received:" field. If it does not say "LMail", do not use
      this server as it probably cannot handle messages with long lines.

適切に線が80のキャラクタより長いメッセージを扱うことができないことを意味します。 ソフトウェアバージョンが1.7f以下であるなら、警告は存在しないでしょう。 代わりに、最初に(下部)、「受け取ったこと」をチェックしてください。 さばきます。 "LMail"を示さないなら、たぶん長い線でメッセージを扱うことができないので、このサーバを使用しないでください。

Thomas                                                          [Page 2]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[2ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

      Finally, make sure that the "Master nodes file" is not older
      than 2 months: there are a handful of sites which never update
      their tables due to staffing problems. They cannot be prevented
      from running LISTSERV, but you will certainly want to avoid them.

最終的に、「マスターノードファイル」が2カ月ほど古くないのを確実にしてください: 人員の問題のためそれらのテーブルを決してアップデートしない一握りのサイトがあります。それらはリストサーブを走らせてもよいのですが、確かに、あなたはそれらを避けたくなるでしょう。

   c. How big is your workload? If you are planning to use the service
      for more than 10,000 daily recipients, you should get permission
      from the LISTSERV administrator, both as a matter of courtesy and
      to hear about any restrictions or regularly scheduled downtime they
      might have. For instance, some universities might not allow large
      distributions during prime time, or they may have several
      DISTRIBUTE machines and will want to make sure you use the "right"
      one.  Send mail to "owner-listserv" at the host in question and
      give an estimate of the amount of daily messages and recipients you
      would like to submit. If your message bounces back with "No such
      local user" or the like, it means the server did not pass the above
      test (b) and you don't want to use it anyway.

c。 あなたのワークロードはどれくらい大きいですか? 1万人以上の毎日の受取人にサービスを利用するのを計画しているなら、あなたはリストサーブ管理者から許可を得るべきです、ともに礼儀の物質としてどんな制限や定期的に予定されている休止時間についても聞くために、それらはそうしたかもしれません。 例えば、いくつかの大学がゴールデンアワーの間、大きい配を許さないかもしれないか、それらは、数台のDISTRIBUTEマシンを持っているかもしれなくて、あなたが「正しい」ものを使用するのを確実にしたくなるでしょう。 問題のホストで「所有者-listserv」にメールを送ってください、そして、毎日のメッセージとあなたが提出したい受取人の量の見積りをお願いします。 あなたのメッセージが「いいえ、そのような地元のユーザ」か同様のもので回復するなら、それは、サーバが上のテスト(b)に合格しなかったことを意味します、そして、あなたはとにかくそれを使用したがっていません。

   An index of sites/hosts which have the required configuration, good
   connectivity, keep their tables up to date and have generally agreed
   to provide this service to anyone in their topological area will be
   published separately in the future.

必要な構成、良い接続性を持って、彼らのテーブルが時代について行かせて、一般に、だれに対するもこのサービスをそれらの位相的な領域に提供するのに同意したサイト/ホストのインデックスは将来、別々に発行されるでしょう。

2. Physical delivery of the DISTRIBUTE request

2. DISTRIBUTE要求の物理的な配送

   The distribution request is delivered via SMTP to the e-mail address
   obtained in step 1 (for instance, LISTSERV@SEARN.SUNET.SE). In fact,
   as long as you can somehow get mail to the server's host, you can use
   the service; SMTP is just the most convenient way of doing so.

ステップ1(例えば、 LISTSERV@SEARN.SUNET.SE )で得られたEメールアドレスへのSMTPを通して分配要求を提供します。 事実上、どうにかサーバのホストにメールを受け取ることができる限り、あなたはサービスを利用できます。 SMTPはそうするちょうど最も便利な方法です。

2.1. Contents of MAIL FROM: field

2.1. メールFROM:のコンテンツ 分野

   You should set the MAIL FROM: field to the address of the person who
   maintains your mailing list or, generally speaking, to the address of
   a human being who can take action in case the message fails to reach
   the DISTRIBUTE server's host. This is a very rare occurrence.

あなたはメールFROM:を設定するべきです。 あなたのメーリングリストを維持する人のアドレス、または、概してメッセージがDISTRIBUTEサーバのホストに届かないといけないので行動を取ることができる人間のアドレスとしてさばきます。 これは非常にまれな発生です。

2.2. Contents of RCPT TO: field

2.2. RCPT TO:のコンテンツ 分野

   The RCPT TO: field points to the server's address (for instance,
   LISTSERV@SEARN.SUNET.SE).

RCPT TO: サーバのアドレス(例えば、 LISTSERV@SEARN.SUNET.SE )としてポイントをさばいてください。

2.3. Contents of the RFC822 header

2.3. RFC822ヘッダーのコンテンツ

   After the DATA instruction, you must supply a valid RFC822 header
   with a "From:" field pointing to the mailbox that should receive
   notification of delivery problems, bounced mail, and so on. This can
   be the same as the MAIL FROM: field, an address of the type "owner-

DATA指示の後に、あなたは「From:」を有効なRFC822ヘッダーに提供しなければなりません。 配送問題の通知、返送されたメールなどを受け取るはずであるメールボックスを示す分野。 これはメールFROM:と同じである場合があります。 分野、タイプ「所有者」のアドレス

Thomas                                                          [Page 3]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[3ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

   xxxx@yourhost", etc.  DO NOT PUT THE LIST SUBMISSION ADDRESS THERE,
   or you will get mailing loops.

" xxxx@yourhost "など DO NOT PUT THE LIST SUBMISSION ADDRESS THERE、またはあなたは得るでしょう。輪を郵送させます。

   For testing, the "From:" field should point to your own mailbox, so
   that you get the responses from the server.

テスト、「From:」のために 分野があなた自身のメールボックスを示すべきであるので、あなたはサーバから応答を得ます。

   As long as RFC822 syntax is respected, the only field that matters is
   the "From:" field (or "Sender:", "Resent-From:", etc.). In practice
   this means you can just pipe the distribution request into "mail
   listserv@whatever" and let your mail program build all the headers.

RFC822構文が尊敬される限り、唯一の重要な分野が「From:」です。 または、分野、(「送付者:」、「From:に憤慨する、」、など) 実際には、これは、あなたがあなたのメールプログラムにただ「メール listserv@whatever 」に分配要求を運んで、すべてのヘッダーを造らせることができることを意味します。

3. Format of the DISTRIBUTE request

3. DISTRIBUTE要求の形式

   The body of the message delivered to LISTSERV defines the recipients
   of the distribution and the text (header + body) of the RFC822
   message you want to have delivered. The request starts with a "job
   card", followed by a DISTRIBUTE command, a list of recipients, and
   finally the message header and body.

リストサーブに渡されたメッセージ欄は分配の受取人とあなたが送りたかったRFC822メッセージのテキスト(ヘッダー+ボディー)を定義します。 要求は「仕事のカード」から始まります、続いて、最終的にDISTRIBUTEコマンド、受取人のリスト、メッセージヘッダー、およびボディーから始まります。

3.1. Syntax of the JOB card

3.1. JOBカードの構文

   The purpose of the JOB card is to make sure that any spurious text
   inserted by mail gateways or the like is flushed and not erroneously
   interpreted as a command. It can optionally be used to associate a
   "job name" with the request, in case you want to use tools to assist
   you in processing the notifications you get from the DISTRIBUTE
   servers when running in test mode. The syntax is as follows:

JOBカードの目的はメール・ゲートウェイか同様のものによって挿入された少しの偽りのテキストも洗い流されて、コマンドとして誤って解釈されないのを確実にすることです。 「ジョブ名」を要求に関連づけるのに任意にそれを使用できます、あなたがテスト・モードへ駆け込むときあなたがDISTRIBUTEサーバから得る通知を処理するのにあなたを助けるツールを使用したがっているといけないので。 構文は以下の通りです:

   //jobname JOB ECHO=NO

//jobname仕事エコー=ノー

   "jobname" can be anything as long as it does not contain blanks, and
   can be omitted. LISTSERV generally ignores case when parsing
   commands, so you can use "job" or "Job" if you prefer. The ECHO=NO
   keyword is required for production use, to suppress the "resource
   usage summary" you would otherwise get upon completion of your
   delivery. You may want to omit it when testing.

それを空白を含んでいなくて、省略できる限り、"jobname"は何かであるかもしれません。 コマンドを分析するとき、リストサーブが一般にケースを無視するので、あなたはよければ「仕事」か「仕事」を使用できます。 ECHO=キーワードは、全く生産使用にそうでなければあなたがあなたの配送の完成のときに得る「リソース用法概要」を抑圧するのに必要ではありません。 テストするとき、あなたはそれを省略したがっているかもしれません。

3.2. Syntax of the DISTRIBUTE command

3.2. DISTRIBUTEコマンドの構文

   Below the JOB card, you must supply the following line:

JOBカードの下に、あなたは以下の線を供給しなければなりません:

   DISTRIBUTE MAIL

郵便物を区分けしてください。

   For production mode, do not specify anything else on that line. When
   testing, you should add ACK=MAIL in order to get an acknowledgement
   confirming the delivery. There are two other useful options:
   DEBUG=YES, which instructs the server to produce a report showing how
   the various recipients will be routed, but without actually

生産モードには、その線の上で他の何も指定しないでください。 テストするとき、あなたは、承認に配送を確認させるようにACKがメールと等しいと言い足すべきです。 他の2つの役に立つオプションがあります: DEBUG=はい実際にしかし、様々な受取人がどう発送されるかを示したレポートを製作する。(そのはいはサーバを命令します)。

Thomas                                                          [Page 4]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[4ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

   delivering the message; and TRACE=YES, which does the same but does
   deliver the message. Before making a "live" test with your actual
   recipients list, you should tack the DEBUG=YES option once to make
   sure you got all the parameters and syntax right, and get a rough
   idea of the efficiency of the distribution (see the section on
   performance).

メッセージを送ります。 そして、TRACEははいと等しいです。(同じようにしますが、それは、メッセージを送ります)。 あなたの実際の受取人リストで「ライブな」テストをする前に、あなたは、あなたがすべてのパラメタと構文を正しくしたのを確実にするために一度はいDEBUG=オプションを鋲で留めて、分配の効率のおよその考えを得るべきです(性能にセクションを見てください)。

3.3. Giving the list of recipients

3.3. 受取人のリストを与えます。

   The list of recipients follows the DISTRIBUTE line and is specified
   as follows:

受取人のリストは、DISTRIBUTE線に従って、以下の通り指定されます:

   //To DD *
   user1@host1 BSMTP
   user2@host2 BSMTP
   /*

DD* user1@host1 BSMTP user2@host2 BSMTP/*への//

   The two lines starting with a "/" have to be copied as-is. Each of
   the lines in between contains the address of one of the recipients,
   followed by a blank and by the word "BSMTP", which indicates that you
   do not want the header rewritten. There are four restrictions:

「a」/から始まる2つの線」はそのままでコピーされなければなりません。 間のそれぞれの線はあなたがヘッダーを書き直して欲しくないのを示す空白と"BSMTP"という言葉があとに続いた受取人のひとりのアドレスを含んでいます。 4つの制限があります:

   a. The address must be a plain "local-part@hostname" - no name string,
      no angle bracket, no source route, etc. Bear in mind that the
      DISTRIBUTE server is not in the same domain as you: all the
      addresses should be fully qualified.

a。 アドレスは明瞭な" local-part@hostname "であるに違いありません--名前ストリングがない、角ブラケットがない、送信元経路がありませんなど。 DISTRIBUTEサーバがあなたと同じドメインにないのを覚えておいてください: すべてのアドレスが完全に資格があるべきです。

   b. If the local-part is quoted, it must be quoted from the first word
      on.  Technically, RFC822 allows: Joe."Now@Home".Smith@xyz.edu, but
      for performance reasons this form is not supported. Just quote the
      first word to tell LISTSERV to run the address through the full
      parser: you would write "Joe"."Now@Home".Smith@xyz.edu instead.

b。 地方の部分が引用されるなら、オンであるという最初の単語からそれを引用しなければなりません。 技術的に、RFC822は以下を許容します。 ジョー、「 Now@Home 、「.Smith@xyz.edu、性能理由がなければ、このフォームは支持されません」。 ただ完全なパーサを通ってアドレスを走らせるためにリストサーブを言う最初の言葉を引用してください: あなたが「ジョー」を書くだろう、「 Now@Home 、「代わりに.Smith@xyz.edu。」

   c. The local-part of the address may not start with an (unquoted)
      asterisk.  You can bypass this restriction by quoting the local
      part and using a %-hack through the server's host:
      "***JACK***%jack-ws.xyz.edu"@server-host.

c。 アドレスの地方の部分は(引用を終わられます)アスタリスクから始まらないかもしれません。 あなたはサーバのホストを通して地方の部分を引用して、%ハッキングを使用することによって、この制限を迂回させることができます: 「***ジャック***%ジャッキ-ws.xyz.edu」@server-host。

   d. Blanks are not allowed anywhere in the address.

d。 空白はアドレスで何処にも許容されていません。

   You can use the pseudo-domain ".BITNET" for BITNET recipients: it is
   always supported within DISTRIBUTE requests.

あなたはBitnet受取人に疑似ドメイン".BITNET"を使用できます: それはDISTRIBUTE要求の中でいつも支持されます。

3.4. Specifying the message text

3.4. メッセージ・テキストを指定します。

   After the last recipient and the closing "/*", add the following
   line,

「最後の受取人と閉鎖の後」/*、」、以下の線を加えてください。

Thomas                                                          [Page 5]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[5ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

   //Data DD *,EOF

//データDD*、EOF

   followed by the RFC822 message (header + body) that you want
   delivered.  The EOF option indicates that the message header and body
   will extend until the end of the message you are sending to the
   DISTRIBUTE server.  If you are worried about extraneous data being
   appended by a gateway, remove the EOF option, add a closing "/*" line
   after the end of the message, followed by a "// EOJ" card to flush
   any remaining text. This, however, will fail if the message itself
   contains a "/*" line; you would have to insert a space before any
   such line.

あなたが渡して欲しいRFC822メッセージ(ヘッダー+ボディー)はあとに続いています。 EOFオプションは、メッセージヘッダーとボディーがあなたがDISTRIBUTEサーバに送るメッセージの終わりまで広がるのを示します。「ゲートウェイによって追加される異質なデータが心配であるなら、EOFオプションを取り除いてください、そして、」 /*を閉じながら、aを言い足してください」は、メッセージの終わり以降、立ち並んで、どんな残っているテキストも洗い流すためにa」//EOJを」 カードに続けました。 「しかしながら、メッセージ自体がa」/*を含んでいると、これは失敗する」という台詞。 あなたはどんなそのような線の前にもスペースを挿入しなければならないでしょう。

4. Examples

4. 例

   Here is an (intentionally short) example to clarify the syntax:

ここに、構文をはっきりさせる(故意に短い)の例があります:

   ----- cut here -----
   //Test JOB
   Distribute mail Ack=mail Debug=yes
   //To DD *
   joe@ws-4.xyz.edu BSMTP
   jack@abc.com BSMTP
   jim@tamvm1.bitnet BSMTP
   jill@alpha.cc.buffalo.edu BSMTP
   james@library.rice.edu BSMTP
   /*
   //Data DD *,EOF
   Date:         Tue, 19 Jan 1993 10:57:29 -0500
   From:         Robert H. Smith <RHS@eta.abc.com>
   Subject:      Re: Problem with V5.41
   To:           somelist@some.host.edu

----- ここで、切られます。----- メール//テストJOB DistributeメールAck=DebugはDD* joe@ws-4.xyz.edu BSMTP jack@abc.com BSMTP jim@tamvm1.bitnet BSMTP jill@alpha.cc.buffalo.edu BSMTP james@library.rice.edu BSMTP/*//データDD*へのはい//と等しいです、EOF日付: 火曜日、1993年1月19日の10:57:29 -0500From: ロバートH. Smith <RHS@eta.abc.com 、gt;、Subject: Re: V5.41To:に関する問題 somelist@some.host.edu

   I agree with Jack, V5.41 is not a stable release. I had to fall back
   to V5.40 within 5 minutes of installation...

私はジャックに同意して、V5.41は安定した釈放ではありません。 私はインストールの5分以内にV5.40へ後ろへ下がらなければなりませんでした…

                                           Bob Smith
   ----- cut here -----

ボブ・スミス----- ここで、切られます。-----

   Note: some of the hostnames are genuine, but the usernames are all
   fictitious.

以下に注意してください。 ホスト名のいくつかが本物ですが、ユーザ名はすべて架空です。

   You would get the following reply:

あなたは以下の回答を得るでしょう:

   --------------------------------------------------------------------
   Job "Test" started on 20 Feb 1993 01:09:40

-------------------------------------------------------------------- 1993年2月20日の01:09:40に始められた仕事の「テスト」

   > Distribute mail ack=mail debug=yes
   Debug trace information:

>ははいDebugメールメールack=デバッグ=トレース情報を分配します:

Thomas                                                          [Page 6]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[6ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

   ABC.COM                   goes to SEARN    (213) - single recipient
   ALPHA.CC.BUFFALO.EDU      goes to UBVM     (027) - single recipient
   LIBRARY.RICE.EDU          goes to RICEVM1  (022) - single recipient
   TAMVM1                    goes to TAIVM1   (247) - single recipient
   WS-4.XYZ.EDU              goes to SEARN    (213) - single recipient

ABC.COMはSEARN(213)に行きます--独身の受取人ALPHA.CC.BUFFALO.EDUはUBVM(027)に行きます--独身の受取人LIBRARY.RICE.EDUはRICEVM1(022)に行きます--独身の受取人TAMVM1はTAIVM1(247)に行きます--独身の受取人WS-4.XYZ.EDUはSEARN(213)に行きます--受取人を選抜してください。

   Path information:

経路情報:

    TAIVM1  : UGA      RICEVM1  TAIVM1
    UBVM    : UGA      UBVM
    RICEVM1 : UGA      RICEVM1

TAIVM1: UGA RICEVM1 TAIVM1 UBVM: UGA UBVM RICEVM1: UGA RICEVM1

   (Debug) Mail forwarded to LISTSERV@UGA      for   3 recipients.
   (Debug) Mail posted via BSMTP to jack@ABC.COM.
   (Debug) Mail posted via BSMTP to joe@WS-4.XYZ.EDU.

(デバッグします) 郵便配達人は3のために受取人を LISTSERV@UGA に送りました。 (デバッグ) jack@ABC.COM へのBSMTPを通して掲示されたメール。 (デバッグ) joe@WS-4.XYZ.EDU へのBSMTPを通して掲示されたメール。

   Job "Test" ended   on 20 Feb 1993 01:09:40

1993年2月20日の01:09:40に終わった仕事の「テスト」

   Summary of resource utilization
   -------------------------------
    CPU time:        0.086 sec                Device I/O:     6
    Overhead CPU:    0.045 sec                Paging I/O:     5
    CPU model:        9221                    DASD model:  3380
   --------------------------------------------------------------------

リソース利用の概要------------------------------- CPU時間: 0.086秒の間の装置入出力: 6のオーバーヘッドのCPU: 0.045秒の間のページング入出力: 5CPUモデル: 9221年のDASDモデル: 3380 --------------------------------------------------------------------

   To actually perform the distribution and get an acknowledgement, you
   would change the first two lines as follows:

実際に分配を実行して、承認を得るために、あなたは以下の最初の2つの線を変えるでしょう:

   ----- cut here -----
   //Test JOB Echo=NO
   Distribute mail Ack=mail
   --------------------

----- ここで、切られます。----- どんなDistributeメール//テストJOB Echo=Ackもメールと等しくはありません。--------------------

   And you would get the following reply:

そして、あなたは以下の回答を得るでしょう:

   --------------------------------------------------------------------
   Mail forwarded to LISTSERV@UGA      for   3 recipients.
   Mail posted via BSMTP to jack@ABC.COM.
   Mail posted via BSMTP to joe@WS-4.XYZ.EDU.
   --------------------------------------------------------------------

-------------------------------------------------------------------- 郵便配達人は3のために受取人を LISTSERV@UGA に送りました。 jack@ABC.COM へのBSMTPを通して掲示されたメール。 joe@WS-4.XYZ.EDU へのBSMTPを通して掲示されたメール。 --------------------------------------------------------------------

   Finally, by removing the "Ack=mail" keyword you would perform a
   "silent" distribution without any acknowledgement, suitable for
   production mode.

最終的に、「Ack=メール」キーワードを取り除くことによって、あなたは生産モードに適した少しも承認なしで「静かな」分配を実行するでしょう。

Thomas                                                          [Page 7]

RFC 1429              Listserv Distribute Protocol         February 1993

トーマス[7ページ]RFC1429リストサーブは1993年2月にプロトコルを分配します。

5. Performance

5. パフォーマンス

   The efficiency of the distribution depends mostly on the quality and
   accuracy of the topological information available to the DISTRIBUTE
   server (and, in some extreme cases, on system load). For BITNET
   recipients, the typical turnaround time for reasonably well connected
   systems is 5-15 minutes. Internet recipients fall in two categories:
   those which can be routed to a machine within or close to the
   recipient's organization (average turnaround time 5-20 minutes), and
   those for which no topological information is available at all. In
   that case the delivery can take much longer, but usually remains
   faster than with a vanilla sendmail setup. At the time being,
   topological information is available for most top-level domains
   outside the US and for many sub-domains of EDU and GOV.

分配の効率はほとんどDISTRIBUTEサーバ(そしてシステム・ロードのいくつかの極端な場合で)に利用可能な位相的な情報の品質と精度に依存します。 Bitnet受取人にとって、合理的によく接続されたシステムのための典型的なターンアラウンドタイムは5-15分です。 インターネット受取人は2つのカテゴリで転びます: 組織以内か受取人の組織(平均したターンアラウンドタイム5-20分)の近くでマシンに発送できるもの、および位相的な情報が全く利用可能でないそれら。 その場合、配送は、はるかに長い間かかるかもしれませんが、通常、バニラsendmailセットアップより速く残っています。 当時、あって、位相的な情報は米国の外のほとんどの最上位のドメインとEDUとGOVに関する多くのサブドメインに利用可能です。

   You can measure the efficiency of the distribution using the
   DEBUG=YES option as explained above. Recipients which get forwarded
   to another server usually get delivered within 5-20 minutes (except
   to poorly connected sites or countries, for which not much can be
   done). Recipients which are handled locally are passed to a local
   SMTP agent whose efficiency depends very much on the amount of
   "burst" queries the local name server can handle in quick succession.

あなたは、上で説明されるようにはいDEBUG=オプションを使用することで分配の効率を測定できます。 通常、5-20分(不十分に接続されたサイトか多くのことをできるというわけではない国を除いた)以内に別のサーバに送られる受取人を渡します。 局所的に扱われる受取人は効率が地方名サーバが間断なく扱うことができる「炸裂」質問の量にたいへん応じた地元のSMTPエージェントに渡されます。

   A number of projects are currently underway to investigate the
   feasibility of improving the quality of the topological information
   available to the DISTRIBUTE servers for the Internet.

多くのプロジェクトが、現在、インターネットに、DISTRIBUTEサーバに利用可能な位相的な情報の品質を改良することに関する実現の可能性を調査するために進行中です。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Eric Thomas
   Swedish University Network
   Dr.Kristinas vaeg 37B
   100 44 Stockholm, Sweden

エリック・トーマススウェーデンの大学Network博士Kristinas vaeg 37B100 44・ストックホルム(スウェーデン)

   E-mail: ERIC@SEARN.SUNET.SE

メール: ERIC@SEARN.SUNET.SE

Thomas                                                          [Page 8]

トーマス[8ページ]