🚀 go-pugleaf

In article <id.TPVS._L3@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <1992Aug31.140004.4374@news.lrz-muenchen.de> Michael.Storz@lrz.lrz-muenchen.dbp.de writes:
|> > In article <id.ZIRS.GD@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> > |> As X.400 gets more common, I'm getting more and more bounces. Worse, I'm
|> > |> getting bounces from replies to messages originated in X.400 land, where
|> > |> the gateway didn't put an unambiguous address in the sender field. Because
|> > |> there is no such thing as an unambiguous address in X.400.
|> 
|> > Sorry, I do not understand these sentences, the information in them seem to be
|> > very strange to me.
|> 
|> > 1) Why should the gateway put an address in the sender field?
|> 
|> So that the recipient can reply to the message. It has to put *something*
|> from the X.400 sender address in the RFC822 From line.
|> 
|> > 2) What do you mean with unambiguous address?
|> 
|> I mean I'll get mail from "Joe.Blow@foo.bar.something.something" and when I
|> reply to it I get a bounce from the X.400 gatweway telling me there are half
|> a dozen Joe Blows at foo.bar.
|> 
|> > 3) Why do you think that X.400 does not know such thing like an unambiguous 
|> >    address?
|> 
|> An X.400 address is more like a pattern. It specifies search criteria in
|> greater and greater detail, but there seems to be no fixed subset of an
|> address that uniquely specifies a recipient.
|> 
|> > 4) What are you doing with an address of the sender field in a reply?
|> 
|> I'm putting it in my "To" field.
 
Ah, now I know why I was so confused by your first sentences. You were talking
about 'sender field' and I thought you meant the RFC 822 sender field, but you
were talking about the RFC 822 From field. Sorry for this misunderstanding.

1) Your statement 'there is no such thing as an unambiguous address in X.400' is
   wrong. X.400(88) 12.4 O/R address states:

       An O/R address contains information that enables MHS to uniquely identify
       a user to deliver a message or return a notification to him.

   Maybe you are confused by the flexibility of X.400 O/R addresses because
   there are several different forms:

       - Mnemonic: Provides a user-friendly means of identifying users in the
                   absence of a directory.
       - Terminal: Provides a means of identifying users with terminals
                   belonging to various networks.
       - Numeric:  Provides a means of identifying users by means of numeric
                   keypads.
       - Postal:   Provides a means of identifying originators and recipients
                   of physical messages.

2) If the gateway didn't put an unambiguous address in the RFC 822 From field,
   then it is not conforming to RFC 1327 or to one of the predecessors RFC 987 
   or 1148. I suppose this could be the case with some commercial gateways. 
   These RFCs specify exactly how to map the fields From, Sender, Reply-To from
   RFC 822 to X.400 and back.

If you get bounces for replies to messages originated from X.400, you should
really complain that to the provider of the gateway and if that doesn't help
make this information available to the net. This would help to make such 
gateways more reliable.

BTW I am responsible for such a gateway, where several thousand mails per month
are mapped from SMTP to X.400 and back and have never experienced such a case.
Mails only bounced when the user keyed in an address manually or when an 
intermediate SMTP system changed an address.

Regards

Michael Storz
================================================================================
Network Administrator and Postmaster  !   X.400 : G=michael;S=storz;OU1=lrz;
for X.400 Mail Domains                !           P=lrz-muenchen;A=dbp;C=de
P=tu-muenchen;  A=dbp;C=de            !   RFC822: storz@lrz.lrz-muenchen.dbp.de
P=uni-muenchen; A=dbp;C=de            !   Fax   : ++ 49 89 2809460
P=lrz-muenchen; A=dbp;C=de            !
P=badw-muenchen;A=dbp;C=de            !   Tel   : ++ 49 89 2105 7420
P=fh-muenchen;  A=dbp;C=de            !

                   L E I B N I Z - R E C H E N Z E N T R U M

                 Supercomputer-Center for Bavarian Universities
                                  Barer Str. 21
                               W-8000 Muenchen 2
                                    Germany
 ================================================================================