Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UUCP + MX = Ugly addresses

0 views
Skip to first unread message

Paul Simons

unread,
Feb 24, 1993, 9:50:31 AM2/24/93
to
I guess by now it's obvious that I am trying to get MX configured to met the nee
ds
of my site. I hope that my travails will help the next person. Is there a way
to
help MX convert UUCP headers such as:

CS.YALE.EDU!harvard.UUCP!WKUVX1.BITNET!list-mgr

to <list...@WKUVX1.BITNET> instead of:

WKUVX1.BITNET!list-mgr%harvar...@CS.YALE.EDU ?
----------
Paul G. Simons sim...@nuconvex.com
CONnecticut Valley Electric eXchange (CONVEX) 203.276.6435
Southington, CT, USA {yale,uunet!hsi}!nuconvex!simonpg

Earle Ake

unread,
Feb 24, 1993, 12:47:12 PM2/24/93
to
Paul Simons (yale!nuconvex.com!simonpg%har...@HARVUNXW.BITNET) wrote:
: I guess by now it's obvious that I am trying to get MX configured to met the nee

: ds
: of my site. I hope that my travails will help the next person. Is there a way
: to
: help MX convert UUCP headers such as:

: CS.YALE.EDU!harvard.UUCP!WKUVX1.BITNET!list-mgr

: to <list...@WKUVX1.BITNET> instead of:

: WKUVX1.BITNET!list-mgr%harvar...@CS.YALE.EDU ?

MX as of 3.1 or so will now use the UUCP rewrite rules if you want it
to. You can then rewrite the messy addresses as you want them to show up.
I have the docs for 3.0 in front of me so it must have been 3.1 where that
feature was added. Check out the current release notes and documentation for
more information.


-Earle
--
Earle Ake Internet: <a...@dayton.saic.com> NSI-DECnet (SPAN): 28276::ake

Eric Thomas

unread,
Feb 25, 1993, 12:58:35 PM2/25/93
to
In article <009689B1.95...@nuconvex.com>, Paul Simons <yale!nuconvex.com!simonpg%har...@HARVUNXW.BITNET> writes:
> help MX convert UUCP headers such as:
>
> CS.YALE.EDU!harvard.UUCP!WKUVX1.BITNET!list-mgr
>
> to <list...@WKUVX1.BITNET> instead of:
>
> WKUVX1.BITNET!list-mgr%harvar...@CS.YALE.EDU ?

And why should MX do that? Routing information has been placed in the address
and, while it is usually redundant, there is no way for MX to know for a fact
that trashing everything but the last token is going to result in a working
address.

Eric

ma...@infocomm.com

unread,
Mar 5, 1993, 2:36:17 AM3/5/93
to

Let me rephrase the original question/problem at least to how it applies to me.

I've just installed MX 3.2 on a trial basis running with UUCP transport.

I send a message which I explictly address as MX%"tcad!infopiz!mark" which
really does a bounce off of my UUCP neighbor site tcad, but the exact same
translations are done for any "bang" path style address. What leaves my system
is:

From infocomm.com!mark Thu, 4 Mar 93 09:56:23 PST remote from infopiz
Received: by infocomm.com (DECUS UUCP /2.0/2.0/2.0/);
Thu, 4 Mar 93 09:56:22 PST
Received: by infocomm.com (MX V3.2) id 188; Thu, 04 Mar 1993 09:56:20 EST
Sender: ma...@infocomm.com
Date: Thu, 04 Mar 1993 09:56:20 EST
From: Mark Pizzolato 415-369-9366 <ma...@infocomm.com>
To: tcad!infopiz!ma...@infocomm.com
Message-ID: <00968FFB.B...@infocomm.com>
Subject: test message to mx%"tcad!infopiz!mark"

Please note the "To:" address form that is generated.

The "Envelope" which is generated by the UUCP interface and appears as the B.
file to be transmitted contains a "C rmail infopiz!mark" which is as expected
AND seems to reflect any MAIL_REWRITE.RULES that may be appropriate (none
happen to be relevant in this case, other cases certainly do interpret the
rules correctly).

The problem is:
- the "To:" address as specified is only meaningful at my site and
should the next site in line want to examine the "To:" address for
interpretation and/or adjustment, the original meaning is not
preserved.

How can I coerce MX's configuration to simply preserve a "bang" form address
for the outgoing "To:" case here?

========================================================

When messages arrive MX seems to be rather agressive when interpreting and
transforming UUCP "From_" header lines. Although the "From_" header should
end up being a sort of last resort origin of a message, it seems that it
attempts to transform any path that may be indicated in the "From_" line to a
domain name form:

A message that arrives (before being processed by MX_RMAIL) with the following:

From infopiz!infocomm.com!mark Thu, 4 Mar 93 21:05:59 PST
remote from oms

Ends up in my VMS mailbox with a "From_" header of:

From infocomm.com!mark Thu, 04 Mar 1993 21:11:22 EST

Now, some of this might be considered OK at times since "infocomm.com!mark" is
a totally valid and unique address. I have another example that took:

From uunet.UU.NET!media!vnunet!twarfield Thu, 04 Mar 1993
19:36:12 EST remote from decwrl

And this ends up in my VMS mailbox with a "From_" header of:

From uunet.UU.NET!media.!vnunet.!twarfield Thu, 04 Mar 1993
19:36:12 EST

With the minor exception of the insertion of the extra "dots" after "media" and
"vnunet", I guess this is probably OK.

The bad news is that this message arrived in my mailbox with a "From:" header
of:

From: twarfield%vnunet%me...@uunet.UU.NET

which is possibly OK, BUT the incoming "From:" header started out as:

From: decwrl!uunet.UU.NET!media!vnunet!twarfield

My problem with the translation that happened is that what arrived will only be
replyable if all the nodes in the path will handle the % hack translation
correctly.

Am I the only one who thinks these translations aren't quite kosher?
If not, then:
1) how can I configure MX to avoid these undesireable translations?
2) how can we make the resulting configuration the default behavior for
a UUCP only site?

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE: (415)369-9366 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN: ma...@infocomm.com

Bob Pasker

unread,
Mar 5, 1993, 12:49:39 PM3/5/93
to
>ma...@infocomm.com writes about inhibiting translations

i have had similar undesirable translations take place. mail with

from_ well!user .....

after arrival on halfdome.sf.ca.us (the MX machine) wind up in VMS
mail FROM addresses of

mx%"user%well...@halfdome.sf.ca.us"

while i can reply to these addresses, they do seem somewhat bizarre.

i think the issue, mark, is that MX wants domain-style addresses and

mx%"foo!bar"

doesnt cut it. the foo%b...@site.domain tranformation at least gives
some semblance of domainishness, although the long bang-style
addresses you're seeing are quite unweildy.

--
--
-- bob pasker
-- r...@netcom.com
--

0 new messages