greg@gagme.chi.il.us (Gregory Gulik) (09/14/90)
Well, I give up... I've been trying to figure this out for days, but I can't do it... If you would just look at the top of your screen at the Path: line, you will see my problem. It seems that inews is writing my path as gagme!gagme.chi.il.us instead of gagme!greg Has anyone had this problem before? How can I fix it? Where can I find the latest version?? Thanks in advance.. -greg
daniel@hexagon.se (Daniel Deimert) (09/18/90)
In article <704@gagme.chi.il.us> greg@gagme.chi.il.us (Gregory Gulik) writes: > >It seems that inews is writing my path as gagme!gagme.chi.il.us >instead of gagme!greg > >Has anyone had this problem before? How can I fix it? Where >can I find the latest version?? I'm having exactly the same problem: Just doing a Pnews alone results in "Path: hexagon!hexagon.se" instead of "hexagon!daniel". (Bnews 2.11.19) But when I'm doing a follow-up from within rn (like now), the Path: is correct. Why? -- Daniel Deimert Fidonet 2:204/117 daniel@hexagon.se ...!sunic!kullmar!pkmab!hexagon!daniel
dem@meaddata.com (David Myers) (09/19/90)
In article <929@hexagon.se> daniel@hexagon.se (Daniel Deimert) writes: > I'm having exactly the same problem: Just doing a Pnews alone results in > "Path: hexagon!hexagon.se" instead of "hexagon!daniel". (Bnews 2.11.19) > But when I'm doing a follow-up from within rn (like now), the Path: is > correct. Why? I stumbled onto this too. It appears that when an article is submitted to inews with a From: line but no Path: line, inews doesn't derive the Path: line correctly, and you get the results you are seeing. Notice that when posting with Pnews, Pnews generates a From: line but no Path: line, but rn doesn't generate either one when you post from within it. A quick and simple fix is to stop Pnews from generating the From: line, and let inews provide both the From: and Path:. Take the following line out of the file Pnews.header: From: $logname@$sitename ($fullname) -- David Myers (513) 865-1343 Mead Data Central This DTS Systems Development P.O. Box 933 space dem@meaddata.com Dayton, Ohio 45401 available. ...!uunet!meaddata!dem
bob@omni.com (Bob Weissman) (09/19/90)
In article <929@hexagon.se> daniel@hexagon.se (Daniel Deimert) writes: >In article <704@gagme.chi.il.us> greg@gagme.chi.il.us (Gregory Gulik) writes: >> >>It seems that inews is writing my path as gagme!gagme.chi.il.us >>instead of gagme!greg >> >>Has anyone had this problem before? How can I fix it? Where >>can I find the latest version?? > >I'm having exactly the same problem: Just doing a Pnews alone results in >"Path: hexagon!hexagon.se" instead of "hexagon!daniel". (Bnews 2.11.19) >But when I'm doing a follow-up from within rn (like now), the Path: is >correct. Why? It's a bug in inews which is tickled by the Pnews.header file. You can fix it easily by removing the "@$sitename" from the "From:" header thusly: *** /usr/local/lib/news/rn/Pnews.header.old Tue Sep 18 16:49:52 1990 --- /usr/local/lib/news/rn/Pnews.header Tue Sep 18 17:11:42 1990 *************** *** 179,185 **** esac $cat > $tmpart <<EOHeader ! From: $logname@$sitename ($fullname) Newsgroups: $ng Subject: $title References: --- 179,185 ---- esac $cat > $tmpart <<EOHeader ! From: $logname ($fullname) Newsgroups: $ng Subject: $title References: -- Bob Weissman Internet: bob@omni.com UUCP: ...!{apple,decwrl,pyramid,sgi,uunet}!omni!bob -- Bob Weissman Internet: bob@omni.com UUCP: ...!{apple,decwrl,pyramid,sgi,uunet}!omni!bob
ske@pkmab.se (Kristoffer Eriksson) (09/22/90)
In article <DEM.90Sep19083342@devil.meaddata.com> dem@meaddata.com (David Myers) writes: >In article <929@hexagon.se> daniel@hexagon.se (Daniel Deimert) writes: > >> I'm having exactly the same problem: Just doing a Pnews alone results in >> "Path: hexagon!hexagon.se" instead of "hexagon!daniel". (Bnews 2.11.19) > > It appears that when an article is >submitted to inews with a From: line but no Path: line, inews doesn't >derive the Path: line correctly, and you get the results you are >seeing. Notice that when posting with Pnews, Pnews generates a From: >line but no Path: line, but rn doesn't generate either one when you >post from within it. The actual source of the trouble is the following section of code from main() in inews.c, about line 455: if (forgedname[0]) { .... if (!header.path[0]) { if ((p1 = rindex(forgedname, '@')) == NULL) (void) strcpy(header.path, forgedname); else { *p1 = '\0'; (void) sprintf(header.path, "%s!%s", p1+1, forgedname); *p1 = '@'; } if ((p1 = strpbrk(header.path, " (<")) != NULL) *p1 = '\0'; } This section creates a new Path: header if the From: header was "forged". It tries to build the Path: based on the forged From: header. This doesn't work for domain addresses that are also followed by the full user name inside parenthesis. If the From: header contained for instance "ske@pkmab.se (Kristoffer Eriksson)", the first step above creates the path "pkmab.se (Kristoffer Eriksson)!ske". In the next step the parenthesis is stripped, together with the user name, leaving only "pkmab.se". Later, this path having only one component left fools inews into believing that it is the user name, and then prepends the system's actual path name, which in my case would produce "pkmab!pkmab.se". My first attempt at fixing this involved stripping the parenthesis before building the path, but that doesn't really produce a correct path either. In my case it produced "pkmab.se!ske", while the correct path is just "pkmab!ske". Actually, it is in general not possible to convert a domain name into a valid path, since the system names in the path need not have any relation to the domain address. After all, the purpose of domain addressing was to hide actual paths. Thus, the whole approach is flawed. It works when the From: address already consists of a path. That's easy: just copying the address as is. I wonder, though, what good it does building a fake path that way. The way I understand news distribution, the systems mentioned in the path will think that they have already seen the article when they notice their name in the Path: header, and reject it. It might make the path useable as a return address to the author of the article, but I think that just demonstrates conflicting goals for that header: the header can't be a return path and a news transport tracker, both at the same time, at least not for users who are "forging" their addresses. When does inews consider the From: address forged? Basically, I think inews considers all attempts of the user to explicitely set the From: header suspect, and that Pnews.header shouldn't try to specify the From: header. There is an allowance for articles with the Approved: and Sender: headers also set, if the -S flag is used. I have no idea why the -S flag should have any significance here, though. Maybe another bug? Apparently in that case it checkes whether the user name of the address in the From: header is present on the local system, and if so, remembers that as being the current user. It doesn't check that the system name is the local system though, and it doesn't complain if the user does not exist. Incidentally, this code is also buggy, this time in the case of path addresses. It depends on the assumption that the user name is always the first part of the address, which is wrong for paths. Moderated articles (the -M flag) are also treated specially, and are provided with a freshly constructed Path:, although their From: headers are considered forged nevertheless. The solution? The least intrusive change (except simply sidestepping it by changing Pnews.header), I think, is to make inews just put the username of the forged address into the Path:, and then let the local system name be added the normal way. Here's a patch: *** inews.c Mon Aug 6 21:53:27 1990 --- ../src/inews.c Sat Sep 22 00:25:21 1990 *************** *** 462,469 **** (void) strcpy(header.path, forgedname); else { *p1 = '\0'; ! (void) sprintf(header.path, "%s!%s", ! p1+1, forgedname); *p1 = '@'; } --- 462,469 ---- (void) strcpy(header.path, forgedname); else { *p1 = '\0'; ! (void) sprintf(header.path, "%s", ! forgedname); *p1 = '@'; } I am not going to correct the other bugs I mentioned, since they don't matter to me, but maybe someone should take a look at them too, and clean up a bit? -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske