NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/vmsnet/mail/pmdf/2292

Internet Message Format | 1992-09-14 | 7.9 KB

Path: sparky!uunet!decwrl!infopiz!mccall!ipmdf-newsgate!list
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Limiting access to outgoing mail.
Message-ID: <[e-mail]>
From: Ned Freed <[e-mail]>
Date: 14 Sep 1992 00:07:28 -0700 (PDT)
Organization: The Internet
Return-Path: <[e-mail]>
Resent-Date: 14 Sep 1992 00:07:28 -0700 (PDT)
Resent-From: [e-mail]
Errors-To: [e-mail]
Resent-Message-ID: <[e-mail]>
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Lines: 151

>   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.

This isn't and has never been the conceptualization of a PMDF channel. A PMDF
channel is an n-tuple that collects together a transport, a protocol, a
collection of protocol usage characteristics, a collection of transport usage
characteristics, and a message queue. Any time you want these things to vary
you need another channel.

Look through the manual and you will see dozens of examples of channels being
used to collect characteristics that have nothing at all to do with the
selection of a host and protocol.

Actually, it is the use of host names on channels that's purely artificial. If
I had it all to do over again I'd completely remove the notion that there's
such a thing as a channel host name. This has always been a nonsensical
concept. Most channels either have many host names or no host names associated
with them. The insertion of host names into channel information is simply a
side effect of the channel selection process, which should have selected a
channel without reference to a channel host. Unfortunately this design choice
came from MMDF and was present in PMDF before I even knew what PMDF was, so it
is far too late to back out now.

> Anyway, on to the project at hand:

> ...

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

You need any of the keywords that affect queuing messages to the channel and/or
dequeuing message from the channel. Keywords that control messages originating
from the channel are not needed. This means you should have something like
this:

d_noexquota nox_env_to goldmail noexquota linelength 255 defragment
...

There is of course no harm in duplicating keywords that affect submission from
the channel. Since this channel is never used for submissions they have no
effect.

> 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:

> %MAIL-E-OPENOUT, error opening USER6:[GUESTS.ZZTEST_USER]MAIL.MAI; as output
> -SYSTEM-F-IVDEVNAM, invalid device name

>  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).

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

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

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.

So whether or not a given operation generates a quota error has to do with
RMS's handling of quotas, which in the case of indexed files is quite a story
in its own right. I suspect that a bunch of the operations RMS performs on
indexed files are done in places where it simply isn't possible to check
quotas. (RMS makes extensive use of various sorts of deferral mechanisms to
handle complex and costly operations like bucket splits.)

All this is a central point of my earlier message -- we cannot possibly
reproduce VMS MAIL's behavior since it is not documented and we cannot
rationalize much of it. Nevertheless, everyone seems to want it to work "just
like someone else was sending it using VMS MAIL". That's fine, but it
automatically costs in terms of self-consistency.

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

> %MAIL-E-OPENOUT, error opening !AS as output
> -RMS-E-CRE, ACP file create failed
> -SYSTEM-F-EXDISKQUOTA, disk quota exceeded

It seems that VMS MAIL has changed the error that is returned when a over-quota
condition is detected. It used to return SS$_EXQUOTA. It now returns
MAIL$_OPENOUT or MAIL$_WRITEERR. Unfortunately MAIL$_OPENOUT and MAIL$_WRITEERR
are both used for many other things; it is probably not acceptable to fail
messages unconditionally when this error is returned.

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, 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?

Yes, a change to VMS MAIL has done exactly this.

>  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.

It is entirely a VMS MAIL issue.

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

This is also a VMS MAIL issue.

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

And this is a change in VMS MAIL that nobody pointed out to me before. (There
is no way we can possibly check the hundreds of values VMS MAIL returns every
time there is a new release of VMS. We don't even have the layered products
necessary to produce many of them.)

I have completed modifications to PMDF to detect the new sort of error messages
VMS MAIL is now producing. I found several complexities and inconsistencies as
I was testing this stuff that I had never seen before, so I cannot say for sure
when we'll be able to fold this into production PMDF.

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.)

                    Ned