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

Allan Cargille <Allan.Cargille@cs.wisc.edu> Thu, 18 March 1993 21:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15197; 18 Mar 93 16:08 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15193; 18 Mar 93 16:08 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa24305; 18 Mar 93 16:08 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 18 Mar 1993 14:24:44 +0000
Date: Thu, 18 Mar 1993 14:24:44 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..730:18.02.93.20.24.44]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Thu, 18 Mar 1993 14:24:43 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allan Cargille <Allan.Cargille@cs.wisc.edu>
Message-ID: <930318142428*/G=Allan/S=Cargille/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS>
To: rd-mhs-managers@cosine-mhs.switch.ch
Cc: "Allan C." <Allan.Cargille@cs.wisc.edu>, ietf-osi-x400ops@cs.wisc.edu
In-Reply-To: <"1194 */S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/"@MHS>
References: <1194*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
Subject: Re: unavailable X.400 routing entries in the COSINE-MHS community

From Urs:

} Tony does not give up as easy, and he is right ;-)
} We had a lengthy discussion on several aspects of this problem at the last
} MHS Managers meeting in Zurich, I might even say that most of the agenda
} items tried to attack one or the other aspect of this problem. It has also
} been discussed on the mhs-managers list on initiatives from Ingacio for
} example. The waves have calmed down with most managers shrugging their
} shoulders since no obvious solution was handy.
} 
} Problem statement:
}   There are at least two ways for non routable X.400 addresses to creep
}   into our network:
}   - on secondary recipient fields
}   - as result of mapping
}   This is increasingly hampering our service!
} 
} For most addresses a route can be found:
} - in the COSINE-MHS domain documents
} - through the ADMD backbone
} - gatewaying into Internet
[....]

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.

It is already agreed that all mapping rules must be valid via SMTP.
Is that the case?  If not, then the problem is much more difficult.
(Or, another way to ask the question is, are there 822 islands somewhere
which are registering global mapping rules?  I hope not!)

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 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 see an immediate solution to problem 2.  Perhaps someone else
can see one?

I still need to thing about Ignacio's proposal that each country
document domains for ADMD delivery.  Perhaps this could also be
included in a local-admd Domain document.

Obviously, we will continue to discuss this topic!  I would be glad to
talk about it at the IETF.  But, like other routing topics, we must
put it at the end of the meeting, as it could consume infinite time! ;-)

Cheers,

allan