Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp From: tp@mccall.com Newsgroups: comp.mail.uucp Subject: Re: Imminent death of UUCP Zone predicted Message-ID: <3193.26aad657@mccall.com> Date: 23 Jul 90 10:49:58 GMT References: <100@raysnec.UUCP> <269B82AE.415E@intercon.com> <707@logicon.com> <1990Jul16.200955.29906@chinet.chi.il.us> <712@logicon.com> Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 59 In article <712@logicon.com>, Makey@Logicon.COM (Jeff Makey) writes: > > I should have been more specific: I have configured sendmail on my > Internet<->UUCP gateway to rewrite *all* headers into bang-only form > when the mail is being delivered via UUCP. The From_ line, in > particular, is rewritten, but sendmail also rewrites From:, To:, Cc:, > Reply-To:, etc. in a similar manner. If it comes from my machine via > UUCP, there are no @-signs in the headers. I realize that this > violates RFC 822, but such behavior is recommended in section 2.1 of > RFC 976 ("UUCP Mail Interchange Format Standard"): > > ``Because of the confusion surrounding hybrid addresses, we recommend > that all transport layer software avoid the use of hybrid addresses > at all times. A pure bang syntax can be used to disambiguate, being > written c.d!a!b in the first case above, and a!c.d!b in the second. > We recommend that all implementations use this "bang domain" syntax > unless they are sure of what is running on the next machine.'' Please note that in your quote from RFC976 it is talking about transport layer software. The transport layer software uses the envelope address, not the header addresses. RFC976 cites full compliance with RFC822, which explicitly prohibits the rewrite that your are performing. RFC976 gives several examples, all of which show bangpaths as envelope addresses, and unmodified RFC822 compliant addresses in headers. It does not recommend rewriting these, it forbids it! > It works, too. If you've been in on this discussion from the beginning, you'll recall that much of it derived from some of us complaining bitterly that it does not work, and we don't like being victimized in this way. > It's the sites that *don't* prepend their own names to the header > addresses that cause problems. More precisely, the problem is caused > by the fact that some sites prepend their own names and others don't. > If everybody did it, headers would all have nice complete bang-paths > in them. If nobody did it, you would only be able to reply to sites > listed in the UUCP Map. Sites that prepend their names to a bang path are doing something nice (I recommend it, in fact, as do most people in this discussion). It isn't required by RFC822, since the message in question ALREADY violates RFC822, because a pure bang path is not a valid address. It is a convention which works well (given that there is already a bang path there, I'm not referring here to the rewriting mentioned above!), but has no backing in a standard. If you want everyone to do it, get it put into a standard (of course you'll have to extend the standard to allow bang paths in the first place). Much software will then be upgraded and most sites will do this. You'll never get them all, but most sites that pass a lot of mail care at least enough to keep their software current. I even think you'll get a fair bit of support, provided you stay backward compatible. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA