From:	MERC::"uunet!DRYCAS.CLUB.CC.CMU.EDU!vmsnet-request" 24-APR-1992 18:59:59.70
To:	mccall!vmsnet-newsgate
CC:	
Subj:	RE: Fixed: UUCICO.EXE with large pkt and windows 0/10

In article <1992Apr23.214119.4090@verifone.com>, jimmy_t@verifone.com writes:
> In article <1992Apr22.112750.11872@infocomm.com>, mark@infocomm.com writes:
>> The following 10 messages are a VMS_SHARE of an MFTU of the up coming version
>> of UUCICO.EXE, UUXQT.EXE and UUXQT_DCL.COM.  The UUCICO.EXE has fixes for the
>> known ACCVIO problems with large packets and/or windows > 3.  They should be
>> installed as a set since the UUCICO is the new version which will be formally
>> released in with our Atlanta Submission.  This version uses subdirectories of
>> your UUCP_SPOOL to recieve files from remote sites, so in order to properly
>> process incoming mail/news, the new versions of UUXQT.EXE and UUXQT_DCL.COM are
>> also provided.
>> 
> Does this UUCICO have the ability to translate to valid VMS filenames
> the wierd names generated by ATTMail?  I had to patch the previous
> version to handle.

Well, this is touching on a rather complex area to explain.  File names are 
now handled in a distinctly safer and more complete way, and as far as the 
needs of any mailer are concerned all required functionality "should" be 
present.

As for your explicit suggestion for a code change.  This code isn't appropriate
for how filename processing is currently being handled.  Please give examples
of the "wierd filenames" that ATTMail might be generating, and I'll make sure
that these types of names are correctly handled (they probably already are, so
please test it for me).

I'll delve into SOME of the rules that are in effect with the new code:

      - All inbound files that DON'T explicitly specify a path, will actually
	arrive in the per site subdirectory of UUCP_SPOOL.
      - All arriving files of this type MUST be named "D.something" or
	"X.something".  Any request to send a file named other than D. or X.
	will be rejected.

I NEED to know if the above rule is too restrictive for some remote
implementations.

      - Inbound file requests that DO explicitly specify a path, will now be
	ONLY be processed if the logical name UUCP_PUBLIC is defined similar to:

	$ DEFINE/SYSTEM/EXEC/NAME=NO_ALIAS UUCP_PUBLIC $DISK6:[uucp.public.]/translation=concealed

	AND the "path" specified in the transfer request MUST either explicitly
	or implicitly refer to UUCP_PUBLIC as the destination "device" of the 
	transfer.

	Example of allowed explicit references:

		UUCP_PUBLIC:[XXX]file.dat
		UUCP_PUBLIC:[000000]file.dat
		UUCP_PUBLIC:file.dat

	Example of allowed implicit references:

		~/XXX/file.dat			UUCP_PUBLIC:[XXX]file.dat
		~/file.dat			UUCP_PUBLIC:[000000]file.dat
		/usr/spool/uucppublic/file.dat	UUCP_PUBLIC:[000000]file.dat

Note:	The directory specified by UUCP_PUBLIC must be writable by the
	UUCP accounts for inbound transfers to work.  If not, then an
	appropriate error response is returned to the requesting host.

      - Remote requests to copy files out of the local machine are first
	enabled (still) by the UUCP_CFG:CONTROL. variable "enbrmtrcv". 
	All such requests must now either explicitly or implicitly refer to
	files in UUCP_PUBLIC.  The name translation rules for these requests
	are the same as for inbound requests (see above), and also require 
	READ permission by the uucp account accessing it.

      - All outbound traffic actually goes through UUCP_SPOOL as it always 
	has. This is why Mail, news and the uucp command don't have to be 
	changed for you to test this code.

      - The "file name" part of file specifications which reference UUCP_PUBLIC
	(explicitly or implicitly), are translated to a VMS valid name of they
	would not normally be an allowable VMS name.  Names with mixed case are
	also translated.  The rules for this special case name translation are
	the same as the rules for MultiNet's Name translation rules for NFS.
	I have the UUCP_PUBLIC directory NFS mounted on my Sun workstation and
	I can easily access files like:

		gcc-2.1.tar.Z

	which is stored on the VMS side as:

		GCC-2.1$5NTAR$5N$Z

Note:	An optional much more complex ACL based protection scheme will be 
	possible to influence protection access to files going to or coming
	from UUCP_PUBLIC will be available in the released code.

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com