sdroppers@pbs.uucp (Seton Droppers) (06/09/90)
I am wondering what should "really" be put in the "From" line of our mail. We
have just recently registered as the domain pbs.org (We used to be simply a UUCP
site) and exchange news and mail via the DECUS UUCP software on a VMS 5.2
system.
When I send mail through our local mailer such that it stays "within" my site I
get a from line for my message (se example 1) with my local mailbox and the
domain (sdropers@pbs.org). When I send mail to either of to neighbors and back
the from line gets changed to the form "othersite!pbs.org!sdroppers" (see
examples 2 and 3). Is this really correct? I have had one remote site request
that my neighbors not "mung" the from line, and this makes lots of sense. Also,
reading paragraph 4.4.1 (page 21) of RFC #822 I wonder what an "authenticated"
machine address refers to?
Thanks ever so much.
Seton
--
Seton Droppers -- "Anything that I say is my opinion and not my employer's."
Public Broadcasting Service, 1320 Braddock Pl. Alexandria, VA 22314
(Domain: sdroppers@pbs.org)
(UUCP: ...{uupsi,vrdxhq,csed-1,ida.org}!pbs!sdroppers) (Voice: 703/739-5100)
(VAX/VMS running DECUS UUCP 1.1, ANU News 5.9C)
---Example 1---
From: UUCP%"sdroppers@pbs.org" 8-JUN-1990 08:06:01.86
To: sdroppers@pbs.org
CC:
Subj: Testing uucp%"sdroppers@pbs.org"
Received: from pbs by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 08:06:00 EDT
Received: by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 08:03:33 EDT
Date: Fri, 8 Jun 90 08:03:33 EDT
From: Seton R. Droppers <sdroppers@pbs.org>
To: sdroppers@pbs.org
Subject: Testing uucp%"sdroppers@pbs.org"
This is a test message. 8-JUN-1990 08:03:30.11.
---Example 2---
From: UUCP%"uupsi!pbs.org!sdroppers" 8-JUN-1990 10:30:51.15
To: pbs!sdroppers
CC:
Subj: Bounce Test uucp%"uupsi!pbs!sdroppers"
Received: from uupsi by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 10:30:47 EDT
Received: from pbs.UUCP by uu.psi.com (5.61/3.1.060790-Performance Systems International-Albany)
id AA08115; Fri, 8 Jun 90 09:53:20 -0400
Message-Id: <9006081353.AA08115@uu.psi.com>
Received: by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 08:47:28 EDT
Date: Fri, 8 Jun 90 08:47:28 EDT
From: Seton R. Droppers <uupsi!pbs.org!sdroppers>
To: pbs!sdroppers
Subject: Bounce Test uucp%"uupsi!pbs!sdroppers"
This is a test message. It should go out to uupsi and back. 8-JUN-1990
08:47:24.44.
---Example 3---
From: UUCP%"vrdxhq!pbs.org!sdroppers" 8-JUN-1990 10:53:47.64
To: vrdxhq!pbs!sdroppers
CC:
Subj: Bounce test uucp%"vrdxhq!pbs!sdroppers"
Received: from vrdxhq by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 10:53:43 EDT
Received: from pbs.UUCP by vrdxhq.verdix.com (4.12/5-June-90) with UUCP
id AA13753; Fri, 8 Jun 90 09:58:03 edt
Message-Id: <9006081358.AA13753@vrdxhq.verdix.com>
Received: by pbs.org (DECUS UUCP w/Smail);
Fri, 8 Jun 90 08:48:21 EDT
Date: Fri, 8 Jun 90 08:48:21 EDT
From: Seton R. Droppers <vrdxhq!pbs.org!sdroppers>
To: vrdxhq!pbs!sdroppers
Subject: Bounce test uucp%"vrdxhq!pbs!sdroppers"
This is a bounce ttest. It should to to vrdxhq and back. 8-JUN-1990
08:48:16.71.tp@mccall.com (06/27/90)
In article <1990Jun15.162029.27337@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > Yes, I understand that RFC976 is intended only to specify uucp mapping > of RFC822 addresses. However the syntax is so much neater than % > or @routes, not to mention being straightforward to parse, that it > seems to me that it should be accepted everywhere. But it is non-standard. If it isn't in RFC822, it isn't going to be understood by EVERYBODY. There are already too many things that are only understood by some sites, not others. Just because it looks nice doesn't mean people will rush to change their software to handle it. Rather than invent another standard, we should try to make the current one (RFC822) work. That means getting sites not to mung compliant addresses, and getting everyone to get a compliant address (i.e. registered domain name). > In article <2844.2676131a@mccall.com> tp@mccall.com writes: >>The domain-bang-path notation was never intended to appear in RFC822 >>compliant headers (like From:), as this notation violates RFC822. > > But this wouldn't matter if (a) mailers understood do.main!user to > be equivalent to user@do.main and (b) didn't rewrite compliant > headers. But (a) they don't (not all of them), and (b) some of them do. How are you going to get them all to change? This will never happen unless RFC822 is updated and adopted by the group that controls internet standards (I know there is one, but I don't know who they are). The internet is too pervasive to buck. Most mail and news crosses it eventually. If your message doesn't follow internet standards, you are at the mercy of the postmaster of each machine, and how much he was inclined/able to deal with non-standard formats. >>Thus, no internet host SHOULD ever see a domain-bang-path address unless it >>put it there, with its domain name attached. > > Are you saying that internet hosts don't want to believe that there are > machines that they cannot access directly or that you prefer ambiguous > or arcane local-parts of addresses? Allowing an abitrary mix of > host and domain names parsed strictly left-to-right would make things > incredibly easy by comparison. The header lines should still not > be re-written unless done by a gateway that knows a different syntax > is needed to be understood by the destination, though. What I'm saying is that on the internet, the From: line MUST be RFC822 compliant. Internet hosts have a set of standards that they must follow to be compliant. The one that deals with mail is RFC822. They are under no obligation to support any extentions to this, and thus there will always be hosts that don't. In effect, the uucp world (specifically the UUCP Project, since nobody else stepped forward), decided to integrate into the internet as far as mail goes. This implies that uucp sites will get registered domain names and will follow the RFC822 standard for mail. As far as mail goes, the term `internet' really includes all uucp hosts that have registered domain names (which implies MX forwarders). An internet host can't tell the difference when sending the mail. Many actual internet hosts are only reachable via MX. The `uucp mail network' has no identity as a network in and of itself. It never has. As a result of the direction the UUCP Project has gone, it never will. As far as mail goes, you can either just be a uucp site, in which case things will never work well, or you can adopt RFC822 and get a registered domain name, in which case things will work fairly well. If we can get sites to stop rewriting valid RFC822 From: addresses, having a registered domain will work as well as being on the internet itself. If you want to use a different standard, it looks like you have 3 options: 1) Do what you want and hope it works, with no guarantees. That's what most unregistered uucp sites do now, by putting user@site.uucp or site!user or something else in the From: line, or not having a From: line and relying on the From_ line. 2) Get RFC822 modified and accepted as an internet standard. At some point, most all internet software would become compliant to the new standard. I bid you good luck. 3) Reject the concept of integrating into the internet address scheme. Form an alternate network of uucp sites, with gateways into whatever networks you want to talk with (e.g. the internet) that perform the gatewaying function the way you want. Then all legitimate gateways would have predicatable behavior, and you could develop a set of rules that would always work. Call your network something other than the `uucp mail network', though, and realize you would need gateways for it also, if you had any uucp links from your network to uucp sites that weren't in your network. Good luck getting this to work. On the other hand, you could consider Bitnet to be an example of this, and it seems to have worked at least as well as uucp (non-domain). My machine has a registered domain name, and as long as it is not munged, it doesn't matter that an internet site can't access me directly. I've been getting mail via this address since the day it was registered, 30 days before the maps were updated. If you have a non-RFC822 address, then you are stuck encoding it into the local-part, because you have NO OTHER OPTION. Once the mail crosses the internet it WILL be made RFC822 compliant. period. How the host that does this chooses to do it is up to the guy who wrote or configured the software. There isn't a standard to cover this. I think this is because no standard can fully handle it. You can make the choice rather than leaving it up to the gateway, by sending out something RFC822 compliant that you think will work, but because of munging, there is no guarantee that your From: line will survive. Domain-bang-path wouldn't solve the problem, even if it were allowed. If a bang path starts with an unqualified uucp host name, what does an internet site do with it? Remember that many sites won't update a bang-path on the From: line, so its contents are unreliable. Getting it into RFC822 would help, but non-internet sites would probably still mess it up. I really couldn't predict how big a problem that would be, or for how long. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
tp@mccall.com (06/27/90)
In article <00001FL@cdis-1.compu.com>, tanner@cdis-1.compu.com (Dr. T. Andrews) writes: > In article <14423@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: > ) Right. If the From: line has what looks like a valid RFC822 > ) address in it, you leave it alone. Otherwise, replace it with > ) the bang path ... Note that user@host.UUCP is explicitly NOT a > ) valid RFC822 address in this context. > True, there is no true ".UUCP" domain. However, if you replace the > "From: name@site.UUCP" with a bang path, you have surely made the > mail unreplyable to people who use the "From:" line. Actually, most uucp sites will understand a bang-path on the From: line. If you don't have a valid RFC822 path to put there, a bang path is probably better than nothing. The problem, however, is that if the message goes out over the internet, it will be made RFC822 compliant, usually by making it a mixed mode address (i.e. bang-path@host.domain). If this goes from the internet back to uucp, it will probably be totally useless. On the other hand, what is a better alternative? user@site.uucp has equally severe problems. > If you leave > the "From:" line untouched, it is replyable. While this is often true, it often isn't. It MAY be replyable. If the site is not in the uucp maps, it is NOT replyable. Such a site should send out site!user rather than user@site.uucp, but I think many such sites are precisely the ones that don't know all the issues involved. site@host.uucp is also not replyable if the host trying to use it doesn't have access to uucp maps, such as an internet site with no uucp links. Such a site could reply to bang-path@host.domain, however. Thus in some contexts, preserving host.uucp is specifically a bad thing. > Sites with "smart" mailers are often able to understand "From:" lines > with ".UUCP" addresses, because they look at the (possibly compiled) > maps. This applies almost exclusively to uucp sites with smart mailers. How many internet sites with no uucp links bother to handle the uucp maps? > Since you cause harm by re-writing the "From:" line, and cause no > harm by leaving it untouched, I advocate leaving it untouched. You cause harm either way. Converting to a bang path is bad, because some sites will update it, and some won't. Thus after a few hops the bang path is probably useless (depending on how smart the hosts actually on the path are, often they can route over the hops that didn't update the path). On the other hand, leaving host.uucp in is bad, because internet sites can't reply to it, and it is useless in the first place if the site isn't in the maps. This is one of those cases where you have to make a judgement call as to what is most likely to work. There is no "good" solution, because there is no "good" way to address a host without a domain name in a way that will work from anywhere. UUCP bang-paths always required the user to know a great deal about the layout of the network to make them work. They still do. Domain name solve this problem to the extent that they are used. Trying to squeeze bang-paths into domain names will never work well, because you get the worst of both worlds. The address gets mangled over time, and often still requires a knowlegeable user to be useful. Unfortunately, you MUST do something of this sort, because it is the only way to reach an unregistered host. BTW, before anyone suggests that when a mixed-mode address goes from the internet to uucp, it should be rewritten RFC976-style, this causes problems too. While it solves this particular case, it then means that you are rewriting valid RFC822 addresses, which is the current problem. It screws up registered sites badly. It also violates both RFC822 and RFC976. This is because RFC976 was written to handle registered uucp sites, while providing as much back-compatibility as possible. It simply can't handle this case. The only PRACTICAL solution (i.e. one that works and doesn't require action from lots of people who don't care enough about the problem to do something about it) is for unregistered hosts to get registered. An unregistered host will always have trouble getting mail. To the extent that this is a problem for internet people (for having to answer questions, or figure out how to address mail), they can best help by helping uucp sites get registered. The process is currently cumbersome and problematical enough to discourage many people from doing it. Improvements would be welcome. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
tp@mccall.com (06/27/90)
In article <14495@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes: > I said >>>the From: line has what looks like a valid RFC822 address in >>>it, you leave it alone. Otherwise, replace it with the bang path you >>>got from the From_ line. Note that user@host.UUCP is explicitly NOT a >>>valid RFC822 address in this context. > > In article <267E85F1.33B4@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Last I checked, this behavior (transforming "user@host.uucp" into >>"foo!bar!host!user") is *not* sanctioned by RFC976. It *is* rude to >>those sites who want to provide return addresses in the UUCP zone. RFC976 says only this about host.uucp: Names such as "ucbvax.UUCP", consisting of a 6 letter name followed by ".UUCP", previously were domain style references to a host with a given 6 letter name. Such names are being phased out in favor of organizational domain names such as "ucbvax.Berkeley.EDU" It also says this: (The UUCP zone is that subset of the community connected by UUCP which chooses to register with the UUCP project. It represents an administrative entity.) Thus host.uucp, being unregistered is not in the uucp zone, nor is it sanctioned by RFC976. RFC976 is intended to define the standard format for the transmission of mail messages between machines in the UUCP Project. Being "in the UUCP Project", can be infered to mean (if you actually read the RFC), having your site registered, and thus having a domain name (because it requires sites "in the UUCP Project" to conform to RFC822). It explicitly requires From: lines to be RFC822 compliant, and Brian is correct that host.uucp is not an RFC822-compliant domain name. RFC822 requires domain names to be not only syntactically correct, but to actually exist as well, and this would mean MX records, etc... RFC976 doesn't cover unregistered sites, and was not meant to. There is no RFC that does, to my knowlege. You aren't in the UUCP zone, because you aren't registered (according to the definition of the zone given in RFC976, anyway). host.uucp is not sanctioned or protected by any standard, so Brian can legitimately do whatever he wants with it. That's why there are standards, to prescribe what should be done in different cases. In the abscence of a standard, one can do just about anything, and there WILL be problems. Each postmaster will either accept whatever the default is, or will make his own best guess about the correct thing to do. Since they all make different guesses, the result is chaos. I see 2 solutions. You could invent a new standard that would apply to unregistered sites, and get it approved and adopted. I don't know what you could do that would work though. Or you could register a domain. Granted this can be a pain if there is no friendly internet site handy. This part of the process could be made much better/simpler/easier. Unfortunately, the NIC controls the process and requirements for registration, and uucp sites are definitely not their priority concern. I don't know what you could do to improve things. > Yes, that's one of the places where RFC976 is wrong. Someday I'll get > around to updating it in a newer RFC. In what way is it wrong? It doesn't even cover this case. > The UUCP zone is dying. It was only a stopgap until a way to register > non-internet sites in the worldwide domain name system existed, and now > that we have that, it can quietly go away. It was a wonderful thing but > it is clearly time to retire it. Umm... I'm registered in the UUCP zone, n'est-ce pas? I registered through uunet, and I'm a uucp site, or did the zone get defined as something else when I wasn't looking? Are you suggesting that each site deal directly with the NIC? While it saves the $35, most people, including myself, wouldn't even know where to start. You'd also have to dig up some friendly name-servers (if you aren't using those provided by the UUCP Project), which would be MUCH more difficult than finding an MX forwarder. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
tp@mccall.com (06/27/90)
In article <1990Jun25.153424.27594@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > Can someone explain how having a registered domain name helps anyone who > doesn't hide multiple machines behind it (other than the obvious reason > of the requirements of certain mailers)? For the case of 1 uucp machine > equals one second-level domain name, won't this just double the size > of the pathalias lookup files if you put the names in the maps, or force > everything to go through the internet (or at least uunet) if you don't? It gives you a valid RFC822 address. Even if some mailer munges the From: line to oblivion, someone can get your email address out of your signature. (Aside: ALWAYS use a signature, because From: lines DO get munged. That's directed at everyone, not anyone in particular.) This address is useable from anywhere on the internet, or any uucp site with a smart mailer, and even most Bitnet sites, I believe. People at uucp sites with dumb mailers have to know how to route mail by hand anyway, and most of the know how to route a message to the internet. If you aren't registered, but are in the maps, your From: lines will usually be useless. People that are not at uucp sites with smart mailers must specifically know how to mail to an unregistered site, which generally involves setting up weird addresses to get things to go to the right gateways (you also have to know which gateways to use). If you aren't even in the maps, hang it up. > Could machines that forward to uucp sites hide the path information in > their subdomain name space instead of the local-part of the address > where it is often misinterpreted? Sure, if they choose. It works reasonably well, except that you have to keep explaining that you don't really work for xyz... Seriously, this works well (I used to be tp@mccall.claremont.edu). I expect the reason it isn't done more is that registering a domain makes you responsible for your subdomains, and thus answerable for the activities of machines within your domain, if not in any legal sense, at least as to the reputation of the company/organization owning the domain. The admin would have to trust you, basically, not to embarrass him. Also, some object to it on esthetic grounds ("But your machine ISN'T part of the university..."). It'd be funny if we started seeing host names like: pcbbs.NotPartOf.Berkeley.edu -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
jeh@dcs.simpact.com (06/29/90)
In article <3001.2688df6b@mccall.com>, tp@mccall.com writes: > (Aside: ALWAYS use a signature, because From: lines DO get munged. This will work until some well-meaning fool (there are always a few around) decides to write a new RFC, and corresponding AI-like software, to recognize signatures and change addresses in them. "If you are sending the message via a uucp link, you must change any RFC822 address that appears in the signature into bang form." Don't laugh. Someone already tried to write the software. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair and uucp protocol guru, VMSnet Working Group, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
karl_kleinpaste@cis.ohio-state.edu (06/29/90)
chip@tct.uucp writes:
If we're not going to use RFC976, then why bother publishing it?
(*chuckle*)
Sometime, strictly for the humor value, write to
hostmaster@nic.ddn.mil, or perhaps postmaster@ddn1.dca.mil, or
something of that ilk, and ask why RFC1031 ("MILNET Name Domain
Transition") hasn't been adhered to[*]. 1031 specifies the conversion
schedule of the MILNET from HOSTS.TXT usage to nameserver usage.
The MILNET purportedly completed this conversion at the end of Oct
1989 (see 1031 p.3, Table 1, "Migration Timetable"). It's just a
fantasy RFC, though; strictly vaporware.
Not all RFCs are either useful or correct.
--karl
[*] Don't actually bother asking. I did so last December for personal
reasons having to do with excessive interaction with MILNET people
over nameserver issues. The answer I got back from the NIC was, shall
we say, unsatisfying.
--
Depression \di-'presh-un\ n. A condition observed on return from
3 weeks' vacation to find ~2000 mail messages waiting for oneself.
(And people marvel that I employ GNUS as a mail-reading interface.)tp@mccall.com (06/29/90)
In article <1412.2689d9b8@dcs.simpact.com>, jeh@dcs.simpact.com writes: > In article <3001.2688df6b@mccall.com>, tp@mccall.com writes: >> (Aside: ALWAYS use a signature, because From: lines DO get munged. > > This will work until some well-meaning fool (there are always a few around) > decides to write a new RFC, and corresponding AI-like software, to recognize > signatures and change addresses in them. "If you are sending the message > via a uucp link, you must change any RFC822 address that appears in the > signature into bang form." > > Don't laugh. Someone already tried to write the software. OK, I know about smilies :-) and frownies :-(, but how do you do a weepie (lots and lots of them). If I didn't know Jamie, I'd think he was pulling my leg. On the other hand, I've met people as dumb as whoever he's talking about, and some of them were even able to write software... -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
les@chinet.chi.il.us (Leslie Mikesell) (07/03/90)
In article <3001.2688df6b@mccall.com> tp@mccall.com writes: >It'd be funny >if we started seeing host names like: > pcbbs.NotPartOf.Berkeley.edu I had in mind something like: site2.site1.bang.Berkeley.edu meaning: consult the rules for delivering to subdomains under the subdomain "bang" to obtain the routing for the message. This notation would make it clear that no one except a gateway for Berkely.edu has any business interpreting it as well as being a legal address everywhere that domain addresses are wanted. If the path contains characters that would be illegal as subdomain names something like this might work: 6973657421316973657432.hex.Berkeley.edu Les Mikesell les@chinet.chi.il.us
oc@vmp.com (Orlan Cannon) (07/03/90)
In article <2998.2688cec8@mccall.com>, tp@mccall.com writes: > If you want to use a different standard, it looks like you have 3 options: > > 3) Reject the concept of integrating into the internet address scheme. > Form an alternate network of uucp sites, with gateways into whatever > networks you want to talk with (e.g. the internet) that perform the > gatewaying function the way you want. Then all legitimate gateways > would have predicatable behavior, and you could develop a set of rules > that would always work. Call your network something other than the > `uucp mail network', though, and realize you would need gateways for it > also, if you had any uucp links from your network to uucp sites that > weren't in your network. Good luck getting this to work. On the other > hand, you could consider Bitnet to be an example of this, and it seems > to have worked at least as well as uucp (non-domain). Or just designate certain machines to be "UUCP-Domain Gateway" machines. Then everyone in the UUCP Domain could have an address such as "joe%bob.uucp@uunet.uu.net". Then just make sure that uunet (or whatever registered gateway) would take the Internet addresses and turn them into valid addresses for whatever neighbor it was passing them to. And receive addresses in any format and turn them into valid Internet addresses. All it would take is informing the gateway what kind of mail software and what kind of addressing you are using. It seems to me that this is the de facto situation and that the problems are occurring at the exceptions rather than the rule (i.e. sites that don't talk to their neighbors about the format of the stuff they intend to pass through them). -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. (800) 627-4551 Oradell, NJ 07649
tp@mccall.com (07/03/90)
In article <1990Jul2.234056.5169@vmp.com>, oc@vmp.com (Orlan Cannon) writes: > In article <2998.2688cec8@mccall.com>, tp@mccall.com writes: >> If you want to use a different standard, it looks like you have 3 options: >> >> 3) Reject the concept of integrating into the internet address scheme. >> Form an alternate network of uucp sites, with gateways into whatever >> networks you want to talk with (e.g. the internet) that perform the >> gatewaying function the way you want. ... > > Or just designate certain machines to be "UUCP-Domain Gateway" > machines. Then everyone in the UUCP Domain could have an address > such as "joe%bob.uucp@uunet.uu.net". > > Then just make sure that uunet (or whatever registered gateway) > would take the Internet addresses and turn them into valid addresses > for whatever neighbor it was passing them to. And receive addresses > in any format and turn them into valid Internet addresses. All it > would take is informing the gateway what kind of mail software and > what kind of addressing you are using. I was referring to what it would take to create a network with no exceptions or problems. You can't co-opt the existing uucp network, because you don't have any way of shutting down non-conforming gateways, which will continue to interject problems into your network. Your scheme, where the gateway routes in the format preferred by the neighbor, simply pushes the problem down a level. The site that received the message and wanted to pass it on would likewise have to ensure that he translated the address as apropriate for the next site to receive it, etc., until it reached its destination. All the translations would have to be unambiguous and reversible, since the recipient may want to reply. Since we are talking about the existing network, what you are seeking here is a degree of cooperation and concientiousness never before seen on a net-wide basis. Great, how do we bring it about? You can't get everyone to run the same software. Even now not all uucp sites run smail. Some sites run smail, some run sendmail, and some run both. In the minority, but definately out there, are mmdf, pmdf, and probably many others I don't know about. What are the chances that these will all work together to the degree that you describe (zip, they are all out there and we still have problems). > It seems to me that this is the de facto situation and that the > problems are occurring at the exceptions rather than the rule (i.e. > sites that don't talk to their neighbors about the format of the > stuff they intend to pass through them). Actually, they aren't exceptions, just different sets of rules. In the absence of an accepted standard that actually handles the problems, you can argue about the best way to do it, but nobody can win the argument. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
root@yclept.chi.il.us (Root) (07/04/90)
In article <ao5ccf.76f@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
[These comments have been heavily abbreviated.]
+In fact, I'm surprised that there are "many" hosts
+still left that don't handle MXs. Independent of UUCP gateways, there
+are lots of hosts that really are on the Internet but have MX records for
+themselves pointing to other hosts (because they don't run sendmail
+daemons or whatever). These machines wouldn't be able to get mail from
+MX-ignorant hosts either.
+
+---
+Tom Fitzgerald Wang Labs fitz@wang.com
+1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
I have seen in recently distributed operating systems, versions of sendmail,
should as 5.14, that do not appear to handle MX records. I have replaced
sendmail on several machines with version 5.64 to obtain MX record capacity.
Randolph J. Herber,
@ home: {att|mcdchg|laidbak|clout|obdient|wheaton}!yclept!rjh,
rjh@yclept.chi.il.ustp@mccall.com (07/05/90)
This is directed at both Les and Tom Neff, even though I'm not quite certain that either was suggesting the idea I'm responding to! :-) In article <1990Jul2.204816.1895@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > I had in mind something like: > site2.site1.bang.Berkeley.edu > meaning: consult the rules for delivering to subdomains under the > subdomain "bang" to obtain the routing for the message. > This notation would make it clear that no one except a gateway for > Berkely.edu has any business interpreting it as well as being a > legal address everywhere that domain addresses are wanted. > If the path contains characters that would be illegal as subdomain > names something like this might work: > 6973657421316973657432.hex.Berkeley.edu Well, either could certainly be done. Note however that you can't generalize this into a netwide mechanism, because (except in the .US domain) the admin of any domain has full control over his subdomain namespace. There are probably subdomains out there already named bang and hex in some domain or other. Of course, you could campaign to make this a common practice. Personally, I think if you are going to host an "alien" machine under your subdomain, you should just give it a name, rather than trying to embed routing info in the address. That's one of the strengths of domains, the address is independent of the underlying routing. The address need not change if the routing does. My address is tp@mccall.com. You can send me mail. If you don't try to look it up, I'll bet you don't know how that mail reaches me. THAT is the whole point! Thus, while I was half joking, I would prefer to see pcbbs.NotPartOf.Berkeley.edu rather than pcbbs.othersite.bang.Berkeley.edu, where othersite!pcbbs!user is a bangpath from Berkeley.edu. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA