Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/3/85; site ukma.UUCP Path: utzoo!watmath!clyde!cbosgd!ukma!david From: david@ukma.UUCP (David Herron, NPR Lover) Newsgroups: net.mail Subject: Re: Parsing mixed form addresses (! and @) Message-ID: <2685@ukma.UUCP> Date: Wed, 12-Feb-86 22:12:31 EST Article-I.D.: ukma.2685 Posted: Wed Feb 12 22:12:31 1986 Date-Received: Fri, 14-Feb-86 02:43:19 EST References: <1942@peora.UUCP> <11500004@unido.UUCP> <117@sering.mcvax.UUCP> <592@well.UUCP> <480@hoptoad.uucp> <253@hropus.UUCP> Reply-To: david@ukma.UUCP (David Herron, NPR Lover) Organization: U of KY Mathematical Sciences Lines: 68 In article <253@hropus.UUCP> ka@hropus.UUCP (Kenneth Almquist) writes: >> 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. > >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. Oh geez.... It's not a good idea to go mucking up a standard to handle local problems. What do you do with these nifty-keeno new-style header lines at gateways? (A position we're in here by sitting on 3 networks (bitnet, csnet, and usenet)). BITNET has something which will solve this problem already. It's called BSMTP, the B stands for Batch. (Remember what kind of computer makes up half of BITNET?). Anyway, BSMTP is a batch form of SMTP. All the same information is exchanged between the two machines, but as two seperate file transfers rather than a two-way conversation. In addition.... there is a program ALREADY EXISTING which will handle BSMTP and do routing amongst a bunch of domains, etc, etc... It's the mail portion of the UREP package (Unix RSCS Emulation Program, the little gadget which attaches us to BITNET). Some problems: 1) UREP documentation is abominable, and the code reads even worse. (It looks like it's well designed code, but there's SO MUCH of it and it's uncommented and not very self-documenting) 2) UREP requires source liscences, etc. Also some dealings with Penn-state. 3) The file which controls the routing is ONE FILE for ALL domains you provide routing into. (This is fine for me because that program only handles stuff going into bitnet, so the file is 1100 lines long, buuuut, between my entire database I probably have 10,000 hosts listed) Also, I don't think there's any hashing on the file meaning linear searches... again, for a huge domain table this will be murder. 4) The code has some hard-wired assumptions (I think) about bitnet. On the other hand, it looks like a very capable system and can easily be made to interface with uucp mail. (bitnet doesn't talk directly to this program, but goes through 2 other programs before it gets to the router, then for sending it back out it goes through another 2 programs). I can probably dig up some documentation if anybody's interested... -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@mathsci.uky.csnet ^ Notice new and improved address---| Postmaster for Kentucky "'New and improved' is a misnomer" -- David Herron, 1986