Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 29 Sep 92 05:31:41 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Internet mail address in RFC 822 header
Newsgroups: bit.listserv.pmdf-l

>    Let me see if I can pose this question a slightly different way,
> since I'm guessing, based on a few recent experiences, at what is going
> on here.  If my guess is wrong, consider this a separate question...

The original question centered around problems relating to registration. These
are essentially separate issues from the ones you raise below.

>   Let's assume that I've got a situation in which most of my users have,
> or can have, VAX-based mail accounts (VMSMail and, in some cases,
> anxiously waiting for your UA, plus maybe an MM user or two).  And many
> of them have access to LAN-based and/or weird-protocol products that
> have the same symptoms as the list in the original message: at least for
> sending purposes, mail is travelling out via MR.  This typically gives a
> given user at least two addresses: something of the VMSMail/easy-RFC822
> persuasion (vms-userid@domain) and something of the X.400 persuasion in
> the local-part.

Standards-track algorithmic mappings between X.400 addresses and RFC822
addresses currently exist. See RFC1327 for details. As far as I can tell, there
are three problems with them:

(1) Not enough vendors use them -- they are nowhere near universal enough.
(2) The mappings make use of X.400 functionality that not all X.400 systems
    support.
(3) The mappings are somewhat inflexible and don't cater to site-specific
    needs very well.

>   I want only the easy-RFC822 addresses to appear "outside": whether the
> user originates mail in one environment or another should be invisible
> to external users and, if the user switches receiving/delivery
> environments back and forth, that should *clearly* be invisible outside.

This is definitely a goal.

>   Now, the question is "how to do that?".  Clearly the reversal database
> works, but, if I correctly understand things, I've got to include one
> record in it for each user with an X.400-ish address, rewriting that
> address into a simple-822-mailbox address.  But those X.400-ish things
> clearly obey patterns, since the local mail administrator controls most
> of their content if not their actual syntax.

This is the key part of doing it right. When we implemented PMDF-MR we took the
time to fully understand the nature of standard algorithms. We also paid
special attention to their limitations. The PMDF-MR rewriting facilities were
the result. These facilities make it rather trivial to implement the standard
algorithms. But many other algorithmic approaches can be used as well. For most
sites once the correspondence that's needed between X.400 and the RFC822 worlds
is understood it can be implemented in the FROM_MR and TO_MR databases.

There are a few problems with this approach:

(1) Some sites have made extremely poor choices that complicate the task
    enormously. For example, some sites have implement ALL-IN-1 user names of
    the form "lastname, firstname". Now, nobody in their right mind would have
    used such a format in either the RFC822 world or the X.400 world. So
    this presents problems for conversion to either one, and we don't have
    facilities to deal with this in the FROM_MR and TO_MR files. The solution
    here is to use the reverse and forward mappings (not the databases). These
    are capable of undoing this sort of mess without too much muss or fuss.
    Other poor choices at a structural level below that of various parts of
    an address are best dealt with this way.

(2) The FROM_MR and TO_MR rewriting databases are extremely complex and
    difficult to work with. What else can I say? They perform an enormously
    complex task and deliberately leave a lot of stuff undecided. There is
    really no way to make them any simpler without sacrificing functionality.

(3) Certain aspects of the FROM_MR and TO_MR mechanism are somewhat
    counterintuitive. People persist in thinking that this is a pattern
    matching mechanism. It is nothing of the kind. The rewrite operation
    has to be bounded on the size of the object being rewritten (which can be
    large but is never enormous) and not the number of rules in the database.
    The pattern matching dog won't hunt under such constraints.

(4) There are probably things I didn't think of that people will want to do.
    The only solution here is to report them and we'll see about enhancing the
    mechanism in future releases. PMDF-MR V4.1 is much more powerful in this
    regard than V4.0 was.

>   So, the revised question (or at least my revised question) is "given
> that I can state a rule that maps the X.400-like addresses given to
> users onto the VMS User IDs we give out, is there a way to apply that
> rule to rewrite the local-part of outgoing mail so that I don't have to
> list every single user in the address reversal database?"

As described above, such rules are best implemented structurally as part of the
PMDF-MR rewriting mechanism. If this does not work these things can always be
done using the forward and reverse mapping facilty of PMDF proper. This will
work nicely PROVIDED you can state the rules simply and comprehensibly. Thus
far my experience has been that structural rewriting is superior to text
mapping in most, but not all, cases. I'd have to know the details of the
transformation you need to assess your situation specifically.

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