Errors-to: epmdf@YMIR.BITNET
Organization: St. Peter's College, US
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-VMS-Cc: IN%"ipmdf@ymir.claremont.edu",TERRY
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 13 Sep 92 13:19:29 GMT
From:         "Terry Kennedy, Operations Mgr" <TERRY@SPCVXA.SPC.EDU>
Subject:      RE: Limiting access to outgoing mail.
Newsgroups: bit.listserv.pmdf-l

> But this immediately begs the question of whether or not the existing channel
> mechanisms can be coerced into doing what you want. And of course the answer i
   s
> yes it can. All you have to do is create a new channel called d_noexquota that
> would look something like this:

  Well, I think that ease of understanding is getting lost in the effort to
have a conceptually clean design. Part of my problem in grasping some of the
subtleties about the way that PMDF works is probably due to this. I'd think
that a single "channel" per host+protocol with a configuration file that says
what actions are legal for addresses passed on that channel would be easier
to understand. However, I'll readily admit that you're lots more familiar with
this stuff than I am. Anyway, on to the project at hand:

>    l holdexquota
>    localhost
>
>    d_noexquota noexquota
>    noexquota.localhost
>
> And then you need some additional rewrite rules:
>
>    noexquota.localhost              $E$F$U%localhost@noexquota.localhost
>    noexquota.localhost              $E$F$U@localhost
>
> Finally, for each user that you want to restrict so they cannot exceed quota
> you would add an alias:
>
>    user:     user@noexquota.localhost

  Ok. I made these changes to my PMDF configuration (here's a VMS DIFF):

************
File PMDF_ROOT:[TABLE]PMDF.CNF;28
  224   ! Rewrites included from external files
******
File PMDF_ROOT:[TABLE]PMDF.CNF;31
  225   ! Rewrites to support the "no exquota" option
  226   !
  227   noexquota.spcvxa        $E$F$U%spcvxa@noexquota.spcvxa
  228   noexquota.spcvxa        $E$F$U@spcvxa
  229   !
  230   ! Rewrites included from external files
************
************
File PMDF_ROOT:[TABLE]PMDF.CNF;28
  238   d 733 nox_env_to goldmail linelength 255 defragment charset7 us-ascii ch
   arset8 iso-8859-1
******
File PMDF_ROOT:[TABLE]PMDF.CNF;31
  244   d_noexquota noexquota
  245   noexquota.spcvxa
  246
  247   d 733 nox_env_to goldmail linelength 255 defragment charset7 us-ascii ch
   arset8 iso-8859-1
************

  I also added an alias for my test userid, "zztest_user", in the aliases file:

! People who abuse quota and aren't allowed to get mail when over quota
zztest_user: zztest_user@noexquota.spcvxa

  Also, my full local channel definition (if it matters) is:

l nox_env_to goldmail holdexquota linelength 255 defragment charset7 us-ascii
[linewrap] charset8 iso-8859-1
spcvxa.spc.edu

  By the way, do I need any of these things on the d_noexquota channel?

  The user had 4 blocks in use. I set the disk quota to 3 + 0 overdraft and
sent the user a mail message. The user did _not_ have an existing mail file.
Here is what I got:

PMDF_ROOT:[LOG]D_NOEXQUOTA_MASTER.LOG;1
$ DECnet_compatibility_channel:
$ !
$ ! We now delivery it all with one invocation of MAIL_SERVER. Speeds things
$ ! up a LOT!
$ !
$ define/user outbound pmdf_root:[log]d_noexquota_master_dirlst_2020643E.tmp
$ run pmdf_root:[exe]list.exe
$ !
$ priv_list = f$setprv("SYSPRV, DETACH, BYPASS")
$ if f$logical("PMDF_MESSAGE_FILE") .nes. "" then close/nolog queue_file
$ open/read pmdf_message_list pmdf_root:[log]d_noexquota_master_dirlst_2020643E.
   tmp
$ !
$ local_loop_1:
$   mail/protocol=pmdf_mailshr
%MAIL-E-OPENOUT, error opening USER6:[GUESTS.ZZTEST_USER]MAIL.MAI; as output
-SYSTEM-F-IVDEVNAM, invalid device name
$   if .not. $status then goto local_loop_1
$ !
$ priv_list = f$setprv(priv_list)
$ close pmdf_message_list
$ delete pmdf_root:[log]d_noexquota_master_dirlst_2020643E.tmp;*

  Now, I don't know why the "invalid device name" message popped up. The
logical for USER6 is:

   "USER6" [exec] = "$1$DUA6:" [concealed,terminal] (LNM$SYSTEM_TABLE)

  The message is now sitting in the D_NOEXQUOTA queue. So, I sent the user a
mail message locally with VMS mail. That created the mail file just fine (I
have EXQUOTA).

  I then mailed a 284 block file to the user via PMDF. That generated the
following log file:

PMDF_ROOT:[LOG]D_NOEXQUOTA_MASTER.LOG;2

$ DECnet_compatibility_channel:
$ !
$ ! We now delivery it all with one invocation of MAIL_SERVER. Speeds things
$ ! up a LOT!
$ !
$ define/user outbound pmdf_root:[log]d_noexquota_master_dirlst_20206A43.tmp
$ run pmdf_root:[exe]list.exe
$ !
$ priv_list = f$setprv("SYSPRV, DETACH, BYPASS")
$ if f$logical("PMDF_MESSAGE_FILE") .nes. "" then close/nolog queue_file
$ open/read pmdf_message_list pmdf_root:[log]d_noexquota_master_dirlst_20206A43.
   tmp
$ !
$ local_loop_1:
$   mail/protocol=pmdf_mailshr
$   if .not. $status then goto local_loop_1
$ !
$ priv_list = f$setprv(priv_list)
$ close pmdf_message_list
$ delete pmdf_root:[log]d_noexquota_master_dirlst_20206A43.tmp;*

  For some reason, this got delivered. The user is now 300 blocks over quota.
Now, I try another test with a different file:

PMDF_ROOT:[LOG]D_NOEXQUOTA_MASTER.LOG;3

$ DECnet_compatibility_channel:
$ !
$ ! We now delivery it all with one invocation of MAIL_SERVER. Speeds things
$ ! up a LOT!
$ !
$ define/user outbound pmdf_root:[log]d_noexquota_master_dirlst_20206448.tmp
$ run pmdf_root:[exe]list.exe
$ !
$ priv_list = f$setprv("SYSPRV, DETACH, BYPASS")
$ if f$logical("PMDF_MESSAGE_FILE") .nes. "" then close/nolog queue_file
$ open/read pmdf_message_list pmdf_root:[log]d_noexquota_master_dirlst_20206448.
   tmp
$ !
$ local_loop_1:
$   mail/protocol=pmdf_mailshr
%MAIL-E-OPENOUT, error opening !AS as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
$   if .not. $status then goto local_loop_1
$ !
$ priv_list = f$setprv(priv_list)
$ close pmdf_message_list
$ delete pmdf_root:[log]d_noexquota_master_dirlst_20206448.tmp;*

  Ok, so this one correctly failed to deliver the message. However, the message
is still sitting in the D_NOEXQUOTA queue and no bounce message was returned. I
thought "noexquota" would yield an immediate bounce, rather than a retry? Is it
possible that this is being converted to "holdexquota" somehow?

  So, I believe I'm seeing 3 problems (or 3 aspects of one problem):

1) The MAIL.MAI file isn't being created (and a wrong error is generated) in
   this case. It may very well be a VMS MAIL issue, but if you could check it
   I'd appreciate it.

2) Some mail is getting through, even with noexquota set. Possibly it's only
   the first message after a mail file is created?

3) Mail which was correctly not delivered isn't generating bounce messages and
   is staying in the queue.

        Thanks,
        Terry Kennedy           Operations Manager, Academic Computing
        terry@spcvxa.bitnet     St. Peter's College, Jersey City, NJ USA
        terry@spcvxa.spc.edu    +1 201 915 9381
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU