🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.mail.sendmail
28 messages
28 total messages Started by tron@Veritas.COM Sun, 01 Sep 1991 07:24
Smail3, RFC1123, and the ! and % operators
#3801
Author: tron@Veritas.COM
Date: Sun, 01 Sep 1991 07:24
43 lines
2085 bytes
In RFC1123 paragraph 5.2.16 states:

              An embedded source route is sometimes encoded in the
              "local-part" using "%" as a right-binding routing
              operator.  For example, in:

                 user%domain%relay3%relay2@relay1

              the "%" convention implies that the mail is to be routed
              from "relay1" through "relay2", "relay3", and finally to
              "user" at "domain".  This is commonly known as the "%-
              hack".  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".

I consider this interpretation to be incorrect and prefer a!(b%c),
which is how Smail3 operates right now.

I would really like to know what opionions people have on this topic.
If all mailers conform to RFC1123, then people who know the RFC1123
will have some idea of what to expect from a remote site.  From that
standpoint, Smail3 should probably be changed.  However, I consider it
incorrect from the standpoint of correct operation in the world of
UUCP.  Perhaps from the standpoint of Internet operation it makes
somewhat more sense.

What do people think?  Somebody has sent me a set of "fixes" to smail
which, among other things, defines a flag for whether to use the old
behavior or the RFC1123 behavior.  This doesn't seem like the kind of
decision that a site should make on its own.  If one site considers %
to be a high-precedence operator, in the sense of the existing Smail3,
then it can turn a%b@c into x!y!z!c!a%b.  If site y considers % to be a
low-precedence operator, then it will deliver z!c!a to site b, which is
not what the original site wanted.

Comments and opinions would be appreciated.  My current intention is to
either leave smail alone or make the new behavior mandatory.  Having a
flag seems the worst of both worlds.
--
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {amdahl,apple,pyramid}!veritas!tron

Re: Smail3, RFC1123, and the ! and % operators
#3802
Author: rickert@mp.cs.ni
Date: Sun, 01 Sep 1991 15:21
61 lines
3204 bytes
In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes:
>In RFC1123 paragraph 5.2.16 states:
>[...]
>              local-part; for example, "a!b%c" would be interpreted as
>              "(a!b)%c".
>
>I consider this interpretation to be incorrect and prefer a!(b%c),
>which is how Smail3 operates right now.
>
>I would really like to know what opionions people have on this topic.
>If all mailers conform to RFC1123, then people who know the RFC1123
>will have some idea of what to expect from a remote site.  From that

 RFC1123 is itself ambiguous.  The notation (a!b)%c is really meaningless
for email addresses.  The authors of RFC1123 apparently intended it
to mean -> c -> a -> b , which seems to contradict the term "lower
precedence".

 Before RFC1123 there were many mailers, including smail and most
sendmail configurations which interpreted a!b%c as -> a -> c -> b .
There were other mailers which by default interpreted it the way RFC1123
intended since they did not treat '!' a routing character at all.

 Since RFC1123 there is been little change in the way mailers interpret
these mixed addresses.  Changing the interpretation tends to break too
many things.  There has, however, been some degree of change in the
formats of addresses created.  Many have concluded that the only reasonable
reaction to RFC1123 is to avoid ever mixing '%' and '!' in an address.
If an address already contains '!' and you wish to add additional
routing, better to use another '!'.

 In the sendmail/IDA rulesets, I did design the parsing so that if the
address contains an '@' the RFC1123 order is followed, but if there is
no '@' the smail order is followed.  However the rule which makes that
distinction is commented out so that the smail order is used to
interpret all incoming addresses.  This seems to still be more reliable.

>What do people think?  Somebody has sent me a set of "fixes" to smail
>which, among other things, defines a flag for whether to use the old
>behavior or the RFC1123 behavior.  This doesn't seem like the kind of
>decision that a site should make on its own.  If one site considers %
>to be a high-precedence operator, in the sense of the existing Smail3,
>then it can turn a%b@c into x!y!z!c!a%b.  If site y considers % to be a

  It is better to turn that into x!y!z!c!b!a .  Most mail software which
can handle '!' can deal with this.  In most cases site 'c', after stripping
off its name, would convert the remaining 'b!a' into 'a@b' as long as
there is at least one '.' in 'b'.  If by some chance 'c' does not do this
conversion, but sends to 'b' anyway, the chances are that 'b' will
still handle it correctly.  The only time problems occur is when the
site 'c' does not convert but sends to a site 'b' which does not understand
the '!' operator.  Mostly this occurs when 'c' is a unix system with a very
old or very badly botched sendmail configuration and 'b' is a BITNET gateway.


--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

Re: Smail3, RFC1123, and the ! and % operators
#3804
Author: vjs@rhyolite.wpd
Date: Sun, 01 Sep 1991 22:13
26 lines
1124 bytes
In article <1991Sep1.152150.18422@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes:
> ...
>  RFC1123 is itself ambiguous.  The notation (a!b)%c is really meaningless
> for email addresses.  The authors of RFC1123 apparently intended it
> to mean -> c -> a -> b ,...
> ...
>   It is better to turn that into x!y!z!c!b!a .

I think this is all true, expect for the "authors ... intended".

I got the impression that the multiple-% stuff is present only because one
or two participants were postmasters in the North East who were great fans
of long %-routes.  (They may still like them.)  I think the vast majority
of well connected sites avoid multiple %'s, rewriting into multple !'s or
RFC-822 source routes, and that almost everyone looks for % after paying
attention to @ and !.

Does "lower precedence" mean "binds more" or "less tightly".  English is
too sloopy for such stuff.  Regardless of whether authors of 1123 might
agree that it is ambiguous, many people will choose the opposite of
whichever was meant.  Thus, pragmatic considersations require avoidng
mixing % and !.


Vernon Schryver, vjs@sgi.com

