Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"DPMSYS%RITVAX.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 6 Sep 92 10:50:29 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Using DELIVER
Newsgroups: bit.listserv.pmdf-l

> I know this has been covered on this list before, but can
> someone explain again why the VMS forwarding address cannot
> be used as the determinant for the execution of DELIVER.

PMDF has to be the entity that determines whether or not integrated DELIVER is
used. This is fundamental -- integrated DELIVER depends on the knowledge that
it is processing a PMDF-originated message. If the mail first passed through
VMS MAIL all the advantages of integrated DELIVER would be totally lost.

This then implies that PMDF would have to react to the forwarding addrtess
before VMS MAIL gets the message. But only VMS MAIL knows about its forwarding
addresses. PMDF doesn't know what these addresses are or how to interpret them.

It is simply not practical to try and teach PMDF about VMS MAIL forwarding. VMS
MAIL forwarding is very complex, very non-intuitive, and any attempt to unravel
it would result in all sorts of hideous bugs until we got all the semantics
issues worked out. It would also be a big layering violation -- we have no
business dealing with data that's private to VMS MAIL. (Note that dealing with
incoming addresses from the foreign interface is a totally different matter
that has no real relationship to general forwarding address handling.)

The task of just identifying a PMDF forwarding address that points at DELIVER
is arguably simpler, but not enough to matter. Don't underestimate the
complexity here -- we're talking about something that hard, that has numerous
serious pitfalls, and probably would take many iterations to get right.

Finally, one of the key uses of integrated DELIVER is to conditionally handle
certain mail and leave the rest available for "normal processing". Part of that
"normal processing" may involve dynamic use of forwarding addresses. But this
isn't possible if you've used up your forwarding facilities on firing up
DELIVER. This is another facet of the layering violation that's implicit in
this suggestion -- it would put the cart before the horse insofar as most uses
go.

It is therefore impractical, perilous, and totally inappropriate for PMDF to
use forwarding address values to determine _anything_.

> I recently encountered the following senario:

> A user runs PMDF with integrated DELIVER on his home
> machine (TECHNO).  On another machine (VAXA) which also runs
> PMDF with DELIVER disabled he has his forwarding address set
> to forward mail to his home machine.   His login directory on
> VAXA is his home directory on TECHNO mounted on VAXA via
> DEC's DFS.

PMDF and DELVIER aside, this is an extremely dangerous setup. DFS interacts
very poorly with VMS MAIL because of VMS MAIL's use of shared indexed files.
DFS cannot support this sort of shared access, and VMS MAIL is not prepared to
deal with the errors that result from collisions across DFS.

Based on very nasty prior experience I would never put this strategy into
production use. I personally have seen this cute little trick cause huge
problems, up to and including the silent loss of lots of mail. "Minor" problems
are usually things like finding your entire cluster wedged tight on Monday
morning.

Incidentally, using NFS doesn't offer a viable alternative. NFS would get
rid of most of the wedging problems at the expense of risking total
corruption of any ISAM database you happen to have (like VMS MAIL folders).

> This all worked fine until I enabled DELIVER on VAXA.  PMDF
> ignored the forwarding to TECHNO and instead processed all
> mail to his account on VAXA using his mail.delivery file
> from TECHNO.

What you have here is basically an impossible situation to resolve. You have
built an environment where users and the software they use has to be able to
tell what system is in use. But you have provided no reasonable mechanism (like
different home directories) for them to use to distinguish one environment from
the other. You therefore force sensitivity to environmental issues into every
single application that anyone writes or uses on your system.

> I realize there are workarounds such as defining different
> mail.delivery file names for different nodes, but what are
> the reasons for allowing the file to override a forwarding
> address.

The fundamental reason is simple -- DELIVER programming logically occurs before
delivery to the user agent is done. Forwarding in the user agent (which is
_very_ different from forwarding at the MTA level) is therefore a step that's
taken after DELIVER programming and not before.

We thought all this through very carefully when integrated DELIVER was
originally added to PMDF. Various orderings were considered including the one
you describe.

Defining different MAIL.DELIVERY files would provide a means for users to
distinguish between different environments. But users still have to code around
the differences. We could provide access in the MAIL.DELIVERY file to node
information to make this sort of thing easier. It would make it possible to
program things in a node-specific way. But the underlying problem remains the
same no matter what.

Another theoretical approach would be to completely eliminate the need to
distinguish between the environments. This would in turn eliminate the need to
forward mail from one place to the other -- why bother if the environments are
identical? However, this simply cannot be done using DFS, NFS, or any other
tool I know of short of actual VMS clustering.

> If there are no technical limitations to letting
> the ~forwarding address be the deciding switch, can the switch
> be defined in the PMDF option file.

There are good technical reasons as well as excellent strategic reasons for not
doing this. This is therefore extremely unlikely to ever get implemented in
PMDF.

However, in my opinion DELIVER usage of this sort is the very least of your
problems -- you simply have a big accident waiting to happen here.

                                        Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU