Connected: An Internet Encyclopedia
RFC 850 - 2.1.8 Path

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 850
Up: 2. Article Format
Up: 2.1 Required Headers
Prev: 2.1.7 Message-ID
Next: 2.2 Optional Headers

### 2.1.8 Path

This line shows the path the article 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, thus "cbosgd!mhuxj!mhuxt", "cbosgd, mhuxj, mhuxt", and "@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp" and even "teklabs, zehntel, sri-unix@cca!decvax" are valid entries. (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 third example was "teklabs". Letters, digits, periods and hyphens are considered part of site 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 system.

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 travelled to reach the local site. 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 sites. Perhaps the most important is to cut down on redundant USENET traffic by failing to forward a message to a site that is known to have already received it. In particular, when site A sends an article to site B, the Path line includes "A", so that site B will not immediately send the article back to site A. The site name each site 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 site adds its own name to the front of a path when it receives a message from another site. Thus, if a message with path A!X!Y!Z is passed from site A to site 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 sites 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. Thus, sites are required to continue to keep the Path line in a working reply format as much as possible, until January 1, 1984. 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 site name and an "!" at the front of the path, and of starting the path with the site name, an "!", and the user name, should be maintained at least until 1984.

Next: 2.2 Optional Headers

Connected: An Internet Encyclopedia
RFC 850 - 2.1.8 Path