Don't even jest it! (Smail3, RFC1123, !%, and the world!)
#3806
Author: lear@turbo.bio.n
Date: Mon, 02 Sep 1991 01:06
11 lines
313 bytes
What this world needs are fewer routing operators.  Let's help end the
% hack in our lifetime.

Oh, and source routes, when used, are generally illegal according to
RFC 822.  Each name in a source route is supposed to be a registered
FQDN.  Often times this is not the case.

--
Eliot Lear
[lear@turbo.bio.net]

Re: Smail3, RFC1123, and the ! and % operators
#3808
Author: urlichs@smurf.su
Date: Mon, 02 Sep 1991 09:24
21 lines
1087 bytes
In comp.mail.misc, article <1991Sep1.221351.14463@sgi.sgi.com>,
  vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
<
< I got the impression that the multiple-% stuff is present only because one
< or two participants were postmasters in the North East who were great fans
< of long %-routes.  (They may still like them.)  I think the vast majority
< of well connected sites avoid multiple %'s, rewriting into multple !'s or
< RFC-822 source routes, and that almost everyone looks for % after paying
< attention to @ and !.
<
I second the thought (which seems to be more-or-less generally accepted) that
the most sensible order of evaluation is @-!-%.
However, rewriting %-adddresses is not a good idea. Unless you are the
machine to the right of the last %, you shouldn't mess with these addresses;
and even then the only thing you should do is to convert the last % to a @
and run the address through the router again.

--
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

Re: Smail3, RFC1123, and the ! and % operators
#3809
Author: tron@Veritas.COM
Date: Mon, 02 Sep 1991 10:35
36 lines
1746 bytes
In article <1991Sep1.221351.14463@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Does "lower precedence" mean "binds more" or "less tightly".  English is
>too sloopy for such stuff.  Regardless of whether authors of 1123 might
>agree that it is ambiguous, many people will choose the opposite of
>whichever was meant.

The example and the text of RFC1123 are in agreement and do not agree
with the behavior I currently use.

>		       Thus, pragmatic considersations require avoidng
>mixing % and !.

I can't say I ever use them myself.  However, smail has to do something
Thus, the question is not whether people should use % and or !, but
how smail should behave when given one.

There is, I think, a simple convincing argument for doing it the way
that Smail currently does it.  Consider an address X@Y.  According to
RFC976 (the UUCP/Internet gateway standard) UUCP sites convert X@Y into
path!...!Y!X.  Also, according to other RFC's, X should be interpreted
by site Y, and no other site.  Thus, if X is a%b, the result should be
path!...!Y!a%b.  If X were a!b, this would be correct.  This should be
correct even if X were a%%%!!b, and site Y had a user with that name
(although the Postmaster of such a site might receive obnoxious mail
every once in a while, and users on his site might receive less mail
than others in the greater E-mail community).

In order to make Smail conform to the RFC, I believe that I have no
choice but to turn a%b@Y into path!...!Y!b!a.

NOTE:  nothing in these arguments apply to header addresses.  The
arguments (and the problems) arrise only in envelope addresses.
--
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {amdahl,apple,pyramid}!veritas!tron

Re: Smail3, RFC1123, and the ! and % operators
#3811
Author: barrett@daisy.ee
Date: Mon, 02 Sep 1991 20:54
33 lines
1360 bytes
In article <1991Sep01.072418.15414@Veritas.COM>,
tron@Veritas.COM (Ronald S. Karr) writes:
> In RFC1123 paragraph 5.2.16 states:

rfc1123>        It is suggested that "%" have lower precedence
rfc1123>        than any other routing operator (e.g., "!") hidden in the
rfc1123>        local-part; for example, "a!b%c" would be interpreted as
rfc1123>        "(a!b)%c".

> I consider this interpretation to be incorrect and prefer a!(b%c),
> which is how Smail3 operates right now.

Some RFC822 mailers understand @ and %, but do not understand !  (sorry,
no example here).  Others understand @, % and !  but make !  bind more
tightly than % (PMDF is an example of this class).

Some UUCP mailers understand !  and @, but either do not understand %
(like vanilla smail2.x) or make % bind more tightly than !  (like some
modified versions of smail2.x)

Ancient UUCP mailers understand !  but do not understand @ and %.

It is not possible to be compatible with all existing mailers, so hybrid
addresses should really be avoided.  Personally, I would go with the
RFC1123 requirement of making % bind less tightly than other routing
operators, so a!b%c means (a!b)%c.

John Klensin, are you out there?

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

Re: Smail3, RFC1123, and the ! and % operators
#3812
Author: mills@ccu.umanit
Date: Mon, 02 Sep 1991 23:51
29 lines
1066 bytes
In <ch2bhbr@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:

>However, rewriting %-adddresses is not a good idea. Unless you are the
>machine to the right of the last %, you shouldn't mess with these addresses;

Here's how I would do it:

1) determine that your host is the one responsible for interpreting
   the address.  It must look like either ``localstuff@your.dom.ain''
   or ``your.dom.ain!restofit'', meaning an Internet domain address.

2) if so, remove your domain, making it a possibly-local address.

3) look for the rightmost ``%'' and change it to a ``@''.

4) if found, route it to the responsible host.

5) look for the leftmost ``!'' and the preceeding node name.

6) if found, route it to the responsible host.

7) it's a local address.  do local delivery.

This is how my sendmail.cf (based on one written by Eric Fair) does it.
Now, if the address contains no ``@'' and it's addressed to your UUCP
node name, the interpretation could be different.
--
-Gary Mills-         -Networking Group-          -U of M Computer Services-

Re: Smail3, RFC1123, and the ! and % operators
#3814
Author: rickert@mp.cs.ni
Date: Tue, 03 Sep 1991 12:34
37 lines
1871 bytes
In article <1991Sep02.205429.7343@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
>Some RFC822 mailers understand @ and %, but do not understand !  (sorry,
>no example here).  Others understand @, % and !  but make !  bind more

  The IBM mailers on VM systems understand @ and % but not !.  There are
