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:

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.

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.

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".

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.

RFC1036: [Source:"RFC-1036"] [Last Changed:December 1987] [Copyright: 1987 M. Horton, R. Adams]
RFC-1036:[Previous][Up to Table of Contents] [Next]

(Corrections, notes, and links for Usenet RKT.)
by Mib Software, INN customization and consulting

-B-r-o-a-d-e-n- your knowledge

Up to RFC1036 2.1. Required Header lines