This line shows the path the message took to reach the current system. When a system forwards the message, it should add its own name to the list of systems in the "Path" line. The names may be separated by any punctuation character or characters (except "." which is considered part of the hostname). Thus, the following are valid entries:

この行はメッセージが現在の系統に到達するまでに通った経路を示します。 系統がメッセージを転送する時、「Path」(経路)行の系統の一覧に 自分の名前を追加するべきです。名前は一つあるいは複数の句読点文字 (ホスト名の一部と見なされる「.」は除く) で区切ることが出来ます。 ですから、次に挙げるのは妥当なものです。

                   cbosgd!mhuxj!mhuxt
                   cbosgd, mhuxj, mhuxt
                   @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
                   teklabs, zehntel, sri-unix@cca!decvax

(The latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) Additional names should be added from the left. For example, the most recently added name in the fourth example was teklabs. Letters, digits, periods and hyphens are considered part of host names; other punctuation, including blanks, are considered separators.

(最後の経路はメッセージが decvax, cca, sri-unix, zehntel, teklabs を 順に通ってきたことを示します。) 追加する名前は左に加えるべきです。 例えば、4番目の例で一番最後に追加された名前は teklabs です。 文字 (訳注: A-Za-z のラテン文字), 数字, 句点 (ピリオド), ハイフン がホスト名の一部と見なされます。他の空白を含む句読点は 区切り子と見なされます。

Normally, the rightmost name will be the name of the originating system. However, it is also permissible to include an extra entry on the right, which is the name of the sender. This is for upward compatibility with older systems.

通常、一番右側の名前は生成系統の名前です。しかし、 送信者の名前を余分に右側に入れることも認められます。 これは古い系統との上位互換性のためです。

The "Path" line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message traveled to reach the local host. There are several uses for this information. One is to monitor USENET routing for performance reasons. Another is to establish a path to reach new hosts. Perhaps the most important use is to cut down on redundant USENET traffic by failing to forward a message to a host that is known to have already received it. In particular, when host A sends a message to host B, the "Path" line includes A, so that host B will not immediately send the message back to host A. The name each host uses to identify itself should be the same as the name by which its neighbors know it, in order to make this optimization possible.

「Path」行は返事(リプライ)には使いませんし、メイルの宛先と 取るべきではありません。これはメッセージが地方(ローカル)ホストに 到達するまでの経路を示すことを意図しています。この情報の使い道は 幾つかあります。一つはパフォーマンスのために USENET 経路選択を 監視することです。あるいは新しいホストに到達する経路を確立するという ものです。おそらく最も重要な用途は既にメッセージを受け取っていると 分かっているホストへメッセージを転送しようとして失敗する 無駄な USENET 混雑を減らすというものです。ホスト A がメッセージを ホスト B に送った時、「Path」行は A を含むので、 ホスト B は直ぐにメッセージをホスト A に送り戻すことが なくなります。各ホストが識別に使う名前はこの最適化が上手く 働くように、隣人が知っているのと同じ名前にするべきです。

A host adds its own name to the front of a path when it receives a message from another host. Thus, if a message with path "A!X!Y!Z" is passed from host A to host B, B will add its own name to the path when it receives the message from A, e.g., "B!A!X!Y!Z". If B then passes the message on to C, the message sent to C will contain the path "B!A!X!Y!Z", and when C receives it, C will change it to "C!B!A!X!Y!Z".

A ホストはメッセージを他のホストから受け取った時に 自分の名前を経路の先頭に加えます。そして、経路「A!X!Y!Z」のメッセージ がホスト A からホスト B に渡されたら、 B はメッセージを A から 受け取った時に経路に自分の名前を加えるので、「B!A!X!Y!Z」となります。 B がメッセージを C に渡せば、 C に送られるメッセージは経路 「B!A!X!Y!Z」で、 C が受け取った時、それを「C!B!A!X!Y!Z」 に変えます。

Special upward compatibility note: Since the "From", "Sender", and "Reply-To" lines are in Internet format, and since many USENET hosts do not yet have mailers capable of understanding Internet format, it would break the reply capability to completely sever the connection between the "Path" header and the reply function. It is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. However, the existing convention of placing the host name and an "!" at the front of the path, and of starting the path with the host name, an "!", and the user name, should be maintained when possible.