many of these, and with the current move of many BITNET hosts to join
Internet, the number is growing.

>Ancient UUCP mailers understand !  but do not understand @ and %.

 Fortunately these are a vanishing breed, and mostly separated from
internet by some other host which knows how to deal with the problem.

>It is not possible to be compatible with all existing mailers, so hybrid
>addresses should really be avoided.  Personally, I would go with the
>RFC1123 requirement of making % bind less tightly than other routing
>operators, so a!b%c means (a!b)%c.

  This is the statement I don't like.  It says less than it seems.  Like
RFC1123 it is confusing.  What does it mean to say '%' binds less tightly
than '!', or to use parentheses to specify binding?  It is better to think
of '!' as a unary operator binding to its left operand, and '%' as a unary
operator binding to its right operand.  What does it mean when RFC1123 says
that '!' has higher precedence, but does not specify whether it is ordering
precedence from low to high, or from high to low?  In mathematical terms,
the binding, or the use of parentheses, specifies the associativity of
operators.  The problem here with email addressing operators is instead one
of commutativity.

  Can we use clear unambiguous terminology?

--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

Re: Smail3, RFC1123, and the ! and % operators
#3815
Author: peter@ficc.ferra
Date: Tue, 03 Sep 1991 17:35
32 lines
1493 bytes
In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes:
> I consider this interpretation to be incorrect and prefer a!(b%c),
> which is how Smail3 operates right now.

> I would really like to know what opionions people have on this topic.

I would agree with smail3 on this topic, since it is more useful: it allows
one to send to bang!inetuser%inet. Since ! is already at a higher
priority than @, you can already send to bang!banguser@inet. Thus
the RFC1123 definition adds no functionality.

On the other hand, from the internet side things change. If you want to
route to inet1, then to inet2, and then to bang!banguser you would need
to use RFC1123's semantics and use bang!banguser%inet2@inet1. If you
think of % as a nested @, these semantics seem obvious. This means you can't
use uucp to connect two internets, but you shouldn't have to: generally you
only need to do this sort of mess at the internet-othernet interface.

So, which way is more useful depends on where you're coming from. Since RFC1123
is the standard, it would be best to stick to it.

Since you can pretty much assume RFC976 conformance from any site on the
interface by now, you would use bang!inet!inetuser or inet!bang!banguser. The
functionality that smail-3's semantics provide is already present

I would say, then, change smail.
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

Re: Smail3, RFC1123, and the ! and % operators
#3816
Author: koreth@twitterpa
Date: Tue, 03 Sep 1991 22:57
24 lines
1135 bytes
In <1991Sep3.123457.10922@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <1991Sep02.205429.7343@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
>>a!b%c means (a!b)%c.
>  Can we use clear unambiguous terminology?

The parentheses weren't, I think, intended to be part of a mail address, but
instead to emphasize the precedence.  So read it, "a!b%c means go to host c,
then to host a, then to address b."

Another example (and incidentally, I agree that this should be made standard
somehow; it's very confusing for new mail users to navigate through networks
that parse this stuff in different ways):

a!b!c%d!e%f!g!h%i should be the same as i!f!g!h!d!e!a!b!c

Frankly, I'm a little mystified by the RFC822 authors' decision to use the
ugly @x,@y,@z:a@b syntax instead of standardizing an existing mail routing
character or two for the same purpose.

---
Steven Grimm  koreth@eng.sun.com   Moderator, comp.{sources,binaries}.atari.st
"We must be brave, and not let them know how frightened we really are."
                 -- OPEN LOOK Graphical User Interface Functional Specification

Re: Smail3, RFC1123, and the ! and % operators
#3817
Author: csvned@jarthur.C
Date: Wed, 04 Sep 1991 04:07
7 lines
204 bytes
Actually, PMDF can be configured to bind either % or ! more tightly, and
this can be done on a per-channel basis.

I've never heard of anyone using this feature for any useful purpose, however.

				Ned

