Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!mcdchg!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.mail.uucp Subject: Re: Who pays the bill? (Was: Imminent Death...) Message-ID: <1990Aug09.192521.15465@chinet.chi.il.us> Date: 9 Aug 90 19:25:21 GMT References: <66099@sgi.sgi.com> Organization: Chinet - Public Access UNIX Lines: 39 In article <66099@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Why "bang on" everyone? Why not hurt only those who use Path: to abuse >your links? >You could zap the Path: abusers by hacking your inews to stick a clinker >like "somewhere!" in Path:'s as articles are relayed by your system. >That would harm exactly those you say you want to "bang," and not the >rest of the universe. It would take far less time than maintaining >what sounds like an interesting set of heuristics. >You could even take the existence of "!somewhere" in an path as >permission to re-route. You would have an automatically generated >"loose source route" flag. This is a great idea! Probably 90% of the mail that everyone is complaining about is generated from news Path: lines or replies to those messages. The crux of the problem is that there is no way to distinguish mail where the user would prefer optimal re-rerouting (as long as it works) from mail where the user really wants the specified route. Some time ago I suggested that sites that wanted to optimize mail routes should just re-write the news Path: line and eliminate everything else but themselves and the sending site. Of course I was informed that such a change would result in the messages being propagated back to the excised sites. However, there should be no such problem from agreeing on a non-existing site name to be used as a "token". Re-routing sites would just move the token to the front of the Path: line before adding their own name or insert it if no one else has. Then, when a mailer sees this token as the next-hop, it should re-route to the right-most destination that it can identify. No one could question the ethics of this form of re-routing, and a few dozen sites running this way could have a major impact on mail traffic (as opposed to waiting for every leaf node to either start running routing software or identify the most convienent nearby site willing to act as a smart-host). Smail 2.5 should automatically re-route when the next hop doesn't exist. The other smart mailers can probably be coaxed to do so as well. Les Mikesell les@chinet.chi.il.us