🚀 go-pugleaf

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!)