Re: Smail3, RFC1123, and the ! and % operators
#3823
Author: chip@tct.com (Ch
Date: Wed, 04 Sep 1991 21:06
14 lines
682 bytes
According to rickert@mp.cs.niu.edu (Neil Rickert):
>In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes:
>>If one site considers % to be a high-precedence operator, in the sense of
>>the existing Smail3, then it can turn a%b@c into x!y!z!c!a%b.
>
>It is better to turn that into x!y!z!c!b!a.

I would avoid any interpretation of "%", unless there are no other
routing operators to be found in the address.  In other words: Put no
interpretation on the "local-part" unless the address is local.
--
Chip Salzenberg at Teltronics/TCT     <chip@tct.com>, <uunet!pdn!tct!chip>
    "He's alive; he's fat; and he's fighting crime.  He's Elvis: FBI."

Re: Smail3, RFC1123, and the ! and % operators
#3825
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:09
27 lines
1157 bytes
tron@Veritas.COM (Ronald S. Karr) writes:
> I would really like to know what opionions people have on this topic.
> If all mailers conform to RFC1123, then people who know the RFC1123
> will have some idea of what to expect from a remote site.  From that
> standpoint, Smail3 should probably be changed.  However, I consider it
> incorrect from the standpoint of correct operation in the world of
> UUCP.

Yah, rah.  Since UUCP sites are forced to rewrite @ into !, those two
operators should be next to each other in precedence.  Following RFC1123,
regardless of its inherent virtues as a standard, causes mail to be
misrouted.

> Comments and opinions would be appreciated.  My current intention is to
> either leave smail alone or make the new behavior mandatory.  Having a
> flag seems the worst of both worlds.

Agreed - when half the sites in the world configure it one way and half
the other way, nobody will know how to address mail to get it through.

I think smail 3.1 should keep working the way it is.  I wish RFC 1123
could be changed.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

Re: Smail3, RFC1123, and the ! and % operators
#3826
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:21
36 lines
1641 bytes
rickert@mp.cs.niu.edu (Neil Rickert) writes:
> RFC1123 is itself ambiguous.  The notation (a!b)%c is really meaningless
> for email addresses.  The authors of RFC1123 apparently intended it
> to mean -> c -> a -> b , which seems to contradict the term "lower
> precedence".

The authors seem to be using "lower precedence" to mean "binds more
loosely", which does kinda make sense.  This interpretation is the only
thing that makes the document read consistently, anyway.

> Many have concluded that the only reasonable
> reaction to RFC1123 is to avoid ever mixing '%' and '!' in an address.
> If an address already contains '!' and you wish to add additional
> routing, better to use another '!'.

This is a good rule of thumb for humans but doesn't help mailers much.  A
UUCP mailer has to rewrite @ addresses into ! paths to get them through
layers of UUCP hosts to a possibly-smart machine on the other side.  If the
possibly-smart machine wants to see a % address there's no way to rewrite
it without getting a mix of ! and % addresses.

>> then it can turn a%b@c into x!y!z!c!a%b.  If site y considers % to be a

>   It is better to turn that into x!y!z!c!b!a .  Most mail software which
> can handle '!' can deal with this.

Well, you're rewriting the local-part of somebody else's address here.  I
can't find it right now but I think RFC 1123 has a recommendation against
this.  Also, there are some mailers that can understand % addresses but
can't understand !.  Older Wollongong TCP/IP packages are like this, I
believe.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

Re: Smail3, RFC1123, and the ! and % operators
#3827
Author: fitz@wang.com (T
Date: Wed, 04 Sep 1991 23:34
31 lines
1342 bytes
peter@ficc.ferranti.com (Peter da Silva) writes:
> On the other hand, from the internet side things change. If you want to
> route to inet1, then to inet2, and then to bang!banguser you would need
> to use RFC1123's semantics and use bang!banguser%inet2@inet1.

Why not "inet2!bang!banguser@inet1"?  inet2 must be able to handle ! syntax
since it's apparently about to pass the message off to a UUCP-only machine.
Or, since you're on the Internet, "@inet1:bang!banguser@inet2"?  Yes, it's
disgusting to me too but it's legal.

I'm not sure your example is relevant anyway.  Users on the Internet rarely
need to hand-route through 2 relays to get to a destination site, while
this is common for the UUCP net.

> If you
> think of % as a nested @, these semantics seem obvious. This means you can't
> use uucp to connect two internets, but you shouldn't have to:

We've got a company internet here that's not connected to the real
Internet, and we'd like to get mail through.  There are hundreds of other
organizations in the same position.

> So, which way is more useful depends on where you're coming from. Since
> RFC1123 is the standard, it would be best to stick to it.

I think RFC 1123, despite being standard, causes problems.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

Re: Smail3, RFC1123, and the ! and % operators
#3828
Author: barrett@daisy.ee
Date: Thu, 05 Sep 1991 11:28
55 lines
2690 bytes
In article <1991Sep3.123457.10922@mp.cs.niu.edu>,
rickert@mp.cs.niu.edu (Neil Rickert) writes:
> >It is not possible to be compatible with all existing mailers, so hybrid
> >addresses should really be avoided.  Personally, I would go with the
> >RFC1123 requirement of making % bind less tightly than other routing
> >operators, so a!b%c means (a!b)%c.
>
>   This is the statement I don't like.  It says less than it seems.  Like
> RFC1123 it is confusing.  What does it mean to say '%' binds less tightly
> than '!', or to use parentheses to specify binding?

I think of !  as a binary operator that associates from the left, and of
% as a binary operator that associates from the right.  If !  binds more
tightly than %, then the a!b portion of a!b%c is considered as one unit
when the % operator is applied, so the address means (roughly) ``tell
system c to send to a!b''.  On the other hand, if % binds more tightly
than !  then b%c is considered as one unit when the !  operator is
applied, so the address means (roughly) ``tell system a to send to b%c''.

The parentheses in ``(a!b)%c'' don't go anywhere the mailer; they are
simply there to tell people what the address ``a!b%c'' *means*.  (Or,
rather, what one possible interpretation of the address means.)

> It is better to think of '!'  as a unary operator binding to its left
> operand, and '%' as a unary operator binding to its right operand.

Unary operators?  I see stuff on both sides of the !'s and %'s.

> What does it mean when RFC1123 says that '!'  has higher precedence,
> but does not specify whether it is ordering precedence from low to
> high, or from high to low?

The (a!b)%c example in RFC1123 clarifies what they mean by ``higher
precedence''.  Clearly, they want a!b%c to mean ``tell system c to send
to a!b''.

> In mathematical terms, the binding, or the use of parentheses,
> specifies the associativity of operators.  The problem here with email
> addressing operators is instead one of commutativity.

I don't think there is a problem with commutativity.  I think we all
agree that the addressing operators are *not* commutative (``a!b'' and
``b!a'' mean completely different things); that ``a!b'' means something
like ``tell system a to send to b''; and that ``a%b'' means something
like ``tell system b to send to a''.  What we don't all agree on is the
meaning of hybrid addresses containing both !  and % operators.

>   Can we use clear unambiguous terminology?

That would be nice.  But first we have to find a suitable terminology.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

Re: Smail3, RFC1123, and the ! and % operators
#3829
Author: peter@ficc.ferra
Date: Thu, 05 Sep 1991 14:21
15 lines
543 bytes
In article <bb92tg.7au@wang.com> fitz@wang.com (Tom Fitzgerald) convinced me
that I was wrong...

> We've got a company internet here that's not connected to the real
> Internet, and we'd like to get mail through.  There are hundreds of other
> organizations in the same position.

I think you're right. RFC1123 conflicts with RFC976, and so should be changed.
Smail's current behaviour is correct.
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

Re: Smail3, RFC1123, and the ! and % operators
#3830
Author: woods@eci386.uuc
Date: Thu, 05 Sep 1991 16:39
24 lines
1175 bytes
In article <28C54AE9.6102@tct.com> chip@tct.com (Chip Salzenberg) writes:
> According to rickert@mp.cs.niu.edu (Neil Rickert):
> >In article <1991Sep01.072418.15414@Veritas.COM> tron@Veritas.COM (Ronald S. Karr) writes:
> >>If one site considers % to be a high-precedence operator, in the sense of
> >>the existing Smail3, then it can turn a%b@c into x!y!z!c!a%b.
> >
> >It is better to turn that into x!y!z!c!b!a.
>
> I would avoid any interpretation of "%", unless there are no other
> routing operators to be found in the address.  In other words: Put no
> interpretation on the "local-part" unless the address is local.

That's exactly what lmail-2.7 does.

FYI, there's a new lmail-3.0 in beta now, soon to appear in c.s.m.  It
fixes a number of silly bugs, has a new locking mechanism based on the
SysVr4 maillock() routine which is backward compatible with AT&T
mailers, and does more error checking than you can imagine!
--
						Greg A. Woods
woods@{eci386,gate,robohack}.UUCP  VE3TCP	Elegant Comm. & UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]	Toronto, Ontario; CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL

Proposed resolution for Smail and RFC1123
#3846
Author: tron@Veritas.COM
Date: Sat, 07 Sep 1991 04:16
34 lines
1660 bytes
After corresponding with a few people on the subject and reading the
various messages that have been posted (thanks everybody), I have
decided that a hybrid approach is most appropriate.

The basic problem with the % operator, UUCP, and RFC1123 is that RFC976
turns ! into a routing operator in the message envelope.  In such
envelopes, the @ operator disappears.  As such, the address a%b@Y may
become path!Y!a%b.  This, correctly, allows Y to handle the a%b address
as local, for possible interpretation under the rules of RFC1123.

Since an address of the form path!Y!a%b is not an internet-conforming
address, anyway, it does not need to be interpreted outside of the
scope of RFC976, so RFC1123 need not apply.

If host Y is given an address a!b%c@Y, then Y has been given an
internet-conforming address, it should use the internet rules
(including RFC1123) for handling its local address.  Thus, the %
operator is used to break it up into a host c and a user a!b.  If c is
also host Y, it is then free to use the rules of RFC976 to break it up
into host a and user b.

In other words, my proposed new rule for smail: if an address was
originally in the form X@Y, where the local part X contains arbitrary
! and % operators, then obey the rules of RFC1123 when interpreting X.
Otherwise, use the existing Smail3 rules and consider % to have a
higher precedence than !.

This should allow for correct operation on both the Internet and in
the UUCP zone, with consistent interpretation of conforming internet
addresses in both zones.
--
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {amdahl,apple,pyramid}!veritas!tron

Re: Proposed resolution for Smail and RFC1123
#3847
Author: urlichs@smurf.su
Date: Sat, 07 Sep 1991 14:27
35 lines
1730 bytes
In comp.mail.misc, article <1991Sep07.041609.16213@Veritas.COM>,
  tron@Veritas.COM (Ronald S. Karr) writes:
<
< If host Y is given an address a!b%c@Y, then Y has been given an
< internet-conforming address, it should use the internet rules
< (including RFC1123) for handling its local address.  Thus, the %
< operator is used to break it up into a host c and a user a!b.  If c is
< also host Y, it is then free to use the rules of RFC976 to break it up
< into host a and user b.
<
There's only one problem -- suppose somebody mails to address a%b@c.
(Whether that % is a routing character or something else is irrelevant.)
C decides that this should be sent through UUCP, and generates g!f!e!d!a%b.
G decides to send that to E via (B)SMTP, and generates a RFC822 address
of either e!d!a%b@f or d!a%b@e. BANG.
Unfortunately, G doesn't have any other choice, except possibly to convert
the whole bang address to an RFC822 source route (not good), or a %-hack
source route (not good), or to ignore RFC822 and send a @-less address
(not good). Hmmm...



Let's look at the problem pragmatically -- how do mixed !-% addresses get
created in the first place? I'm only aware of %-@ addresses getting converted
into !-% (UUCP routing) and possibly into @-!-% (as in the above example).

I can _not_ think of a reasonable example for a mailer to insert %-routes
into addresses while ignoring !-routes in front; if you want to do source
routing, RFC822 already has an equally ugly mechanism for this, and any user
who uses such addresses will have big problems anyway. ;-)

