Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.misc Subject: Re: Which headers may Sendmail re-write? Message-ID: <1990Dec18.155353.5024@mp.cs.niu.edu> Date: 18 Dec 90 15:53:53 GMT References: <1990Dec16.203543.22769@chinet.chi.il.us> <1990Dec17.183615.3887@mp.cs.niu.edu> <1990Dec18.071226.20809@chinet.chi.il.us> Organization: Northern Illinois University Lines: 104 In article <1990Dec18.071226.20809@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec17.183615.3887@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > >> If you were a UUCP neighbor of mine, I would automatically rewrite >>'chinet.chi.il.us' as 'chinet.UUCP' on all header destined for you, until >>I was sure you could properly recognize the address as local. > >Hmmm, I thought that the big argument for having a registered domain >name was that it gave you an absolute address (i.e. interpreted the >same everywhere). If the gateways are going to eat the names on the >way out that concept sort of disappears. Besides, "real" uucp machines >won't understand "machine.uucp" as their own names either. Serves me right for trying to save a few words. The address would actually be written to 'machine!user'. I DO want you to register a domain name. I want it so badly, that even if your software isn't ready for it you should do it, and I will transform the addresses so that you software doesn't need to deal with it. As I said, I will only convert headers to UUCP format until I know that your software is ready to deal with domain name formats. >But, let's look at something a little more complicated, where the domain >name actually hides many uucp hosts. For example I have set up >fb.com through uunet, and everything destined for anyone@fb.com is >actually delivered to uucp machine "afbf05" which happens to be a >local call to uunet (D.C. area) but in fact most of the mail is >destined for one of several machines in the Park Ridge IL area connected >by a satellite link. All of the machines know how to resolve any >variation of user@fb.com (just like a local address, everybody is in >the aliases file), but it would clearly be wrong to change To: user@fb.com >to user@afbf05.uucp when in fact the user isn't there. Delivery would >not be affected of course, but you will force exactly the problem you >are claiming to be fixing - if someone does a group reply it's going >to bounce through the DC machine just to get back to the local host. Yes, but if you domain is set up this way, it presumably CAN handle domain names. As I said, I will preserve domain name formatted headers to a uucp neighbor as soon as I know they are set up to handle them correctly. >>Actually, if 'chinet' were a UUCP neighbor, and sent mail for me to >>relay to Internet, I would rewrite 'From: les@chinet.UUCP' as >>one of 'From: chinet!les@mp.cs.niu.edu', or >>'From: les%chinet.UUCP@mp.cs.niu.edu' or 'From: les%chinet@mp.cs.niu.edu'. >>But it would be my choice, not yours. (I believe I am currently using the >>second of these forms). > >What do you expect to happen when the "site!user@domain" form goes back off >the internet down a path to a uucp destination? Say you get a message I expect the internet -> UUCP gateway to transform the address to 'site!user' if the gateway happens to be 'domain', and to transform it to 'domain!site!user' (or perhaps 'gateway!domain!site!user') otherwise. Most Internet to UUCP gateways do this, Chip Salzenberg to the contrary notwithstanding. In that case prepending another 'node!' by a site along the way doesn't totally massacre the address. >In the case of fb.com it will look pretty much the way you write it but >my machines deliberately interpret the !-path first to accomodate a >broken (but not replacable) UA that generates group replies by making >a path back to the sending machine prepended to the To: and CC: addresses. >(But my reply to the sender will work anyway because it will use the >uucp From_ line). Oh. You mean that while complaining about everyone else's software, you own software is hopelessly broken! > >>However, since 'chinet' is not my UUCP neighbor, I rewrite >>'From: les@chinet.UUCP' as 'From: les@chinet.UUCP'. >> The difference is that for my UUCP neighbors I have an obligation of making >>their addresses useable by Internet hosts, and of providing a route back to >>them. But for a UUCP address which is not a neighbor, I have no such >>obligation to provide a return route. > >I would be a little more comfortable if this was worded more like: "I don't >modify les@chinet.UUCP because I have no naming authority for chinet.UUCP." I don't rewrite 'les@chinet.UUCP' as 'les@chinet.chi.il.us' because I have no naming authority for chinet. I don't rewrite it as 'les%chinet.UUCP@mp.cs.niu.edu' because chinet is not my uucp neighbor so I have no obligation to provide a route. (Does that make you happier? I didn't think it would). If chinet were my neighbor, I would consider rewriting 'les@chinet.UUCP' as 'les@chinet.chi.il.us', but this would be a matter of discussion. I would not do such renaming if chinet objected. But in that case I would provide the extra routing. >And this is precisely why I would like to see the uucp <-> internet gateway >machines set up domain names solely for the purpose of mapping their >uucp neighbors into convenient domain style names. In that case you would >not only have the "authority" to map the names, you would be able to do >it without undocumented or ambiguous kludges. As pointed out by others, the name space for which I have authority to create names may not be an appropriate name space for my UUCP neighbors. This is a side effect of the organizational orientation of the Internet names. Had there instead been a purely geographical name allocation this would be easier. But organization name structure do have benefits, as your experience with 'fb.com' illustrates. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940