Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!tolsoft!tron From: tron@tolerant.com (Ron Karr) Newsgroups: comp.mail.uucp Subject: Re: Paths and Precedence (Re: Question about From: lines) Message-ID: <1990Jul4.221134.15621@tolerant.com> Date: 4 Jul 90 22:11:34 GMT References: <2999.2688d45c@mccall.com> <2690C7F4.A40@tct.uucp> Reply-To: tron@tolsoft.UUCP (Ronald S. Karr) Organization: Tolerant Software Lines: 23 In article <2690C7F4.A40@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to fitz@wang.com (Tom Fitzgerald): >>Smail 3.1 avoids this problem by rewriting a%b as b!a in outgoing mail, >>[...] > >Lest anyone get the wrong idea, Smail 3.1 doesn't modify the message >header. It only modifies the envelope (i.e. rmail argument). While >envelope munging is unfortunate, it isn't EVIL and RUDE like header >munging. Actually, this behavior is controlled on a per transport basis. By default, if smail3.1 is given an address a!b%c where a is one hop, then it gives to a the address b%c. A flag can be used to change this behavior if you believe that your neighbors won't understand the b%c form. Also by default, if a is two hops, then it will give the address a!b%c to the neighboring host. With respect to operator precedence, Smail3.1 is correct in accordance with RFC822 and RFC976, with the % operator added as a more tightly binding operator than both @ and ! (and : and ::, for that matter). -- tron |-<=>-| ARPAnet: tolsoft!tron@apple.com tron@tolerant.com UUCPnet: {amdahl,apple,hoptoad}!tolsoft!tron