NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/vmsnet/mail/pmdf/2186

Internet Message Format | 1992-08-25 | 5.1 KB

Path: sparky!uunet!europa.asd.contel.com!emory!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!simpact!inland!cmkrnl!infopiz!mccall!ipmdf-newsgate!list
From: [e-mail] (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with personal aliases
Message-ID: <[e-mail]>
Date: 25 Aug 92 19:31:56 GMT
Organization: The Internet
Lines: 96
Return-Path: <[e-mail]>
Resent-Date: 25 Aug 1992 12:31:56 -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

>     I think thast you're hitting me pretty hard on this one.
> While it may be documented that pmdf test is not appropriate
> to use for personal aliases, I didn't know and stepped into
> it.  It did seem reasonable - I'm sorry!

I don't know why you feel you're being "hit hard" here. I simply explained the
situation with TEST/REWRITE and why it is unlikely to change. This is certainly
not your fault -- it isn't anybody's fault -- it is just the way things have to
be given the nature of the various user agents we support.

It would be very nice if we could use one consistent mechanism for constructing
message headers. This is simply not to be since the world of user agents
contains far too much variety in this area for a single approach to ever make
sense. (The code to do this that's specific to VMS MAIL is well over 1000 lines
long and is scattered in over a dozen locations throughout the foreign
transport handler. It is pretty much impossible to simulate outside of this
environment.)

>    I am not responsible for the condition of the miriad of
> mishappen sendmails in the world.  Their purpose is just to
> haunt us all.

I just reread my original message and the only remark in it that is remotely
perjorative is directed at sendmail. I fully expect to be forgiven for yowling
about this wretched state of affairs; I certainly don't mind if you do so as
well!

As I pointed out originally, this bug in sendmail is generally not a problem
since it translates a header with no contents into an illegal header (which is
more or less the same thing insofar as replies go). It is simply a problem when
you're trying to figure out what header PMDF actually generated. Once things
pass through sendmail there is no hope of this being possible.

> > Finally, I don't know what you expected to get, but this is the expected
> > result when you use a persnoal alias that is marked private and noexpand.
> > If you want the alias to expand into the real address just mark it expand
> > and it will. If you want it to expand into an alias other people can use
> > mark it public.

> Again I have to plead ignorance.  I had to search for a while
> [for the manual as well as for the answer] to understand what you
> were saying.

I didn't have a manual handy (you didn't either apparently) to give you
page and section numbers. Sorry about that.

Note that the DB utility is capable of providing some limited help information
about what options are available. Use the ? key in the middle (or at the end)
of commands to get at this stuff.

> I note that I could only use the resultant address
> [when I used expand] if I set transport to in%.

Personal aliases are entirely a PMDF facility. They can only work in VMS MAIL
when you specify a transport that gets you to PMDF (usually IN%). VMS MAIL
doesn't know anything about them nor is there any possible way to tell VMS MAIL
about something like personal aliases. You have to use a transport selector (no
apologies to OSI for the terminology here); it is the only mechanism available
in VMS MAIL to activate PMDF and all its associated facilities (including
personal aliases).

> I couldn't come
> up with any suitable combination of quotes to get the address through.
> Is that correct?

I don't know what you mean exactly here. To use a personal alias in VMS MAIL
just type

    IN%alias-name

if alias-name is also a logical name you have to use

    IN%"alias-name"

to get around VMS MAIL's translation of logical names. (Once again, this
behavior is entirely due to VMS MAIL and has nothing to do with PMDF.)

You can also type something like:

    IN%"alias-name@localhost"

and it will work, but the @localhost is assumed and isn't otherwise necessary.

The To: and Cc: headers that will actually appear in your outgoing mail are
derived from a combination of the addresses you submitted via the transport
interface, the list of actual envelope addresses that results from the
expansion of the transport addresses, the contents of the various PMDF alias
files and databases, the original VMS MAIL To: and Cc: lines, and a large base
of essentially heuristic knowledge about how VMS MAIL operates.

The interaction of all this stuff is so complex and so full of heuristics that
it is unrealistic to even attempt to describe it in detail. However, if you
have specific questions about why something works the way it does I'll be happy
to analyze a specific case or six in detail.

                Ned