Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CS.NIU.EDU!rickert
From: rickert@CS.NIU.EDU (Neil Rickert)
Newsgroups: comp.mail.sendmail
Subject: Re: Mail addresses and RFC1123
Message-ID: <9007242101.AA32438@cs.niu.edu>
Date: 24 Jul 90 21:01:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 84


 In response to my earlier comment:
>
>   As I interpret RFC1123, a host which does not understand the '!' character,
>   but which needs a route for delivery, should not use the address
>			     @a:c!u@b
>   with its clear interpretation of delivery -> a -> b ->c -> u  but the host
>   should instead format the address as
>			     c!u%b@a
>   with a suggested interpretation of -> a -> c -> b -> u.  (Note that since
>   the host does not understand !, it treats 'c!u' as merely a single mailbox
>   name).
>

towfiq@interlan.Interlan.COM (Mark Towfigh) writes:

>Where do you get this interpretation?  It seems to me that the two
>forms are identical, and should both result in a->b->c->u.  To quote
>from the RFC in question:
>
>	It is suggested that "%" have lower precedence
>	than any other routing operator (e.g., "!") hidden in the
>	local-part; for example, "a!b%c" would be interpreted as
>	"(a!b)%c".
>

 This unfortunate language is just one of the problems with RFC1123.  To say
that '%' has lower precedence than '!' should mean that the processing of '!'
must PRECEDE the processing of '%'.  This was the interpretation I used.  The
algebraic notation (a!b) only confuses the issue.  In algebraic terminology,
the use of parentheses in (a*b)+c implies both that 'a*b' is to be processed
first before applying the '+', and that '(a*b)' must be treated as a unit.

As I read it, "(a!b)%c" has the following interpretation:
  Send the mail to host 'a' for delivery to mailbox 'b'.  Take the result
  of that mailing, whatever it is (undoubtedly an error message accompanying
  bounced mail, since mailbox 'b' is really on host 'c'), and use that result
  as the name of a mailbox on host 'c'.

 Actually the correct way to parenthesize 'a!b%c' is '(a!)b(%b)'.  This
completely specifies the binding of operators to operands, which is what
parentheses are good for.  Unfortunately it does not say which operator
should be processed first - algebraic notation was not designed for that.

 Until I hear a definitive statement to the contrary, I will continue with
my interpretation.  Incidentally most software I have seen only looks for
a '%' after it has failed to find any other addressing operators.  This means
that software which recognizes '!' as an addressing operator typically gives
higher precedence to '!' than to '%', while software which does not recognize
'!' necessarily gives higher precedence to '%'.  The result is hopeless
ambiguity.

 When software, such as used at a gateway host, provides a route back through
itself for return addresses, IT MUST USE AN OPERATOR OF HIGHEST PRECEDENCE.
Anything else requires modification of the local part.  In particular any
addressing operator in the local part which the gateway does not interpret
as an addressing operator (the '!' at bitnet gateways, for example), will
of necessity be treated as having lower precedence than the routing
operator.  Thus if ambiguity is to be avoided, any routing operator chosen
must be universally recognized as having the highest precedence.  The '%'
operator does not meet these requirements.

 As part of its justification to use '%' routes in place of source routes,
RFC1123 says:

              source routing is discouraged".  Many hosts implemented
              RFC-822 source routes incorrectly, so the syntax cannot be
              used unambiguously in practice.  Many users feel the
              syntax is ugly.  Explicit source routes are not needed in

 But consider the following rewrite rule from 'sendmail.main.cf' distributed
with Sun systems:

R$+%$+			$@$>3$1@$2			user%host

 This will convert 'user%relay2%relay1' to 'user@relay1%relay2' with
not much hope of correct delivery.  Given that there are more than two or
three Suns out there, one might conclude that 'many hosts implement %-routes
incorrectly, so the syntax cannot be used unambiguously in practice.'

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Sci Dept, Northern Illinois U., DeKalb IL 60115
  InterNet, unix: rickert@cs.niu.edu              Bitnet, VM: T90NWR1@NIUCS
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=