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

Internet Message Format | 1992-09-11 | 6.4 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: 11 Sep 1992 15:16:26 -0700 (PDT)
Organization: The Internet
Return-Path: <[e-mail]>
Resent-Date: 11 Sep 1992 15:16:26 -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: 108

>   I'd like to be able to specify keywords to override the channel parameters
> or the PMDF defaults as well. That way, I can set holdexquota as a channel
> keyword and noexquota for a particular "problem" user. Likewise, I can set
> sendpost/nosendpost for delivery errors to this address.
>
>   What do you think?

Dan already addressed the issue of doing this generally. Let me add one
preliminary point to this: such a change if done generally (all channel
keywords can operate in a per-user manner) would violate a big chunk of the
design philosophy behind PMDF and is therefore unlikely to occur, quite
independent of how hard it is to do. We are perfectly willing to consider this
on a case-by-case basis though.

Now let's get down to specifics and consider the keywords you're interested in
here. It is important to first note that PMDF channel keywords take effect in
all sorts of different ways -- some affect messages as they are enqueued,
others affect dequeuing, and some only establish environmental conditions for
the act of enqueing or dequeing.

The quota-related keywords fall into this last category. We don't implement
them ourselves -- it is not possible for us to implement them ourselves. We
simply establish an environment that causes VMS MAIL to do what we want.

The result of this is that we have absolutely no fine-grain control of the
effect of these keywords. Moreover, no amount of hacking short of rewriting VMS
MAIL from scratch will produce such fine grain control. In other words, we set
up the quota strategy before we pass a list of addresses and a message off to
VMS MAIL. That quota setting affects all addresses equally. The obvious way we
could achieve finer control is submit each address one at a time in a separate
session with VMS MAIL.

The result of doing this would be a huge increase in overhead -- probably a
factor of 5 or more for every message delivered to VMS MAIL. And there is
nothing we can do to lessen it; most of the overhead is in VMS MAIL and not
PMDF. Needless to say, this is not a realistic avenue to pursue.

So is there another way? Of course there is. We can split up addresses by their
quota characteristics and deliver each distinct quota group separately. This
means writing out separate copies of messages queued by group and acting on
them with separate processing facilities.

What I have just decribed is the bare minimum necessary to solve the problem.
It is also a very close match to a PMDF channel. In other words, in order to
get the effect you want to have on a per-user basis we would have to duplicate
all the functionality in PMDF we already have that separates things out by
channel. There is no real difference except that one directory would be
involved and not two. Such a distinction is simply not worth the trouble
involved in implementing it all.

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 is
yes it can. All you have to do is create a new channel called d_noexquota that
would look something like this:

    l holdexquota
    localhost

    d_noexquota noexquota
    noexquota.localhost

And then you need some additional rewrite rules:

    noexquota.localhost              $E$F$[e-mail]
    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:     [e-mail]

I have not tried this myself but I don't see any reason why it won't work.  It
will have the side-effect of blocking the ability of these users to use
DELIVER. However, since DELIVER can be used to bypass quota checking this is
probably a good thing.

Now let's move the discussion on to the sendpost/nosendpost issue. These
channel keywords fall into the category of things that PMDF acts on as  a
result of the effects produced by calling some other entity. In the case of the
local channel the entity is VMS MAIL. And right away we run into trouble again.
The results returned by VMS MAIL relate to the original address list in a
highly nontrivial way. Much of the complexity in PMDF's local delivery
facilities is devoted to attempting to track this relationship. But it is
simply not possible to do it accurately in all cases. Most of the time this
does not matter, since all we're interested in is whether or not we need to
issue an error, requeue the message, or toss out the address. But it begins to
break down when you start talking about specific handling conditional on the
address and exact sort of error that was reported. We had code back in VMS 4.x
to actually walk around in VMS MAIL's internal data structures trying to
recorrelate things, but this code became less useful in VMS 5.x because of the
elimination of lists in forwarding addresses, so we decided it was more
dangerous than the accrued benefits and dropped it.

The net of all this is that it once again is only possible to insure proper
per-user sendpost handling is done only if we group the addresses in advance by
sendpost setting. So we're back to the same problems that per-user quota
restrictions present, albeit for somewhat different reasons. And once again the
only efficient solution amounts to creating what amounts to a separate channel,
and once again it is easy to cobble this up by using existing facilities.

I'm pretty sure there is no general moral here. I have only considered two
channel keywords, and in both these cases implementing them on a per-user basis
was only possible by creating another channel (either visibly or invisibly).
Other things like access control definitely won't work out this way, and Dan
has already described our proposed per-user access control facility. It now
remains to consider any other cases as they come up.

                Ned