--
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

Re: Smail3, RFC1123, and the ! and % operators
#3851
Author: kre@cs.mu.oz.au
Date: Sun, 08 Sep 1991 02:31
101 lines
4732 bytes
This entire discussion is right off the wall - its a completely
pointless exercise.  Both ! and % occur only in the "local part"
of an address (assuming we're talking about rfc822 type addresses)
and so have no defined meaning at all.  Its possible that some
sites (perhaps many sites) may decide to define one or both as
a routing character to be used when there's no @ in the address,
but that's not certain in any particular case - even less is it
certain that any particular site will treat both of them as routing
characters.  Its only when that particular co-incidence happens that
this particular ambiguity raises its ugly head.

Since you can't possibly tell what some remote site may be choosing
to treat as characters with routing related semantic meanings in local
parts, and even less can you require it, its completely meaningless
to attempt to provide any kind of standard meaning to this construct.
Sites will do whatever they want - usually whatever the author of the
mailer (or sendmail.cf file) chose for them, and they're perfectly
entitled to do just that.

So, users can't rely on this kind of thing, and given that, it simply
doesn't matter what sites do - though its helpful if having once
chosen a behaviour they stick with it, so the users will at least
have consistency, if not predictability.

However, the way I read this...

>In RFC1123 paragraph 5.2.16 states:

>              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".

is in line with standard mathematical notation, the words "lower
precedence" mean the same here as they would were the operaters
"+" and "*" and the operands numbers, and the example with the
parentheses is the natural result of that.

Just as with numbers, to me that example means "evaluate a!b, take
the result of that and use it in result%c".

Now, to "evaluate a!b" in a mailer (which happens to be treating !
as a routing character) I "send the mail to host a, and give it "b" to
act on.  So, now I have sent the mail to a, and have (b)%c, in
which the parentheses are clearly redundant, so I have b%c at a.
To evaluate b%c, assuming I am using % as a routing chacter, I
send the mail to host c, and give it b to act on.

So according to my reading of rfc1123 I am obviously advised (should
I happen to wish to treat both ! and % as routing characters) to send
the mail along the path "a" to "c" then to "b".

Furthermore, I contend that quite apart from the way that others seem
to have been interpreting this paragraph, this is the only possible
interpretation you can reasonably give it.  That is, other people
look at the example, see the parentheses, immediately interpret them
in a more tradional "mailer" sense, as "hide what's in here till later"
and come to the opposite conclusion, and then have to somehow make sense
of that.

However, look at it again more closely...

>              It is suggested that "%" have lower precedence
>              than any other routing operator

Read that aloud several times, then think about it a bit.
"lower precedence than any other routing operator"...

Clearly "@" is a routing operator, and "%" must be intended to have
lower precedence than "@", so now we have a reference point for deciding
just what "lower preference" is really intended to mean.

Its unquestionable that in an address with both @ and %, the "@" is
"acted upon" first, in the sense that the mail is sent to the host
associated with the "@" first, and then to the host associated with
the "%".

Now, since "%" is suggested to have lower precedence than "!" as
well, the same must happen, or "precedence" would have no meaning at
all, ie: if both "!" and "%" occur (and there is no "@" in the address),
send the mail to the host associated with the "!" first, and then to the
host associated with the "%".

No other interpretation makes any sense.

Finally, to pacify the clowns ... I repeat again, all of this is site
dependant, sites can do whatever they like, this paragraph of rfc1123
is nothing more than a suggestion, nor could it be more.  Also, 1123
is "requirements for internet hosts" and has nothing whatever to do
with hosts which aren't on the internet - so if you're a uucp only host
or something, this need not have anything to do with you at all, unless
you want it to.

The bozo who suggested that this doesn't apply to internet hosts because
internet addresses are required to contain @ characters should go back
and ponder what an internet host is supposed to do with an address
that ends "@my.domain" - its in this circumstance that the question
arises.

kre

Re: Proposed resolution for Smail and RFC1123
#3852
Author: tron@Veritas.COM
Date: Sun, 08 Sep 1991 03:12
38 lines
1829 bytes
In article <xq7b=7#@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>There's only one problem -- suppose somebody mails to address a%b@c.
>(Whether that % is a routing character or something else is irrelevant.)
>C decides that this should be sent through UUCP, and generates g!f!e!d!a%b.
>G decides to send that to E via (B)SMTP, and generates a RFC822 address
>of either e!d!a%b@f or d!a%b@e. BANG.

That's it, just throw a monkey wrench into my perfect solution to
solve all of the world's mail problems.

Hmmm...

I think that this runs into a crucial problem with respect to the UUCP
zone and SMTP: UUCP requires source routing, and SMTP (combined with
RFC1123) doesn't really provide source routing.

>Unfortunately, G doesn't have any other choice, except possibly to convert
>the whole bang address to an RFC822 source route (not good), or a %-hack
>source route (not good), or to ignore RFC822 and send a @-less address
>(not good). Hmmm...

Actually, @-less addresses may be a solution.  I will (perhaps
incorrectly) contend that this problem should only arrise when SMTP is
used for transfering mail within the UUCP zone.  As such, the rules of
RFC976 apply, rather than the rules of RFC822.  If the transfer is
Smail3-to-Smail3, there won't be a problem.  Smail3 will accept
addresses in SMTP messages that don't have a @.  Does anyone envision
any situations where this will present a problem?

There would have to be a mailer transport flag indicating RFC976 or
RFC822 behavior.  Also, this change to the SMTP protocol would only
be required when encountering !-% addresses.  If a !-only or %-only
address were encountered, conversion to !-@ or %-@ should still be
performed.
--
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {amdahl,apple,pyramid}!veritas!tron

Re: Smail3, RFC1123, and the ! and % operators
#3864
Author: fitz@wang.com (T
Date: Mon, 09 Sep 1991 23:09
28 lines
1244 bytes
kre@cs.mu.oz.au (Robert Elz) writes:
> Both ! and % occur only in the "local part"
> of an address (assuming we're talking about rfc822 type addresses)
> and so have no defined meaning at all.

... until the mail reaches the machine on the right hand side of the @, at
which time it had better have a defined meaning.  ! and % matter a lot at
that point.

> Its possible that some
> sites (perhaps many sites) may decide to define one or both as
> a routing character to be used when there's no @ in the address,
> but that's not certain in any particular case - even less is it
> certain that any particular site will treat both of them as routing
> characters.  Its only when that particular co-incidence happens that

The vast majority of sendmail sites, which is to say the vast majority of
UNIX Internet sites, treat both ! and % as routing characters.  Certainly
every sendmail.cf I've read does this.  The only sites I've found that
don't route using % are running smail 2.5 or a dumb UUCP mailer.  The only
ones I've found that don't route using ! are VMS sites.

This "particular coincidence" seems to be extremely widespread.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

Re: Proposed resolution for Smail and RFC1123
#3867
Author: mills@ccu.umanit
Date: Tue, 10 Sep 1991 03:21
15 lines
742 bytes
In <xq7b=7#@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:

>There's only one problem -- suppose somebody mails to address a%b@c.
>(Whether that % is a routing character or something else is irrelevant.)
>C decides that this should be sent through UUCP, and generates g!f!e!d!a%b.
>G decides to send that to E via (B)SMTP, and generates a RFC822 address
>of either e!d!a%b@f or d!a%b@e. BANG.

But, if somebody mails to a%b@c, when it arrives at C, C must interpret
the local part.  C is the responsible host.  It can't just prefix a bang
path and forward it somewhere else.  C must make it into a valid address
for whatever transport it uses.
--
-Gary Mills-         -Networking Group-          -U of M Computer Services-

Re: Smail3, RFC1123, and the ! and % operators
#3982
Author: moore@wilma.cs.u
Date: Fri, 27 Sep 1991 04:00
105 lines
4926 bytes
In article <1991Sep01.072418.15414@Veritas.COM>, tron@Veritas.COM (Ronald S. Karr) writes:
|> In RFC1123 paragraph 5.2.16 states:
|>
|>               An embedded source route is sometimes encoded in the
|>               "local-part" using "%" as a right-binding routing
|>               operator.  For example, in:
|>
|>                  user%domain%relay3%relay2@relay1
|>
|>               the "%" convention implies that the mail is to be routed
|>               from "relay1" through "relay2", "relay3", and finally to
|>               "user" at "domain".  This is commonly known as the "%-
|>               hack".  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".
|>
|> I consider this interpretation to be incorrect and prefer a!(b%c),
|> which is how Smail3 operates right now.
|>
|> I would really like to know what opionions people have on this topic.
|> If all mailers conform to RFC1123, then people who know the RFC1123
|> will have some idea of what to expect from a remote site.  From that
|> standpoint, Smail3 should probably be changed.  However, I consider it
|> incorrect from the standpoint of correct operation in the world of
|> UUCP.  Perhaps from the standpoint of Internet operation it makes
|> somewhat more sense.
|>
|> What do people think?  Somebody has sent me a set of "fixes" to smail
|> which, among other things, defines a flag for whether to use the old
|> behavior or the RFC1123 behavior.  This doesn't seem like the kind of
|> decision that a site should make on its own.  If one site considers %
|> to be a high-precedence operator, in the sense of the existing Smail3,
|> then it can turn a%b@c into x!y!z!c!a%b.  If site y considers % to be a
|> low-precedence operator, then it will deliver z!c!a to site b, which is
|> not what the original site wanted.

First of all, the correct interpretation of an address is dependent on
where the address comes from.  Any discussion of "how do you treat address
'x'" is meaningless without stating the source of address 'x'.

Now, assuming that the address

node!user%domain%relay3%relay2@some.domain

arrives via Internet mail (SMTP over TCP) at the primary mail exchanger
for "some.domain", the "correct" interpretation of the local-part
of the address is however that mailer wants to treat it.  Ideally,
there should be no assumption on the part of the mailer software that
enforces how local-parts are interpreted.

A reasonable default in this case (assuming that '%' cannot
appear in a local mailbox name) is to strip the '@some.domain',
change the last '%' to an '@', and interpret the resulting string
as an Internet mail address.

The other "obvious" interpretation would treat the address as
a UUCP address with the first hop named "node".  I feel that this
interpretation is less desirable than the first one, because it is
mixing the (admittedly unofficial) addressing conventions of the
Internet with those of UUCP.

If the same address had appeared on the envelope of a message which arrived
via "uux rmail", I would choose the latter interpretation.

Of course, e-mail users are well advised to avoid ambiguous addresses.
Domain-style addresses are then interpreted right-to-left (using the
'%' hack when necessary), and UUCP and DECnet addresses are interpreted
left-to-right, each for as many hops as possible.

|> Comments and opinions would be appreciated.  My current intention is to
|> either leave smail alone or make the new behavior mandatory.  Having a
|> flag seems the worst of both worlds.

Any 'flag' governing how to interpret addresses needs to be specific to
the addressing conventions of the incoming transport.  A system-wide
choice which is right for the Internet would be wrong for UUCP or DECnet.
If the primary address interpretation strategy failed, others could be
tried.

So e.g. for Internet:

(assuming the local mailer is a primary MX for "some.domain", strip
the '@some.domain' off, and:)
a) try the percent hack (attempt to relay msg to "relay2" via SMTP/TCP)
b) if that fails (i.e. no host or MX for "relay2"), treat it as a uucp address
c) if that fails (i.e. "node" isn't a known uucp host),
   bounce the message

And for UUCP:

a) try sending to "node" using uucp
b) if that fails ("node" isn't a known uucp host), try relaying it to
   'some.domain'
c) otherwise bounce the message

