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" <TERRY%SPCVXA.BITNET@CUNYVM.CUNY.EDU>
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.
