Re: Questions on "MHS use of Directory to support MHS Routing": definitions

[Andrew Worsley <[e-mail]>]

> > If you talk P1 and it supposedly can handle all the MTA services it is an M
TA.
> * Ta.  What if it talks SMTP or GreyBook ?

  In the X.400 standards everyone talks X.400 - Hence the standards, as far as
  I can see, say *nothing* about this. In which case we turn to what other
  people have proposed, like Steve Kille in RFC1148. This translates a subset
  of messages (IPM) into RFC-822 mail and it does not clearly connect the
  822 world as an MTA or MS or UA. It just translates the message and passes
  it on and tries to do a reasonable job of joining the two worlds.

  So basically talking about an MTA for SMTP and GreyBook is stricly speaking
  no sense. What you are asking about is probably something that Steve's RFC
  on directory routing has defined and so you should look for the answer's from
  that proposed RFC.

> 
> > There is an expectation that UA are only likely to be "up" when the user is
> > ready to read mail (logged in?) whereas the MS is expected to available at 
any
> * OK -- as I said, I come from RFC 822 land, from the days before X.400
> * hi-jacked "UA" to mean something different from previous common usage.
> * My problem is that I've never (knowingly) met a UA or MS -- I have always h
ad
> * messages written into UN*X files by co-located MTA/MS/UA, so the distinctio
ns
> * have appeared very blurred !

   Actually I think UA was hijacked from X.400 a long time ago by others but
   who cares?

> * [ Assuming we are NOT just considering X.400 (as the doc indeed says), my
> *   understanding is that a UA is given all the messages at once, whereas a M
S
> *   allows the "user agent" to pick & choose messages and manipulate them. Ye
s ?
> * ]
> 
> > I think the picture is further confused by X.400's lack of consideration fo
r
> > the non-X.400 world. As delivery to a non-X.400 mail system is not precisel
y
> > in any of the above categories.  
> * Thanks for that moral boost !
> 
> * I assume throughout that the document IS referring to delivery using 822 as
> * well ...

  In the document they appear to talk about "local RFC 822 mailboxes (UAs)"
  being represented by mHSPersonalName object (pages 25/26) section 12.
  I don't understand this so I will not comment much more on it.

  I guess they are talking about registering message delivery locally via 822
  but I am surprised if they are thinking about delivering via 822 over
  a network. The rest of the document doesn't mention 822 MTAs or anything
  like that. So I assume that it is only considering delivering messages
  via X.400. You have to use gateway type services to connect 822 type networks
  into this. i.e. there is no 822 or GreyBook MTAs, I think. Please correct
  me if I am wrong about this.

> 
> >* Does each UA have a DN ? What does it look like ?
> > Yes each MS/UA can. It can look like pretty much anything you want I think.
> * Remembering that I have a co-located MTA/MS/UA for some 200 users, I assume
> * 1) there is not a separate "mailbox/UA" for each user, but just ONE.
> * 2) the DN of this object can actually be the same as the MTA name ?

  This again is not an X.400 question but a question about the RFC. I think
  (from memory so please check) that you have the choice of these options
  for your local users. You can just set a single (at least small) global
  entry for your site and handle all mail which matches the parts you specify
  of the ORAddress/DN. i.e. you could specify something like
      /C=GB/ADMD= /PRMD=UK.AC/O=cam/OU=cl/
  and get everything.

   or you can specify entries for all the users in a entries below the routing
   tree entry for the above. I don't know how practical this second option is,
   it is exactly the sort of question people need to ask about this RFC,
   I think anyway.

> 
> > I think the best way of viewing these things registed in the DIT (X.500
> > Directory Information Tree) is as services registered.
> * Given that, and the fact that I only want to register one service ("deliver
> * mail to cl,cam,gb"), I assume I should stuff an MTA dirtectly in cl,cam,gb.
> * My problem is that I have been using QUIPU's iaed (ISO listener which looks
> * for all presentationAddresses to listen on in a particular part of the tree
)
> * so have HAD to register individual machines so that they can listen -- soun
ds
> * like I need to "hide" these and register a DIFFERENT entity for other MTAs 
to
> * actually call - yes ? 

  Don't understand why this problem. I think jpo/pete/sek should be answering
  these questions. To show my lack of understanding I will say: I thought
  if you are offering an MTA service on three different machine each MTA service
  should have it's own entry and hence a presentationAddress attribute which
  presumable will be different, as in practice it is not easy to make the one
  address be listened to by different machines.

  There are a lot of attributes in the MTA Object Class which allow a lot of
  flexibility over specifying what ORaddresses it will and will not parse, some
  which seem to be for redirection and bad sender redirection...

> 
> > I believe that this is what the Directory was for. Registering addresses of
> > services.
> * OK -- I suspect it boils down to what a "service" is ....
> * Is it MTA1 ("deliver mail to cl,cam,gb"), MTA2 ("deliver mail to a qmgr X")
,
> * or MTA3 ("deliver mail to qmgr X using protocol Y").
> 

   I think it is deliver X.400 messages. You can specify other restrictions
   with the conversion attributes of the MTA object class. This seems to be
   limited abit to X.400 body part conversion though. 


