Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hropus.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!hropus!ka From: ka@hropus.UUCP (Kenneth Almquist) Newsgroups: net.mail Subject: Re: Parsing mixed form addresses (! and @) Message-ID: <253@hropus.UUCP> Date: Sat, 8-Feb-86 00:22:54 EST Article-I.D.: hropus.253 Posted: Sat Feb 8 00:22:54 1986 Date-Received: Tue, 11-Feb-86 05:09:28 EST References: <1942@peora.UUCP> <11500004@unido.UUCP> <117@sering.mcvax.UUCP> <592@well.UUCP> <480@hoptoad.uucp> Organization: Bell Labs, Holmdel, NJ Lines: 59 > Just because I run uucp doesn't mean I don't know better! It means > nobody has offerred me an Arpanet connection in the same price range. You want to run RFC822 mail over UUCP. Fine. But pretending that UUCP mail is RFC822 mail doesn't work very well. Consider a simple RFC822 address: "Kenneth Almquist"@hropus.att The first uux that gets this address will strip off the quotes; the second will split the address at the space, which is now unquoted. Or consider any address that contains angle brackets; uuxqt will kick back all such addresses for security reasons. Berkeley's attempts to treat UUCP mail like RFC822 mail have not given us a correct implementation of RFC822 over UUCP. What they *have* done is to make a mess of UUCP mail; it is clear to me that things like giving @ precedence over ! are undesireable in UUCP mail and should be fixed. But you want to run RFC822 mail to your Arpanet gateways. This seems like a reasonable idea to me. If nothing else RFC822 mail has the advantage of having a well defined standard. But you loose this advantage if you don't implement the standard correctly. If RFC822 is worth doing at all, it is worth doing right. I will briefly consider some problems: First problem: some UUCP's insist on sending back acknowledgements for every remote execution unless the program being run is rmail. Solution: send RFC822 mail by remotely executing rmail with the -a option. Install a new version of rmail which execs the old version unless it is called with the -a option. Second problem: RFC822 assumes that the destination(s) and return path for the mail will be sent in the SMTP envelope. Solution: store this information in two lines preceding the piece of mail. For example: Currently-To: , <@hropus: xxx@houxm> Return-Path: [The RFC822 header starts here] The addresses are all route-addresses in the format specified by RFC822. Third problem: Once you start talking RFC822 to some sites, you must be able to convert UUCP mail to RFC822 and vice versa. Solution: you can use the Berkeley mail code, which does this badly, or write your own and do a better job. So if you like RFC822, write some code to do it, get you neighbors to install it, and live happily ever after. The only reason that we don't have RFC822 mail running on top of UUCP now is that no one has gotten around to doing it. It would not take all *that* much work to put together a system to handle RFC822 mail over UUCP, and anyone who did it would be rewarded by the love of all the RFC822 lovers out there. My only suggestion is that you write up a proposal for encapsulating RFC822 mail and post it before you start coding, since everybody will have to live with this standard. I would be willing to expand upon my own ideas of how to do this if anyone is interested. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path) But we *had* a nice mail standard, until people started contaminating it with ideas from RFC822 :-)