Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway From: buclin@sic.epfl.ch (Bertrand Buclin) Newsgroups: comp.protocols.iso.x400.gateway Subject: Re: The disjunct-RFC822 domain problem and DD.RFC-822 Message-ID: <1152@sicsun.epfl.ch> Date: 25 Feb 91 23:44:09 GMT References: <2904*harald.alvestrand@elab-runit.sintef.no> Reply-To: Buclin@sic.epfl.ch Organization: Ecole Polytechnique Federale de Lausanne Lines: 62 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: comp-protocols-iso-x400-gateway@cernvax.cern.ch ReSent-From: Jerry Sweet ReSent-To: ifip-gtwy@ICS.UCI.EDU >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