Finally, addresses should only be rearranged when crossing a boundary
between one network and another.  If a message comes in via UUCP and
leaves via UUCP, it should look exactly as if a bare-bones UUCP
system would have handled it.  (so mail to a!b!c@d would be relayed
to b!c@d in care of a)
--
Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN  37996-1301
Internet: moore@cs.utk.edu      BITNET: moore@utkvx

Re: Smail3, RFC1123, and the ! and % operators
#3990
Author: davecb@nexus.yor
Date: Sat, 28 Sep 1991 20:47
107 lines
4893 bytes
Once upon a time, ron@Veritas.COM (Ronald S. Karr) wrote:
| [rfc1123 says] "a!b%c" would be interpreted as "(a!b)%c".
| I consider this interpretation to be incorrect and prefer a!(b%c),
| which is how Smail3 operates right now.

moore@wilma.cs.utk.edu (Keith Moore) writes:
|First of all, the correct interpretation of an address is dependent on
|where the address comes from.  Any discussion of "how do you treat address
|'x'" is meaningless without stating the source of address 'x'.
[and an analysis which resolves the interpretation problem by applying
a channel-specific disambiguation rule]

  Well, I'm going to agree with you in general, but disagree with you in
a particular but important case.

  I agree that between addressing zones, an address which contains
