buclin@sic.epfl.ch (Bertrand Buclin) (02/28/91)
>> >> 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!!!!) RFC-987, clause 5.3, second paragraph (page 47). >> 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. Absolutely not. When I write "we", you sould read the gateway implementor/ operator. Of course, mapping tables are not in (normal) human-readable form... >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. It is not an EAN problem (nor PP or Mailway or any other gateway), it's a protocol problem. Ok, RFC-987 says an indication of the nature of the gateway should be included in the report, but I think that in the very case of tunnelling (=using an X.400 network to interconnect two SMTP nets) the Report Request bits in P1.PerRecipientFlag should be set to Basic and not Confirmed. Consider the different case one can encounter : - The message is delivered to its recipient (normal case). The users are used to receive no acknoledge of their messages in SMTP world. Using Basic flag will make then the X.400 tunnel transparent - There is an while the mail is in the X.400 world. A DR is generated reporting that error. The user is informed and everything is fine. - There is an error while the mail is back in SMTP world. Then the normal SMTP error reporting mechanisms will generate an error message which will be delivered to the originator. Normally, a DR is associated with a given message, and in most X.400 implementations, it is handled by the UA (by just informing the user that a DR has arrived for a given message and then associating the DR with the message). The way RFC-987 proposes to map DR is confusing for the end user, and of course no RFC-822 user agent can handle DR the same way an X.400 UA does. -- 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