From: CRDGW2::CRDGW2::MRGATE::"SMTP::CUNYVM.CUNY.EDU::POSTMAST%YMIR.BITNET" 14-JUL-1989 02:46 To: MRGATE::"ARISIA::EVERHART" Subj: RE: PMDF and DELIVER, take 2 Resent-From: @CUNYVM.CUNY.EDU:postmast@YMIR.BITNET Received: from YMIR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 0573; Fri, 14 Jul 89 02:30:53 EDT Resent-Message-Id: <84B2D7807A1FE07BAA@YMIR.BITNET> Message-Id: <84B43130E03FE000A4@YMIR.BITNET> Received: from JNET-DAEMON by YMIR.BITNET; Thu, 13 Jul 89 23:06 PDT Received: From SPCVXA(TERRY) by YMIR with Jnet id 5702 for IPMDF@YMIR; Thu, 13 Jul 89 23:06 PDT Resent-Date: Thu, 13 Jul 89 23:08 PDT Date: Fri, 14 Jul 89 02:01 EDT From: "Terry Kennedy, Operations Manager" Subject: RE: PMDF and DELIVER, take 2 Resent-To: INFO-PMDF-LIST2@YMIR.BITNET To: ipmdf@YMIR.BITNET Errors-To: postmast@YMIR.BITNET X-Vms-To: IN%"ipmdf@ymir" A few days ago, I wrote: > We are experiencing a different problem with DELIVER. It seems that > certain DEC programs using CALLABLE mail (not yet documented or sup- > ported outside DEC) fail when the user has deliver in use. For exam- > ple, VAX Notes reports "No such user in UAF". However, if the user > has (some yet undetermined set of) privileges, it works, even if they > are not enabled (set in AUTHPRIV, not in DEFPRIV). Very strange. > Also, sending to username or node::username fails, but 0::username > works. Very odd indeed. Since then, I have discovered the following: 1) The privilege required is SYSPRV. I am not sure where the problem is, but it definitely manifests in VAX Notes (a DEC product using callable mail). 2) A simple work-around is to use deliver in the following way: SET FORWARD 0::DELIVER%"""username""" where username is your username. This forces things to go through the network. It appears that either Notes or callable mail is trying to determine the forwarding address and use it directly. Unfortunately, they do not recognize foreign protocol hooks, so it checks for a user- name of "DELIVER%username", which of course does not exist in the UAF. Of course, this solution adds a bit of network overhead, but at least it works. Anyway, the problem is with VMS and not with DELIVER.