routing information in what the zone considers to be the local-part
should only be routed in terms of the **rest** of the address.  In our
example, a!b%c in a zone which assumes rfc822 really means send to ``c,
local-part is a!b''.
  On first glance, this might mean that in the uucp zone, a!b%c is ``send
to a, local-part is b%c''.

  However, I claim that it is bad public policy to make this
distinction.  I argue (a) technological simplicity, (b) universality
and (c) the desirability of interworking with the broader internet
support the opposite conclusion.

a) Technological simplicity:
  Some mailers used in a uucp environment are perfectly
capable of dealing with mail in rfc822 format and resolving the
address into ``pure'' or ``old'' uucp notation without losing
information.  For example, on lethe the address ``davecb@yorku.ca''
resolves to yorku.ca!davecb, a legal command component to pass to the
uux program (yunexus!davecb is the older form of the same thing).
  Others are incapable of this transformation, but can deal with
non-local machine names in peculiar formats by the simple process of
not trying to interpret them.  telly!yorku.ca!davecb at last appears
processable by everyone who talks to telly, since they only need the
information to the left of the first ``!'' to send to.

  Given this ability to deal with 822-style addresses, by
transformation and by information-hiding, I argue that it is easy
to honor the rfc1123 clarification at the transformational level.
  That this question was raised at all also argues that selecting a
