Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!ucivax!gateway From: koorland@vancouver.osiware.bc.ca (Neil Koorland) Newsgroups: comp.protocols.iso.x400 Subject: Addressibility of UAs? Message-ID: <9105071223*koorland@vancouver.osiware.bc.ca> Date: 7 May 91 16:13:13 GMT Lines: 40 Approved: usenet@ics.uci.edu > 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: ------------------------------------------------------------------------------