home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!gatech!paladin.american.edu!auvm!SIGURD.INNOSOFT.COM!NED
- Errors-to: epmdf@YMIR.BITNET
- X-Envelope-to: PMDF-L@IRLEARN.BITNET
- X-VMS-To: IN%"C.SANTANA@CGNET.COM"
- X-VMS-Cc: IN%"sross@cgnet.com",IPMDF
- MIME-version: 1.0
- Content-type: TEXT/PLAIN; CHARSET=US-ASCII
- Content-transfer-encoding: 7BIT
- Message-ID: <01GOSKG2NNFM984XOW@YMIR.CLAREMONT.EDU>
- Date: Tue, 15 Sep 92 09:02:18 GMT
- Sender: PMDF Distribution List <PMDF-L@IRLEARN>
- From: Ned Freed <NED@SIGURD.INNOSOFT.COM>
- Subject: RE: default host name as foreign host
- Newsgroups: bit.listserv.pmdf-l
- Lines: 61
-
- > I have been attempting to do the following:
-
- > In VMSmail, addressing a message To: in%username
- > (no quotes or host/domain)
-
- > Instead of this being translated to: username@localhost.localdomain,
- > I would like it to always translate to a particular foreign host.domain.
-
- You can do this sort of thing only if you resort to the VMSMAIL-TO-PMDF mapping
- in the mapping file. It is possible to do this there but doing so is incredibly
- dangerous. There are many portions of PMDF as well as other software that
- assume IN%username will translate to IN%"username@localhost". If you change
- this assumption you will probably break all sorts of things, and I cannot
- answer for the consequences.
-
- What you can do is assign a separate foreign protocol name to this function.
- This will work and should not disturb existing PMDF functionality. All you need
- to do is assign another MAIL$PROTOCOL_xxx logical to point at PMDF_MAILSHR. The
- mapping file will then let you handle this separate foreign protocol in a
- completely different ways. Please see the documentation (5.1) for details on
- how the mapping works.
-
- You can even reverse the effects of this mapping using the PMDF-TO-VMSMAIL
- mapping.
-
- All this means going to a lot of trouble to just to eliminate the need to type
- in a host name. This may appear at first glance to be a nice friendly thing to
- do for your users, but it usually ends up as a disasterous choice.
-
- Users really need to become familiar with the realities of addressing since
- they may not always be faced with a nice friendly system with all sorts of
- hacks like this around. (Or the next set of hacks will be totally different.)
- You're not doing anyone a favor when you hide reality from them -- you are
- simply making it much harder for them when they inevitably come face to face
- with real addresses.
-
- It might be worth it if we were talking about really ugly addresses here.
- However, Internet addresses are relatively clean and simple, and if the
- addresses you're using aren't nice and simple there are probably better ways to
- clean them up.
-
- So my best advice is that while you can do this sort of thing with PMDF do
- everyone a favor and don't even try to set it up.
-
- > I have tried setting the official-host-name of my local channel to
- > the foreign host, and then adding the local host name as the
- > local-host-alias for EVERY channel in the channel/host table.
- > This did not work (the FROM address of a local message was always
- > assigned to the foreign host/domain) and also seems a bit unelegant,
- > if not downright dangerous.
-
- The per-channel local-host-alias affects only messages being queued to the
- channel. It has no effect or meaning aside from this, and certainly will have
- no effect on the default host associated with mailbox-only addresses. It will
- affect outgoing mail and probably render it totally unrepliable.
-
- The official local host name is what's used for this purpose, but it is
- also the fundamental definition of your host's identity. You cannot change
- it without completely changing your host's identity as well.
-
- Ned
-