Re: unavailable X.400 routing entries in the COSINE-MHS community

" (Tony Genovese)" <genovese@ophelia.nersc.gov> Fri, 19 March 1993 00:59 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18700; 18 Mar 93 19:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18696; 18 Mar 93 19:59 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa03220; 18 Mar 93 19:59 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 18 Mar 1993 18:51:06 +0000
Date: Thu, 18 Mar 1993 18:51:06 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..593:19.02.93.00.51.06]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Thu, 18 Mar 1993 18:51:06 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: " (Tony Genovese)" <genovese@ophelia.nersc.gov>
Message-ID: <9303190050.AA23533@ophelia.nersc.gov>
To: Allan.Cargille@cs.wisc.edu
Cc: ietf-osi-x400ops@cs.wisc.edu
Subject: Re: unavailable X.400 routing entries in the COSINE-MHS community

Hi Allan,
	
> Hi, I'd like to add my own thoughts on the routing problem.
> 
> First, I don't think that people who use PP and have Internet DNS
> access have a problem.  The reason is that any X.400 message that
> cannot be routed via X.400 is automatically gatewayed and delivered
> using 822 if a mapping rule is defined.
> 
	I have PP and DNS and I have a problem :-) But, you may be
correct, that it is an administation problem. Though, still viewed
as a serious problem.  Most mail going to the ESnet mail hubs is
SMTP. If this mail is to be routed via X.400 it requires that the 
domain table have entries that can be used  for x.400 mappings. If I 
am guaranteed (yea sure) that smtp works and x.400 may work - Why do 
X.400?  That is the question I am being asked.

> 
> Then there are two remaining problems, as Urs said:
> 
> (1) How does an X.400 MTA know what messages should be routed to an
>     RFC1327 gateway for delivery?
> 
> (2) The third-party problem -- unrouteable addresses can be introduced
>     into the GO-MHS community by third-party relay.
> 
> It's easy to solve problem (1) with a perl script.  All the mapping
> rules are known.  All the GO-MHS routeable X.400 domains are known.
> For every defined mapping rule, if the X.400 address cannot be routed
> based on the GO-MHS Domain entries, then that X.400 address should be
> routed to a gateway for delivery.

	This, on the surface sounds correct to me. It sounds like this
"tool" could build the PP domain table to only include domains that
the local MTA sould route. What I guess I do not understand, and yes
I know there is alot,  what is meant by forwarding to a gateway for
deliver. If the domain was not in my Domain table I would send it out
via SMTP. Or do you mean, in my case, I would somehow have an entry in 
my domain table that would route the message (via SMTP) to some other
MTA that manages the domain for the intended recipient. And this MTA
will do the right thing with the message. i.e. forward via X.400 or SMTP 
which ever the recipient wants?

> 
> This solution could also be implemented using the GO-MHS WEP and
> DOMAIN document structure by introducing a "local-gateway" Domain
> document.  (Someone else already proposed this solution - Urs?)

	I don't understand, what does a local-gatewey domain document
do for me? What infromation would be in it? How would it work?

> 
> I don't see an immediate solution to problem 2.  Perhaps someone else
> can see one?

	This is what I remember as the historic question about routing this
group has delt with. Was there any consensus on the problem definition or 
solution? 


So, do I understand there is to topics for the IETF discussion:

	1. New domain tool or rfc1327 routing info

	2. The Third-party problem

I do not beleave a hallway discussion is enough for me. If You beleave
this is a simple problem could Urs or Allan write a "simple" position
paper. I beleave Allan's message is a damn good start at identifing and
proposing solutions. The discussion can be on the list with a small slot
at the IETF.

Thanks for the insight,

Tony...