Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"berman@williams.EDU"
X-VMS-Cc: IPMDF
Date:         Wed, 15 Apr 92 23:54:00 PST
From:         "Ned Freed, Postmaster" <NED@HMCVAX.CLAREMONT.EDU>
Subject:      RE: Rule matching left of the '@'
X-To:         berman@williams.EDU, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> This may be a wierd question, but is there any way to to rule matching
> in the username section of the destination address.

The short answer is no, it is not possible to do this. However, I don't
think this is a good solution to your problem anyway.

> We have a situation
> where all of out internet mail routing is handled by a unix box to which
> PMDF sends all out outbound mail and from which it receives most
> inbound. The exception is BITNET mail which comes directly to our VAX
> via an IP encapsulated JNET link. We are currently advertising
> addressing of the form firstname.lastname@Williams.EDU for Internet
> addressing and are running in to situations where people will try to use
> that form from BITNET.

You did not say whether or not you implemented this transformation in
PMDF or not. If you implemented it in PMDF using the address reversal
database, this should not present any problem for you. The reverse
database in PMDF only converts the addresses after they have been
rewritten. This rewriting process includes the substitution of the
proper BITNET alias for the local host into the address. As a result you
should never see firstname.lastname@williams.edu on BITNET channels.

It is actually something of a problem that things work in this order.
Some people actually want to rewrite after the address reversal database
has been applied. PMDF V4.1 has the capability to do this plus a lot
more stuff; the reversal capabilities are now much more powerful
overall.

However, what I think you have done is implement this transform on your
router box. I think you have made a big mistake in doing this. It is not
that you're trusting a UNIX box, probably running sendmail, to do this
sort of thing (although I personally would never trust sendmail to do
this right). The problem is that you're rewriting the username part but
not the host name. This means that for a given address you have no way
of knowing a priori whether or not it needs to be transformed. And this
is very bad, and is just going to cause you endless trouble no matter
what you do.

The solution is to modify the rewriting process so that the domain name
changes along with the left hand side. You may want to change the domain
name for your VMS system (maybe just for mail, maybe more generally).
Then you can just route stuff of the form user@williams.edu over to the
UNIX box and get it rewritten.

> Worse than that, we have run into at least one
> situation where the foreign mailer, smoehow realizing that Williams was
> on the BITNET remapped Williams.EDU to Williams.BITNET.

If any mailer is doing this it is seriously broken. It might just be
reasonable to substitute an Internet address for a BITNET address, but
only when such a substitution is specified in the BITNET node entry.
Regardless, it is never, ever reasonable to do the converse. You should
start complaining very loudly to the management of the systems that are
doing this, and if you don't get satisfaction you should raise the issue
with CREN.

As far as I can tell you don't have a registered BITNET gateway. If you
do in fact have such a thing then you can expect to get all sorts of
to first.last@williams.edu that never passes through your router. This
is what BITNET gateways are for.

> A solution to this would be to parse the "." on the left of the "@" and
> send the message to our primary mail router for delivery. We really
> don't want to enter all the aliasing to translate first.last to username
> in two locations.

In effect this relies on the fact that your local addresses don't have
dots in them while the aliases do. Unfortunately, this is something
that's beyond your control in general. For example, a PMDF user is able
to set up subaddresses that contain dots. These would totally confuse
your proposed solution to this problem. Another example is the case of
%-hack routing -- this is a place where dots may indeed appear inside of
a local part but not be what you think they are.

The bottom line is that assumptions about the format of the local part
of addresses are something you should not make. Using this information
for purposes of routing is very dangerous. You may be able to get away
with it. In fact, you may be able to hack PMDF to handle this stuff in
the way you say. But it will be hacking, and I don't recommend it. What
I do recommend is putting the information where it belongs, that is,
associating your "shadow domain" of aliases with a domain name other
than the one you use on your local host.

Another solution is to take your list of aliases and build an alias
database with them. Once you install this database you'll effectively
give PMDF the ability to do this conversion. Keeping the database in
sync should not be that hard; just build an automatic application to get
the mapping file and rebuild the database every day or so.

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