特別上位互換性についての注意: 「From」, 「Sender」, 「Reply-To」 行は Internet 式であるので、また多くの USENET ホストは まだ Internet 式を理解できるメイル・ソフトウェアを持っていないので、 「Path」頭と返事機能の関係を完全に無くすと返事を送ることが 出来なくなります。古めの実装では経路は常に妥当な返事の送り先の 文字列では無いと認められ、実装においてはこの問題を直す必要はありません。 しかし、ホスト名と「!」を経路の最初に置く、 経路がホスト名, 「!」, 利用者名で始まるという現在の慣習は可能なら 維持するべきです。

          The Path header's content indicates which relayers the arti-
          cle has  already  visited,  so  that  unnecessary  redundant
          transmission can be avoided:

               Path-content    = [ path-list path-delimiter ] local-part
               path-list       = relayer-name *( path-delimiter relayer-name )
               relayer-name    = 1*rn-char
               rn-char         = letter / digit / "." / "-" / "_"
               path-delimiter  = "!"

          The  Path  content  is a list of relayer names, separated by
          path delimiters, followed (after a final delimiter)  by  the
          local  part of a mailing address.  Each relayer MUST prepend
          its name, and a delimiter, to the Path content in all  arti-
          cles  it processes.  A relayer MUST not pass an article to a
          neighboring relayer whose name is already  mentioned  in  an
          article's  path list, unless this is explicitly requested by
          the neighbor  in  some  way.   The  Path  content  is  case-
          sensitive.

               NOTE:  The Path header supplied by a posting agent
               should normally contain only the local part.   The
               relayer  that the posting agent passes the article
               to for posting will prepend its  relayer  name  to
               get the path list started.

               NOTE:  Observe that the trailing local part is NOT
               part of the path list.  This Path header:

                    Path: fee!fie!foe!fum

               contains three relayer names:  "fee",  "fie",  and
               "foe".  A relayer named "fum" is still eligible to
               be sent this article.

               NOTE: This syntax has the disadvantage of contain-
               ing  no  white space, making it impossible to con-
               tinue a Path header across several lines.   Imple-
               mentors  of relayers and reading agents are warned
               that it is intended that  the  successor  to  this
               Draft will change the definition of path delimiter
               to:

                    path-delimiter = "!" [ space ]

               and are urged to  fix  their  software  to  handle
               (i.e.,  ignore) white space following the exclama-
               tion points.  They are urged to hurry;  some  ill-
               behaved  systems  reportedly  already feel free to
               add such white space.

               NOTE: RFC 1036 allows considerably more  flexibil-
               ity  in  choice  of delimiter, in theory, but this
               flexibility has never  been  used  and  most  news
               software  does  not  implement  it  properly.  The
               grammar reflects the current  reality.   Note,  in
               particular,  that  RFC 1036 treats "_" as a delim-
               iter, but in fact it is known to appear in relayer
               names occasionally.

          Because  an  article will not propagate to a relayer already
          mentioned in its path list, the path list MUST  not  contain
          any  names  other  than  those  of  relayers the article has
          passed through AS NEWS.  This is trivially obvious for  nor-
          mal  news  articles, but requires attention from the modera-
          tors of moderated newsgroups and the implementors and  main-
          tainers of gateways.

               NOTE:  For  the  same  reason,  a  relayer and its
               neighbors need to agree on the choice  of  relayer
               name,  and  names  should  not  be changed without
               notifying neighbors.

          Relayer names need to be unique  among  all  relayers  which
          will  ever  see  the articles using them.  A relayer name is
          normally either an "official" name for the host the  relayer
          runs  on,  or  some  other "official" name controlled by the
          same organization.  Except in cooperating subnets that agree
          to  some  other  convention, and don't let articles using it
          escape beyond the subnet, a relayer name MUST  be  either  a
          UUCP  name  registered  in the UUCP maps (without any domain
          suffix such as ".UUCP"), or a complete Internet domain name.
          Use  of a (registered) UUCP name is recommended, where prac-
          tical, to keep the length of the path list down.

          The use of Internet domain names in the path  list  presents
          one problem: domain names are case-insensitive, but the path
          list is case-sensitive.   Relayers  using  domain  names  as
          their  relayer names MUST pick a standard form for the name,
          and use that form consistently to the exclusion of all  oth-
          ers.   The  preferred  form for this purpose, which relayers
          SHOULD use, is the all-lowercase form.

               NOTE: It is arguably  unfortunate  that  the  path
               list is case-sensitive, but it is much too late to
               change this.   Most  Internet  sites  do,  in  any
               event,  use  one  standardized  form of their name
               almost everywhere.

          In the ordinary case, where the poster is the author of  the
          article,  the  local  part following the path list SHOULD be
          the local part of the poster's full Internet domain  mailing
          address.

               NOTE:  It  should  be just the local part, not the
               full address.  The character "@" does  not  appear
               in a Path header.

          The  Path content somewhat resembles a mailing address, par-
          ticularly in the UUCP world with its manual routing and  "!"
          address  syntax.   Historically, this resemblance was impor-
          tant, and the  Path  content  was  often  used  as  a  reply
          address.  This practice has always been somewhat unreliable,
          since news paths are not always mail paths and news  relayer
          names  are  not  always recognized by mail handlers, and its
          reliability has generally worsened  in  recent  times.   The
          widespread   use  of  and  recognition  of  Internet  domain
          addresses, even outside the  actual  Internet,  has  largely
          eliminated  the  problem.   Readers  SHOULD not use the Path
          content as a reply address.   On  the  other  hand,  relayer
          administrators  are  urged  not  to break this usage without
          good reason; where practical, paths followed by news  SHOULD
          be  traversable  by mail, and mail handlers SHOULD recognize
          relayer names as host names.

          It will typically be difficult or impractical  for  gateways
          and  moderators to supply a Path content that is useful as a
          reply address for the author, bearing in mind that the  path
          list they supply will normally be empty.  (To reiterate: the
          path list MUST not contain any names  other  than  those  of
          relayers  the  article  has  passed  through AS NEWS.)  They
          SHOULD supply a local part that will result in replies to  a
          Path-derived  address  being  returned  to the sender with a
          brief explanation.   Software  permitting,  the  local  part
          "not-for-mail" is recommended.

               NOTE:  A  moderator  or  gateway administrator who
               supplies a local part that delivers such  mail  to
               an  administrative  mailbox  will quickly discover
               why it should be  bounced  automatically!   It  is
               best, however, for the returned message to include
               an explanation  of  what  has  probably  happened,
               rather than just a mysterious "undeliverable mail"
               complaint, since the sender may not be aware  that
               his/her  software  is unwisely using the Path con-
               tent as a reply  address.   Reply  software  might
               wish  to  question  attempts  to  reply to a Path-
               derived address ending in "not-for-mail" (which is
               why a specific name is being recommended here).

      Path-content        = *( path-identity [FWS] delimiter [FWS] )
                               tail-entry *FWS
      path-identity       = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
      delimiter           = "/" / "?" / "%" / "," / "!"
      tail-entry          = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

