Newsgroups: vmsnet.mail.pmdf
Subject: RE: Limiting access to outgoing mail.
From: "Terry Kennedy, Operations Mgr" <terry@spcvxa.spc.edu>
Date: 14 Sep 1992 08:40:32 -0400 (EDT)
Organization: St. Peter's College, US
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 08:40:32 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GORI6ICB6Q984UWP@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@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

[We had a power failure while I was editing this reply. Hopefully the journal
file recovered everything. Please let me know if something seems chopped at
the wrong place].

> This is entirely a VMS MAIL issue. I cannot reproduce it on my system here. I
> have no recommendations for how to fix it.

  That's odd. I've reproduced it a number of times here. I can get it to fail
100% of the time. In case it matters, here's the version info from the various
parts of VMS MAIL:

SYS$COMMON:[SYSLIB]MAILSHRP.EXE;1
		image name: "MAILSHRP"
		image file identification: "X-9"
		link date/time: 12-OCT-1991 04:43:53.93
		linker identification: "05-09"

SYS$COMMON:[SYSLIB]MAILSHR.EXE;4
		image name: "MAILSHR"
		image file identification: "X-9"
		link date/time:  8-JUL-1992 14:46:49.83
		linker identification: "05-13"

SYS$COMMON:[SYSEXE]MAIL.EXE;2
		image name: "MAIL"
		image file identification: "X-10"
		link date/time: 12-OCT-1991 05:04:57.58
		linker identification: "05-09"

	Patch Information

		DEC eco levels   1- 96: %X'00000004', %X'00000000', %X'00000000'
		user eco levels 97-128: %X'00000000'
		read/write patch area address: %X'00013615', length: 491
		read-only patch area address:  %X'00000000', length: 0
		patch command text VBN: 158
		last patch date/time: 25-AUG-1992 20:19:19.79

	PATCH TEXT

	VMI$EXE
	SE EC
	^X00000003
	INSE /I
	^X00005EA0
	'MOVC5 #^X00000000,(SP),#^X00000000,#^X00000058,W^^X00000094(SP)'
	'MNEGW #^X00000001,W^^X0000009C(SP)'
	EXI

  I'll report this problem to DEC, where I'm sure it will receive the same
prompt attention that the "unbalanced quote" problem has - NOT!

> This is once again entirely a VMS MAIL issue. I have no way of knowing how VMS
> MAIL implements, extends or modifies quotas. I have seen similar things happen
> and I have seen much stranger things happen. A lot of strange effects are
> explained by the fact that VMS MAIL doesn't check quotas per se; it simply
> reacts to quota errors and handles them cleanly by backing out all traces of
> the incomplete delivery.

  It turns out that Jnet was installing MAIL.EXE with EXQUOTA. I turned that
off and I haven't seen this problem happen again.

> This actually may be a change in VMS proper that VMS MAIL hasn't picked up on
> yet. There's code in VMS MAIL to deal with SS$_EXQUOTA, but the STV error we're
> seeing here is SS$_EXDISKQUOTA. I suspect that this got changed as part of the
> big "let's fix quota/privilege errors to be more specific" move that started
> around VMS 5.2. (SS$_EXDISKQUOTA is third from the end of the SS$_ error list,
> which means it is one of the most recently added errors.) If this is in fact a
> case of VMS MAIL not picking up on the change it just means we have to add VMS
> MAIL to the very long list of applications that have been adversely affected by
> these changes.

  Ok. I'll report this one as well.

> Until I can add support for this into PMDF there is no way to get noexquota to
> bounce messages immediately. (You can of course use the notices mechanism to
> bounce all the mail within a day. Originators don't get an indication of what
> the real problem is but then again they probably don't need to know its a disk
> quota problem.)

  So if I put "notices 1" on the d_noexquota channel then this will bounce them
after one day? And it won't affect anything else?

	Terry