Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!MRC@SU-SCORE.ARPA From: MRC@SU-SCORE.ARPA (Mark Crispin) Newsgroups: net.mail.headers Subject: Re: Bogus "Arpanet hosts" Message-ID: <337@hou3c.UUCP> Date: Mon, 5-Mar-84 00:22:48 EST Article-I.D.: hou3c.337 Posted: Mon Mar 5 00:22:48 1984 Date-Received: Wed, 29-Feb-84 14:37:08 EST Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 29 To: Hamilton.ES@PARC-MAXC.ARPA Cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from "Bruce Hamilton" of Mon 27 Feb 84 20:05:41-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Bruce - The TOPS-20 mailer, by deliberate design, does not perform any relay services beyond that of a bridge. CMU and Columbia both run this software (although your example involved CMU-CS-PT, a Unix system). Unlike the UUCP world, I consider store-and-forward relaying and relative addressing to be temporary measures pending the adoption of a universal standard for electronic mail addressing. It's too bad that so many people confuse "where" the person is with the "way to get there." I also have substantial reservations about the entire philsophy of header-munging. All too often I have seen my message headers transmogrified into invalid headers by a well-meaning, but incorrect, header modifier. Several delivery problems, especially in the early days of SMTP, proved to be undebuggable because a header modifier succeeded in destroying the information needed to figure out what happened. Worse is the habit of MMDF and certain other header modifiers to make a message header "cute" by applying certain rules of case modification; I'm really tired of seeing crap such as "Mit-Xx", "Su-Ai", or - the worst insult of all - "Mrc". I feel that a host using the services of a bridge should be willing to generate a message header that is valid at the other side of the bridge. It isn't difficult to do, especially if both sides of the bridge are willing to recognize Internet addresses. -- Mark -- -------