harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (02/25/91)
Simon,
I try to feed this discussion where Steve wants it.
The problem is:
site A<-- SMTP --->gwy B<--X400----->gwy C<--SMTP---->site D
a_b@host.adom SA=Bgwy; a_b@host.adom
DD.RFC-822=a(u)b(a)host.adom OR
/SA=Bgwy/DD.RFC-822=a(u)b(a)host.adom/@Cgwy
(yes, the last one gives me shudders too.....)
I THINK that there are two legal alternatives on the RHS: One where C-to-D is
sure that it is in the same namespace as A-to-B, one where it is not.
The last one may be useful for mapping local stuff like .dnet or .bitnet
In some way or another, you have to have control over mail to .adom at D,
otherwise you cannot get mail to any .adom address without specifying gateways.
If the pointer is to a valid gateway, you have no problem, things will
take the same return path even though you stripped off the gateway info.
If it is not, you are in trouble in any case.
I still fail to see the case where a gateway table is required, rather
than useful, if the routing based on DNS is set up properly (that is,
pointing to a valid gateway).
(BTW, the discussion is still not showing up in
comp.protocols.iso.x400.gateway, is someone messing it up by attaching
distribution: na or equivalent silliness?)
harald Tveit Alvestrandbuclin@sic.epfl.ch (Bertrand Buclin) (02/26/91)
>I still fail to see the case where a gateway table is required, rather >than useful, if the routing based on DNS is set up properly (that is, >pointing to a valid gateway). Harald, The example given at the beginning of the discussion (which I enclose below) shows exactly the need for a gateway table. > user%host.decnet@cs.manchester.ac.uk > > C=GB;A= ;P=AC.UK;O=Manchester;OU=CS; > DD.RFC-822=user(p)host.decnet(a)cs.manchester.ac.uk As stated initially (and confirmed by Steve), the above mapping, although syntactically correct, is semantically wrong. It is derived from the current mapping tables. There is no RFC 987 gateway at Manchester corresponding to SA address C=GB;A= ;P=AC.UK;O=Manchester;OU=CS; The correct gatewayed address is C=GB;A= ;P=AC.UK;O=mhs-relay;DD.RFC-822= ... Suppose, on another hand, that there exists a real X.400 domain at Manchester which as exactly the same SA as in the above example. There will be no User Agent at Manchester which will be able to deliver a mail with the above address. Unfortunately, this kind of situation will occur each time that there is an overlap between the X.400 name space and the Internet name space (the both name spaces being mapped onto each other using the current RFC 987 mapping tables). Having a gateway table could also solve a couple of other current problems of RFC 987. I'll just cite on problem which is causing a lot of trouble to our users : RFC 987 ask to set the P1.PerRecipientFlag to Confirmed if we want to have message contents returned in case of non delivery. This causes Delivery Reports to be generated each time a message traverse the gateway. Since in our case, all mail to the Internet travel through the X.400 network, the RFC 987 at the other end of the X.400 net sends "success delivery reports" for each mail. RFC 987 tells to map a DR as a normal RFC-822 message telling the user that his mail has been successfully delivered. The user generally take that as a aknowlegde for his mail, and think that effectivly the recipient has received the mail. This thoughts are completely wrong : the mail has just correcly left the X.400 network, and the DR does absolutely not ensure that the mail has reached its recipient (I've tried to explain our users this kind of subtle difference, but it's from far not easy ...). I a gateway table was present, we could set the PerRecipientFlag to Basic (just asking for Non-Delivery Reports) because the table will tell us that the recipient address is in a RFC-822 domain. (Steve, please take the above as an input for your RFC revision). -- Bertrand Buclin Internet: Buclin@Sic.Epfl.CH Service Informatique Central X.400: C=CH;A=ARCOM;P=SWITCH; Ecole Polytechnique Federale de Lausanne O=EPFL;OU=SIC;S=Buclin; CH-1015 Lausanne Tel: +41 21 693 22 11 (Switzerland) Fax: +41 21 693 22 20
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (02/26/91)
Bertrand, I *still* fail to see your point. I may be unusually thick..... The example address is user%host.decnet@cs.manchester.ac.uk > > The correct gatewayed address is > > C=GB;A= ;P=AC.UK;O=mhs-relay;DD.RFC-822= ... > I am not sure about that. I would assume that the gatewayed address is generated by a gateway that gets a message from Manchester on SMTP, and wants to generate an X.400 address. We then have 2 cases: 1) The gateway has a table entry for it, for example the one you use. 2) The gateway does NOT have a table entry for it, so it uses SAs that will lead to the message being routed back to the SAME gateway. Since the gateway got the message from Manchester by SMTP in the first place, it seems not unreasonable to impose the condition that it be able to return the message to Manchester using SMTP. > Suppose, on another hand, that there exists a real X.400 domain at Manchester > which as exactly the same SA as in the above example. There will be no > User Agent at Manchester which will be able to deliver a mail with the > above address. Unfortunately, this kind of situation will occur each > time that there is an overlap between the X.400 name space and the Internet > name space (the both name spaces being mapped onto each other using the > current RFC 987 mapping tables). > We have exactly this problem in UNINETT. We have several domains sharing address space. We have found 2 solutions: 1) The addresses may be sorted using O and OU fields only. The MX records for the X.400 parts point to UNINETT's gateways, and the tables on UNINETT's gateways are able to sort correctly. The MX records for the SMTP parts point directly to the machines involved. All other X.400 MTAs do one of two things: - Route the message to the X.400 MTA for the subdomain, where some messages get sent on to the UNINETT gateways for relaying to SMTP - Route all the mail through one of the UNINETT central machines, which sort correctly. 2) The addresses may NOT be sorted using O and OU. In this case, we require that the organization operate its own RFC-987 gateway, and each network sends its mail (X.400 or SMTP) to that gateway. ELAB-RUNIT (my organization) is such an organization. In both cases, all addresses are reachable from both the SMTP world and the X.400 world, without any gateway table required. Your other problem: > > Having a gateway table could also solve a couple of other current problems > of RFC 987. I'll just cite on problem which is causing a lot of trouble > to our users : > > RFC 987 ask to set the P1.PerRecipientFlag to Confirmed if we want to > have message contents returned in case of non delivery. Can you give me chapter and verse on this one, please? (Steve, one suggestion for RFC-1148/2: INCLUDE AN INDEX!!!!) > <the users think that mail has arrived when it has been gatewayed, > because the gateway returns a DR> > If a gateway table was present, we could set the PerRecipientFlag > to Basic (just asking for Non-Delivery Reports) because the table will tell > us that the recipient address is in a RFC-822 domain. Now you are asking to present the Gateway Table to the users. I do not like to do this...they are MORE than enough confused if required to read the mapping tables :-((((((((((( The basic problem is probably that EAN does not present the Supplementary Information field of the X.400 DeliveryReport to the user. If this said something like "GATEWAYED TO THE INTERNET", your users would probably stop complaining. This is one thing that I have suggested that the EAN Support Team take as an important action item. (it SHOULD say something like that. See RFC 987, section 4.4.2, page 35) So, why do we need the gateway table? harald Tveit Alvestrand (I got this on Email first, so this is an EMailed reply. Long live the confusion!)
buclin@sic.epfl.ch (Bertrand Buclin) (02/28/91)
Harald, >Since the gateway got the message from Manchester by SMTP in the first >place, it seems not unreasonable to impose the condition that it be able >to return the message to Manchester using SMTP. This is a political issue ... In Switzerland, it has been decided that all mail outside a given site is routed using X.400 and not SMTP, even if it is technically possible (and easier). Incoming mail, could follow whatever route (direct SMTP, Bitnet, X.400). I don't want to argue on this axiom, but it fixes the context. Every site has two choices : - Either it uses X.400 internally (what is generally the case) - or it has a local gateway able to convert from the internally used mail protocol (SMTP, VMS Mail, QuickMail, etc ...) to X.400 (this is the case at EPFL). We then have the situation given by Simon (local SMTP domains, an X.400 backbone, and at the other end of the backbone another RFC987 gateway for mail directed to Internet). Now, come back to the example I gave (user%host.decnet@cs.manchester.ac.uk). >I would assume that the gatewayed address is generated by a gateway that >gets a message from Manchester on SMTP, and wants to generate an X.400 >address. Let's make a more general assumption : the mail does not come from any gateway; the user composes it. He takes the address from anywhere (business card, publication, from a friend, or whatever source; the point is that a user sends a mail with that address for the recipient). >We then have 2 cases: >1) The gateway has a table entry for it, for example the one you use. There is no specific entry, the gateway use the generic one for .ac.uk : ac.uk#PRMD$UK\.AC.ADMD$ .C$GB# And this leads to the O/R address : C=GB;A= ;P=UK.AC;O=Manchester;OU=cs;DD.RFC-822=... As Steve quoted, there is no RFC 987 gateway at Manchester, and if I want the mail to reach its recipient, the gateway should use the SA : C=GB;A= ;P=UK.AC;O=mhs-relay;DD.RFC-822=... (or O=nsfnet-relay or any other SA identifying a valid RFC987 gateway that serves Manchester). The current mapping without gateway table assumes that on the path from my gateway to Manchester there is an MTA which identify the above recipient address as being aimed to be delivered by it. I think this is quite a strong hypothesis. -- Bertrand Buclin Internet: Buclin@Sic.Epfl.CH Service Informatique Central X.400: C=CH;A=ARCOM;P=SWITCH; Ecole Polytechnique Federale de Lausanne O=EPFL;OU=SIC;S=Buclin; CH-1015 Lausanne Tel: +41 21 693 22 11 (Switzerland) Fax: +41 21 693 22 20