csg@pyramid.pyramid.com ("Carl S. Gutekunst") (05/07/91)
Either this is a religious question, or I'm just totally confused. :-) In the X.400 implementations I am examining, there appear to be two distinct ways of addressing users or access units: - The MTA is identified by the entire O/R name, except for the personal name. Within that particular MTA, users and other access units are addressed only by the personal name. If the same network node is to be responsible for, say, two different organization units, then either two MTAs have to be run concurrently, or some form of kludge applied to the MTA (like aliases for components of the O/R name). - The MTA controls little more than the country code, ADMD, and PRMD. Each user is assigned a full O/R name. Thus one MTA can be responsible for as many different logical domains, orgnization names, organization units, and so on as there is room in the routing tables. The first scheme is what I am used to in UNIX and most PC mailers: one MTA is never responsible for more than one fully qualified domain. The second scheme is obviously more flexible, although it seems to come at the price of dragging along a large volume of information for each user; it also seems vulnerable to configuration errors. And the first scheme can achieve the same flexability by running multiple MTAs on the same network node, which should be simple if the design has been done correctly. Any comments? Is one of these more "right" than the other? Anyone out there have administrative experience with both? <csg>
rjl@gandalf.ssw.com ("Robert J. Leone") (05/07/91)
As far as who contains what routing information, all that is up to the implimentor. The important thing is that the mail gets to the recipient. For an ADMD MTA, all it needs to do is get mail to some MTA of the PRMD that the recipient belongs to. For an MTA of a PRMD, all that's important is that it is able to somehow route the mail to the MTA that services the UA of the recipient. The knowledge of routing info is up to the implimentor of the ADMD or PRMD. A PRMD MTA may have complete info of exactly who is where for the entire PRMD. Or it may route by Organisational info to the right MTA within the PRMD. Or it may route everything that is not local to itself to some Master MTA within the PRMD which figures out the correct routing from there. Or some other scheme. The CCITT X.400 spec is silent on how the mail gets there as long as it gets there. Bob Leone Soft Switch
koorland@vancouver.osiware.bc.ca (Neil Koorland) (05/07/91)
> The first scheme is what I am used to in UNIX and most PC mailers: one MTA is > never responsible for more than one fully qualified domain. The second scheme > is obviously more flexible, although it seems to come at the price of dragging > along a large volume of information for each user; it also seems vulnerable to > configuration errors. And the first scheme can achieve the same flexability by > running multiple MTAs on the same network node, which should be simple if the > design has been done correctly. > > Any comments? Is one of these more "right" than the other? Anyone out there > have administrative experience with both? X.400 imposes no restrictions on which UAs are associated with with which MTAs, and is in fact even more flexible than just the cases mention in your message. The ORAddress is used as a unique UA identifier, whose attributes can be used for routing, but do not imply any one final MTA. The association of UAs to MTAs is a purely administrative function for the domain responsible for the UAs and MTAs being associated. You could have different Organizations or OrganizationalUnits associated with a single MTA, or you could have UAs which only differ in PersonalName associated with different MTAs. (The same holds true for which MSs are associated with which MTAs.) However, some X.400 implementations will impose restrictions, often only allowing the first scheme you describe. The administrative "price" that is incurred when more flexibility is allowed, is not necessarily as costly as you seem to imply. It could just involves minor entry additions to a table. It can often be more costly trying to work around implementation limitations by administering multiple MTAs where a single MTA could have sufficed. The point is that you should not be forced to change your users' organizational structure to accommodate shortcomings in an implementation, although this can often be the case. ----------------------------------------------------------------------------- Neil Koorland OSIware Inc. Tel: +1-604-436-2922 200-4370 Dominion St Fax: +1-604-436-3192 Burnaby, B.C. CANADA V5G 4L7 Internet: <koorland@vancouver.osiware.bc.ca> ------------------------------------------------------------------------------
JPALME@qz.qz.se (Jacob Palme QZ) (05/07/91)
The person most responsible for routing in X.400 is Robert H. Willmott, U.K. Dep. of Trade and Industri, ITSU, Kingsgate House, 66-70 Victoria Street, London SW1E, United Kingdom Phone +44-736-62211 I do not know if he can be reached by e-mail. My guess is that his reply to your question is that all MTA-s which handle a common domain should have a common directory system, in which they can find which MTA serves each indivudual OR-address within their domain.
csg@pyramid.pyramid.com ("Carl S. Gutekunst") (05/08/91)
In article <154581@pyramid.pyramid.com> I wrote: >In the X.400 implementations I am examining, there appear to be two distinct >ways of addressing users or access units.... Any comments? Is one of these >more "right" than the other? The E-mail I'm getting suggests that I didn't phrase the question well; all have essentially said, "You can do it any way you like, because the Blue Book doesn't specify." But I already knew that. I'm asking for people's opinions and experiences. Particularly if you have experience administrating both (say, a Retix X.400 and a PP site.) <csg>
kaufmann@zpl.dfn.dbp.de (05/08/91)
To support Neils view: One of the DFN-X400-products (OSITEL/400) is able to route on arbitrary attributes including Surnames. So You can route every single UA-mailbox on a different way, via different MTAs or as separated remote UAs. Peter Kaufmann
JPALME@qz.qz.se (Jacob Palme QZ) (05/08/91)
Correction: Robert H. Willmotts phone number is +44-732-62211.
hta@isolde.er.sintef.no (Harald Tveit Alvestrand) (05/10/91)
I have personally worked on a system where we had 3 different types of MTA
routing on names within one namespace.
The setup was:
2 EAN MTAs giving service to users
1 M.PLUS MTA handling external communication on X.400
1 IDA SENDMAIL MTA (OK, it's not X.400, but it is an MTA :-) handling
RFC-822 communication and user services
We have a bunch of scripts generating tables from a single "alias file"
for all 3 systems.
The verdict so far is that:
- It works!
- It loops :-(
With these particular versions of the programs, none of the pieces were
able to add trace to the message that survived the transfers between them,
and no other loop detection was available.
(Keywords:
- X.400(84) has standard trace only on PRMD/ADMD boundaries
- M.PLUS in its antique version that we use stripped trace when routing
from X.400 to Sendmail)
We are thinking about throwing it all out and replacing it with PP.
Conclusion: I recommend this kind of thing ONLY if you can do proper loop
detection.
The University of Oslo is serving several namespaces using one PP MTA.
It makes moving people around within the university much easier.
So, yes, you can do both things, and it is very useful to do so, but doing
it in a mixed environment is a pain, because of the multiplicity of tables
involved.
--
Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94khiem@hpindqi.cup.hp.com (Khiem Ho) (05/10/91)
> (Keywords: > - X.400(84) has standard trace only on PRMD/ADMD boundaries > - M.PLUS in its antique version that we use stripped trace when routing > from X.400 to Sendmail) > -- > Harald Tveit Alvestrand > Harald.Alvestrand@delab.sintef.no > C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald > +47 7 59 70 94 While CCITT X.400 (84) didn't define it, most profiles that I've seen (CEN/CENELEC, US GOSIP, etc) use an InternalTraceInfo defined in the old MOTIS '86. The InternalTraceInfo records the path within a PRMD, ie among MTAs within a PRMD. This "should" be implemented widely, as it is a required field for a PRMD MTA. Khiem Ho ------------------------------------------------------------------------- Hewlett Packard Information Network Division MS/43LS, 19420 Homestead Road, Cupertino, CA 95014 ------------------------------------------------------------------------- X.400: C=US;AD=ATTMAIL;PD=HP;ORG=HP;OU1=HP6600;SN=Ho;GN=Khiem Unix Mail: khiem@cup.hp.com Telephone: +1-(408)447-2660 Fax: +1-(408)447-3660 -------------------------------------------------------------------------
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (05/13/91)
"- The MTA controls little more than the country code, ADMD, and PRMD." This is "the right thing" according to X.400 84. The other attributes should be used as a search key in the local directory, which should result in the identification of a "delivery method"... Problem is that there was no way to define how several MTAs could share the same PRMD in X.400 84... Christian huitema
Stef@ics.uci.edu (Einar Stefferud) (05/14/91)
> "- The MTA controls little more than the country code, ADMD, and PRMD." > This is "the right thing" according to X.400 84. The other > attributes should be used as a search key in the local directory, > which should result in the identification of a "delivery method"... > Problem is that there was no way to define how several MTAs could > share the same PRMD in X.400 84...Christian huitema CCITT had no interest in how routing would be doen inside a PRMD, and so left it as "a local matter". This was actually a very wise decision, though it does not provide a "cook book" receipe for the unintiated (or the unanointed). The basic fact remains, learned from internet experience with domain names used for mail addresses, that rotuing is best done by taking the entire address as a key, and doing a "longest match" on this "address-as-a-key" to find the preferred next hop from the table. Of course, the table has to be constructed so that the "longest match" is indeed the preferred next hop, adn so it is easy to find in the normal process of table lookup. Now, with more experience, includijg the thought of dealing with multiple ADMDs from a single PRMD, and dealing with complex PRMD situations with shared domains (another cold dash of hard reality), it should be clear that the "key" for table lookup should utilize every relevant bit of "per-recipient+per-domain" information that the MTA can gets its hands on, and had best be able to do sophisticated things with that information. This will be required to provide "bill control" where-in a PRMD selects routes to ADMDs based on tarrif tables for routing domains, and on security considerations for security reasons, and on quality of service considerations, and on where spcific individual recipients actually are from time to time. Routing is not a simple thing, and it is not the business of CCITT to specifiy how it is to be done by any PRMD. The business of interpreting CCITT silence to mean anytnign was (and is) a big mistake. The silence only means that their lips were not moving. It also means that they did not know what to say, or they wisely recognized that it is not their province to say anything about intra-PRMD routing. Suffice to note that some of us will do it better than others, for whatever this sage observation may be worth. Best...\Stef