NOTE: A Path-content will inevitably contain at least one path-identity, except possibly in the case of a proto-article that has not yet been injected onto the network.

参考: Path-content (経路内容) は必然的に最低一つの path-identity (経路識別子) を含みます。但しまだネットワークに注入されていない 原記事の場合には一つも含まない可能性もあります。

NOTE: Observe that the syntax does not allow comments within the Path header; this is to simplify processing by relaying and injecting agents which have a requirement to process this header extremely rapidly.

参考: 構文は Path (経路) 頭中に注釈を許していないことに注意して下さい。 これは、この頭をとても速く処理する必要がある中継・注入各代理者が 単純に処理出来るようにするためです。 (以上 5.6.1 より)

   '/' The name immediately to the right is known to be the identity of
       the machine from which the article was received (either because
       the entry was made by that machine and we have verified it, or
       because we have added it ourselves).

「/」 すぐ右にある名前は記事を受信した元の機械の識別子と分かっています。 (エントリーがその機械により作られて我々がそれを確認出来るからか、 我々自身がこれを追加したから。)

   '?' The name immediately to the right is the claimed identity of the
       machine from which the article was received, but we were unable
       to verify it (and have prepended our own view of where it came
       from, and then a '/').

「?」 すぐ右にある名前は記事を受信した元の機械の自称識別子 だけど、我々はそれを確認出来ませんでした (でもって、我々自身の 出所の推測を加えたら、その時は「/」)。

   '%' Everything to the right is the pre-injection region followed by
       the tail-entry.  The name on the left is the FQDN of the
       injecting agent. The presence of two '%'s in a path indicates a
       double-injection (see 8.2.2).

「%」 tail-entry (末尾エントリー) の前までの、右側全ては注入前の領域です。 左の名前は注入代理者の FQDN です。一つの経路情報に二つの「%」 があるということは、重注入 (8.2.2 参照) を示しています。

   '!' The name immediately to the right is unverified. The presence of
       a '!' to the left of the '%' indicates that the identity to the
       left is that of an old-style system not conformant with this
       standard.

「!」 直ぐ右の名前は未確認です。「%」の左側に「!」が来た場合、 左の識別子はこの規格に適合しない古い方式の処理系です。

',' Reserved for future use, treat as '/'.

「,」 将来の利用のために予約しますので、「/」として扱います。

Other その他

       Old software may possibly use other delimiters, which should be
       treated as '!'.  But note in particular that ':', '-' and '_' are
       components of names, not delimiters, and FWS on its own MUST NOT
       be used as the sole delimiter.

古いソフトウェアは他の区切子を使うかもしれませんが、 それは「!」として扱うべきです。しかし、特に「:」, 「-」, 「_」 は名前の部品であって、区切子ではなく、 FWS はそれ単独では 区切子として使ってはいけないことに注意して下さい。

        NOTE: Old Netnews relaying and injecting programs almost all
        delimit Path entries with the '!' delimiter, and these entries
        are not verified. As such, the presence of '%' as a delimiter
        will indicate that the article was injected by software
        conforming to this standard, and the presence of '!' as a
        delimiter to the left of a '%' will indicate that the message
        passed through systems developed prior to this standard. It is
        anticipated that relaying agents will reject articles in the old
        style once this new standard has been widely adopted.

参考: 古い電子ニュース中継・注入プログラムはほとんど全て、 Path エントリーを「!」区切子で区切るので、これらのエントリーは 未確認です。ですから、「%」が区切子として現れればその記事は この規格に適合するソフトウェアにより注入されたことを示し、 「%」の左に「!」が区切子として現れればメッセージが この規格以前に開発された処理系を通過したことを示します。 これは中継代理者が、この規格が広く採用された後に旧式の記事を 却下することを予告するものです。 (以上5.6.4より)