> > You register MTAs which mean register an MTA service as available for each
> > MTA you register.
> * Is that statement somewhat cyclic, or am I misreading it ?
> * Or does it say "an MTA registration registers an MTA service" ?

  It does mean that (I believe). You are registering MTA services. Each
  registration has attributes which qualify the service it offers.

> 
> > That the MTA is the optimal one to send to is really up to the routing
> > protocol which isn't defined!
> * Oh dear -- I thought it was ....
> * Well, I thought that this document defined a "reasonable" way to route --
> * maybe not "optimal", but at least "reasonable" ...

  I guess that is what we are hoping....

> 
> > You could have the one MTA service run on different hardware at different
> > times (or the same time) if you could work out a wayto satisfy the service
> > requirements for acknowledgement and so on.
> * That's what I wanted to hear !
> * SO: I can have one registered MTA1 running on multiple MTA2s ... Fine.

  In theory. In practice I think its hard to make it work using ISODE/PP.
  I can't find out how the OSI address of an MTA is defined in my copy of
  the RFC so I can't tell if there is an easy way to do what you want.

  You should be able to specify more than one MTA service, I guess one per
  machine you want to process mail and perhaps some sort of general redirect
  as well.

> 
> >* Now I'm struggling with X.400 passing over a DN so that the called MTA can
 use
> >* the info to look up the caller to check the calling network address, and
> >* discover the expected "MTAname and password".
> > Wait till you have strong security with each call possibly requiring checki
ng
> > cetificates and other such stuff.
  
  I was speaking sarcastically... You think this is complicated. Actually it
  might work quite nicely, but take a while to run....

> * I can't wait that long -- I want to sort things out now ...
> 
> > An MTA delivers or passes along a message (P3 or P1 connection).
> * That's using X.400 terminology.
> * MTAs may also be using 822 protocols, so may be using SMTP, GreyBook, etc
> * as well .....
> 
> > Steve's MHS-directory-routing has given MTA's directory entries but otherwi
se
> > they don't have addresses, I think.
> * "Address" as in "DN" rather than "network address".

   As in DN, yes which you can send a message to in X.400.

> * They also have a "name" as in "name & pawword" -- yes ?

  They have authentication attributes which can be simple authentication
  (i.e. as password and name), none or strong (cetificates) which is not
  supported. Look at MTA Object Class, page 30 and page 36....

> 
> 
> SO: to revert to my problem:
> 
> MTAInfo ::= SEQUENCE {
> name DistinguishedName,
> weight [1] RouteWeight OPTIONAL,
> mta-attributes [2] SET OF Attribute OPTIONAL}
> 
> As I understand it, the referenced DistinguishedNames will have the objectCla
ss
> mTA which allows it to have a single presentationAddress, and normally a sing
le
> supportedApplicationContext. This means that an "MTA" supporting (say) X.400,
> SMTP and GreyBook will need at least three DNs (more if an appcont needs more
> than one presentationAddress due to different TSELs or whatever).

   My copy of the RFC doesn't list supportedApplicationContext as an attribute
   of MTA ObjectClass (it also appear to define mhs-message-transfer-agent) so
   I can't answer this. I am surprised if such a restriction is enforced anyway.
   Is this "supportedApplicationContext" multi-valued? Or can you specify
   lots of values for it. I am surprised that such an attribute is used to
   specify what protocol it talks, are you sure about this? I thought it would
   specify wether you are using P1 or P3 or perhaps even 88 version of things.

   I would have thought that SMTP/GreyBook would be specified in the conversion
   or other such attributes. Are you trying to deliver mail via SMTP via
   a presentation address? Surely if you have SMTP mail you need an IP address
   and you use the DNS? I must be misunderstanding things badly...

> 
> As I currently have 3 MTA2s offering a single MTA1 "service", all using
> iaed (thus needing separate subtrees to hold their addresses -- I realise tha
t
> this is an implementation detail, but it only aggrovates the problem a bit!)
> I end up with a dozen DNs (MTA3s) for a single (MTA1) "service".  This makes 
me
> rulucatant to try to update any attributes !

  There is some pattern matching stuff on page 19 which allows you to
  specify lots of DN patterns to be routed by the one MTA. Is this the sort
  of thing you are trying to do?

> 
> In particular the mTAName in all MTA3s will be the that of the MTA1.
> 
> SO: when the document uses the work "MTA", am I meant to be able to deduce
> which of the three MTA catagories (MTA1, MTA2 or MTA3) is meant ?

  I think of it as:
   "A service which in practical terms will be offered on several machines
   for redunancy with each having a different address."
  
  I as understand it none of them advertise they accept SMTP or GreyBook
  via the X.500 DIT (using Steve's RFC) but you can probably specify that they
  offer conversion to RFC-822/whatever mail. Again I wait to be corrected....

	Andrew
CSIRO, Division of Information Technology (Melbourne),     Phone [phone]
723 Swanston St.                                           Fax   [phone]
Carlton, Vic, 3053, Australia                   Email:[e-mail]