The original Distribution header provided a means to limit the distribution of articles to a subset of the sites which received the newsgroups it was posted to. It was designed to control a feed. Each site feeding other sites would, for each feed, configure the list of distributions appropriate to send to that site. If an article had a Distribution header, a check would be made to see if any of the distributions in the header matched the distribution list for the feed.
Sadly, this list was often configured in the form "all distributions except the following" where the local distributions would be listed.
This mean an unknown distribution, leaked from an external site, would match the "all distributions" and get fed out. This meant that once an article leaked out from a distribution's subnet, it flooded the entire net, or at least the very large subset that used "all but these" style of configuring the feed.
Indeed, many sites deliberately wanted this flood. Hub sites at national and multinational ISPs wanted to receive all the local distributions, for the use of their users in the individual geographic regions. This assured netwide propagation of all distributions, defeating the purpose of the header. It became close to valueless.
While distributions SHOULD still control feeds as they do, they SHOULD also be associated with the site. Each site SHOULD maintain a list of the distributions to which it is a "member." Newsreaders SHOULD also allow the user to maintain a list of distributions to which the user is a member.
When an article arrives with a Distribution header, the forwarding of the article to other sites should follow the configuration for Distributions on the outgoing feed as before.
If the site is a member of one of the distributions on the distribution line, the article SHOULD be stored in the local database. If it is a control message or other special message (such as one containing a Supersedes) the site SHOULD act on the message.
If the site is not a member of any of the distributions on the distribution line, and the message is a control message or other special message, it SHOULD NOT (except as below) execute the special action.
If it is an ordinary posting, the site will decide whether to store it in the local database. It MAY elect to not store it, so that it will not be available to local users. It MAY elect to store it, expecting the user to then decide if the article fits the distribution desires of the user. Or it MAY elect to keep track of distributions desired by the users, and store only those articles which contain a distribution in that list, or use other parameters to decide which distributions to store and which to not store.
For cancel messages (and supersedes/replaces) in a distribution in which the site is not a member, IF the site still stores articles in that distribution in its database of articles, then it should examine the article being removed. If that article was posted to the distribution in question, the removal SHOULD be executed.
This is to say, if you get a cancel in a distribution you don't belong to, you don't execute it unless it cancels an article that was also in that same distribution.
Newsreaders MAY also keep track of distributions the user wishes to belong to. In this event, they should examine the Distribution headers of articles to be presented to the user, and SHOULD not display them if the user does not belong to any of the distributions named.
This system assures that articles with Distributions have their effect only at sites which explicitly belong to the distribution, even if they propagate widely outside that subset of the net.
However, sites that wish to be careful in their feeding can assure that unwanted distributions do not even arrive, thus making feeds more efficient. If they do arrive, they do no harm.
Hub sites can arrange to receive all distributions and let their users filter as appropriate. This may mean the Distribution header should appear in news overview databases.
Distributions can now be used to define rigid subsets of the net that sites can "subscribe" to. For example, say a party wishes to issue 3rd party cancel messages that delete spam or net abuse at sites which wish to listen to that canceller. These messages would now be posted to a specific distribution. They might still reach the entire net, and would make it to hubs, but they would only have effect at sites which explicitly took membership in the distribution, even without authentication.
However, as these might be very high volume messages -- especially if there are many such 3rd party cancel services -- it remains possible for sites to ask their feeders to not even feed articles in this distribution, thus making the system efficient.
In addition, certificates can also be issued limited to a distribution or subnet. This allows sites to easily group together, and declare themselves to be a subnet, and issue a certificate within that subnet. Sites would only grant the power named in the certificate if they were a member of the distribution named in the certificate, or if the article being affected by the certified command was posted in the distribution named in the certificate, as appropriate.