``correct'' interpretation is not technologically difficult (:-))

b) Universality
  I claim that context-dependent addressing is a **bad thing**.  As
a postmaster, I am prepared to use heuristics to deal with some of
the mail that lands in the dead-letter office.   After the fact I
can often manually forward mail whose address is context-dependent
by mentally simulating the context and guessing at where the mail
was supposed to go.
  However, since my customers insist on assuming mail is a reliable
bidirectional communications channel, I'd be facing a significant risk
(of dismissal!) if this heuristic had to become part of day-to-day
operations.

(c) the desirability of interworking
  I claim that the mechanisms used in the internet (domain-based
absolute addresses) and in x.400/x.500 (attribute-based absolute
addresses) are more suitable than routes, as used in raw uucp.
  I sincerely wish to encourage better cooperation between the
community which happens to use uucp transport and that which uses IP
transport: I don't see an advantage to religious wars if one of the
sides already has picked up much of the notation and techniques of the
other.  Therefor I argue against anything that would pull the
uucp-using community farther away from the internet community, and
claim that context-dependent interpretation of mail addresses is such
a danger.

  I see no reason why humans who happen to use uucp shouldn't be able
to send mail using ``person@place.domain'' notation, even if the
lower-level transport requires that be turned into routes, numeric
addresses or the names of postmen's horses.  I therefor argue against
addresses of the form a!b%c at all, and argue for a single, universal
interpretation if they do occur.
  As a side point to the above, I have made representations to a
national user group that they lend their good offices to the
registration of all my province's uucp-using sites in the internet
domain name system, with suitable forwarders for each of these sites
in .on.ca...

--dave (money follows mouth) c-b









  I only wish one form of address, one including the attributes
<personal-name|userid>, <organizational subunit|machine>,
<organization> and <upper-level organizing construct>.  That implies
that I'm partial to either of two notations: internet and x400.  And
I'd far prefer only one notation, too!

c)
--
David Collier-Brown,  | davecb@Nexus.YorkU.CA | lethe!dave
72 Abitibi Ave.,      |
Willowdale, Ontario,  |  Today's featured dish:
CANADA. 416-223-8968  |      Sun-dried alligator.

Re: Smail3, RFC1123, and the ! and % operators
#3992
Author: tron@Veritas.COM
Date: Sun, 29 Sep 1991 22:44
48 lines
2421 bytes
In article <davecb.686090823@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  I agree that between addressing zones, an address which contains
>routing information in what the zone considers to be the local-part
>should only be routed in terms of the **rest** of the address.  In our
>example, a!b%c in a zone which assumes rfc822 really means send to ``c,
>local-part is a!b''.
>  On first glance, this might mean that in the uucp zone, a!b%c is ``send
>to a, local-part is b%c''.
>
>  However, I claim that it is bad public policy to make this
>distinction.  I argue (a) technological simplicity, (b) universality
>and (c) the desirability of interworking with the broader internet
>support the opposite conclusion.

I agree that this is bad policy.  However, RFC976, RFC822, and RFC1123
fundamentally disagree on the matter.  As such the argument of
universality breaks down, along with the desirability of internetworking.
Essentially, internetworking and address universality requires that
the address operators be context sensitive.  The technological simplicity
argument is meaningless if it doesn't accomplish the goal of making
mail networks work correctly.

Simply stated, if someone says that their address is user%host@local.gateway
and neither gateway nor host recognize the ! operator, then a UUCP zone
host has no choice but to use the address:

	neighbor!path!internet.gateway!local.gateway!user%host

This is how UUCP zone hosts send mail to machines on the Internet, as
described very explicitly in RFC976.  RFC976 does not discuss the %
operator, but through implication with RFC822 it must be considered
part of the local-part for the host "gateway".

As I see it, conformance to RFC976, RFC822, and RFC1123, along with
correct operation on both the Internet and the UUCP zone, requires
context-sensitive parsing of addresses is the only alternative.
However, the context can be limited purely to noting the existence of
an @ operator in an address.  The address a!b%c@d is handled according
to the rules of RFC1123, the address a!b%c is handled according to the
rules of RFC976.

This is not an argument for how net software and standards should
work.  It is an argument for how mail software must work for existing
mail addresses to work on existing networks.
--
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {amdahl,apple,pyramid}!veritas!tron

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads