NTIN36@gec-b.rutherford.ac.UK (Jim Craigie) (03/16/91)
From: Bertrand Buclin <buclin@ch.epfl.sic>
Subject: Re: The disjunct-RFC822 domain problem and DD.RFC-822
Date: 25 Feb 91 23:44:09 GMT
RFC 987 ask to set the P1.PerRecipientFlag to Confirmed if we want to
have message contents returned in case of non delivery.
RFC 987 section 5.3 specifies two methods for providing Return of Contents
service:
The method in paragraph 2 does not seem to me to require P1.PerRecipientFlag
to be set to confirmed, so I would support deleting the requirement here.
The method in paragraph 3 definitely requires Confirmed reports. However,
this whole method is quite suspect as it places the unrealistic requirement
that reports be routed back on the same route as the subject message.
Jimosmith@acorn.co.UK (Owen Smith) (03/20/91)
In article <16MAR199114:37:11NTIN36@UK.AC.RUTHERFORD.GEC-B> NTIN36@gec-b.rutherford.ac.UK (Jim Craigie) writes: >Subject: Re: The disjunct-RFC822 domain problem and DD.RFC-822 In my experience, very few X.400 MTA implementations bother to do Return of Contents when generating reports. So relying on it is probably a bad scheme. Also, there is a downgrading problem. The X.419 1988 to 1984 downgrade rules specifically state that when downgrading a Report, any returned contents should be left alone ie. not downgraded. Thus when a 1984 gateway or UA further down the line looks at the returned contents, it may well find itself looking at something with 1988 service elements in. Bit of a problem. In my opinion this is a bug in the downgrade rules. Mind you, the downgrade rules completely neglect P2, which is also a major omission. Owen. The views expressed are my own and are not necessarily those of Acorn.
jh@tut.fi (Juha Heinanen) (03/25/91)
in finland we have several X.400 sites that have multiple word organization names, like O=nokia data communications, where i send mail myself today. i personally don't have any problems with these kind of addresses including space, since i use (a) emacs mail interface and (2) pp sendmail program that both support quoted strings including spaces. however, i have heard alot of complaints from user that (a) are using elm or other Unix user agents and (b) versions of Unix sendmail programs that can't handle spaces in quotes. it looks like fixing the ua's would take a very long time because there are so many of them and their users are not computer hackers. one possible solution is to write an explicit mapping for each case where spaces appear in X.400 addresses, like from o=Gold 400 to gold-400. another solution is to define an automatic mapping from space to something else, eg to _. i don't care which one you pick, but please agree on something soon so that our users can get their work done. -- juha -- -- Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958