Thread View: comp.protocols.iso.x400.gateway
2 messages
2 total messages
Started by Harald Tveit Alvestrand
Mon, 25 Feb 1991 13:48
The disjunct-RFC822 domain problem and DD.RFC-822
Author: Harald Tveit Alvestrand
Date: Mon, 25 Feb 1991 13:48
Date: Mon, 25 Feb 1991 13:48
33 lines
1851 bytes
1851 bytes
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 Alvestrand
Re: The disjunct-RFC822 domain problem and DD.RFC-822
Author: Bertrand Buclin
Date: Mon, 25 Feb 1991 23:44
Date: Mon, 25 Feb 1991 23:44
62 lines
3752 bytes
3752 bytes
>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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads