Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jarthur!ucivax!gateway From: kehres@ima.COM (Tim Kehres) Newsgroups: comp.protocols.iso.x400.gateway Subject: Re: UUXQT Problems with X.400 encoded O/R Names Message-ID: <9103061855.AA12958@ima.com> Date: 6 Mar 91 19:40:39 GMT Lines: 87 Approved: usenet@ICS.UCI.EDU In-Reply-To: <9103060945.aa17310@Obelix.TWG.COM>; from "David Herron" at Mar 6, 91 9:45 am X-Mailer: ELM [version 2.3 PL0] David, > > > This "problem" exists for ALL implementations of UUCP. At least, > > > for all the ones I've seen (since V7), .... > > > > This does not appear to be the case. My experience with 4.3 BSD UUCP has > > shown this not to be true, and my tests with 4.2 have shown there not to > > be a problem as well. It seems to be limited to HDB (and possibly to the > > old System V version) of UUCP. > > Hmm.. I just glanced into the 4.3-tahoe source we have on line here > and in chkpth.c:chkpth() was code which looked exactly as I expected. > Namely, it checks a string to see if its prefix is in the "path table" > which is read out of USERFILE. It presumes that the string is a rooted > path name & fails if it doesn't begin with a '/' & fails if it doesn't have > a prefix in USERFILE. The 4.3-tahoe source I believe came out after the original 4.3 release. My understanding is the tahoe (and then reno) stuff is all post 4.3 and not identical. It could very well be that these versions have attempted to emulate the HDB software in this regard. Aside from looking at source code fragements, actually try to send messages through this software. This is what I have done, and as stated, encoded O/R addresses *do* get properly passed with stock 4.2 and 4.3 UUCP's. In the end the only thing that matters is the behavour of the software, not an individual code fragement. Regarding the validity of UUCP security checking in this context: > No I still disagree. Every version of UUCP I am familiar with (my familiarity > starts with V7..) has checked the arguments to remote command requests as > if they were file names. `uuxqt' has no idea at all what sort of command > it is executing .. it only cares that it executes it and gathers up its > standard output & mails that back to the requestor. Therefore it cannot > make the assumption that `rmail' is `safe' because everything on its command > line is e-mail addresses -- it simply does NOT know this! Again, please try sending these types of messages through the various types of UUCP, and you will find that the behavour differs depending upon the version. Regarding UUXQT knowing what it is executing, the folks at ISC looked into the HDB code, and found that this was not really the case. If you think about it for a bit, UUXQT has to know, since what it runs is controlled by the contents of the Permissions file. All it has to do is to check for rmail, and if this is the case, let rmail handle any error checking. > Also note that X.400 addresses can contain all sorts of fun characters, some > of which will cause problems when passed through a /bin/sh command line. This > is another little detail of doing commands via UUCP -- that commands are > executed via a shell. Sorry, I don't buy this one either. The messaging world is much bigger than just those hosts running UNIX. It is not proper to make rules (or artificial limitations) based upon what type of host your message may be automatically routed through. From my experience with UUCP (much longer than I wish to admit), I have yet to see messages get lost (or bounce) due to this type of problem. Note that I am not saying it is impossible, just not something that is a practical concern at this time. > occasionally some vital quoting is lost. This problem will be worse with X.400. > > At any rate I can't fault UUCP for erring on the side of caution, even > if its slightly paranoid caution. And yes you can If there is quoting present in the rmail command, this is an error on the side of originating UUCP side. Just as in 821, there are times where the comments and phrases of 822 are not proper - namely in the envelopes. > > Please note that the assumption that I am making is that we > > should be able to transfer 822 compatible messages across a UUCP link. > > with the caveat that quoting will be stepped upon. This is done thousands, > if not millions, of times a day in the UUCP portion of the matrix. Address of the form: "Full Name" are not passed in this form through rmail, but rather in the message header. What is passed through rmail is "user@host.domain". Regards, Tim Kehres P.S.: Perhaps the discussion of UUCP specific issues should be continued off this list since it is probably not of general interest to this list.