jerry@oliveb.olivetti.com (Jerry Aguirre) (05/12/88)
The pseudo inews that comes with NNTP adds a "From:" line and a "Path:" line. The "From:" line is an obvious requirement so that mail replies will work. The "Path:" line is created as "hostname!login" where "hostname" is the name of the NNTP client. Inserting the hostname of the client is what seems incorrect. The "Path:" header line is used to avoid sending articles to sites they have already passed through. In the trivial case it prevents a site from sending the article back to the site it came from. But the posting NNTP "client" most likely doesn't have news feed to it and most certainly doesn't have the article in question. So inserting its hostname is at best un-necessary and in theory wrong. Aside from increasing the "Path:" line unnecessarily it also increases the posibility of a name collision. The typical work station using NNTP to access news has no external connections and the administration usually doesn't worry about conflicting with external names. How about if the pseudo inews creats a "Path:" line of just "login"? Then the server news software should prefix it with "serverhost!".
rsalz@bbn.com.UUCP (05/13/88)
Jerry @ Olivetti writes:
How about if the pseudo inews creats a "Path:" line of just "login"?
Then the server news software should prefix it with "serverhost!".
Reply 1: phil@east.Berkeley.EDU (Phil Lapsley)
Because that's not always right. Consider the situation at Berkeley:
When somebody posts news through pasteur, say from "cory.berkeley.edu",
the path line becomes:
Path: pasteur!cory.berkeley.edu!user
which is ok; any replies will get to pasteur ...
Reply 2: karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
But in our network, where news is available to all systems, undergrads
have no access to the server machine. Hence, if we simply have
server!user in the Path: header, mail using that header will bounce.
Thus, it is very necessary to us that the client be in the Path:.
Are my eyes deceiving me, or are you both really in favor of this
gross behavior just so that replies along the Path: line will work?
Say it ain't so, guys!
/rich $alz
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (05/13/88)
jerry@oliveb.olivetti.com writes:
But the posting NNTP "client" most likely doesn't have news feed to it
and most certainly doesn't have the article in question. So inserting
its hostname is at best un-necessary and in theory wrong.
But in our network, where news is available to all systems, undergrads
have no access to the server machine. Hence, if we simply have
server!user in the Path: header, mail using that header will bounce.
Thus, it is very necessary to us that the client be in the Path:.
Aside from increasing the "Path:" line unnecessarily it also increases
the posibility of a name collision.
Not so if you make a truly trivial modification to inews.c so that it
provides a fully-qualified hostname in the Path: line. Take a look at
this article, for example. Yes, it makes the Path: header longer, but
I don't consider the extra 19 bytes to be of much significance.
I posted the inews.c diff to this newsgroup a couple of months ago.
The typical work station using NNTP
to access news has no external connections
The Sun3/50 on my desk does UUCP all by itself. And all of our
machines have Internet access.
--Karlphil@east.Berkeley.EDU (Phil Lapsley) (05/13/88)
Rich $alz @ BBN asks the musical question, > Are you both really in favor of this gross behavior [adding client host > names to the path line] just so that replies along the Path: line will work? All I can say in defense is that I wish people would put replyable addresses in the From: line so I could use that for replies. The Path: line was never intended for replies anyway, but at least it gives some *clue* how to get there (as opposed to "From: mumblefrotz.uucp"). So, yes, I think this gross behavior is acceptable until the From: line gets its act together. Phil
wisner@killer.UUCP (Bill Wisner) (05/15/88)
> Are my eyes deceiving me, or are you both really in favor of this > gross behavior just so that replies along the Path: line will work? In a word.. yes. -- Bill Wisner ..!{ames,att,decwrl,ihnp4,mit-eddie}!killer!wisner
jerry@oliveb.olivetti.com (Jerry Aguirre) (05/17/88)
In article <3289@pasteur.Berkeley.Edu> phil@east.Berkeley.EDU (Phil Lapsley) writes: > >When somebody posts news through pasteur, say from "cory.berkeley.edu", >the path line becomes: > > Path: pasteur!cory.berkeley.edu!user > >which is ok; any replies will get to pasteur, which is a registered UUCP >name, and pasteur can handle the cory.berkeley.edu business to do the >right thing. "pasteur!user" would be wrong. Well, now that we have established that this is only for backward compatability with ancient mailers perhaps we can discuss alternatives. When I was writing I was aware of the fact that the user might not have an account on the server and that replies using the path could cause problems. My assumption was that that such sites would maintain mail aliases on the server site. This is the way we maintain our systems. So, I would assume that in my case it would be OK to omit the client name from the path line. I realize this isn't a sollution for everyone. Other sites may not want to go to the extra overhead of system wide mail aliases or may not even have unique login IDs. Jerry Aguirre
ambar@athena.mit.edu (Jean Marie Diaz) (05/17/88)
In article <21931@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: >In article <3289@pasteur.Berkeley.Edu> phil@east.Berkeley.EDU (Phil Lapsley) writes: >>When somebody posts news through pasteur, say from "cory.berkeley.edu", >>the path line becomes: >> >> Path: pasteur!cory.berkeley.edu!user >> >>which is ok; any replies will get to pasteur, which is a registered UUCP >>name, and pasteur can handle the cory.berkeley.edu business to do the >>right thing. "pasteur!user" would be wrong. >When I was writing I was aware of the fact that the user might not >have an account on the server and that replies using the path could >cause problems. My assumption was that that such sites would maintain >mail aliases on the server site. [...] Well, I agree with neither of you (suprise! :-). My context is running the news server for MIT Project Athena. I don't want the client (ie, workstation) names anywhere; they don't receive mail. Our mail hub, athena.mit.edu, maintains all the mail aliases for all our users, and it is pointless (as well as difficult) to duplicate this work on our news hub, bloom-beacon.mit.edu. So (as you can see from this posting), the Path: line comes out as bloom-beacon!athena.mit.edu!user (which will work, if ya gotta...), and the From: and Reply-To: headers come as user@athena.mit.edu (correct!), and life is sweet. I'm just grateful that it was relatively trivial to hack the nntp inews to DTRT. rrn, on the other hand.. (grrr) .. has that stupid .UUCP hack hardcoded in 2 different places, as well as some other lossage induced by our weird situation (cancel messages don't work). Although we're running the NNTP1.5 server, our rrn client is still 1.3, 'cause I don't want to do that hacking again, really. AMBAR ambar@bloom-beacon.mit.edu {backbones}!mit-eddie!ambar