Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: kehres@touch.COM (Tim Kehres)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: UUXQT Problems with X.400 encoded O/R Names
Message-ID: <9102250732.AA15991@earth.touch.com>
Date: 25 Feb 91 20:04:32 GMT
Lines: 34
Approved: usenet@ICS.UCI.EDU
X-Mailer: ELM [version 2.3 PL0]

A few months ago there was some discussion regarding the problems with
the sending of X.400 O/R Names through a System V UUCP channel.  Most of
these discussions I am assuming were in somewhat private circles, and as
far as I can tell, nothing has come of them.

The problems were in reference to the UNIX HDB UUCP utility, UUXQT
consulting the Permissions file and determining that the supplied address
represented a file name (the leading '/'), and then refusing the
transaction based upon improper access to this file name.  For example,
the following address would cause this problem:

	/c=us/admd=sprint/prmd=touch/s=kehres/@somewhere.com

Has anyone had any further experience with this problem?  As we left it,
the only workaround we found was to totally relax the permissions to allow
reading and writing from the root directory (not a very nice solution).

I have heard unconfirmed rumors that AT&T's response has been that they
had no intention to do anything about this except in cases where it could
effect AT&T Mail.  Has anyone heard anything else regarding this, either
to confirm this, or to prove it false?  Please don't misinterpret me here,
I am not out to get AT&T, in fact I am hoping AT&T might be able to prove
the rumors wrong and provide an industry wide fix to this problem.

This is a significant problem since it effects *all* sites running HDB
UUCP, regardless of the vendor (Interactive, SCO, and HP as well as many
other implementations are all effected).

Any insight regarding other workarounds, or fixes would be greatly
appreciated.

Best Regards,

Tim Kehres