david@wiley.UUCP (David Hull) (02/22/90)
I noticed this problem when I was installing NNTP the other day,
as we are getting ready to convert to domainized names on our network.
If a user on random posts an article over NNTP to the NNTP server, then
the NNTP mini-inews puts
Path: random!user
into the header of the article. Unfortunately, we have made no attempt
to make sure that random is unique in the comp.sys.maps namespace, and
if there is a collision, then that other random and any hosts which may
be on the other side of USENET from it will never see the article.
It seems that the right thing to do is to put a domainized hostname
in the Path. Currently, hostname is the nickname, but /etc/hosts
has the full name, i.e.,
0.0.0.0 random.my.domain random
I made a trivial change to inews/uname.c to look the canonical name up
in the hosts database. This has the secondary advantage that the From
line now contains the right thing even if the client and the server are
in different domains. The patch follows.
I wonder how much of a problem this is in the real world?
-David
---------------------------------------
David Hull TRW Inc. Redondo Beach, CA
david%wiley.uucp@csvax.caltech.edu
...!{uunet,cit-vax}!wiley!david
*** inews/uname.c- Mon Jun 26 21:37:02 1989
--- inews/uname.c Thu Feb 15 19:58:50 1990
***************
*** 32,41 ****
--- 32,51 ----
#endif /* UNAME */
#ifdef GHNAME
+ #include <sys/types.h>
+ #include <sys/socket.h>
+ #include <netdb.h>
+
uname(uptr)
char *uptr;
{
+ struct hostent *he;
+
gethostname(uptr, 256);
+
+ he = gethostbyname(uptr);
+ strncpy(uptr, he->h_name, 255);
+ uptr[255] = '\0';
}
# define DONE
#endifemv@math.lsa.umich.edu (Edward Vielmetti) (02/23/90)
An arguably right thing to do is to put the name of your mail hub (or your news hub) in the Path: and squash out all of the client names. Look at the GENERICPATH stuff. --Ed
david@wiley.UUCP (David Hull) (02/28/90)
In article <EMV.90Feb22171219@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >An arguably right thing to do is to put the name of your mail hub >(or your news hub) in the Path: and squash out all of the client >names. The problem with this is that some newsreaders actually use the Path: to route replies. The NNTP server is not going to have the same set of users as all potential clients, and keeping track of the other machines on the network is hard enough, much less the users on those machines. -David
louie@sayshell.umd.edu (Louis A. Mamakos) (03/01/90)
In article <8988@wiley.UUCP> david@wiley.UUCP (David Hull) writes: >The problem with this is that some newsreaders actually use the Path: >to route replies. These newsreaders are fundamentally hosed if they do this. Almost all of our news links are via NNTP, and you can't use the Path: line to send mail back; its not a valid UUCP (or otherwise) mail path.
emv@math.lsa.umich.edu (Edward Vielmetti) (03/01/90)
In article <1990Mar1.044342.2928@haven.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: In article <8988@wiley.UUCP> david@wiley.UUCP (David Hull) writes: >The problem with this is that some newsreaders actually use the Path: >to route replies. These newsreaders are fundamentally hosed if they do this. Almost all of our news links are via NNTP, and you can't use the Path: line to send mail back; its not a valid UUCP (or otherwise) mail path. Well, you don't need to put "!" in the path -- RFC 1036 makes this perfectly clear. (Don't know how much news you'll break this way, anyone want to try?) heh heh heh, think of all those !s hard-coded on bitnet systems.... --Ed e.g. Path: zaphod.mps.ohio-state.edu, math.lsa.umich.edu!emv is legal! 2.1.6. Path This line shows the path the message 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 (except "." which is considered part of the hostname). Thus, the following are valid entries: cbosgd!mhuxj!mhuxt cbosgd, mhuxj, mhuxt @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM teklabs, zehntel, sri-unix@cca!decvax (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 fourth example was teklabs. Letters, digits, periods and hyphens are considered part of host 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 systems. 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 traveled to reach the local host.
david@wiley.UUCP (David Hull) (03/04/90)
In article <1990Mar1.044342.2928@haven.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >These newsreaders are fundamentally hosed if they [use Path: to route >replies]. Almost all of our news links are via NNTP, and you can't use >the Path: line to send mail back; its not a valid UUCP (or otherwise) >mail path. vnews (part of the B news distribution) and rn will both use Path: for the reply if INTERNET is not defined. However, my guess is that even most UUCP-only sites define INTERNET and have their mail systems forward addresses they don't understand to some site which does. That's what we do. In article <EMV.90Mar1020759@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >[Quoting RFC1036:] > 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 > traveled to reach the local host. Ah, but you left out the last paragraph in this section: Special upward compatibility note: Since the "From", "Sender", and "Reply-To" lines are in Internet format, and since many USENET hosts 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. 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 host name and an "!" at the front of the path, and of starting the path with the host name, an "!", and the user name, should be maintained when possible. -David