Makey@Logicon.COM (Jeff Makey) (06/27/90)
In article <2057@ramona.Cary.NC.US> andrew@ramona.Cary.NC.US (Andrew Ernest) writes: >The maps also control the uniqueness of the unqualified names which >are prepended to the Path field in news articles. If this were true, the world would be a much happier place. Case in point: "snoopy" in the UUCP Map is the same machine as "Logicon.COM", while "snoopy" in a USENET Path: header is the same machine as "snoopy.Colorado.EDU". I'll let you guess what happens when someone mails a reply to a Path: header and then someone along the way reroutes to simply "snoopy!user". :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
les@chinet.chi.il.us (Leslie Mikesell) (06/28/90)
In article <689@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: >If this were true, the world would be a much happier place. Case in >point: "snoopy" in the UUCP Map is the same machine as "Logicon.COM", >while "snoopy" in a USENET Path: header is the same machine as >"snoopy.Colorado.EDU". I'll let you guess what happens when someone >mails a reply to a Path: header and then someone along the way >reroutes to simply "snoopy!user". Re-routing is a different issue from domain naming. Virtually all of the uucp mailers that handle domain names do a complete expansion of the path on the first machine that recognizes the domain or its uucp gateway. Intermediate machines beyond that point don't know that you didn't specify the expanded uucp path yourself and are just as likely to re-route. Les Mikesell les@chinet.chi.il.us
tneff@bfmny0.BFM.COM (Tom Neff) (06/28/90)
Everyone with a UUCP site has already had to solve the problem of finding a feed site or sites. Finding an MX forwarder is an analogous issue. If one of your UUCP feed sites is on the Internet, it would be logical to ask them to be your MX forwarder. If none of your UUCP feeds are on the Internet, then you can either (a) find a new direct site that is on the Internet and ask them to MX you, or (b) try your feeds' feeds themselves. Someone should turn up within a couple of hops. For myself I don't feel the UUCP Zone was a bad thing. What *was* bad was the way various news and mail packages started plugging in "yoursite.UUCP" as the default return address, whether or not you had actually registered! That ruined the usefulness of the pseudo-domain, because you could never trust the designation. Done properly, with everything effectively MX'ed from UUCP gateways, it might have worked. The other fly in the ointment is the unreliability of syntaxes for hybrid Internet/UUCP addresses. There are all sorts of authoritative RFCs lying around on the subject, but out in the field it's chaos. I have been round and round the post with the forms site!user@MAJORSITE.NET user%site@MAJORSITE.NET user%site.UUCP@MAJORSITE.NET MAJORSITE.NET!site!user with and without quote marks scattered around in likely places. (The only one I have gotten reliably to work is No. 2.) Of course some purists like to say "if it doesn't conform, ignore it" but in practice some of us DO want to get through. -- "DO NOT, repeat, DO NOT blow the hatch!" /)\ Tom Neff "Roger....hatch blown!" \(/ tneff@bfmny0.BFM.COM
karl_kleinpaste@cis.ohio-state.edu (06/28/90)
chip@tct.uucp writes:
...I must object to the
implication that it is therefore acceptable to *sabotage* the UUCP
zone before it dies a natural death.
...
Speaking for users in the UUCP zone: We would appreciate the
cooperation of gateway administrators in keeping our mail working as
it has been. Please do not mangle UUCP zone addresses. We'll get
registered eventually! There's no need to coerce us into changing by
mangling our return addresses.
I respectfully disagree. Domain-coping mailers have existed for
UUCP-only sites since at least 1985, when smail 2.1 came out. Smail
2.5 hasn't been patched or otherwise updated officially (e.g., via
Horton, Auton, et al) since 1987. Five years is darn well plenty of
time to have expected people to have gotten registered. One of the
first tasks which a new site should undertake when connecting is to
get such a domain name. And it's an easy, reasonably quick and
progressively better documented procedure. A lot of sites have staff
(e.g., me) who will happily do a bunch of the legwork for such a site
gratis, just for the sake of the improvement to the domain space by
annihilating yet another UUCP-centric name; and UUNET and others will
do it for a smallish fee.
It's an existence proof, and nothing more: You (the editorial "you,"
meaning all ".uucp" site admins) haven't yet registered, and you've
had a bloody long time in which to do so; therefore I have no reason
to expect that you ever will unless forced. I have been tempted on
several occasions to stop acknowledging the pseudodomain .uucp much as
I have been tempted to stop acknowledging .bitnet.
Note that I don't "sabotage" stuff.uucp in the sense you seem to mean.
I do rewrite such things from "somebody@stuff.uucp" to "stuff!somebody."
As far as I can see, the two are semantically equivalent. I simply
refuse to hand "somebody@stuff.uucp" to an SMTP-reached site. There
are a surprisingly large number of them that (correctly) refuse to
acknowledge ".uucp." I send them "stuff!somebody@cis.ohio-state.edu."
postmaster with an attitude,
--karl
--
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.)syd@DSI.COM (Syd Weinstein) (06/28/90)
karl_kleinpaste@cis.ohio-state.edu writes: >I respectfully disagree. Domain-coping mailers have existed for >UUCP-only sites since at least 1985, when smail 2.1 came out. Smail >2.5 hasn't been patched or otherwise updated officially (e.g., via >Horton, Auton, et al) since 1987. Five years is darn well plenty of >time to have expected people to have gotten registered. One of the >first tasks which a new site should undertake when connecting is to >get such a domain name. And it's an easy, reasonably quick and >progressively better documented procedure. As a site on the ``Internet'' and an ex uucp site, I must take a slight protest to this one Karl. While a uucp site, I did run a 'domain smart mailer', initially smail 2 and then smail 3. (in fact we still run smail 3.1 as our sendmail replacement) However, domain name registration requires more than just running smail and filing an ap, it requires a forwarder (MX style) that is on the ``Internet''. Otherwise, how will all the internet people send mail to them. And thats the rub, finding an MX server. If you have the desire to pay for it, there is always uunet, or other pay for MX services, but a large number of uucp sites listed in the maps are not willing to pay (let alone able, many are small systems in private use). As as often been discussed and will never be settled, who will be the MX forwarder (forwarders) of last resort. We already have that in a sense via the uucp mapping project. Now I agree, that all nodes should list themselves in the maps as soon as possible to avoid name space conflicts and provide routing info. However, that is different from a domain name. I agree that the .uucp zone is an abomination, and that the proper syntax is site!user@fqdn where fqdn will do the routing if site is not a local uucp neighbor, but I think making everyone get fqdn's is also an abomination. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
karl_kleinpaste@cis.ohio-state.edu (06/29/90)
syd@DSI.COM writes: However, domain name registration requires more than just running smail and filing an ap, it requires a forwarder (MX style) that is on the ``Internet''. Otherwise, how will all the internet people send mail to them. And thats the rub, finding an MX server. ... As as often been discussed and will never be settled, who will be the MX forwarder (forwarders) of last resort. I have made this offer in the past, and I make it again now: +------------------------------------------------------------------------+ | I, personifying the nameservers and mailers of Ohio State Computer | | Science, am willing to be nameserver and MX for ___ANYBODY___ who is | | willing to make the UUCP calls to osu-cis to pick up his/her own mail. | +------------------------------------------------------------------------+ My only restriction is that I am severely limited in the amount of long distance calling I can do, and so we support it only to our vendors. Hence, you have to be willing & able to make the calls yourself. But then, in keeping with my other philosophical viewpoints about "them that wants the data pays the phone bill," this is Right. It is in my interest to get sites DNS-registered. That's why I'm willing to make this kind of offer/effort. Getting sites registered reduces the likelihood that I will be hassled about how to reach obscure places. In the long run (admittedly, the run can seem mighty long), it saves me time to do this. I am NS and MX for 3 domains in West Germany, ferpetesake; they make TB calls to osu-cis to get/send their mail. I am nameserver secondary for organizations in Australia. There are 60 lines of my named.boot describing things which have nothing to do with OSU. The nameserver running on tut.cis.ohio-state.edu has used almost 96 CPU minutes since being booted only 9 hours ago -- and Tut is a Pyr 98x, no slouch of a machine. I first made this offer a long time ago when an argument was going down about the silly political battles that raged around Europe and the difficulty of getting into the European UUCP maps. That's where the 3 West German domains came from. I also routinely help people get domain registrations accomplished without being either NS or MX for them. I send them the canned form from the NIC, with a little commnentary on how to fill it out, they send it back, I add a bit of text about who the nameservers are, contact a friend or two to set up a nameserver and/or secondary, and away they go. IT'S NOT THAT TOUGH AND I AM TIRED OF PEOPLE BITCHING ABOUT IT BEING TOUGH. THERE ARE THOSE OF US OUT HERE WHO WILL HELP. *ASK*! I would appreciate it if others who are willing to assist in these matters would stand up and be counted. Be part of the solution, not part of the problem. (In a perverse way, I feel I'm going to regret this posting.) --karl -- 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.)
wisner@hayes.fai.alaska.edu (Bill Wisner) (06/29/90)
karl_kleinpaste@cis.ohio-state.edu writes: >I would appreciate it if others who are willing to assist in these >matters would stand up and be counted. Be part of the solution, not >part of the problem. OK, then. I, like Karl, am willing to help people get domains registered with the NIC and line up nameservers for them. I can't offer MX forwarding, since I don't bother running UUCP (and who'd want to call Alaska?) but I have been known in the past to put people in contact with local internet sites who would act as MX forwarders. Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 "Put a cork in it, Wisner." -- Karl Kleinpaste <karl@cis.ohio-state.edu>
pjg@acsu.Buffalo.EDU (Paul Graham) (06/29/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: |For myself I don't feel the UUCP Zone was a bad thing. What *was* bad |was the way various news and mail packages started plugging in |"yoursite.UUCP" as the default return address, whether or not you had |actually registered! That ruined the usefulness of the pseudo-domain, |because you could never trust the designation. Done properly, with |everything effectively MX'ed from UUCP gateways, it might have worked. it shouldn't have since being registered and using the ".uucp" are mutually exclusive. being registered means having a real name. ".uucp" *might* mean someone is in the uucp maps. then again it might not.
dalew@twiki.PDX.COM (Dale A. Weber) (06/29/90)
karl_kleinpaste@cis.ohio-state.edu writes: > Horton, Auton, et al) since 1987. Five years is darn well plenty of > time to have expected people to have gotten registered. This is probably true, but unless one has an appropriate Internet Forwarder, one can't register a domain. > One of the first tasks which a new site should undertake when connecting > is to get such a domain name. And it's an easy, reasonably quick and > progressively better documented procedure. I certainly agree that any new site's SA should definitely _try_ to get a properly registered domain. Until recently, I wasn't able to do so because I could not find a local Internet Site that would provide the necessary forwarding. I found the folks down at orstcs very pleasant to work with and they told me they'd provide that service for my site. Unfortunately this is a long distance call for me with orstcs being in Corvalis, OR and I being in Portland. Finally, I went to uunet and have recently gotten my domain registered and am sharing it with several local sites, mostly personal systems. But, the connection to uunet still costs me. I don't mind the cost though because I gain more benefits from being connected to uunet than just having am Internet Forwarder. I'm sure that there are others that don't have access to any Internet sites local to them, or perhaps none that are willing to provide that service (as I found in my case). > A lot of sites have staff (e.g., me) who will happily do a bunch of the > legwork for such a site gratis, just for the sake of the improvement to > the domain space by annihilating yet another UUCP-centric name; and > UUNET and others will do it for a smallish fee. For those that are already subscribed to uunet, there is no charge to have them register your domain name for you and it's all taken care of via E-Mail quickly. But, the point is that until I decided to go to uunet I could not find a local or really low cost path to an Internet Site willing to provide that service (and I truely appreciate the kind folks at orstcs and am hoping to eventually be able to connect with them regularly). Some of us don't have large sites with budgets that can support calling L/D to our forwarders. My site accesses uunet through CompuServe's dial network at 2400 Bps and the cost is something I can live with. I could _not_ live with the long distance charges though and would not be able to afford to share the domain I registered if it were not for the existance of uunet and the very helpfull and responsive folks there. > It's an existence proof, and nothing more: You (the editorial "you," > meaning all ".uucp" site admins) haven't yet registered, and you've > had a bloody long time in which to do so; therefore I have no reason > to expect that you ever will unless forced. Please see above. Just because all of the existing .UUCP sites have had a long time to register, does not mean they are able to do so. I've run a UUCP capable site for just over a year now full time, and until just a couple months ago, I would not have been able to register a domain name. I knew of the existance of uunet, but until recently when I started asking questions, I had thought it cost a _lot_ of money to connect with uunet. It doesn't, and I hope that more SAs would consider talking to the folks at uunet if they don't have any local Internet sites, or such sites aren't willing to provide forwarding services. The cost isn't bad if you have a local CompuServe network dial-in number and don't mind 2400 Bps. It only costs me $35.00/month to maintain twiki's account with uunet and $5.00/hour for connect time which includes both CompuServe network time _and_ connect time to uunet itself - very reasonable and probably within reach of many more folks than might think so. > I have been tempted on several occasions to stop acknowledging the > pseudodomain .uucp much as I have been tempted to stop acknowledging > .bitnet. This would be wrong, for reasons I state above. > Note that I don't "sabotage" stuff.uucp in the sense you seem to mean. > I do rewrite such things from "somebody@stuff.uucp" to "stuff!somebody." > As far as I can see, the two are semantically equivalent. Only if your site talks to site 'stuff' though. If it doesn't then you need to leave the address alone unless you can find a proper path to get the mail to that site. The two are not equivalent at all. I've seen addresses like 'stuff!somebody@site.domain' bounce several times also. I don't worry about this so much since my site started talking to uunet though, because I know I can send mail to uunet addressed as 'site!user' and uunet will deal with it properly and get the mail to it's destination. I don't mean this as a flame. I just wanted to present some additional information that you and others may not have concidered. --- INTERNET: dalew@pdx.com OR dalew@twiki.pdx.com (Dale A. Weber) UUCP: ..!uunet!twiki!dalew OR ..!{sun!nosun, tektronix}!tessi!twiki!dalew BBS: +1(503)239-4960, 24 Hours, 1200/2400 Bps MNP 1-5, PCPable via ORPOR
tp@mccall.com (06/29/90)
In article <KARL.90Jun28154651@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: > I have made this offer in the past, and I make it again now: > > +------------------------------------------------------------------------+ > | I, personifying the nameservers and mailers of Ohio State Computer | > | Science, am willing to be nameserver and MX for ___ANYBODY___ who is | > | willing to make the UUCP calls to osu-cis to pick up his/her own mail. | > +------------------------------------------------------------------------+ Very laudable, and appreciated by many, I'm sure. What do you say to those who can get free uucp connections, but would have to pay to reach a generous internet site such as yourself? Many internet sites will refuse to provide MX forwarding, and some are incapable. (I'm not well versed on the issues involved with MX support, being a uucp site, so maybe they were capable but wanted to refuse politely.) Many people are only able to run uucp and get news precisely because it is free, in the sense that there is a local site willing to feed them, so there are no phone bills. I am one of those. Luckily, my feed site is able and willing to be an MX forwarder, but many aren't so lucky. Since most internet sites that are willing to be forwarders insist on a direct connection, many sites are left out in the cold. There either is a willing internet site local to you or there isn't. If there isn't, and you can't spend the LD, you're stuck. Interestingly, when I had my modem in New York City (via a leased line and stat mux we have connecting us there), I was unable to find any site that would be an MX forwarder for me. In fact I was unable to find any site that would provide me even a limited news feed! The only sites willing to be mail links to me were not on the internet. You see, in NYC "local" calls cost money. So even having a site in a large city doesn't guarantee that you can find an MX forwarder at other than long distance rates. When I moved my modem to Manhattan, Kansas, I was able to get a mail and news link and MX forwarder from Kansas State University, which other than a few PC's has the ONLY uucp sites in town. Size of the town is irrelevant, what matters is whether there is at least one "friendly" internet site around. > My only restriction is that I am severely limited in the amount of > long distance calling I can do, and so we support it only to our > vendors. Hence, you have to be willing & able to make the calls > yourself. But then, in keeping with my other philosophical viewpoints > about "them that wants the data pays the phone bill," this is Right. Not if they can get free access elsewhere. Note that in some cases it isn't the actual cost, but how to convince management to put it on the budget. > I also routinely help people get domain registrations accomplished > without being either NS or MX for them. I send them the canned form > from the NIC, with a little commnentary on how to fill it out, they > send it back, I add a bit of text about who the nameservers are, > contact a friend or two to set up a nameserver and/or secondary, and > away they go. Now this is an offer many would appreciate! It took me 3 months (and of course $35) to get registered through uunet. Even being on usenet, I had no idea that it could be done free. I thought the NIC had designated uunet as handling all requests from uucp sites. If I read your message right, I was ripped off, in that I could have sent my form to the NIC instead of uunet and saved my money (and 3 month lead time, probably). > IT'S NOT THAT TOUGH AND I AM TIRED OF PEOPLE BITCHING ABOUT IT BEING > TOUGH. THERE ARE THOSE OF US OUT HERE WHO WILL HELP. *ASK*! It's not tough if you can do it. For some people it is impossible. Don't get me wrong, I'm sure that there are many, many others who will be very glad to hear of your offer. But for some people, it is not a workable solution, so they will continue running with unregistered hosts. Precisely why do all internet sites that act as MX forwarders insist on direct connections? After all, the indirect route that would be used is probably the route currently being used by the unregistered site. People don't mind routing for unregistered sites, but are unwilling to do it for registered sites. -- 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
mark@DRD.Com (Mark Lawrence) (06/29/90)
} karl_kleinpaste@cis.ohio-state.edu writes: } } >I would appreciate it if others who are willing to assist in these } >matters would stand up and be counted. Be part of the solution, not } >part of the problem. } wisner@hayes.fai.alaska.edu (Bill Wisner) wrote: } OK, then. I, like Karl, am willing to help people get domains } registered with the NIC and line up nameservers for them. I can't } offer MX forwarding, since I don't bother running UUCP (and who'd want } to call Alaska?) but I have been known in the past to put people in } contact with local internet sites who would act as MX forwarders. Another option is to do what the folks in Minnesota have done: organize a park (e.g. TulsaRelay.Org or Relay.Tulsa.OK.US or some such), get it registered and connected up to your local friendly neighborhood Internet host and invite all commers to register their sites under that domain. I'm not sure of the mechanics of the actual routing at the hub (is smail x.y or deliver capable of it?) but it seems like a do-able thing for sites who *don't* enjoy direct connection the the internet. The apparent recalcitrance of .UUCP sites to register may have more to do with ignorance than foot-dragging. I know I was the first site to approach the administrator of the local Internet host and we learned how to do it together with some helpful boosts (thanks, Karl). -- mark@DRD.Com uunet!apctrc!drd!mark$B!J%^!<%/!!!&%m!<%l%s%9!K(B "...do justice, love mercy, and walk humbly..." Micah 6:8
tp@mccall.com (06/30/90)
In article <KARL.90Jun29151044@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: > Actually, I am perfectly happy to be MX for a domain which is not a > direct UUCP connection to me. Sorry for the imprecision in the > previous article -- what I meant to say is, "I can't call you, but if > you can get your mail yourself _via_some_means_, I'll MX for you." > That is, I'll be MX for Foo-Bletch.ORG via pathalias support through > hop1!hop2!hop3!hop4!foo-bletch!%s if you wish. It works fine. One of > my MX connections does this, though it's only one intermediate hop. I think if more people were willing to do this, it'd go a long way towards getting more people registered. > I tend to think that just about any site can get an approximately-free > connection via such a means. If not, I have to wonder at the > viability of the site. I agree. > No, you weren't ripped off. The catch is that, while I am willing to > do these things, I don't _have_ to, and if I don't get around to doing > something for you next week, well, tough, sort of. I don't tend to > dally over such requests, but considering my current mail/news > condition (see my .signature), if I got a new request for such help > today, it would sit a couple of weeks before I even looked at it. > > UUNET, on the other hand, is in the business position of providing the > service. If you ask, they will do it. They will do all the legwork > for you, much as I would, but they have to recover the cost of doing > so differently than my employer (a state-supported university) would. > $35 is probably too low a cost, if you consider the amount of time and > effort required to do this sort of work. You got a good deal, even if > it still took a couple of months, as long as I include a guestimate > that a non-zero (non-trivial?) fraction of that time was you trying to > figure out what you had to do in order for UUNET to finish the job. What I meant was that I could do it rather than getting you or uunet or anyone else to do it. Perhaps it is more difficult than I thought. Apologies to uunet if my previous comment was unwarranted. The time delay was because I missed one thing I had to do (get my MX forwarder to send them mail), and they simply waited over a month until I wrote to them asking what the hold-up was. Granted it was my fault, but since I was paying money, I would have liked to see them follow up on it. Most businesses would under similar circumstances. They sent me a form, I sent it back, and I sent them a check. I waited the 30 days they say to allow, without hearing anything. Only in response to my query did they tell me what they were waiting on, and then it took 30 days. Yes it was my fault, but no it was not good service. > Sooner or later, a lot of us who really and truly believe in the > viability of domains are going to get sick of dealing with all those > unregistered hosts, and we're going to stop attempting to deal with > !-paths and .bitnet, and it's going to be quite a shock to all the > unregistered admins. I couldn't say that I blame you, but you will cause a chicken and egg problem, where you can't get onto the net (in any useful manner) without getting registered, and you can only find out about that by getting on the net. Seriously, I wonder how many sites out there aren't registered because they think that they can not due to lack of an available forwarder? >>[why do MX forwarders insist on direct connections] > They don't, and they don't have to. I don't, so I'm an existence > proof of the fact. I imagine, however, that an argument could be made > that life will be less traumatic if such connections are direct -- I > know that I _prefer_ direct connections, but I just don't _require_ > them. Most do, or at least used to. Even your previous message implied that you did. I suspect it is a common misconception. The old smail2.5 kit came with a list of possible forwarders. There were very few of them and the all insisted on direct connections except rutgers, who STRONGLY preferred them. That kit still floats around. That particular file is the only one I know of on the subject of finding a forwarder. (uunet told me that no such list currently exists.) So there is some misinformation floating around that makes it seem VERY hard to register. That information is obsolete, but has not been superceded. The file was produced by Stargate, who used to provide more documentation (and charge higher fees) than uunet. There is not one good, informative, source of information on this topic anywhere. (uunet's packet does mention that they will be your forwarder, if you subscribe to their service. I have nothing against their service, but I know I can't cost-justify it to my management...). Someone could write the docs, but how would you get them to the people that need to see them? -- 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
steve@thelake.mn.org (Steve Yelvington) (06/30/90)
[In article <1990Jun29.142342.29248@DRD.Com>,
mark@DRD.Com (Mark Lawrence) writes ... ]
> Another option is to do what the folks in Minnesota have done: organize a
> park (e.g. TulsaRelay.Org or Relay.Tulsa.OK.US or some such), get it
> registered and connected up to your local friendly neighborhood Internet
> host and invite all commers to register their sites under that domain.
>
> I'm not sure of the mechanics of the actual routing at the hub (is smail
> x.y or deliver capable of it?) but it seems like a do-able thing for
> sites who *don't* enjoy direct connection the the internet.
The mailhub is bungia.mn.org. I believe it's running Smail 2.5.
There's no magic to Smail; it's not a very big or complicated program
to set up (in contrast to @#$% sendmail!). I've been under the wing
of the .mn.org domain for about a year and having the domain address
works just dandy.
> The apparent recalcitrance of .UUCP sites to register may have more to do
> with ignorance than foot-dragging.
Absolutely. Figuring out this stuff can be a real nightmare. I've
been working on documentation for an Atari ST port of Smail and
uucico (dcp) and the most difficult part I've encountered is
providing bulletproof, general advice on getting registered. I had it
easy. If I lived in Tennessee or Arizona or somesuch place I probably
still wouldn't have an FQDN.
A couple of days ago I received a mail query from the operator of a
BBS on the Citadel network asking how to obtain a second-level domain
address (perhaps .citadel.org, like .fidonet.org). I considered what
(little) I knew: You fill out a bunch of paperwork and submit it to
the Network Information Center, wherevertheheck that is....
My advice was to forget that idea and register in the
.<city>.<state>.US domain instead, or just hide behind an existing domain
and concoct a monster-name like sysop@darkrealm.citadel.moundst.mn.org.
--
Steve Yelvington at the lake in Minnesota
steve@thelake.mn.orgkarl_kleinpaste@cis.ohio-state.edu (06/30/90)
tp@mccall.com writes: What do you say to those who can get free uucp connections, but would have to pay to reach a generous internet site such as yourself? Actually, I am perfectly happy to be MX for a domain which is not a direct UUCP connection to me. Sorry for the imprecision in the previous article -- what I meant to say is, "I can't call you, but if you can get your mail yourself _via_some_means_, I'll MX for you." That is, I'll be MX for Foo-Bletch.ORG via pathalias support through hop1!hop2!hop3!hop4!foo-bletch!%s if you wish. It works fine. One of my MX connections does this, though it's only one intermediate hop. I tend to think that just about any site can get an approximately-free connection via such a means. If not, I have to wonder at the viability of the site. Many internet sites will refuse to provide MX forwarding, and some are incapable. Yes, many will refuse. MX forwarding imposes load, and many places aren't willing to spend cycles in such a way. I do it because I've got 4 Pyramids with cycles to spare while still being able to get useful work done on the machines. I have to admit that I would find it hard to believe that any are truly incapable. The software is available, the configurations are not that difficult. The primary problem in being an MX host for a UUCP-connected domain is that there are several pieces to the puzzle, and getting them all just _so_ is a small bit of pain. I wrote a "cookbook" article on how to do it about a year ago; I'll see if I can dig it back out and re-post it. > I also routinely help people get domain registrations accomplished > without being either NS or MX for them... Now this is an offer many would appreciate! It took me 3 months (and of course $35) to get registered through uunet. Even being on usenet, I had no idea that it could be done free. I thought the NIC had designated uunet as handling all requests from uucp sites. If I read your message right, I was ripped off, in that I could have sent my form to the NIC instead of uunet and saved my money (and 3 month lead time, probably). The NIC has not designated UUNET in any special place in this regard. I registered wciu.edu myself a few weeks ago (I'm primary NS, hydra.convex.com is secondary NS [thanx, Lee], elroy.jpl.nasa.gov is MX), and the NIC was happy enough to let it go through for me. No, you weren't ripped off. The catch is that, while I am willing to do these things, I don't _have_ to, and if I don't get around to doing something for you next week, well, tough, sort of. I don't tend to dally over such requests, but considering my current mail/news condition (see my .signature), if I got a new request for such help today, it would sit a couple of weeks before I even looked at it. UUNET, on the other hand, is in the business position of providing the service. If you ask, they will do it. They will do all the legwork for you, much as I would, but they have to recover the cost of doing so differently than my employer (a state-supported university) would. $35 is probably too low a cost, if you consider the amount of time and effort required to do this sort of work. You got a good deal, even if it still took a couple of months, as long as I include a guestimate that a non-zero (non-trivial?) fraction of that time was you trying to figure out what you had to do in order for UUNET to finish the job. But for some people, it is not a workable solution, so they will continue running with unregistered hosts. Sooner or later, a lot of us who really and truly believe in the viability of domains are going to get sick of dealing with all those unregistered hosts, and we're going to stop attempting to deal with !-paths and .bitnet, and it's going to be quite a shock to all the unregistered admins. Consider the MILNET's position WRT nameservers -- some days, it seems to me that half the MILNET is still running off HOSTS.TXT. I hear about it due to CompuServe.COM, easily the most bizarre mailer connection I've ever built, though not really difficult in and of itself. But I _routinely_ hear from Bozo@Stuff.MIL asking why they get "host unknown" when writing to CompuServe. Precisely why do all internet sites that act as MX forwarders insist on direct connections? (-: "You proceed from a false assumption." --Spock, ST2:TWoK :-) They don't, and they don't have to. I don't, so I'm an existence proof of the fact. I imagine, however, that an argument could be made that life will be less traumatic if such connections are direct -- I know that I _prefer_ direct connections, but I just don't _require_ them. --karl -- 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.) (In other words, personal.general still has 200 messages; hang on.)
amanda@mermaid.intercon.com (Amanda Walker) (06/30/90)
In article <3008.268b1e9a@mccall.com>, tp@mccall.com writes: > Many people are only able to run uucp and get news precisely because it is > free, in the sense that there is a local site willing to feed them, so > there are no phone bills. Not necessarily. 'intercon.com', for example, is a local call away from uunet, but we've switched to only polling them hourly between 6AM & 8PM in order to reduce the phone bill. Our modem is on a business line, which gets charged in "message units"... That being said, it's still a lot cheaper than our occasional UUCP to osu-cis :-). -- Amanda Walker InterCon Systems Corporation --
scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (06/30/90)
In article <1990Jun29.142342.29248@DRD.Com> mark@DRD.Com (Mark Lawrence) writes: >Another option is to do what the folks in Minnesota have done: organize a >park (e.g. TulsaRelay.Org or Relay.Tulsa.OK.US or some such), get it >registered and connected up to your local friendly neighborhood Internet >host and invite all comers to register their sites under that domain. That's more or less what I've been doing with my domain, SF-Bay.ORG. I've got 3 sites that want to have domain addresses without having to deal with the NIC or UUNET or whomever. I'm completely open to anyone in the San Francisco Bay area, though since my local calling area is just a portion of Silicon Valley anyone further would have to poll me. In article <KARL.90Jun29151044@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >The primary problem in being an MX host for a UUCP-connected domain is >that there are several pieces to the puzzle, and getting them all just >_so_ is a small bit of pain. I wrote a "cookbook" article on how to >do it about a year ago; I'll see if I can dig it back out and re-post it. Please do. Configuring smail to do the forwarding within my domain was really simple. Trying to figure out how to make one of the hosts at work act as a backup MX host is quite a mystery to me. -- Scott Hazen Mueller | scott@zorch.SF-Bay.ORG or (ames|pyramid|vsi1)!zorch!scott 10122 Amador Oak Ct.|(408) 253-6767 |Mail fusion-request@zorch.SF-Bay.ORG Cupertino, CA 95014|Love make, not more|for emailed sci.physics.fusion digests SF-Bay Public-Access Unix 408-996-7358/61/78/86 login newuser password public
karl_kleinpaste@cis.ohio-state.edu (06/30/90)
tp@mccall.com writes: I think if more people were willing to do this, it'd go a long way towards getting more people registered. So let's start a propaganda campaign to get more of 'em to do it! What I meant was that I could do it rather than getting you or uunet or anyone else to do it. Perhaps it is more difficult than I thought. Oh. Sorry, I misinterpreted your statement. Yes, you could have done it yourself, as long as your mail to hostmaster@nic.ddn.mil arrived in a replyable form. (Now _there's_ a chicken-and-egg problem. :-) There's just the one form to fill out, it's a bit obscure at points (the correct response to the hostname conversion question is invariably "N/A" :-), but that's all. You need to have identified your NSes before you send it in, but you can arrange for the exact place for MX to occur afterwards if you wish. And in fairness to those of us trying to deal with new domains, prettyplease don't let any mail escape your site with your new domain name advertised in From: lines until the root servers are advertising it, usually ~10 days after you send in your form. > [I am tempted to nuke support for !-paths and .bitnet.] I couldn't say that I blame you, but you will cause a chicken and egg problem, where you can't get onto the net (in any useful manner) without getting registered, and you can only find out about that by getting on the net. Well said. That's probably the one reason that would truly induce me to keep such support (at least !-path support, but not necessarily .bitnet support) forever. On the other hand, there's this different outlook that you can't get any connection at all until/unless you call some person on the phone with whom to set up the connection...and that person could easily insist on helping you get a domain set up first. Probability of the latter occurring: Zero and dropping. I'll keep !-path support, though grudgingly. Seriously, I wonder how many sites out there aren't registered because they think that they can not due to lack of an available forwarder? Interesting point. I don't know, but if there's one, it's too many. So there is some misinformation floating around that makes it seem VERY hard to register... There is not one good, informative, source of information on this topic... Someone could write the docs, but how would you get them to the people that need to see them? Consider me motivated. (And Ambar may be disappointed in me just a little. :-) I'll spend a couple of hours in the next week or two creating some suitable docs which I can then post periodically to comp.mail.whatever as a sort of FAQ-style article. I have to finish digging out from under my curent pile, but I'll get it done. --karl -- 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.) (In other words, personal.general still has 130 messages; hang on.)
kannan@osc.edu (Kannan Varadhan) (06/30/90)
Following in the footsteps of Bill Wisner et al, Thus spake karl_kleinpaste@cis.ohio-state.edu >+------------------------------------------------------------------------+ >| I, personifying the nameservers and mailers of Ohio State Computer | >| Science, am willing to be nameserver and MX for ___ANYBODY___ who is | >| willing to make the UUCP calls to osu-cis to pick up his/her own mail. | >+------------------------------------------------------------------------+ I run primary name service for *.osc.edu domain, and secondaries for sites on OARnet. I **don't do UUCP** (I bounce it off to Karl across the river here :). I am willing to share the nameserver loads. I might also be able to help a little with the domain registration forms. >I would appreciate it if others who are willing to assist in these >matters would stand up and be counted. Be part of the solution, not >part of the problem. Kannan, [hp]ostmaster@osc.edu -- Kannan Varadhan, Internet Engineer, OARNet Ohio Supercomputer Center, Columbus, OH 43212 +1 (614) 292-4137 email: kannan@oar.net | osu-cis!malgudi.oar.net!kannan
cathyf@rice.edu (Catherine A. Foulston) (06/30/90)
In article <iRJiL5w162w@twiki.PDX.COM> dalew@twiki.PDX.COM (Dale A. Weber) writes: >karl_kleinpaste@cis.ohio-state.edu writes: >> Note that I don't "sabotage" stuff.uucp in the sense you seem to mean. >> I do rewrite such things from "somebody@stuff.uucp" to "stuff!somebody." >> As far as I can see, the two are semantically equivalent. > > Only if your site talks to site 'stuff' though. If it doesn't then you >need to leave the address alone unless you can find a proper path to get >the mail to that site. The two are not equivalent at all. I've seen >addresses like 'stuff!somebody@site.domain' bounce several times also. I It appears to me that if someone, somewhere, treats 'stuff.uucp' differently from 'stuff,' then they are different, and rewriting 'stuff.uucp' could cause a problem if the mail ever in the future goes through the place that treats them differently. If everybody in the world treats the two in the same way, then they are (by definition?) semantically equivalent. So, is there ever reason to treat them differently? The only reason I see is that, say, stuff.school.edu is known locally as stuff, but there is also a uucp site stuff somewhere nearby. Then one might treat 'stuff' as meaning stuff.school.edu while 'stuff.uucp' would mean the uucp site stuff. If some site does this, then, by the above discussion, stuff.uucp must always be known as stuff.uucp, and nobody can ever rewrite it to just stuff (just as one would never rewrite stuff.com or stuff.org as just 'stuff'), or mail will run into trouble if it passes through school.edu. The chances of the .uucp sticking through the entire travels of the mail seem small. Stuff may not be able to get a real domain name. So what do you do if you're stuff? What if you're school.edu? I can think of a few solutions, but I don't like any of them. Cathy -- Cathy Foulston + cathyf@rice.edu + Rice University, Network & Systems Support
trier@cwlim.CWRU.EDU (Stephen C. Trier) (07/01/90)
In this discussion about encouraging the growth of domain names for UUCP sites, I haven't seen any discussion of the .US domain. The .US domain is administered by Ann Westine at ISI, and registration is free. The registration form is simple, and the name server support is included. There's only one big catch, and that's that the UUCP site _must_ be only one hop off the Internet. For example, my machine "seldon" is eligible, since its feed is from an Internet site, but some machine connected to seldon by UUCP would not be eligible unless registered under my domain with seldon serving as a gateway. I'm hoping to register under .US soon, when seldon will have the domain name seldon.clv.oh.us. (This is, of course, subject to change.) -- Stephen Trier (Mail: sct@po.cwru.edu) Also known as trier@shasta.scl.cwru.edu and sct%seldon@scl.cwru.edu, but don't use these addresses: Both are down for a week! :-(
pat@orac.pgh.pa.us (Pat Barron) (07/02/90)
In article <1990Jun30.182851.20356@usenet.ins.cwru.edu> sct%seldon@scl.cwru.edu writes: >In this discussion about encouraging the growth of domain names for >UUCP sites, I haven't seen any discussion of the .US domain. The .US >domain is administered by Ann Westine at ISI, and registration is free. >The registration form is simple, and the name server support is included. >There's only one big catch, and that's that the UUCP site _must_ be >only one hop off the Internet. Not necessarily true. The thing is that your forwarder must know how to get mail directly to you (i.e., you can't have an MX that points to another MX record). One of my MX forwarders (VAX.CS.PITT.EDU) is two UUCP hops away, but it knows how to route mail to me through the intermediate UUCP hop. This is perfectly OK. --Pat. -- Pat Barron Internet: pat@orac.pgh.pa.us - or - orac!pat@cert.sei.cmu.edu UUCP: ...!uunet!apexepa!orac!pat - or - ...!pitt!darth!orac!pat
mdb@ESD.3Com.COM (Mark D. Baushke) (07/02/90)
On 29 Jun 90 19:10:43 GMT, karl_kleinpaste@cis.ohio-state.edu said:
karl> Actually, I am perfectly happy to be MX for a domain which is not a
karl> direct UUCP connection to me. Sorry for the imprecision in the
karl> previous article -- what I meant to say is, "I can't call you, but if
karl> you can get your mail yourself _via_some_means_, I'll MX for you."
karl> That is, I'll be MX for Foo-Bletch.ORG via pathalias support through
karl> hop1!hop2!hop3!hop4!foo-bletch!%s if you wish. It works fine. One of
karl> my MX connections does this, though it's only one intermediate hop.
Hmmm...is it fair to assume that you do not allow non-direct sites to
have *.Foo-Bletch.ORG names to be routed thusly
hop1!hop2!hop3!hop4!foo-bletch!mumble.Foo-Bletch.ORG!%s
because you favor rabbid domain-absolutist routing (I think this was
the term)?
This avoids the problem of the host hop2 implementing Karl's favorite
routing policy and figuring out that the 'best' route to
mumble.Foo-Bletch.ORG is via osu-cis causing a loop.
[Please no more discussion on rabbid domain-absolutist routing. It was
beat to death enough in recent memory. Only corrections to the name of
the technique allowed. :-)]
A similar rational holds for our Internet site. We prefer direct UUCP
connections if we are to act as an MX for a site.
If I am 'directly connected' I can use 'smartuucp' and pass
user@mumble.Foo-Bletch.ORG without fear. This is good, simple and
promotes using the domain syntax everywhere including UUCP transport.
If I am not directly attached, I either have to worry about the
routing policies of any intermediate third parties or flatten the
domain name to a single UUCP hostname. I probably also need to
originate a UUCP syntax path to that site from my machine.
Flattening is ugly since one of the powerful features of the DNS is to
allow each organization to add their own sub-domains if they so desire
without bothering me to create a ...!foo-bletch!mumble path for each
possible subdomain entry of Foo-Bletch.ORG.
This would be less of a problem with a bunch of single host sites that
desired to share a domain, such as is done in lonestar.org. (It is
equivalent to creating a new domain for a site, but with no new
paperwork to send to the NIC after the first one has been done.)
BTW: Our site is willing to act as a DNS secondary for any domain needing one.
--
Mark D. Baushke
Internet: mdb@ESD.3Com.COM
UUCP: {3comvax,auspex,sun}!bridge2!mdbkls@ditka.UUCP (Karl Swartz) (07/02/90)
In article <3008.268b1e9a@mccall.com> tp@mccall.com writes: >In article <KARL.90Jun28154651@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: >> | I, personifying the nameservers and mailers of Ohio State Computer | >> | Science, am willing to be nameserver and MX for ___ANYBODY___ who is | >> | willing to make the UUCP calls to osu-cis to pick up his/her own mail. | >Very laudable, and appreciated by many, I'm sure. What do you say to those >who can get free uucp connections, but would have to pay to reach a >generous internet site such as yourself? Not to mention a decrease in service. Right now the majority of my Internet mail hops onto uucp at apple.com, goes to zygot, and then to ditka. Each call is "on demand" so it generally only takes a few minutes for mail to get from the Internet to ditka. But every time I've looked for a suitable MX I've run up against a blank wall. I live in the foothills in the East Valley region of San Jose, in the San Jose 3 calling area. The only Internet sites I've found for which this is a local call are apple.com and several random HP sites. Mail to the appropriate people disappears into a black hole. So that leaves me with a choice of polling a site outside my local calling area, going through an intermediate uucp site, or finding some wealthy Internet site which doesn't mind paying for calls to me every once in a while. Polling is unappealing mainly because of the great reduction in service it would imply. Yes, I know more people would be able to reach me, so I would be trading service rather than giving it away, but the people who want to reach me find a way anyway. Going through intermediate sites seems to be taboo, though like Terry I don't quite see the logic when Internet sites are quite happy to use the same intermediate sites for .UUCP traffic. And wealthy Internet sites don't seem to advertise their services very widely. (I'd welcome hearing from any volunteers.) >So even having a site in a large city doesn't guarantee that >you can find an MX forwarder at other than long distance rates. Yup. You'd think one could find something here in Silicon Valley, and maybe I will, but it sure isn't obvious. >> IT'S NOT THAT TOUGH AND I AM TIRED OF PEOPLE BITCHING ABOUT IT BEING >> TOUGH. THERE ARE THOSE OF US OUT HERE WHO WILL HELP. *ASK*! No, it's not, and in fact since I work at an Internet site I can probably take care of the nameserver and everything else rather easily. But we don't have uucp there so I still need to find a place for the MX to point to that won't dramatically reduce my level of servce or cost me an arm and a leg over what I pay now. -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
tp@mccall.com (07/02/90)
In article <KARL.90Jun29210152@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: > tp@mccall.com writes: > So there is some misinformation floating around that makes it seem VERY > hard to register... > There is not one good, informative, source of information on this topic... > Someone could write the docs, but how would you get them to the people that > need to see them? > > Consider me motivated. (And Ambar may be disappointed in me just a > little. :-) I'll spend a couple of hours in the next week or two > creating some suitable docs which I can then post periodically to > comp.mail.whatever as a sort of FAQ-style article. I have to finish > digging out from under my curent pile, but I'll get it done. Great! You might look into having it posted in news.announce.newusers to get maximum coverage. In a perfect world, when someone calls up a site admin and gets his first uucp feed, your docs should be the first thing he sees come over the wire. THAT would go a long way towards getting everyone registered. -- 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 (07/02/90)
In article <1990Jun30.182851.20356@usenet.ins.cwru.edu>, trier@cwlim.CWRU.EDU (Stephen C. Trier) writes: > In this discussion about encouraging the growth of domain names for > UUCP sites, I haven't seen any discussion of the .US domain. The .US > domain is administered by Ann Westine at ISI, and registration is free. > The registration form is simple, and the name server support is included. > There's only one big catch, and that's that the UUCP site _must_ be > only one hop off the Internet. Well, that is a big catch (which I wasn't even aware of), and is undoubtledly the big drawback to the .US domain, but I can think of others: 1) You are restricted to the geographical format of address, site.city.state.US. This is fine if your enterprise exists in only one city, and you NEVER intend to move. 2) You are NOT allowed to create subdomains! This is a ridiculous restriction. There is no reason for it other than the fact that the domain admin wants it that way, because creating a subdomain would have NO impact to the domain admin. All things being equal, I would have gone with mccall.us rather than mccall.com, because (a) it pleases my sense of esthetics, since the rest of the world forms addresses this way, and (b) I heard a rumor a long time ago that this is the format of address being favored by OSI networks, and I thought it might help in some distant future transition. I even had one prospective MX forwarder agree to MX for me on the condition that I NOT register in the .US domain. I consider it unfortunate that what should be the top level domain for this country was given to someone who has chosen to run it in a manner inconsistent with all other top level domains. -- 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 <KARL.90Jun28154651@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >+------------------------------------------------------------------------+ >| I, personifying the nameservers and mailers of Ohio State Computer | >| Science, am willing to be nameserver and MX for ___ANYBODY___ who is | >| willing to make the UUCP calls to osu-cis to pick up his/her own mail. | >+------------------------------------------------------------------------+ >My only restriction is that I am severely limited in the amount of >long distance calling I can do, and so we support it only to our >vendors. Hence, you have to be willing & able to make the calls >yourself. But then, in keeping with my other philosophical viewpoints >about "them that wants the data pays the phone bill," this is Right. If this is accessable through the same machine/port servers that the annon uucp archives at osu-cis use, potential callers should be aware that the port server often answers the call but is unable to establish a connection to the host (This is not a flame - I love those archives but it might be a problem for people making regular calls). >It is in my interest to get sites DNS-registered. That's why I'm >willing to make this kind of offer/effort. Getting sites registered >reduces the likelihood that I will be hassled about how to reach >obscure places. In the long run (admittedly, the run can seem mighty >long), it saves me time to do this. Why not make it simpler for everyone concerned by setting up a single domain name just for the purpose of inheriting uucp orphans as subdomain members and encourage them to do the same. If everyone is running routing software it is simple enough to make a uucp neighbor into a subdomain. Once someone sets up the 2nd level domain name, there would not need to be any more paperwork involved. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (07/03/90)
In article <KARL.90Jun28114641@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >I respectfully disagree. Domain-coping mailers have existed for >UUCP-only sites since at least 1985, when smail 2.1 came out. Smail >2.5 hasn't been patched or otherwise updated officially (e.g., via >Horton, Auton, et al) since 1987. Five years is darn well plenty of >time to have expected people to have gotten registered. Perhaps *you* have been doing mail administration for five years, but I suspect most unix sites are a lot newer than that, and their administrators are correspondingly less experienced. >It's an existence proof, and nothing more: You (the editorial "you," >meaning all ".uucp" site admins) haven't yet registered, and you've >had a bloody long time in which to do so; therefore I have no reason >to expect that you ever will unless forced. I have been tempted on >several occasions to stop acknowledging the pseudodomain .uucp much as >I have been tempted to stop acknowledging .bitnet. But in fact, you handle it admirably. Here's the results of some messages sent from Compuserve via the internet gateway: The domain fb.com is actually handled by machine afbf05 which happens to have a map entry curtesy of uunet. Machine afbf01 doesn't have its own map entry but is shown as a node in the map entry for chinet. sent to: >INTERNET: les@fb.com From uunet!compuserve.com!70010.266 From: Les Mikesell <uunet!CompuServe.COM!70010.266> To: <les@fb.com> The Received: lines show the path through saqqara -> uunet -> afbf05 sent to: >INTERNET: les@afbf05.uucp From uunet!compuserve.com!70010.266 From: Les Mikesell <uunet!compuserve.com!70010.266> To: <afbf05!les> There are 2 Received: lines for saqqara, then rutgers ->uunet -> afbf05 sent to: >INTERNET: les@afbf01.uucp From gargoyle!compuserve.com!70010.266 From: Les Mikesell <chinet!gargoyle!compuserve.com!70010.266> To: <oddjob!gargoyle!chinet!afbf01!les> There are 2 Received: lines for saqqara, then rutgers ->oddjob.uchicago.edu ->gargoyle->chinet->afbf01 These headers are all replyable due to routing software in the places that need it, although I would prefer to have the To: and From: kept in @ notation. Note that rutgers has no problem finding afbf01.uucp (nor does uunet) even though it does not have its own map entry. >Note that I don't "sabotage" stuff.uucp in the sense you seem to mean. >I do rewrite such things from "somebody@stuff.uucp" to "stuff!somebody." >As far as I can see, the two are semantically equivalent. I simply >refuse to hand "somebody@stuff.uucp" to an SMTP-reached site. There >are a surprisingly large number of them that (correctly) refuse to >acknowledge ".uucp." I send them "stuff!somebody@cis.ohio-state.edu." Hmmm, pretty much kills any chance of replying. Fortunately you don't do the same to the To: address. Note above that other sites do not treat ! and @ addresses alike, semantically equivalent or not. Les Mikesell les@chinet.chi.il.us
" Maynard) (07/03/90)
In article <1990Jun29.235451.16343@zorch.SF-Bay.ORG> scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) writes: >Configuring smail to do the forwarding within my domain was really simple. It was, huh? How do you do it? I, so far, have been unable to get smail 2.5 to deal with 'user@foo.conmicro.com' as 'foo!user'. I'd like to, as there are a few of my UUCP-connected neighbors who'd like to take advantage of my domain name, but about the only answer I've gotten so far was to hack the pathalias output to add the transform manually - not a good thing to do. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. "It's a hardware bug!" "It's a +---------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
trier@cwlim.CWRU.EDU (Stephen C. Trier) (07/03/90)
In article <3019.268f6566@mccall.com> tp@mccall.com writes: >2) You are NOT allowed to create subdomains! This is a ridiculous >restriction. There is no reason for it other than the fact that the domain >admin wants it that way, because creating a subdomain would have NO impact >to the domain admin. I'm not certain that this is true. In the documentation I received, it gave a specific example of a regional computer club allocating a domain for the use of its members running UUCP. Perhaps I misunderstand what you mean by "sub-domain". The other restrictions are, indeed, fairly major for some sites. However, for many sites registration in .US would be worthwhile, especially when compared to registration in the UUCP Zone. If you can find an Internet site for a UUCP feed, registration is a snap and the price is right. (No trying to find a name server and no charge.) The advantage of .US is simplicity; the disadvantage is simplicity. For small, single-machine sites like mine, the choice makes sense. Larger sites should probably use .COM or .ORG. -- Stephen Trier Case Western Reserve University Home: sct%seldon@scl.cwru.edu Information Network Services Work: trier@cwlim.ins.cwru.edu I do not speak for Case Western Reserve.
tp@mccall.com (07/03/90)
In article <1990Jul2.233815.11438@usenet.ins.cwru.edu>, trier@cwlim.CWRU.EDU (Stephen C. Trier) writes: > In article <3019.268f6566@mccall.com> tp@mccall.com writes: >>2) You are NOT allowed to create subdomains! This is a ridiculous >>restriction. There is no reason for it other than the fact that the domain >>admin wants it that way, because creating a subdomain would have NO impact >>to the domain admin. > > I'm not certain that this is true. In the documentation I received, it > gave a specific example of a regional computer club allocating a domain > for the use of its members running UUCP. Perhaps I misunderstand what > you mean by "sub-domain". I'm sorry, I was imprecise. You are not allowed to create subdomains locally, they must all be registered with the .US domain administrator. An example of what I mean. I have a DECnet network (yes, I run VMS) consisting of 2 local area clusters. For unix types, this is similar to having 2 NFS servers, each with a group of satellite machines. Each of my clusters has a DECnet node alias, and a real node name. For instance, MIS1 is a workstation in one of my clusters. It can be reached with the node name MIS1 or MIS (which will refer to a random node in the cluster, but all cluster nodes share the mail repository, so this works fine). I have it set up so that tp@mis1.mccall.com is legal, and gets delivered on node MIS1. mis2.mcccall.com is the other machine in the cluster, and mis.mccall.com will go to one or the other machines. A similar scheme is used for the other cluster (which is the only way they can get mail from the outside, since mccall.com gets delivered on the MIS cluster). In otherwords, I've completely mapped my DECnet network onto my local set of subdomains. I didn't have to ask or tell anybody to do this. If I had registered in the .US domain, I'd have had to register all of these (it would add up to 12 domains). Every time I got a new workstation, I'd have to register it. My MX forwarder would have MX records for all of these, thus propagating this hassle to even more people. In the .com domain, I've registered mccall.com and also declared my node (known as mccall in the uucp maps) as the gateway to the .mccall.com domain, so that mail to tp@mis1.mccall.com gets sent to host...!mccall!mis1.mccall.com!tp, and delivered properly. One of the great benefits of domains is that you don't have to advertise your entire network to the entire world, you just advertise your domain gateways and then handle routing to subdomains internally. -- 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
rsalz@bbn.com (Rich Salz) (07/03/90)
In <KARL.90Jun29151044@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >Actually, I am perfectly happy to be MX for a domain which is not a >direct UUCP connection to me. This is kind of risky, no? Easy to get mail loops. I think conventional wisdom is that the MX'er should be one-hop off the IP-connected Internet. At any rate, none of the intermediate sites had better be on the Internet or the odds of getting a loop will approximate 1.000, and rightly so. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
m5@lynx.uucp (Mike McNally) (07/03/90)
As a relative novice to the strange world of electronic mail
management, I'm not quite sure of what the "politically correct"
sentiment is towards the maintenance of the pathalias-style maps. Is
it a wish of the Illuminati that the map system will vanish when
everybody has a registered MX? Correct me with violent sarcastic
flames if I'm wrong, but it seems to me that there's something to be
said for the flexibility in routing afforded by the current technology
of local dialed uucp connections. If, on the other hand, the map
system is thought to be a Good Thing, then what difference does it make
that one has to poll a not-quite-local or even a long-distance site
(like uunet maybe) for an MX, since much (most?) traffic will still be
through local uucp neighbors? I know that's true for me; of course,
the overwhelming majority of traffic here is either news or junk sent
between here and customer sites over direct uucp link. Am I being
hopelessly dense or what?
I guess I might feel different if I were operating a private machine out
of my apartment, but even for a relatively small firm like Lynx the
$100 or so a month for uunet service seems manageable.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,daver}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.pmm@mips.COM (Paul M. Moriarty) (07/04/90)
Several people have posted complaining about how difficult it is to find
an MX forwarder and a few people at Internet sites have mentioned that
they would be willing to provide NS and/or MX services for interested
sites.
I propose that it would be much easier for UUCP sites to find the
appropriate Internet sites if a list was compiled and maintained of
Internet sites willing to provide this service.
I hereby volunteer to compile, maintain (at least initially), and
periodically post the information.
Cooperative Internet sites:
Please provide the following information:
Site Name:
Site Address:
Contact Person:
MX service?:
NS service?:
Comments:
--
Paul M. Moriarty pmm@mips.com {ames,decwrl}!mips!pmm
Sr Systems Administrator
MIPS Computer Systems, Inc +1 408 524 8335karl_kleinpaste@cis.ohio-state.edu (07/04/90)
mdb@ESD.3Com.COM writes:
karl> Actually, I am perfectly happy to be MX for a domain which is not a
karl> direct UUCP connection to me.
Hmmm...is it fair to assume that you do not allow non-direct sites to
have *.Foo-Bletch.ORG names to be routed thusly
hop1!hop2!hop3!hop4!foo-bletch!mumble.Foo-Bletch.ORG!%s
because you favor rabbid domain-absolutist routing (I think this was
the term)?
(The name I've attached to it is Domain Absolutist Rabid Rerouting,
DARR, a mere word rearrangement from what you said. It's the highly
restricted rightmost-FQDN syntax-based version of General Rabid
Rerouting, GRR, which reroutes everything regardless of syntax or
destination.)
I would have to check that any multi-hop path doesn't have that
property. I don't consider it a bug, from my standpoint -- it's only
a question of whether a piece of mail will re-enter the Internet. As
Eliot wrote to me the other day:
EL: My suggestion, though, is that you state the possibility for mail
EL: loops, and that you won't be responsible for them if you do not have
EL: a direct connection with the [destination] site.
I will take enough responsibility to check with intermediate
postmasters if I can, but nothing further. I still _prefer_ direct
connections; I just don't _require_ them.
--karl
--
"Reading news with GNUS gives the phrase `garbage collecting'
a whole new meaning." --jgreely@cis.ohio-state.edutneff@bfmny0.BFM.COM (Tom Neff) (07/04/90)
Why not retain .UUCP but express bang paths as subdomains? To: ciavax!castro!liddy!hunt!libra becomes To: libra@hunt.liddy.castro.ciavax.UUCP Then teach gateways to perform the above transformation, each way.
jamesd@techbook.com (James Deibele) (07/05/90)
In article <3008.268b1e9a@mccall.com> tp@mccall.com writes: [...] >Since most internet sites that are willing to be forwarders insist on a >direct connection, many sites are left out in the cold. There either is a >willing internet site local to you or there isn't. If there isn't, and you >can't spend the LD, you're stuck. Ah, c'mon. You call once a night long-distance to pick up your mail and drop off anything that you want to go out. If there's nothing there, you get nicked for a one-minute phone call. Assuming that the worst case is $.20 a minute for that call, and there are 30 days in a month, you're looking at $6 a month. Figure that there will be mail coming or going the other times, and you're probably up to $10 a month. That's the worst case, assuming that you can't find anyone else in your neck of the woods to group together in a park and that absolutely none of your local Internet folk are friendly. That sounds pretty reasonable to me. -- jamesd@techbook.COM ...!{tektronix!nosun,uunet}!techbook!jamesd Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257 Technical books mailing list --- mail "techbook!tbj-request" "Sitting on the console all day, watching the news scroll away ..."
tp@mccall.com (07/06/90)
In article <1990Jul5.005618.17046@techbook.com>, jamesd@techbook.com (James Deibele) writes: > In article <3008.268b1e9a@mccall.com> tp@mccall.com writes: >>Since most internet sites that are willing to be forwarders insist on a >>direct connection, many sites are left out in the cold. There either is a >>willing internet site local to you or there isn't. If there isn't, and you >>can't spend the LD, you're stuck. > > Ah, c'mon. You call once a night long-distance to pick up your mail and drop > off anything that you want to go out. If there's nothing there, you get > nicked for a one-minute phone call. Assuming that the worst case is $.20 a > minute for that call, and there are 30 days in a month, you're looking at > $6 a month. Figure that there will be mail coming or going the other times, > and you're probably up to $10 a month. That's the worst case, assuming that > you can't find anyone else in your neck of the woods to group together in a > park and that absolutely none of your local Internet folk are friendly. First, remember we are talking about calling LD and registering, vs. a free local call and not registering (I know local call's aren't always free, but they are usually cheaper than LD). 1) If you work at a company, and want to spend money, you have to justify it. This is often a much bigger roadblock than the dollar figure itself. 2) I had a once a night LD link from Kansas to California. It was so unreliable (i.e. I could only get through sometimes, so some mail got bounced for sitting around too long) that I got thrown off of mailing lists. And it still always cost me $20-$30 per month, bare minimum (maybe higher costs for business lines? I dunno. I paid around a dollar for the first minute.) 3) I tried to call several times per night to avoid this problem. The cost of the 1 minute phone calls adds up fast if you do 3 or 4 per night. I ran into my $100 limit per month, and had to go back to the above alternative. I also started real hard looking for a local uucp link. As I said, I'm lucky, as there is a site in town that can/will MX for me. 4) Getting together a park still assumes that someone in the park can get mail forwarded via MX. You're just shifting the problem to someone else (which may or may not help at all). 5) You may not even have any local internet folk. And even if you do, it is not at all unlikely that they will be unfriendly. It happened to me. I had a modem in New York City, and had actually set up forwarding with rutgers in New Jersey before one guy in the city changed his mind (he didn't even answer my mail for 3 weeks, later said he read it but was too busy to answer, and if I hadn't found anyone else, he'd do it, but it would be a while before he could get around to it. REAL friendly). -- 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
Anselmo-Ed@cs.yale.edu (Ed Anselmo) (07/06/90)
>>>>> On 3 Jul 90 13:35:24 GMT, rsalz@bbn.com (Rich Salz) said:
Karl> Actually, I am perfectly happy to be MX for a domain which is
Karl> not a direct UUCP connection to me.
Rich> This is kind of risky, no? Easy to get mail loops.
Rich> I think conventional wisdom is that the MX'er should be one-hop
Rich> off the IP-connected Internet.
Rich> At any rate, none of the intermediate sites had better be on the
Rich> Internet or the odds of getting a loop will approximate 1.000,
Rich> and rightly so.
If you flatten the UUCP envelope from foo.dom.ain to foo (or whatever
their UUCP name is), then unless an intermediate site tries to be cute
about things (i.e. expanding UUCP names into domains), there shouldn't
be much trouble (famous last words...). Of course, the odds of this
happening increase with the number of intermediate hops. Things
always seem to be easier if the site is directly connected to the
Internet host.
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edkarl_kleinpaste@cis.ohio-state.edu (07/06/90)
Anselmo-Ed@cs.yale.edu writes:
Rich> This is kind of risky, no? Easy to get mail loops.
Rich> I think conventional wisdom is that the MX'er should be one-hop
Rich> off the IP-connected Internet.
If you flatten the UUCP envelope from foo.dom.ain to foo...
...there shouldn't be much trouble
As I've said, I prefer direct connections; but I'll put up with a
multi-hop connection if necessary. The only multi-hop case which I
currently support has a single intermediate hop.
--karl
--
Chill out -- it's just the Usenet.Makey@Logicon.COM (Jeff Makey) (07/07/90)
In article <ANSELMO-ED.90Jul6120157@bigbird.cs.yale.edu> Anselmo-Ed@cs.yale.edu (Ed Anselmo) writes: >If you flatten the UUCP envelope from foo.dom.ain to foo (or whatever >their UUCP name is), then unless an intermediate site tries to be cute >about things (i.e. expanding UUCP names into domains), there shouldn't >be much trouble (famous last words...). I don't consider it "cute," but my site (which gateways only a couple of dozen messages per day between Internet and UUCP) has been carefully tailored to do *both* of these things. During address canonicalization a selected set of .UUCP names are rewritten as their corresponding fully qualified domain names. Only when delivery is actually to be made via UUCP is the FQDN replaced with the corresponding .UUCP name. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
david@twg.com (David S. Herron) (07/09/90)
In article <KARL.90Jun28114641@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >Note that I don't "sabotage" stuff.uucp in the sense you seem to mean. >I do rewrite such things from "somebody@stuff.uucp" to "stuff!somebody." >As far as I can see, the two are semantically equivalent. I simply >refuse to hand "somebody@stuff.uucp" to an SMTP-reached site. There >are a surprisingly large number of them that (correctly) refuse to >acknowledge ".uucp." I send them "stuff!somebody@cis.ohio-state.edu." er.. It would be better if that were somebody%stuff@cis.ohio-state.edu (or %stuff.uucp) if only to avoid the operator-precedence problem. Otherwise I agree with you -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (07/09/90)
In article <3070.2694591f@mccall.com> tp@mccall.com writes: >In article <1990Jul5.005618.17046@techbook.com>, jamesd@techbook.com (James Deibele) writes: >5) You may not even have any local internet folk. And even if you do, it is >not at all unlikely that they will be unfriendly. It happened to me. I had ^^^^^^^^^^ Hmmm >a modem in New York City, and had actually set up forwarding with rutgers >in New Jersey before one guy in the city changed his mind (he didn't even >answer my mail for 3 weeks, later said he read it but was too busy to >answer, and if I hadn't found anyone else, he'd do it, but it would be a >while before he could get around to it. REAL friendly). ^^^^^^^^^^^^^ Hmmmm #2. The last sentance shows a VERY disturbing attitude on the part of small UUCP sites. i.e. UUCP connections are a RIGHT not a PRIVLEDGE. Most small sites take on the attitude that bigger site admins should drop all their responsibilitys to their organization and cater to the whim of the smaller site; GET REAL. How many of these small sites realize the amount of TIME and MONEY it takes to support a small .UUCP site from the other side? How many realize how bad they screw things up with poorly constructed mail addresses with .UUCP or multiple combinations of !%@ that take ALOT of time constructing rulesets for? Then they have the balls to bitch at their feed site when the bad addresses they send through get bounced. Why any internet site would take on the pain in the ass of supporting a .UUCP site is beyond me, the grief involved isn't worth it. I know from experience. The small sites complain about how expensive domain registration is, that cost is no where near the TIME cost of supporting a .uucp site on the feed side. I'd feed a domain site that generated valid internet addresses in a second, I'd tell someone who insisted on a .uucp domain to keep on walking. I'm not being unfriendly, I'm saving myself and my organization time and money. If the small sites can't be burdened to construct valid and easily parsed addresses then their feeds shouldn't be burdened with having to decipher the garbage To: and Reply-To: lines. The US post office, and most others in the world, REQUIRE a certain format of a letter's address. I see no reason why requiring e-mail addresses to be standard is any more unreasonable than requiring paper mail addresses to be standard. -Rob All views expressed here are MY OWN and in no way, shape or form represent the views of the U of M or any of its subunits. If you want to scream at somebody about the contents, scream at me.
tp@mccall.com (07/09/90)
In article <3662@umn-d-ub.D.UMN.EDU>, rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) writes: > In article <3070.2694591f@mccall.com> tp@mccall.com writes: >>In article <1990Jul5.005618.17046@techbook.com>, jamesd@techbook.com (James Deibele) writes: >>5) You may not even have any local internet folk. And even if you do, it is >>not at all unlikely that they will be unfriendly. It happened to me. I had > ^^^^^^^^^^ Hmmm >>a modem in New York City, and had actually set up forwarding with rutgers >>in New Jersey before one guy in the city changed his mind (he didn't even >>answer my mail for 3 weeks, later said he read it but was too busy to >>answer, and if I hadn't found anyone else, he'd do it, but it would be a >>while before he could get around to it. REAL friendly). > ^^^^^^^^^^^^^ Hmmmm #2. > > The last sentance shows a VERY disturbing attitude on the part of > small UUCP sites. i.e. UUCP connections are a RIGHT not > a PRIVLEDGE. Most small sites take on the attitude that bigger > site admins should drop all their responsibilitys to their > organization and cater to the whim of the smaller site; GET REAL. Personally I figure anyone that takes 3 weeks to answer mail is being a tad unfriendly, unless it is an honest mistake. This guy read my mail but chose to ignore it. That is not what I call friendly. I'd rather get a message saying I can't do it now, contact me in a month if you still haven't found anyone (I did get one of those BTW). I was responding to someone who seemed to doubt that it was likely that an internet site would balk at doing MX forwarding for a uucp site. If you read the messages leading up to this, in this discussion friendly implies willingness to help a uucp site get registered/connected. Maybe thats the wrong word. I certainly don't think anyone is obligated to help me out. I did want to point out that many sites are unwilling to be helpful in this regard (is helpful a better term? Read my message again substituting helpful/unhelpful for friendly/unfriendly, and I think it will be closer to my intended meaning). > How many of these small sites realize the amount of TIME and > MONEY it takes to support a small .UUCP site from the other > side? I've done it. I've run a uucp site with numerous small neighbors, most unregistered. It isn't that big a pain. (Running newsfeeds to them when their sites frequently go down IS a pain, but that is another issue.) Maybe it's worse for a sendmail site, I don't know. I don't deny your right to refuse to do it. It would be nice if you didn't take 3 weeks to say no (or maybe, or whatever). > How many realize how bad they screw things up with > poorly constructed mail addresses with .UUCP or multiple > combinations of !%@ that take ALOT of time constructing > rulesets for? Note that I was talking about finding an MX site so that I could STOP being a .uucp site! It sounds like if you go to as much trouble as you imply, you probably provide very good service, in which case I find your attitude puzzling. If you didn't do a lot of work on custom rule sets, but just took the easy way out, it wouldn't be that much work. Also note that (possibly unlike your site), I am talking about sites that already had uucp connections, so they have already dealt with the needed rewrite rules. I only had the uucp maps to use in finding connections, so I certainly wasn't contacting anyone who didn't already know how to deal with uucp sites, including unregistered ones. > Then they have the balls to bitch at their > feed site when the bad addresses they send through get > bounced. Unless someone at my feed site reads this group, they are totally unaware of how I feel about munging headers (I intend to talk to them about it when the are less busy). However, it is IN GENERAL (certainly not always), the internet sites running sendmail and gatewaying mail between uucp and the internet that take PERFECTLY VALID RFC822 addresses, such as mine <tp@mccall.com> and screw them up by rewriting them as bang paths, which THEN get screwed up. Re-read my message, I'm talking about difficulties in getting registered, which is needed in order to NOT generate .uucp addresses, or things with % or ! in them. > Why any internet site would take on the pain in the ass of > supporting a .UUCP site is beyond me, the grief involved > isn't worth it. I guess some people are more generous than you. Luckily, there seem to be a lot of them. I was simply pointing out the existance of people like you. Thank you for confirming my point. > I know from experience. The small sites > complain about how expensive domain registration is, that > cost is no where near the TIME cost of supporting a .uucp > site on the feed side. Then you have ill-mannered sites. Tell them so and dump them. Just don't generalize that to all of us. Again, I wanted to get registered, and couldn't find an MX site. Let me get this straight. You feel that we should get registered so we won't generate bogus addresses, but you aren't in the least bit interested in helping us do it, right? Thanks a lot! Some of us don't have the money or connections to get onto the internet (it takes both). I guess you consider us useless, eh? I note that you read netnews, which originated in the uucp world, and includes many uucp sites (including the sender of the message you are flaming in response to), so we must not be totally beneath your notice. Why are you even reading a group devoted to uucp mail? I guess you think we should all subscribe to uunet and leave you alone, eh? Some people can't afford that. Sorry. Some people seem to get spoiled by having a university or large commercial concern to pick up their tab. I hope you end up at a small site some day that nobody wants to take the time to deal with. > I'd feed a domain site that > generated valid internet addresses in a second, I'd tell someone > who insisted on a .uucp domain to keep on walking. Many of us generate valid domain addresses which are then screwed up by our feed sites. You may be blaming the wrong people. If you've been reading this discussion, you will see that very few people INSIST on a .uucp address, but many people can't find an MX forwarder, which is a prerequisite to doing anything else. I guess you are an example of the reason for this. > I'm not > being unfriendly, I'm saving myself and my organization > time and money. If the small sites can't be burdened to construct > valid and easily parsed addresses then their feeds shouldn't > be burdened with having to decipher the garbage To: and Reply-To: > lines. Refusing with good grace (for whatever reason, including yours) to be helpful is not unfriendly. Flaming people for being in a situation that they can not or do not know how to correct is certainly unfriendly, at the least. I am (thanks to the good people at Kansas State University) no longer in this situation, but I still have empathy for those who are. Having been there twice, at 2 different sites/companies, I feel qualified to some extent to speak on the subject. I'd bet you have never run a small uucp site. > The US post office, and most others in the world, REQUIRE a certain > format of a letter's address. I see no reason why requiring e-mail > addresses to be standard is any more unreasonable than requiring paper > mail addresses to be standard. The post office does not require each person using the mail to find a well-connected sponsor before he can put a return address on his envelope to which said post office will be willing to deliver mail. Your analogy is flawed. > All views expressed here are MY OWN and in no way, shape or form > represent the views of the U of M or any of its subunits. If you want to > scream at somebody about the contents, scream at me. Sure thing. However, if you are the postmaster of your site (as you imply), I submit that the above paragraph is blatantly false. -- 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
rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (07/10/90)
In article <3077.26985a23@mccall.com> tp@mccall.com writes: >In article <3662@umn-d-ub.D.UMN.EDU>, rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) writes: >> In article <3070.2694591f@mccall.com> tp@mccall.com writes: >>>in New Jersey before one guy in the city changed his mind (he didn't even >>>answer my mail for 3 weeks, later said he read it but was too busy to >>>answer, and if I hadn't found anyone else, he'd do it, but it would be a >>>while before he could get around to it. REAL friendly). >> ^^^^^^^^^^^^^ Hmmmm #2. >> >> The last sentance shows a VERY disturbing attitude on the part of >> small UUCP sites. i.e. UUCP connections are a RIGHT not >> a PRIVLEDGE. Most small sites take on the attitude that bigger >> site admins should drop all their responsibilitys to their >> organization and cater to the whim of the smaller site; GET REAL. > >Personally I figure anyone that takes 3 weeks to answer mail is being a tad >unfriendly, unless it is an honest mistake. This guy read my mail but chose >to ignore it. That is not what I call friendly. I'd rather get a message >saying I can't do it now, contact me in a month if you still haven't found >anyone (I did get one of those BTW). > Hmmm, when was the last time you had 1000+ messages in your mail box? Yup, I'm serious, 1000+. If anyone feels they are being ignored then use Ma Bell. If they hang up on you immediately THEN you are being ignored. Try administrating hundreds or thousands of clients and servers, each with a very impatient user, and you'll start to understand why 3 weeks may be a SHORT period of time to get a response. >> How many of these small sites realize the amount of TIME and >> MONEY it takes to support a small .UUCP site from the other >> side? > >I've done it. I've run a uucp site with numerous small neighbors, most >unregistered. It isn't that big a pain. (Running newsfeeds to them when >their sites frequently go down IS a pain, but that is another issue.) Maybe >it's worse for a sendmail site, I don't know. I don't deny your right to >refuse to do it. It would be nice if you didn't take 3 weeks to say no (or >maybe, or whatever). > For the last sentance, refer to the previous paragraph. As for the first part: I also have worked with small UUCP only sites with 10 or so smaller neighbors. When a site admin took the time to learn how to maintain mail and use it I had no problems. When a site admin felt it was my problem to fix HIS/HER bad addresses then there were problems. If your small sites accept the responsibility of maintaining their mail system then count yourself lucky. >> How many realize how bad they screw things up with >> poorly constructed mail addresses with .UUCP or multiple >> combinations of !%@ that take ALOT of time constructing >> rulesets for? > >Note that I was talking about finding an MX site so that I could STOP being >a .uucp site! It sounds like if you go to as much trouble as you imply, you >probably provide very good service, in which case I find your attitude >puzzling. If you didn't do a lot of work on custom rule sets, but just took >the easy way out, it wouldn't be that much work. > I learned my lesson after spending weeks bending over backwards trying to fix rulesets. It is easier to have the small systems generate proper addresses than for me to waste my time trying to fix them when they reach the larger system. Needless to say, when I moved the responsibility for proper addresses to the smaller sites they got upset. Apparently a feed site is supposed to do hours of programming for FREE so that the small sites don't have worry about how they address the mail. I've corrected people on this small point and most got rather huffy about it. Again, if you have small sites that take responsibility for themselves count yourself lucky. >> Why any internet site would take on the pain in the ass of >> supporting a .UUCP site is beyond me, the grief involved >> isn't worth it. > >I guess some people are more generous than you. Luckily, there seem to be a >lot of them. I was simply pointing out the existance of people like you. >Thank you for confirming my point. > My "problem" is that I was too generous to the wrong people and am now jaded due to the experiences. For every small site that is willing to take responsibility for what is comming out of it there are at least 2 more that think mail addresses are the feeds responsibility and not their own. >> I know from experience. The small sites >> complain about how expensive domain registration is, that >> cost is no where near the TIME cost of supporting a .uucp >> site on the feed side. >Then you have ill-mannered sites. Tell them so and dump them. Just don't >generalize that to all of us. Again, I wanted to get registered, and >couldn't find an MX site. > I picked the wrong message to go into soapbox mode. I did not mean to imply that YOUR site was ill mannered. It would appear that you have been lucky enough to have responsible site admins on the small systems you feed. >Let me get this straight. You feel that we should get registered so we >won't generate bogus addresses, but you aren't in the least bit interested >in helping us do it, right? Thanks a lot! > Hmmm, you're reaching a bit here. My problem is with sites that don't take responsibility for their bad addressing. If they want to register a domain I would help them. IF I saw the request in an overloaded mail box or IF they called me. If I didn't have the time myself I'd refer them to uunet or maybe a local site that might have someone that could spare the time. My gripe is against those who DON'T get registered even though they have the means to do so AND who complain when their trash addresses come bouncing back to them AND they won't bother to do anything on their end. >Some of us don't have the money or connections to get onto the internet (it >takes both). I guess you consider us useless, eh? I note that you read >netnews, which originated in the uucp world, and includes many uucp sites >(including the sender of the message you are flaming in response to), so we >must not be totally beneath your notice. Why are you even reading a group >devoted to uucp mail? I guess you think we should all subscribe to uunet >and leave you alone, eh? Some people can't afford that. Sorry. > Because I manage a local domain park I like to see if new software for helping me do that is available. Also, does the word "cross-posting" help clear anything up? Until recently the cost of being in the domain park that I'm in was a whopping $0.00 a year... The people who feed us need to be compensated for their time now; no biggie. The domain park was originally formed so people wouldn't have to pay uunet's rates. The top level park has 1 MX forwarder. It is the job of each small site in the park to generate valid To: and From: headers, again no biggie. If a site can't be bothered to construct valid addresses then there are other places they can get "free" UUCP feeds from... You assumed since I posted from my guest account at the U that I was some stuck up University admin. WRONGO. Most of the sites I deal with are small UUCP sites, my own personal system is a small UUCP site. I help maintain 6 small UUCP sites out of the goodness of my heart, for lack of a better term. The gripe I have comes from experience with small UUCP sites. The larger sites I've worked at were responsible for what went out their ethernets and UUCP lines. Again, your experiences with small sites has obviously been a hell of alot better than mine. #include <std/disclaimers.h> Also, the U of M Duluth is NOT the MX forwarder for the park I'm in. I'm in a subdomain of the mn.org domain. As such, UMD has no bearing on anything I've stated in this note or the previous one. >Some people seem to get spoiled by having a university or large commercial >concern to pick up their tab. I hope you end up at a small site some day >that nobody wants to take the time to deal with. > See above for the first sentance. I HAVE been on the receiving end of people saying F.O. when I've asked for feeds. I also understand why they said F.O. from other experiences I have had. Small sites don't seem to understand what's involved with scaling 10 sites up to 1000+. They don't seem to comprehend that someone's mailbox can have 1000+ messages in it, all of them screaming for IMMEDIATE attention. They seem to think that they are being snubbed or that system admins are selfish when they say that they don't have the time to rewrite the sendmail rulesets that service hundreds of workstations and multiple networks so that the site can handle some obscure feature of the small systems's mailer. You say I'm spoiled without knowing anything about my experience with UUCP systems large and small and then damn me to be stuck in the middle of nowhere with arrogant UUCP sites... >> I'd feed a domain site that >> generated valid internet addresses in a second, I'd tell someone >> who insisted on a .uucp domain to keep on walking. > >Many of us generate valid domain addresses which are then screwed up by our >feed sites. You may be blaming the wrong people. If you've been reading >this discussion, you will see that very few people INSIST on a .uucp >address, but many people can't find an MX forwarder, which is a >prerequisite to doing anything else. I guess you are an example of the >reason for this. > ????? I've spent MANY hours making sure that any site I'm responsible for doesn't mess up a valid address and trys the best it can to deliver a poorly constructed address. In my experience MOST, but not all, messed up addresses are due to the INITIAL system NOT producing an user@host.domain type address in the headers. Intermediate sites then try to construct an address without enough knowledge of the source/destination. I personally bounce the message back from whence it came rather than playing God and guessing wrong. If the initial site constructed a valid address to begin with then the intermediate sites would have had less need to muck with the address. Again, it appears that you and your feed sites are at odds so I won't go into your specific situation. Again, my beef is with sites that refuse to take responsibility for their own end of things. You obviously do and I wish there were more sites like yours. >> I'm not >> being unfriendly, I'm saving myself and my organization >> time and money. If the small sites can't be burdened to construct >> valid and easily parsed addresses then their feeds shouldn't >> be burdened with having to decipher the garbage To: and Reply-To: >> lines. > >Refusing with good grace (for whatever reason, including yours) to be >helpful is not unfriendly. Flaming people for being in a situation that >they can not or do not know how to correct is certainly unfriendly, at the >least. I am (thanks to the good people at Kansas State University) no >longer in this situation, but I still have empathy for those who are. >Having been there twice, at 2 different sites/companies, I feel qualified >to some extent to speak on the subject. I'd bet you have never run a small >uucp site. > Hmm, you flamed back without knowing that I've run many small UUCP sites and have helped run large UUCP/SMTP/MX forwarder sites. Maybe I'm guilty of not explaining myself better. >> The US post office, and most others in the world, REQUIRE a certain >> format of a letter's address. I see no reason why requiring e-mail >> addresses to be standard is any more unreasonable than requiring paper >> mail addresses to be standard. > >The post office does not require each person using the mail to find a >well-connected sponsor before he can put a return address on his envelope >to which said post office will be willing to deliver mail. Your analogy is >flawed. > But they DO require that the To and return addresses be in a standard format so the analogy is still there. Maybe the reason that more internet sites don't MX is because of small sites that cause feed admins to burn out on helping them. The less work the larger site has to do, or COMPENSATE for, the more likly they'll be "friendly". >> All views expressed here are MY OWN and in no way, shape or form >> represent the views of the U of M or any of its subunits. If you want to >> scream at somebody about the contents, scream at me. > >Sure thing. However, if you are the postmaster of your site (as you imply), >I submit that the above paragraph is blatantly false. I implied nothing about being a system admin at the posting site, only that I HAD experience with system administration. The account is a guest account and as I stated before: All views expressed here are MY OWN and in no way, shape or form represent the views of the U of M or any of its subunits. If you want to scream at somebody about the contents, scream at me. Let's move this to mail, I doubt people want us to waste net bandwidth on this subject. -Rob
tp@mccall.com (07/10/90)
Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 90 In article <3670@umn-d-ub.D.UMN.EDU>, rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) writes: > In article <3077.26985a23@mccall.com> tp@mccall.com writes: >>In article <3662@umn-d-ub.D.UMN.EDU>, rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) writes: >>> In article <3070.2694591f@mccall.com> tp@mccall.com writes: > Let's move this to mail, I doubt people want us to waste net > bandwidth on this subject. > > -Rob Rob and I apparently had some severe misunderstandings here. I'll only respond to those things that I think are of general interest, the rest I'll move to mail. I apologize for the flames, they were caused by interpretting his message as a direct response to mine, which it wasn't. > For the last sentance, refer to the previous paragraph. As for the > first part: I also have worked with small UUCP only sites with > 10 or so smaller neighbors. When a site admin took the time to > learn how to maintain mail and use it I had no problems. When a > site admin felt it was my problem to fix HIS/HER bad addresses then > there were problems. If your small sites accept the responsibility > of maintaining their mail system then count yourself lucky. I'm amazed that you have had such apparently consistant bad experience. I would caution other readers not to generalizing from Rob's experience, as mine has been quite the contrary. He posts several examples of rudeness and ill-manneredness (is that a word) from small sites. I've served over 10 and never run into any single one with such a bad attitude. If I did, I'd tell him to find another feed, plain and simple. I've found that most people to whom I've given a uucp link properly appreciated that I was doing them a favor, and behaved accordingly. > My gripe is against those who DON'T get registered even though they > have the means to do so AND who complain when their trash addresses > come bouncing back to them AND they won't bother to do anything on > their end. I do agree that anyone who can get registered and does not deserves the mail difficulties he gets. The whole gist of this discussion thread was that some people did not realize that it is not always easy to get registered, and some people don't know how. Hopefully the document Karl is working on will help with the latter. The willingness of sites like Karl's to support MX for indirect uucp links should help the former. > They seem to think that they are being > snubbed or that system admins are selfish when they say that they > don't have the time to rewrite the sendmail rulesets that > service hundreds of workstations and multiple networks so that the > site can handle some obscure feature of the small systems's mailer. Does anyone else think that this sort of thing indicates a general weakness in sendmail? Few people seem to really know how to do anything non-trivial with it. > ????? I've spent MANY hours making sure that any site > I'm responsible for doesn't mess up a valid address and trys > the best it can to deliver a poorly constructed address. In my > experience MOST, but not all, messed up addresses are due to > the INITIAL system NOT producing an user@host.domain type > address in the headers. Many sites, including uunet, will trash a user@host.domain address if they are sending to a uucp site (uunet will desist if asked). Many others (not including uunet, according to them, I don't connect to them) will trash a user@host.domain address if it comes from a uucp node. I'm connected to a machine that does both. Many people have urged me to bitch, yell, and scream at them about this. I guess you understand more than most people why I haven't. I have 36 rewrite rules to clean up the addresses they send me. I need to add 9 more to handle addresses that should have been user%site@host.domain. >>The post office does not require each person using the mail to find a >>well-connected sponsor before he can put a return address on his envelope >>to which said post office will be willing to deliver mail. Your analogy is >>flawed. >> > But they DO require that the To and return addresses be in a standard > format so the analogy is still there. Maybe the reason that more > internet sites don't MX is because of small sites that cause > feed admins to burn out on helping them. The less work the larger > site has to do, or COMPENSATE for, the more likly they'll be "friendly". Internet site admins: Is this part of the problem? It never occured to me because I've never run into this type of behavior. Karl: If this is a problem, perhaps you should include something on manners/netiquette in your document on getting registered. -- 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
honey@doom.ifs.umich.edu (Peter Honeyman) (07/10/90)
karl_kleinpaste@cis.ohio-state.edu writes: >+---------------------------------------------------------------------- ---+|> >| I, personifying the nameservers and mailers of Ohio State Computer ||> >| Science, am willing to be nameserver and MX for ___ANYBODY___ who is ||> >| willing to make the UUCP calls to osu-cis to pick up his/her own mail. ||> >+------------------------------------------------------------------------+ but what happens, karl, when you move on to that high-paying silicon valley job, leaving confusion and turmoil behind? this happens regularly in ann arbor, whereupon folks relying on the good offices of the university for their free services are left high and dry. peter
honey@doom.ifs.umich.edu (Peter Honeyman) (07/10/90)
David S. Herron writes: |> It would be better if that were somebody%stuff@cis.ohio-state.edu |> (or %stuff.uucp) if only to avoid the operator-precedence problem. there is no ambiguity when an smtp speaker utters stuff!somebody@cis.ohio-state.edu to an smtp listener. see rfc 821. peter
karl_kleinpaste@cis.ohio-state.edu (07/10/90)
honey@doom.ifs.umich.edu writes:
but what happens, karl, when you move on to that high-paying silicon
valley job, leaving confusion and turmoil behind?
You make the very poor assumption, Peter, that my mail, news, and
nameserver configurations exist in state which would cause confusion
or turmoil among the rest of the staff if I left.
--
"Reading news with GNUS gives the phrase `garbage collecting'
a whole new meaning." --jgreely@cis.ohio-state.edushwake@raysnec.UUCP (Ray Shwake) (07/10/90)
In article <7871@lynx.UUCP> m5@lynx.uucp (Mike McNally) writes: >As a relative novice to the strange world of electronic mail >management, I'm not quite sure of what the "politically correct" >sentiment is towards the maintenance of the pathalias-style maps. Is Some of us in the uucp-only world have done very well, thank you, by relying on the basic uucp file transfer mechanism enhanced by pathalias-supporting smart mailers at the FRONT end to get where we want to go. Personally, I could care less what is "politically correct". Those who remember Pirsig's classic "Zen and the Art of Motorcycle Maintenance" recall the importance of pursuing "that which is "good" rather than "that which is true". For many, pathaliasing works. As to the address formats, there are really only two that could remotely be considered "intuitive", viz: user@sitename (specified user AT specified sitename) site!...!site!user (reach user by following this path) Logical domain constructs (user@site.x.y.z) resemble the first format, but don't do so in an intuitive fashion. At the next level (i.e. becoming somewhat less intuitive) site!...!site!user@knownsite (reach user by following this path once you reach a known site) All the rest, especially including the awful % character are merely hacks. Please don't bother quoting RFCs to me. "Request for Comments" does not qualify as Standard in my book. The only real standard is X.400, which is intended to integrate DISsimilar environments. The more presumptuous out there should recognize that people and organizations differ in both vision and strategic goals, and will respond accordingly.
emv@math.lsa.umich.edu (Edward Vielmetti) (07/10/90)
In article <1990Jul10.172111.19334@iti.org> scs@vax3.iti.org (Steve Simmons) writes: >honey@doom.ifs.umich.edu writes: > but what happens, karl, when you move on to that high-paying silicon > valley job, leaving confusion and turmoil behind? While OSUs commmitment to unix support is clearly more consistant than UofMs, Peter is correct in noting a single point of failure is not a good way of doing things. A2 has been thru several cycles of feast and famine, and those cycles stopped only when we went to multiple sources of support. Steve, what you really mean is that once some sites that used to be uucp sites paid their $$$$ and got on the internet for real, things got better. I'd point to iti, Ocwin, now GM Research as being key additions. Sites which once were a cost to support at UM are now completely autonomous and able to provide services to others. Unless U of Michigan units start to try to do cost recovery for uucp services (and thus start to throw scarce unix expertise at it), I suspect the big growth in state-wide connectivity will be dedicated lines for IP traffic to former UUCP-only sites. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> (formerly uunet!umix!emv)
scs@vax3.iti.org (Steve Simmons) (07/11/90)
karl_kleinpaste@cis.ohio-state.edu writes: >honey@doom.ifs.umich.edu writes: > but what happens, karl, when you move on to that high-paying silicon > valley job, leaving confusion and turmoil behind? >You make the very poor assumption, Peter, that my mail, news, and >nameserver configurations exist in state which would cause confusion >or turmoil among the rest of the staff if I left. While OSUs commmitment to unix support is clearly more consistant than UofMs, Peter is correct in noting a single point of failure is not a good way of doing things. A2 has been thru several cycles of feast and famine, and those cycles stopped only when we went to multiple sources of support. Karls setups may be the best in the world, but one day OSU may officially decide not to do that any more, and turn the key. Anti-social? Sure. Not likely in the near future? Your guess is better than mine. Disasterous when it happens? Damn betcha.
amanda@mermaid.intercon.com (Amanda Walker) (07/12/90)
In article <KARL.90Jul10094904@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: > You make the very poor assumption, Peter, that my mail, news, and > nameserver configurations exist in state which would cause confusion > or turmoil among the rest of the staff if I left. Karl really does grok this stuff. 'intercon.com' is running a minor variation of his sendmail.cf, and it has very little in common with his machines beyond a 32-bit word size :-). If only the rest of the major sites were as rationally set up. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
amanda@mermaid.intercon.com (Amanda Walker) (07/12/90)
In article <100@raysnec.UUCP>, shwake@raysnec.UUCP (Ray Shwake) writes: > As to the address formats, there are really only two that could > remotely be considered "intuitive", viz: > > user@sitename (specified user AT specified sitename) > site!...!site!user (reach user by following this path) Fine so far. However, the second is not an address. It is a route. There are many mailers that blur the distinction, but it is there nonetheless. > Logical domain constructs (user@site.x.y.z) resemble the first > format, but don't do so in an intuitive fashion. On the internet, they are exactly equivalent. "site.x.y.z" is a unique name for a specific host, at least as far as the sending side is concerned. > At the next > level (i.e. becoming somewhat less intuitive) > > site!...!site!user@knownsite (reach user by following this > path once you reach a known site) This is broken. This is not guaranteed to work, and is guaranteed not to work for many values of "knownsite" (any site I run, for example). The ability to tunnel UUCP paths through the Internet is a bug. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
les@chinet.chi.il.us (Leslie Mikesell) (07/12/90)
In article <1990Jul10.133026.18326@terminator.cc.umich.edu> honey@citi.umich.edu writes: >David S. Herron writes: >|> It would be better if that were somebody%stuff@cis.ohio-state.edu >|> (or %stuff.uucp) if only to avoid the operator-precedence problem. >there is no ambiguity when an smtp speaker utters >stuff!somebody@cis.ohio-state.edu to an smtp listener. >see rfc 821. The recipient in this particular conversation is unambiguous, but how should the return address look when it hits the (uucp) mailbox? If "stuff" is A!B!C, what should the From_, From: and any To:/Cc: lines look like at the receiving end, and how should non-ambiguous replies be constructed, knowing that something!something@somewhere *is* ambiguous in uucp-land? Always saying user@domain is not a solution if you assume that the intermediate uucp hops run out-of-the-box AT&T rmail. Even if user@domain is valid and what the user says, the local mail has to generate a path to the domain gateway. Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (07/12/90)
In article <269B82AE.415E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > This is broken. This is not guaranteed to work, and is guaranteed not to > work for many values of "knownsite" (any site I run, for example). > The ability to tunnel UUCP paths through the Internet is a bug. Do you have any UUCP neighbors? Are they in the maps? If so, every site running "pathalias" is going to want to tunnel UUCP paths through the internet to you. UUCP-only sites don't have the ability to make use of MX records. Which, by the way, can produce stunningly poor results... for example, going by the DNS mail to ferranti.com will be sent via uunet. So I get mail sent from Rice University, not 20 miles (and 2 hops) away, sent via Virginia, which I guess is about 2000 miles away. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
Makey@Logicon.COM (Jeff Makey) (07/13/90)
In article <269B82AE.415E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >> site!...!site!user@knownsite (reach user by following this >> path once you reach a known site) > >This is broken. This is not guaranteed to work, and is guaranteed not to >work for many values of "knownsite" (any site I run, for example). If "knownsite" receives such an address via SMTP, and can reasonably be expected to gateway UUCP mail traffic to the first "site" in the bang-path, then "knownsite" has no valid excuse for failing to deal with this properly. Yes, there are plenty of UUCP-only sites that don't grok site!user@fqdn the way Internet sites are supposed to; that's why I always use pure bang-paths when sending mail via UUCP. >The ability to tunnel UUCP paths through the Internet is a bug. It's a feature. Internet sites are required to ignore the presence of bang-paths (and any other route encoding) in the local part of an address, except when the FQDN on the right-hand side of the address is that of the current host. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
karl_kleinpaste@cis.ohio-state.edu (07/13/90)
peter@ficc.ferranti.com writes:
Do you have any UUCP neighbors? Are they in the maps?
If so, every site running "pathalias" is going to want to tunnel UUCP
paths through the internet to you.
UUCP-only sites don't have the ability to make use of MX records.
T'ain't necessarily so.
Any of my UUCP neighbors is free to run, e.g., smail 2.5 as a backend
with a one-line /usr/lib/uucp/paths file:
smart-host osu-cis!%s
which is to say that everything they send goes through me. I do MX
RRs appropriately. By extension, they are using MX RRs. If they have
other connections (most of them have at least a couple, naturally),
they can add those as well so they don't bother going through osu-cis
when it's just some other entity around town.
Thus, someone at such a UUCP neighbor can address
peter@ficc.ferranti.com
which their local smail will deliver via
uux - osu-cis!rmail (ficc.ferranti.com!peter)
and It Just Works.
Which, by the way, can produce stunningly poor results... for example,
going by the DNS mail to ferranti.com will be sent via uunet. So I get
mail sent from Rice University, not 20 miles (and 2 hops) away, sent via
Virginia, which I guess is about 2000 miles away.
Any reasonable mail administration is going to deal with local
peculiarities. If what you say is true, it would seem that Rice
hasn't done so, but they would be well advised to take a look at local
improvements they could make for the sake of nearby people such as
yourself. E.g., I speak UUCP direct to Pyramid much as Rice should
speak UUCP direct to Ferranti. My local peculiarities are codified
thus...
sendmail.cf:
[[ Define a few classes: ]]
## CONFIG HERE
## The following classes are sets of entities within top-level domains
## to which we speak UUCP directly. These are not hosts within your
## domain, but whole domains external to yourself.
## Legend: C == com; O == org; E == edu; N == net.
CCacadch compuserve copi equi imp johngalt morningstar netsys pinnacle protec pyramid resource stargate
COhdl sub
CNgeo sub
[[ S0 delivery based on those classes. ]]
R$+<@$*$=C.com> $#smail$@$2$3.com$:$1 Generic commercial
R$+<@$*$=O.org> $#smail$@$2$3.org$:$1 Generic org
R$+<@$*$=N.net> $#smail$@$2$3.net$:$1 Generic network
/usr/lib/uucp/paths sample entries:
acadch.com acadch!%s
compuserve.com compuserve!%s
copi.com copibob!%s
equi.com equicom!%s
hdl.org cmhhdl!%s
imp.com acadch!imp.com!%s
johngalt.com jgalt!%s
morningstar.com mstar!%s
netsys.com netsys!%s
pinnacle.com pinnacl!%s
protec.com protec!%s
pyramid.com pyramid!%s
resource.com resource!%s
stargate.com stargate!%s
sub.net watzman!%s
sub.org watzman!%s
When I write mail to csg@pyramid.com, it delivers via UUCP -- I have
made myself into what amounts to an MX host for pyramid.com, though no
nameserver knows it.
All I really need at this point is a patch to sendmail which would
allow me to create multi-token class elements so that I can create a
single class to be dealt with for smail delivery, e.g.:
CMacadch.com compuserve.com copi.com equi.com imp.com johngalt.com morningstar.com netsys.com pinnacle.com protec.com pyramid.com resource.com stargate.com hdl.org sub.org geo.net sub.net
Then all my $#smail resolutions (there are actually more than the
example 3 I showed; I am MX for several sites in .us, and each gets
[mumble] its own $#smail rule) would reduce to a single one. Of
course, given the length of that class definition, I'd probably want
to resort to defining it in a file and reading it in via FM instead of
CM.
I understand that Sun's sendmail allows multi-token class elements,
but I wouldn't know personally, as I run almost-raw 5.61.
--karlshwake@raysnec.UUCP (Ray Shwake) (07/13/90)
In article <269B82AE.415E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >> user@sitename (specified user AT specified sitename) >> site!...!site!user (reach user by following this path) > >Fine so far. However, the second is not an address. It is a route. There >are many mailers that blur the distinction, but it is there nonetheless. Of COURSE it's a route. But it's also an address. Just like the scribble on the front of the USnail envelope you received yesterday is both address and route. >> site!...!site!user@knownsite (reach user by following this >> path once you reach a known site) > >This is broken. This is not guaranteed to work, and is guaranteed not to >work for many values of "knownsite" (any site I run, for example). >The ability to tunnel UUCP paths through the Internet is a bug. As we used to say, "Where you stand [on an issue] depends on where you sit". My own submission should properly be seen as a set of "postulates", a way of returning to first principles, if you will. The fact that your own mailers and routers couldn't handle such an environment might suggest that YOUR system is broken, n'est pas? That fact that sites ON the Internet can handle UUCP traffic is, in my book, hardly a bug. If it couldn't, it would be worthless to me.
amanda@mermaid.intercon.com (Amanda Walker) (07/13/90)
In article <_2M4591@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > going by the DNS mail to ferranti.com will be sent via uunet. So I get > mail sent from Rice University, not 20 miles (and 2 hops) away, sent via > Virginia, which I guess is about 2000 miles away. So? Rice can always have mail to *@*.ferranti.com routed to you via UUCP if this sort of efficiency is an issue. I, for example, do this with the Johns Hopkins Advanced Physics Lab. However, in exchange for "efficiency" (in this case, low latency), I have to take the responsibility of keeping my manual routing information up to date. This is only worth it for a few cases. Also, I don't have any problem with mumble!foo!zot@bar as a UUCP path. I just don't accept its legality as an internet address. How it gets to the Internet is irrelevant as long is it has a valid address once it gets there. If you want to get mail back from the internet, though, get a domain. Me, a domain bigot? You betcha, even though I run a UUCP-only site. -- Amanda Walker <amanda@intercon.com> Postmaster With An Attitude InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/13/90)
In article <269D03E5.5995@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <_2M4591@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da > Silva) writes: > > going by the DNS mail to ferranti.com will be sent via uunet. So I get > > mail sent from Rice University, not 20 miles (and 2 hops) away, sent via > > Virginia, which I guess is about 2000 miles away. > So? Rice can always have mail to *@*.ferranti.com routed to you via UUCP > if this sort of efficiency is an issue. It isn't for them. It is for me. And even if it was, the only practical way for them to do this for any significant number of sites is by using pathalias. But I forgot... you don't believe in pathalias. You think Usenet should depend entirely on the benign neglect of the Internet. > Me, a domain bigot? You betcha, even though I run a UUCP-only site. % smail -A amanda@mermaid.intercon.com uunet!mermaid.intercon.com!amanda You're in u.usa.va.1, with uunet as the only listed connection. Is UUNET a local call? There are quite a few sites that list a connection to you, so you'll still get pathalias routed from some places. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
rhealey@umn-d-ub.d.umn.edu (Rob Healey) (07/14/90)
In article <104@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >In article <269B82AE.415E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >>> user@sitename (specified user AT specified sitename) >>> site!...!site!user (reach user by following this path) >>Fine so far. However, the second is not an address. It is a route. There >>are many mailers that blur the distinction, but it is there nonetheless. > > Of COURSE it's a route. But it's also an address. Just like the > scribble on the front of the USnail envelope you received yesterday > is both address and route. > Bzzzzzzzzzzt, but thank you for playing. OK, the first address is an ADDRESS. It says WHERE to go but NOT HOW to get there. The second one is a ROUTE. It tells you WHERE to go and HOW to get there... B^). There is a MAJOR distinction here. The address you put on a USnail mail is an ADDRESS only. You don't tell the post office how it should go about doing it's business. If you send two letters IDENTICALLY addressed but mailed some time unit apart they will both arrive at the destination, if you're lucky B^), but the post office may have used DIFFERENT ROUTES to send them based on what plane/truck was going where at a certain time. NOW, can we all see why a user@f.q.d.n is an ADDRESS and !just!a!little!bang!fest!user is a ROUTE and that the two are NOT the same although the end effect may be? I'll shut up now, -Rob
bob@MorningStar.Com (Bob Sutterfield) (07/14/90)
(Hasn't this topic been flogged enough yet?)
In article <104@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes:
Of COURSE [site!...!user] is a route. But it's also an address.
Just like the scribble on the front of the USnail envelope you
received yesterday is both address and route.
Thanks for providing such an excellent illustration for the point you
contest!
Looking at the front of that envelope, I have no way of knowing
whether the postman walked down my street from the corner to the
north, or whether my block started on the south end. I suspect he was
wearing neither snowshoes nor a sun hat today, but he may have worn a
rain poncho for part of the morning. And it really doesn't matter,
because the envelope is now sitting in my hand. I don't know whether
he was driving one of their old Jeeps or one of their nifty new GM
lo-step aluminum vans. I don't know whether my letter sat waiting in
a bag in a corner storage bin for a few hours this morning, or whether
it came out from the local station in the postman's vehicle as part of
the first bag of the day. I don't know whether it was hauled from the
city's central station in a trailer towed by a Mack tractor or an
International. I don't know whether that truck got to the local
station via I-71 and Broadway, or whether it came along Fourth Street
and Cleveland Avenue, with stops at a few other substations along the
way. And on it goes... I don't know and don't care about the route,
or how it was carried, so long as it arrives in my hand at 43224-3424.
An address hides routing and transport issues. Addresses can stay
stable (and therefore useful for business cards, sales literature, and
articles in refereed journals) regardless of massive changes in
connectivity and technology. Routing and transport technology are the
postmaster's problem, and should be well-hidden from innocent users.fitz@wang.com (Tom Fitzgerald) (07/14/90)
les@chinet.chi.il.us (Leslie Mikesell) writes: > Always saying user@domain is not a solution > if you assume that the intermediate uucp hops run out-of-the-box AT&T > rmail. Even if user@domain is valid and what the user says, the > local mail has to generate a path to the domain gateway. This is optimizing for broken sites at the expense of working sites. We've had several RFCs and gigabytes of text in this newsgroup saying what UUCP sites should be doing, and lots of us are doing the right thing (I think). Is it really worth working so hard to give life-support to broken configurations, when it makes things worse for up-to-date configurations? --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
peter@ficc.ferranti.com (Peter da Silva) (07/16/90)
In article <apqzpx.h2i@wang.com> fitz@wang.com (Tom Fitzgerald) writes: > Is it really worth working so hard to give life-support to broken > configurations, when it makes things worse for up-to-date configurations? When it's what AT&T, Intel, ISC, Unisys, and just about everyone else in the System V world ships to their customers... yes. In the real world, some guy at a small company (say, a parts house that's using a UNIX box for inventory control) decides they'd like to get onto uucp mail, so they hook it up. One of their customers (say, an automobile dealership) decides they want to get into the act... I've helped a few people set things like this up, and the machines they're using would make your head spin. Ever hear of Regulus? At least with AT&T style mail you know what you're getting. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
les@chinet.chi.il.us (Leslie Mikesell) (07/17/90)
In article <KARL.90Jul10094904@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >honey@doom.ifs.umich.edu writes: > but what happens, karl, when you move on to that high-paying silicon > valley job, leaving confusion and turmoil behind? > >You make the very poor assumption, Peter, that my mail, news, and >nameserver configurations exist in state which would cause confusion >or turmoil among the rest of the staff if I left. I believe that Peter was raising the question of whether your successor would share your willingness to provide free services to the uucp communitity, rather than the ability of the staff to provide it. The confusion and turmoil would be among those who suddenly find TNSTAAFL (or whatever the correct acronym is for There's No Such Thing As A Free Lunch...). Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (07/17/90)
In article <707@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: >>> site!...!site!user@knownsite (reach user by following this >If "knownsite" receives such an address via SMTP, and can reasonably >be expected to gateway UUCP mail traffic to the first "site" in the >bang-path, then "knownsite" has no valid excuse for failing to deal >with this properly. Yes, there are plenty of UUCP-only sites that >don't grok site!user@fqdn the way Internet sites are supposed to; >that's why I always use pure bang-paths when sending mail via UUCP. Yes, once upon a time you could predict what would happen when you handed site!anything to a remote "rmail" program. These days, they may or may not take it upon themselves to interpret the "anything" part. Personally, I think that while such programs are useful, they should not call themselves "rmail". The next problem is that random sites on the path will prepend their own names to the header address fields so that the sender's @ to ! inversion is not reversible, making replies impossible. >It's a feature. Internet sites are required to ignore the presence of >bang-paths (and any other route encoding) in the local part of an >address, except when the FQDN on the right-hand side of the address is >that of the current host. But, as you note, it's unpredictably difficult to present such an address from a uucp site. While many gateways may correctly deliver path!domain!path!user, they don't all rewrite the headers correctly and even if they do, intermediate sites may destroy them. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (07/17/90)
In article <apqzpx.h2i@wang.com> fitz@wang.com (Tom Fitzgerald) writes: >les@chinet.chi.il.us (Leslie Mikesell) writes: >> Always saying user@domain is not a solution >> if you assume that the intermediate uucp hops run out-of-the-box AT&T >> rmail. Even if user@domain is valid and what the user says, the >> local mail has to generate a path to the domain gateway. >This is optimizing for broken sites at the expense of working sites. We've >had several RFCs and gigabytes of text in this newsgroup saying what UUCP >sites should be doing, and lots of us are doing the right thing (I think). Should we storm AT&T and burn the source to rmail or just quietly go on in the belief that everyone using it is doing the wrong thing and should be punished by shunning them? >Is it really worth working so hard to give life-support to broken >configurations, when it makes things worse for up-to-date configurations? This attitude does a lot to explain the popularity of using fax machines for anything important even when revisions need to be retyped. Most of our communications outside of the organization are with attmail or BITNET users, and I don't care if they have up-to-date configurations or not (what is that, anyway, X.400?). Les Mikesell les@chinet.chi.il.us
tp@mccall.com (07/17/90)
In article <1990Jul16.202721.271@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <apqzpx.h2i@wang.com> fitz@wang.com (Tom Fitzgerald) writes: >>les@chinet.chi.il.us (Leslie Mikesell) writes: >>> Always saying user@domain is not a solution >>> if you assume that the intermediate uucp hops run out-of-the-box AT&T >>> rmail. ... >>This is optimizing for broken sites at the expense of working sites. We've >>had several RFCs and gigabytes of text in this newsgroup saying what UUCP >>sites should be doing, and lots of us are doing the right thing (I think). > Should we storm AT&T and burn the source to rmail or just quietly go > on in the belief that everyone using it is doing the wrong thing and > should be punished by shunning them? Perhaps we can help the unfortunate users stuck with these machines improve their software? After all, broken machines are only a problem when they are not end-nodes (I'll support that assertion below). MANY of the broken machines are end-nodes. Some few are not, and are a problem. Has anyone told them they are a problem? Has anyone simply refused a link to a broken machine that is not and end-node? When you get a new link and uucp the news software down to them, send them smail too, and tell them to get registered. Also tell them that if they don't get registered, they must remain an end node, or you will drop your link with them. I'll get flamed for that, but I think it is a reasonable condition. I can give links to whoever I want, and I am doing them a favor. I feel I'm justified in putting conditions on my favors, and I feel that that particular condition is reasonable, since it is not too tough to get registered. Implicit in the requirement is my help (as someone who has done it) to get registered. As to the assertion above that only broken nodes that are not end-nodes are a problem, my reasoning is as follows: 1) If an end-node with dumb mail software doesn't know how to send mail to a particular address, that's his problem, and nobody else's. 2) If an end-node with dumb mail software generates bad addresses that people can't reply to, that's also his problem, he won't get his mail. 3) If a node is not an end-node and is broken, then he will screw up someone's mail other than his own, and that is a problem. In other words, I fully support anyone's right to cause himself problems, but I won't be a party to helping him (by supporting a link to him) cause problems for others. I urge any registered site out there who connects to an unregistered site to help that person get registered, and lean on him to do it. (Donning asbestos suit now...) -- 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
karl_kleinpaste@cis.ohio-state.edu (07/17/90)
les@chinet.chi.il.us writes:
I believe that Peter was raising the question of whether your successor
would share your willingness to provide free services to the uucp
community...
If I were to leave and my successors decided they didn't want to
support the current configuration, they know more than enough to keep
it alive long enough to allow an orderly changeover, decommissioning
things here when appropriate, but not cutting anyone off without both
warning and a chance to relocate; we here are responsible people.
Other parts of OSU would probably be happy (I have reason to believe
they would be positively overjoyed) to take on a lot of my
domain/UUCP/archive support.
--karlverber@pacific.mps.ohio-state.edu (Mark Verber) (07/17/90)
There are a number of people around OSU who would be willing to freely support uucp sites wanting MX service if Karl ever left. This is because most to the system/network people are domain absolutists by religion but realize that what is "correct" also need to be practical. Hense a willingness to help uucp sites. I expect that the OSU/CIS would continue the services that Karl has been offering, even if Karl left. Karl's co-workers are great people and believe in what Karl is doing. I expect that even if the existing staff didn't have time to keep up with all Karl was doing, they would permit some trusted member of the community to maintain the uucp stuff Karl had been doing. In the past OSU/CIS has permitted "guest" super-users who kept useful things running. If fact, Karl was at one time one of those "guest" super-users. I am personally happy that Karl is doing the work now. He has an already abused nameserver, and a pyramid whose sole purpose in life is to do uucp things and be the compuserve mail gateway. If for some unknown reason OSU/CIS had to get out of the buisness of free MX connections, there are a number of site around OSU, including mine, that would be willing to pick up the slack. Cheers, Mark
karl_kleinpaste@cis.ohio-state.edu (07/17/90)
les@chinet.chi.il.us writes: >Is it really worth working so hard to give life-support to broken >configurations, when it makes things worse for up-to-date configurations? This attitude does a lot to explain the popularity of using fax machines for anything important even when revisions need to be retyped. Why is it always _presumed_ that old, out-of-date things must be perpetuated? When your car has to be replaced, do you buy the exact same model you got last time? Do you look for the same model year? Do you look for the exact same feature set? Or do you instead go looking for newer technology, better gas mileage, safer passenger restraints, more functional cockpit gadgetry, and so on? What is it about using computers makes people think this way? "If it's changed _at_all_, well, heaven defend us, it's Morally Incorrect, and how dare the programmers _change_ something! Most importantly, find me a way of making the world look like it used to. Paper, yeah! I can't possibly be expected to learn anything new!" The only reason that fax can be said to work better than email is that the underlying transport, the raw phone network, has its operation ENFORCED by people who know what they're doing, and they're damn well accountable when it doesn't work. UUCP stuff is typically managed by people who seem to be offended by the idea that they should be required to take something seriously. I've got this UUCP neighbor sysadmin who took offense when I sent him a toasty-gram to complain that he had 4 days' worth of news (~16Mb) piling up here -- "Well, I just didn't get around to telling you that our system is dead." Gee, thanx, my spool area overran twice because of you, bozo. Responsibility, people -- that's what fax has over email. People who deal with the phone network take it seriously -- they have to. People who manage email frequently don't. So of _course_ it doesn't work as well. --karl PS- Yes, I saw the CACM article on fax -vs- email. I wasn't impressed. The idea of converting all email systems to use phone-number addressing is revolting. What I want is a user interface in front of my telephone that lets me ask for a person, and it finds the phone number for me. I don't want to have to open a @#$% phone book. PPS- Observe, if you will, that phone numbers have one other redeeming value: They are semantically equivalent to domain addresses. When you dial a phone, for fax or not, you just tell the phone network where you want to go, and don't have a clue on how you get there -- no indications of, "go through the downtown central office and from there to the Hinsdale office in Chicago, where you can connect with the Orland Park local office, which will find..." No. I just tell the phone network the numeric equivalent of "Carlene Kleinpaste," using a hierarchically-defined address, and expect the network to figure out the rest on its own. !-paths suck.
kjones@talos.pm.com (Kyle Jones) (07/17/90)
Leslie Mikesell writes: > Always saying user@domain is not a solution if you assume that > the intermediate uucp hops run out-of-the-box AT&T rmail. > Even if user@domain is valid and what the user says, the local > mail has to generate a path to the domain gateway. Tom Fitzgerald writes: > This is optimizing for broken sites at the expense of working sites. We've > had several RFCs and gigabytes of text in this newsgroup saying what UUCP > sites should be doing, and lots of us are doing the right thing (I think). Mikesell again: > Should we storm AT&T and burn the source to rmail or just quietly go > on in the belief that everyone using it is doing the wrong thing and > should be punished by shunning them? Both. Whenever I set up a new UUCP neighbor and discover that they're using rotted software, I inform them of that fact and offer something better. If they don't reform, then I reward their intransigence by marking them DEAD in my maps. As for AT&T, the bombing begins in five minutes... :-) Fitzgerald again: > Is it really worth working so hard to give life-support to broken > configurations, when it makes things worse for up-to-date configurations? Mikesell: > This attitude does a lot to explain the popularity of using fax machines > for anything important even when revisions need to be retyped. Eh? If it's important, then we set up a direct connection and cut out the middleman. I mean, if you're going to make the phone call anyway, you might as well do it right. kyle jones <kjones@talos.pm.com> ...!uunet!talos!kjones "No further communication will be accepted! If there is the slightest hostile move, your host will be destroyed immediately!"
Anselmo-Ed@cs.yale.edu (Ed Anselmo) (07/17/90)
>>>>> On 17 Jul 90 15:30:25 GMT, karl_kleinpaste@cis.ohio-state.edu said:
karl> PPS- Observe, if you will, that phone numbers have one other
karl> redeeming value: They are semantically equivalent to domain
karl> addresses. When you dial a phone, for fax or not, you just tell
karl> the phone network where you want to go, and don't have a clue on
karl> how you get there -- no indications of, "go through the downtown
karl> central office and from there to the Hinsdale office in Chicago,
karl> where you can connect with the Orland Park local office, which
karl> will find..." No. I just tell the phone network the numeric
karl> equivalent of "Carlene Kleinpaste," using a
karl> hierarchically-defined address, and expect the network to figure
karl> out the rest on its own. !-paths suck.
The phone system was/is one of Peter Honeyman's pet examples of what
*isn`t* an absolute address. E.g. my work number (203) 432-1254.
Within Yale, you only have to dial the last 5 numbers (the seven digit
version won't work). From many offices, you'll have to dial "9" to
get an outside line (i.e. the number is relative to "the outside
world"). From many countries, you'll have to dial a country code
followed by the number (the number is relative to the US phone
system). And so on ....
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edkarl_kleinpaste@cis.ohio-state.edu (07/18/90)
Anselmo-Ed@cs.yale.edu writes:
The phone system was/is one of Peter Honeyman's pet examples of what
*isn`t* an absolute address. E.g. my work number (203) 432-1254.
Within Yale, you only have to dial the last 5 numbers (the seven digit
version won't work). From many offices, you'll have to dial "9" to
get an outside line (i.e. the number is relative to "the outside
world"). From many countries, you'll have to dial a country code
followed by the number (the number is relative to the US phone
system). And so on ....
All you're defining is the number of domain qualifiers needed. Around
here, it is possible to write mail to "karl" if you're within this
department; "karl@cis" if you're within OSU and have a mailer config
that will attempt partial domain matches; "karl@cis.ohio-state.edu" if
you're outside the domain entirely.
Similarly, "last N digits" is within your local phone system; xxx-yyyy
is within your area code; aaa-xxx-yyyy is within (approximately?)
North America; cc-aaa-xxx-yyyy if you're trying to address another
country.
Looks domainist to me -- universal naming with abbreviations allowed
when operating within the local domain. The extent of relativity in
the address in both cases is merely defining the part of the address
that isn't "oneself."
--karlAnselmo-Ed@cs.yale.edu (Ed Anselmo) (07/18/90)
>>>>> On 17 Jul 90 18:12:57 GMT, karl_kleinpaste@cis.ohio-state.edu said:
karl> All you're defining is the number of domain qualifiers needed. Around
karl> here, it is possible to write mail to "karl" if you're within this
karl> department; "karl@cis" if you're within OSU and have a mailer config
karl> that will attempt partial domain matches; "karl@cis.ohio-state.edu" if
karl> you're outside the domain entirely.
Defining the universe as "the set of machines properly supporting
DNS-compatible mailers" then yes, "karl@cis.ohio-state.edu" is an
absolute address. Of course, this isn't really practical yet, so
"karl@cis.ohio-state.edu" is your address, relative to the previously
mentioned machines.
karl> Similarly, "last N digits" is within your local phone system; xxx-yyyy
karl> is within your area code; aaa-xxx-yyyy is within (approximately?)
karl> North America; cc-aaa-xxx-yyyy if you're trying to address another
karl> country.
karl> Looks domainist to me -- universal naming with abbreviations allowed
karl> when operating within the local domain. The extent of relativity in
karl> the address in both cases is merely defining the part of the address
karl> that isn't "oneself."
Domainist, perhaps. Absolute, no.
We'll define the phone universe as "the set of phones reachable from
my desk phone here at Yale". Let's assume that cc-aa-xxx-yyyy is my
full, unabbreviated phone number. This number won't work from the
office down the hall. The abbreviation is required, not just allowed.
I don't think there's a phone number that is guaranteed to connect to
me from an arbitrary phone. Therefore, I'll assert that phone numbers
are relative addresses.
Nonetheless, I wholeheartedly support domain registration for UUCP
sites :-).
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edMakey@Logicon.COM (Jeff Makey) (07/18/90)
In article <707@logicon.com> I wrote: >I always use pure bang-paths when sending mail via UUCP. I should have been more specific: I have configured sendmail on my Internet<->UUCP gateway to rewrite *all* headers into bang-only form when the mail is being delivered via UUCP. The From_ line, in particular, is rewritten, but sendmail also rewrites From:, To:, Cc:, Reply-To:, etc. in a similar manner. If it comes from my machine via UUCP, there are no @-signs in the headers. I realize that this violates RFC 822, but such behavior is recommended in section 2.1 of RFC 976 ("UUCP Mail Interchange Format Standard"): ``Because of the confusion surrounding hybrid addresses, we recommend that all transport layer software avoid the use of hybrid addresses at all times. A pure bang syntax can be used to disambiguate, being written c.d!a!b in the first case above, and a!c.d!b in the second. We recommend that all implementations use this "bang domain" syntax unless they are sure of what is running on the next machine.'' It works, too. In article <1990Jul16.200955.29906@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >The next problem is that random sites on the path will prepend their >own names to the header address fields so that the sender's @ to ! >inversion is not reversible, making replies impossible. It's the sites that *don't* prepend their own names to the header addresses that cause problems. More precisely, the problem is caused by the fact that some sites prepend their own names and others don't. If everybody did it, headers would all have nice complete bang-paths in them. If nobody did it, you would only be able to reply to sites listed in the UUCP Map. >In article <707@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: [...] >>It's a feature. Internet sites are required to ignore the presence of >>bang-paths (and any other route encoding) in the local part of an >>address, except when the FQDN on the right-hand side of the address is >>that of the current host. > >But, as you note, it's unpredictably difficult to present such an >address from a uucp site. While many gateways may correctly deliver >path!domain!path!user, they don't all rewrite the headers correctly >and even if they do, intermediate sites may destroy them. A well-behaved UUCP->Internet gateway will rewrite the headers correctly. If your gateway to the Internet is broken, find another one (there are plenty of them that work properly). The same goes for the broken intermediate UUCP sites: mark them DEAD in your local pathalias data, or establish a direct connection to your destination machine if the mail is really important. It's the only real solution. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
amanda@mermaid.intercon.com (Amanda Walker) (07/18/90)
In article <KARL.90Jul17113025@giza.cis.ohio-state.edu>, karl_kleinpaste@cis.ohio-state.edu writes: > UUCP stuff is typically managed by > people who seem to be offended by the idea that they should be > required to take something seriously. Also, there seems to be a prevalent attitude that getting a UUCP connection gives you two-way email access to the Internet for free (in terms of both money and hassle) because, well, "other people run gateways, right?" Too bad life isn't quite that simple... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
amanda@mermaid.intercon.com (Amanda Walker) (07/18/90)
In article <ANSELMO-ED.90Jul17124237@bigbird.cs.yale.edu>, Anselmo-Ed@cs.yale.edu (Ed Anselmo) writes: > The phone system was/is one of Peter Honeyman's pet examples of what > *isn`t* an absolute address. E.g. my work number (203) 432-1254. > Within Yale, you only have to dial the last 5 numbers (the seven digit > version won't work). From many offices, you'll have to dial "9" to > get an outside line (i.e. the number is relative to "the outside > world"). Bad analogy. Your fully qualified telephone number (+ 1 203 432 1254), is globally unique. Your PBX may require a '9' to get through your "gateway," and it may allow shortcuts within your "domain," but that's just local policy, and your business. Given your FQTN though, Anyone in the world with direct international dialing can call you, without having any idea where you actually are, or the path their vice takes to get from them to you. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <1990Jul16.202721.271@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <apqzpx.h2i@wang.com> fitz@wang.com (Tom Fitzgerald) writes: > >Is it really worth working so hard to give life-support to broken > >configurations, when it makes things worse for up-to-date configurations? > This attitude does a lot to explain the popularity of using fax machines > for anything important even when revisions need to be retyped. That's the bottom line, isn't it. Email is way more efficient than FAX, but it's just too inconvenient. What we need is a ".phone" domain. Mail to someone at "+17135551212.phone" is accomplished by making a call to +17135551212, logging in as anonymous, and sending mail. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <KARL.90Jul17113025@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: > Why is it always _presumed_ that old, out-of-date things must be > perpetuated? Well, come up with a new, up-to-date, alternative that works as well, *AND* is as convenient as a plain-jane UUCP connection. Then people will stop trying to perpetuate the old stuff. It's more hassle to get properly DNSified, and a plane-jane UUCP connection is already more hassle than FAX. > Or do you instead go > looking for newer technology, better gas mileage, safer passenger > restraints, more functional cockpit gadgetry, and so on? Newer doesn't mean safer. One of the reasons I got my current car (a Mazda 323, '89 model year) was because it didn't have fancier passenger restraints. Just simple 3-point belts on all 4 seats. I doubt I'll be able to get such a reliable system in my next car. > What is it about using computers makes people think this way? Nothing. Some people are neither fanatic xenophiles nor xenophobes. > The only reason that fax can be said to work better than email is that > the underlying transport, the raw phone network, has its operation > ENFORCED by people who know what they're doing, and they're damn well > accountable when it doesn't work. The underlying transport for UUCP is the exact same raw phone network. It's not the transport mechanism that makes the difference, it's the addressing: you don't have to know two names for a machine (UUCP name and phone number) to connect to it, and you don't have to ask permission of someone at the other end to make a call. > PS- Yes, I saw the CACM article on fax -vs- email. I wasn't > impressed. The idea of converting all email systems to use > phone-number addressing is revolting. I'm not suggesting that. I'm suggesting making that alternative available. > you just tell the phone network where > you want to go, and don't have a clue on how you get there I guess you missed hearing about "equal access". > !-paths suck. !-paths (a) work, and (b) save money. The user doesn't see them, but I'd much rather send mail for "splut.conmicro.com" to "sugar.hackercorp.com" via a local phone call than to "uunet.uu.net". Pure DNS mail, for a UUCP site, is like making all your phone calls via your long-distance carrier. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <KARL.90Jul17141257@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: > Similarly, "last N digits" is within your local phone system; xxx-yyyy > is within your area code; aaa-xxx-yyyy is within (approximately?) > North America; cc-aaa-xxx-yyyy if you're trying to address another > country. 10333-aaa-xxx-yyy to route (there's that word again) via SPRINT, or 1-800-877-8000 if you're calling from a COCOT, or you have to dial 9, or in some cases 77-code-9. Then there's things like 1-900-BLOCKER. If you know what you're doing, and it's important to route, you can route. It's supported. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
kevin@kosman.UUCP (Kevin O'Gorman) (07/18/90)
tp@mccall.com writes: >Has anyone simply refused a link to a broken machine that is not and >end-node? When you get a new link and uucp the news software down to them, >send them smail too, and tell them to get registered. Also tell them that >if they don't get registered, they must remain an end node, or you will >drop your link with them. I've got a different problem. I'm the end-node, uucp-only site. I would sort of like to get registered, but every time I have asked about it I've gotten very little response, or response that just has to be wrong (folks at the "network control center" (??) who insisted I would have to have a network id (one of those 000.00.0.00 things), or a response that was just too confusing or promised to be expensive. My main feed is an internet site which is willing to do what is required (or give me "guest root" privilege to do it myself), but their current people either don't know much about it or don't have much time to hold my hand about it. I'm going to guess that I'm not alone. And I've done what I can think of already: I run smail 2.5 and Mush, and I try to send out sensible headers, though the rules are a bit hard to understand in an environment where it seems NOBODY is willing to document major features like "%", and many people are smugly superior about their undersanding of a very complicated situation. BTW this surely does not apply to the poster of the original article. Indeed, I am encouraged to ask these questions the helpful attitude expressed here. >I'll get flamed for that, but I think it is a reasonable condition. I can ^^^^^^ not by me >give links to whoever I want, and I am doing them a favor. I feel I'm >justified in putting conditions on my favors, and I feel that that >particular condition is reasonable, since it is not too tough to get >registered. Implicit in the requirement is my help (as someone who has done >it) to get registered. >I urge any registered site out there who connects to an unregistered site >to help that person get registered, and lean on him to do it. (Donning >asbestos suit now...) Okay, but how about the unregistered site who's not having much luck leaning on the regisered one? I would like to know: 1) Can I get registered without paying $100 or more. 2) What exactly is an MX record, and where does it go? 3) What do I have to do to their sendmail (shudder) to make it deliver mail to my new domain if I get one? 4) What do I have to do to smail and/or rmail to make it accept the domain based mail when it comes in. 5) What else, if anything, do I have to do to the neighbor's machine to make all this work? -- Kevin O'Gorman ( kevin@kosman.UUCP, kevin%kosman.uucp@nrc.com ) voice: 805-984-8042 Vital Computer Systems, 5115 Beachcomber, Oxnard, CA 93035 Non-Disclaimer: my boss is me, and he stands behind everything I say.
Makey@Logicon.COM (Jeff Makey) (07/19/90)
In article <F1R44SF@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Pure DNS mail, for a UUCP >site, is like making all your phone calls via your long-distance carrier. Pure DNS mail, for a UUCP-only site, is an oxymoron. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
amanda@mermaid.intercon.com (Amanda Walker) (07/19/90)
In article <F1R44SF@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > I'd > much rather send mail for "splut.conmicro.com" to "sugar.hackercorp.com" > via a local phone call than to "uunet.uu.net". So do it. If you're running sendmail, it's easy, and if not, I'd be real surprised if smail didn't also let you do it. If this decision is made by the mailer, your users don't have to use bang-paths. If you change your connectivity, all you have to change is one file, as opposed to telling everyone to send their mail a different way. Using domain addresses certainly does not preclude making local routing decisions--in fact, in my experience, it makes it easier, since you actually know where a given piece of mail is headed... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
lear@turbo.bio.net (Eliot) (07/19/90)
Don't confuse routing information with billing information. They are distinct. -- Eliot Lear [lear@turbo.bio.net]
jon@savant.UUCP (Jon Gefaell) (07/19/90)
In article <110@umn-d-ub.d.umn.edu> rhealey@umn-d-ub.d.umn.edu (Rob Healey) writes: > > The second one is a ROUTE. It tells you WHERE to go and HOW to > get there... B^). There is a MAJOR distinction here. The address > you put on a USnail mail is an ADDRESS only. You don't tell the > post office how it should go about doing it's business. If you Bzzzt! Sorry, but thank _you_ for playing our game! (deja vu!) :) Ever hear of First Class Mail, AirMail, Express Mail, Third Class Mail, Bulk Mail, Ad Nauseum.. There are more ways to specify _HOW_ to deliver a message, as well as _WHERE_.... Otherwise, I don't know what I'm talking about :) -- +----------- Domain? DOMAIN? We Don't Need No Steeeenkin' Domain! -----------+ | __/\ | | \/~~ | +-savant!jon@virginia.edu {...}!uunet!virginia!savant!jon jeg7e@virginia.edu-+
pjg@acsu.buffalo.edu (Paul Graham) (07/19/90)
peter@ficc.ferranti.com (Peter da Silva) writes: |karl_kleinpaste@cis.ohio-state.edu writes: |> Similarly, "last N digits" is within your local phone system; xxx-yyyy |> is within your area code; aaa-xxx-yyyy is within (approximately?) |> North America; cc-aaa-xxx-yyyy if you're trying to address another |> country. |10333-aaa-xxx-yyy to route (there's that word again) via SPRINT, or |1-800-877-8000 if you're calling from a COCOT, or you have to dial 9, |or in some cases 77-code-9. Then there's things like 1-900-BLOCKER. well while one may quibble with the point somewhat (honey notwithstanding) i think you're indulging in semantic sleight of hand. you've may select the carrier but you still don't exert explicit control over the route you just get to pick a couple of branch points. in any case paper mail is a better analogue. you do have an unambiguous address and you can use it, in paris texas or paris france. (not to imply that texas and france enjoy comparable levels of sovereignty.)
ggw@wolves.uucp (Gregory G. Woodbury) (07/20/90)
In <612@savant.UUCP> jon@savant.UUCP (Jon Gefaell) writes: > >In article <110@umn-d-ub.d.umn.edu> rhealey@umn-d-ub.d.umn.edu (Rob Healey) writes: >> The second one is a ROUTE. It tells you WHERE to go and HOW to >> get there... B^). There is a MAJOR distinction here. The address >> you put on a USnail mail is an ADDRESS only. You don't tell the >> post office how it should go about doing it's business. If you > >Bzzzt! Sorry, but thank _you_ for playing our game! (deja vu!) :) > >Ever hear of First Class Mail, AirMail, Express Mail, Third Class Mail, >Bulk Mail, Ad Nauseum.. There are more ways to specify _HOW_ to deliver >a message, as well as _WHERE_.... Buzzzt! Sorry........... Only one of the things you mention has any effect on the route that an item of mail will take. "AirMail" does specify that you wish overseas or transcontinental mail to be routed via the fastest available carrier. All the other items mentioned (1st class, Express, 3rd class, bulk) are priority classifiers that tell the postal service how much you are willing to pay for expiditious delivery. In no case do you have any control of the topological path that the envelope traverses besides the endpoints. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
peter@ficc.ferranti.com (Peter da Silva) (07/20/90)
In article <714@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: > In article <F1R44SF@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >Pure DNS mail, for a UUCP > >site, is like making all your phone calls via your long-distance carrier. > Pure DNS mail, for a UUCP-only site, is an oxymoron. Nonsense: Just create a file called "/usr/lib/uucp/paths" containing the single line "smart-host uunet!%s 0". -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (07/20/90)
In article <11R41EF@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Jul16.202721.271@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >That's the bottom line, isn't it. Email is way more efficient than FAX, >but it's just too inconvenient. > >What we need is a ".phone" domain. Mail to someone at "+17135551212.phone" is >accomplished by making a call to +17135551212, logging in as anonymous, and >sending mail. Interesting idea... user@+number.phone for dialup mail user@+number.fax for fax Are we going to allow them in routes? site_a!site_b!+18005551234.phone!site_c!site_d!user What about using BFT via fax? site_a!site_b!+18005551234.bftp.fax!site_c!site_d!user Lot's of interesting variations... -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
karl_kleinpaste@charcoal.com (07/20/90)
kevin@kosman.uucp writes:
I would like to know:
1) Can I get registered without paying $100 or more.
2) What exactly is an MX record, and where does it go?
3) What do I have to do to their sendmail (shudder) to make it
deliver mail to my new domain if I get one?
4) What do I have to do to smail and/or rmail to make it accept
the domain based mail when it comes in.
5) What else, if anything, do I have to do to the neighbor's
machine to make all this work?
[1] You can get registered for $0. Really.
[2] An MX RR (Mail eXchanger Resource Record) is an indication of an
SMTP-reachable site which is willing to be the recipient of mail
intended for another site, frequently non-SMTP-reachable. That MX
host is then expected to figure out the proper way to reach the
intended destination by whatever means are appropriate, usually
UUCP.
[3] There's a tweak or two to a .cf which makes it understand that
delivery to certain domain names should not be performed by SMTP.
Keep reading.
[4] Smail 2.5 understands domains reasonably well, and can find any
domain address of any kind via suitable support in
/usr/lib/uucp/paths, generated with pathalias. Keep reading.
[5] Your neighbor's machine will require:
A UUCP connection to your system.
A .cf change to understand that your domain is actually
reached via UUCP.
A backend (I use smail 2.5 myself) which understands the
translation between your domain name and your UUCP
name.
When this discussion was still in its youth (as opposed to heading for
rigor mortis now), Terry observed the lack of documentation and
support for getting new sites registered, and I countered with a left
jab...ahem, with an intention to write up such docs and post them here
as a sort of FAQ-style posting. I haven't had time to finish it up
yet, but it's in progress. I hope to have it done by the middle of
end of next week.
--karlandyb@coat.com (Andy Behrens) (07/20/90)
kevin@kosman.UUCP (Kevin O'Gorman) writes: > I've got a different problem. I'm the end-node, uucp-only site. I would > sort of like to get registered, but every time I have asked about it I've > gotten very little response, or response that just has to be wrong (folks > at the "network control center" (??) who insisted I would have to have a > network id (one of those 000.00.0.00 things), or a response that was just > too confusing or promised to be expensive. My main feed is an internet > site which is willing to do what is required (or give me "guest root" > privilege to do it myself), but their current people either don't know > much about it or don't have much time to hold my hand about it. > > I would like to know: > 1) Can I get registered without paying $100 or more. > 2) What exactly is an MX record, and where does it go? > 3) What do I have to do to their sendmail (shudder) to make it > deliver mail to my new domain if I get one? > 4) What do I have to do to smail and/or rmail to make it accept > the domain based mail when it comes in. > 5) What else, if anything, do I have to do to the neighbor's > machine to make all this work? 1. You can register your site for free (if you're willing to do a lot of work yourself), or for $35 if you want assistance from uunet. 2. To be registered -- if you're not on the Internet directly -- you will need to find a site ("forwarder") to forward mail to you (typically, over uucp). You will also need to find at least 2 Internet sites ("nameservers") which will tell the rest of the Internet that mail destined for your machine should be sent to your forwarder. Each nameserver will have MX records for the host(s) in your domain, identifying the forwarder that will pass the mail on to you. If your forwarder is well-administered and willing, it can also serve as one of your two nameservers. From your description, this doesn't seem like a workable idea. 3. Your forwarder's sendmail needs to be able to recognize To: addresses like "user@yourhost.yourdomain.com", and send the mail to you over uucp. That's an easy change. If you're not running a smart mailer, it also needs to rewrite the addresses in ! format so your mailer will be able to send replies. 4. If your neighbor rewrites addresses in uucp style, with !s, you don't need to change smail at all. The steps you need to follow are: 1. Find a site willing to be your forwarder. (You've already done that). 2. Find two sites willing to act as nameservers.(*) 3. Choose a domain name. Fill out the forms(*) and send them to the Network Information Center(*). If nobody else has the claimed the name, it's yours. 4. Ask the administrators of your nameservers to add MX records(*) so that machines on the Internet will send your mail to your chosen forwarder. 5. Ask the administrator of the forwarder machine (your uucp neighbor) to update sendmail so it will recognize your new name and pass mail to you. 6. To be nice, update your Usenet map entry so that uucp-only sites can start using your domain name also. * For $35 [last time I checked] the uunet folks will find nameservers for you, send you the forms you'll need, pass them on to the NIC, and make sure that your nameservers know about your forwarder. They'll do this even if you aren't a uunet client. It's a good deal, and will save you a lot of headaches. -- Live justly, love gently, walk humbly. Andy Behrens andyb@coat.com uucp: {uunet,rutgers}!dartvax!coat.com!andyb bitnet: andyb%coat.com@dartcms1 Burlington Coat, PO Box 729, Lebanon, N.H. 03766 (603) 448-5000
peter@ficc.ferranti.com (Peter da Silva) (07/20/90)
In article <26A4DCA7.16B1@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > So do it. If you're running sendmail, it's easy, and if not, I'd be real > surprised if smail didn't also let you do it. If this decision is made > by the mailer, your users don't have to use bang-paths. I think we have a communications problem here. I'm not suggesting forcing users to use explicit routing. I was under the impression that you were opposed to the mail routing agent building explicit bang paths, and that you were in favor of breaking explicit routing to force sites to route mail via the domain name system. That, to me, is sheer lunacy. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
chip@tct.uucp (Chip Salzenberg) (07/21/90)
According to amanda@mermaid.intercon.com (Amanda Walker): >In article <F1R44SF@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da >Silva) writes: >> I'd much rather send mail for "splut.conmicro.com" to >> "sugar.hackercorp.com" via a local phone call than to "uunet.uu.net". > >So do it. Well, of course, we do. But to do so, our MTAs perforce do source routing. We put bang paths in our envelopes and keep the headers RFC822. If only intervening sites would LEAVE THE HEADERS ALONE, everything would be fine. Another point to be made from the "splut/sugar" example is that the DNS and MX records aren't the be-all and end-all of E-Mail addressing. There's still a need for the UUCP maps, and until everyone (and I do mean *everyone*) is on the Internet, that need will continue. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
chip@tct.uucp (Chip Salzenberg) (07/21/90)
According to Makey@Logicon.COM (Jeff Makey): >I [...] rewrite *all* headers into bang-only form when the mail >is being delivered via UUCP. The From_ line, in particular, >is rewritten, but sendmail also rewrites From:, To:, Cc:, Reply-To:, >etc. in a similar manner. This behavior prevents UUCP-only sites from exchanging RFC822-conformant mail. It is EVIL and RUDE. Oddly, Jeff quotes RFC976 in defense of this practice: > ``Because of the confusion surrounding hybrid addresses, we recommend > that all transport layer software avoid the use of hybrid addresses > at all times. [...]'' As Jeff should know, "chip@ateng.com" is NOT a hybrid address. However, ateng.com is a UUCP-only domain. So Jeff would rewrite mail to ateng to contain "To: ateng.com!chip", thus breaking the header. Gateways should rewrite message envelopes, but not headers. ********************************* ** UUCP is just a transport. ** ********************************* Please don't rewrite our headers! -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
cik@l.cc.purdue.edu (Herman Rubin) (07/21/90)
In article <1990Jul19.180709.27037@wolves.uucp>, ggw@wolves.uucp (Gregory G. Woodbury) writes: > In <612@savant.UUCP> jon@savant.UUCP (Jon Gefaell) writes: > > > >In article <110@umn-d-ub.d.umn.edu> rhealey@umn-d-ub.d.umn.edu (Rob Healey) writes: ......................... > All the other items mentioned (1st class, Express, 3rd class, > bulk) are priority classifiers that tell the postal service how much you > are willing to pay for expiditious delivery. In no case do you have any > control of the topological path that the envelope traverses besides the > endpoints. Would the Post Office return your mail if the route it decided upon from one site to another was not open? It would come up with an alternate route. Also, it it did not find the street address you put down, it might even try to figure out what you meant, although this has declined. But I doubt it would do the things the "smart routers" do like just returning mail it the route it tries does not work. At least it will try to get it to an identifiable post office. I have had this fail with uucp. Also, we have different mail systems. There are different syntaxes for the addressing for each system. In postal addresses, there is usually a way of identifying the location of the post office, and the street address or firm name can be distinguished from the internatl delivery system within the firm. This is not clear with ! addressing. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
Makey@Logicon.COM (Jeff Makey) (07/21/90)
In article <W.R4HSA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <714@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: [...] >> Pure DNS mail, for a UUCP-only site, is an oxymoron. > >Nonsense: Just create a file called "/usr/lib/uucp/paths" containing >the single line "smart-host uunet!%s 0". Nice try, but /usr/lib/uucp/paths is not part of the Domain Name System. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
amanda@mermaid.intercon.com (Amanda Walker) (07/21/90)
In article <FRS4D5F@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > I was under the impression that you were > opposed to the mail routing agent building explicit bang paths, and that > you were in favor of breaking explicit routing to force sites to route > mail via the domain name system. That, to me, is sheer lunacy. Ah. The transport-level destination (the "envelope address" in SMTP, or the "From " line in UUCP) is the routing agent's business. For any site connected via UUCP (aside from the trivial case of being one hop away from the internet), bang paths will end up in the transport destination given the current state of the net. However, the RFC822 "To:" and "From:" lines should *only* contain domain addresses, and any intermediate site should be able to make a routing decision for the message (or a reply) based on those domain addresses alone, unless the mail is routed only via UUCP. Ideally, in my opinion, the transport-level destination should just be a copy of the RFC822 "To:" address, but that is currently impractical given the number of RFC822-ignorant UUCP sites out in the world. This I regard as an opportunity for improvement :-). For example, we have the luxury of being connected via uunet, which is a "real live" Internet site, and all of our private UUCP links are to sites which grok domain addresses. Therefore, even though all of our offsite mail travels via UUCP, no bang paths ever even enter the picture unless we are sending mail to a domain-less UUCP site (and even that is only because uunet is willing to deal with bang-paths as addresses). For example, when my sendmail decides a message is headed offsite, it queues up a UUX command to the appropriate host that says "rmail user@host.domain". I don't have to run pathalias; our newsfeed doesn't even include comp.mail.maps... Even if we took on downstream feeds, as long as they all had domain names we still wouldn't need maps or pathalias. I consider this to be a feature. I do not see why anyone but the site directly involved should have to care about how machines are actually connected, only what particular machine a piece of mail is going to. The DNS serves admirably well at providing this information. Running pathalias and keeping your own complete UUCP map for doing source routing is like using old-style host tables on the Internet... Local connectivity information should stay local. I remember when pathalias was new, and I even then I thought that it was a sign that a different mail routing mechanism was needed... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
fitz@wang.com (Tom Fitzgerald) (07/21/90)
Makey@Logicon.COM (Jeff Makey) writes: > It's the sites that *don't* prepend their own names to the header > addresses that cause problems. More precisely, the problem is caused > by the fact that some sites prepend their own names and others don't. If valid RFC822 addresses weren't rewritten into ! addresses in the first place, this wouldn't be a problem. > If everybody did it, headers would all have nice complete bang-paths > in them. ....which often aren't usable. First of all, they're very often nonoptimal. If the optimal path from a to e is a!b!c!d!e, the optimal path from e to a is frequently _not_ e!d!c!b!a. This happens because of polling intervals and different choices about routing and transport by the intermediates. Occasionally (maybe 2% of the time) the reversed path isn't even usable. And the fact remains that not all sites prefix the path with their nodename. If we're going to adopt a method that requires all the nodes in the UUCP net to change their behavior, why not get everyone to become RFC822 conformant so that !-paths aren't necessary at all? --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Makey@Logicon.COM (Jeff Makey) (07/21/90)
In article <26A76773.3660@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >when my sendmail decides a message is headed offsite, it queues up a UUX >command to the appropriate host that says "rmail user@host.domain". I don't >have to run pathalias; our newsfeed doesn't even include comp.mail.maps... How do you know which is the appropriate host? Letting uunet handle mail to unrecognized domains and unregistered hosts is nothing more than a cop-out, as uunet must maintain the routing information that you don't. >I do not see why anyone but the site directly involved should have to care >about how machines are actually connected, only what particular machine a >piece of mail is going to. The DNS serves admirably well at providing this >information. Only when the DNS is available and only for registered sites. Some facts of real life are that the Internet and its DNS is not always available, and there will always be unregistered sites that someone will want to send mail to. As a site that is directly on the Internet, and also speaks UUCP, I consider it an important feature of UUCP that it is completely independent of the Internet. My 56Kb Internet connection is great, when it works, but it is occasionally unavailable for some reason or another (e.g., hardware problems, usage policy). When this happens, UUCP will still get the mail through. I realize that a *lot* of UUCP traffic actually travels over the Internet. It doesn't have to. I can change all of my UUCP-over-TCP links to UUCP-over-telephone in about 5 minutes when necessary. >Running pathalias and keeping your own complete UUCP map for doing source >routing is like using old-style host tables on the Internet... Local >connectivity information should stay local. Pathalias is just a different form of domain name resolver, and comp.mail.maps is an excellent mechanism for distributing the domain database to sites that don't, won't, or can't use the Internet DNS. One of my major gripes is that there is so little overlap between the UUCP Map and the Internet DNS that I am compelled to support both. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
Makey@Logicon.COM (Jeff Makey) (07/21/90)
In article <aq3svf.axd@wang.com> fitz@wang.com (Tom Fitzgerald) writes: >If valid RFC822 addresses weren't rewritten into ! addresses in the first >place, this wouldn't be a problem. [...] >And the fact remains that not all sites prefix the path with their >nodename. The one problem you fail to take into account is the sites (and there are plenty of them) that rewrite From: user@fully.qualified.domain into the completely wrong form of From: bozo-site!user@fully.qualified.domain where "bozo-site" is the UUCP name of such a site. I am not one of these sites, but when I ship such mail out via UUCP with From: snoopy!fully.qualified.domain!user I can sleep well knowing that I am immune from such lunacy. While I currently do this for all UUCP traffic, I am beginning to be convinced that I should only do this if bozo-site is the next UUCP hop. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
les@chinet.chi.il.us (Leslie Mikesell) (07/21/90)
In article <KARL.90Jul17113025@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >Why is it always _presumed_ that old, out-of-date things must be >perpetuated? When your car has to be replaced, do you buy the exact >same model you got last time? Begging your pardon, but my mail software is neither old nor out of date. It supports multiple binary attachments to messages and several other things that I don't want to give up just to get a dotted address in my From: line. I'm talking about AT&T's PMX-mailers and while I think the "enhanced" /bin/mail that comes with the pmx products has several problems, it is not trivial to drop in a replacement. I am doing it (with smail 3.1) but it hasn't been easy and there are still a few problems to solve.. This is at the national office of The American Farm Bureau, and I have also obtained a uunet connection and a domain name of fb.com. The Farm Bureau happens to be a federation, meaning that we don't really have control over the state offices and thus have to talk to all sorts of equipment to make everyone communicate. For example, one state has a model 43 teletype hanging off a KU-band 2 way satellite dish (weird, eh?), and another has a unix box running a similar AT&T mailer but they also have the X.400 extensions for communication with OfficeVision on their mainframes. Now, I'd like to provide all the state offices that have unix machines access to the "rest of the world" through uunet - in particular, lots of USDA people seem to hang out on BITNET. Physically, this is no problem - everyone can connect to the machine in DC via KU band satellite and it's a local call from there. The problem is, I'm willing to provide subdomain names for the states, but I can't force them to change their mailers to put it in their From: lines, and without it they aren't going to get any replies back. Now after hearing all the ranting about how easy it is to switch to a domain naming scheme, I want to know which software is (a) binary transparent and (b) knows how to rewrite "From:" lines into domain format based on the contents of the uucp From_ lines *and* the destination address. I'm not interested in "brute-force" tricks here - I can manage that on my own. What I want is a realistic answer about software available (for SysV) that knows as much about rewriting the header lines as the envelope To: address. The IDA sendmail enhancements seem to address this type of problem, but it doesn't look likely to work under SysV. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (07/21/90)
In article <1990Jul17.153938.24561@talos.pm.com> kjones@talos.pm.com (Kyle Jones) writes: >Eh? If it's important, then we set up a direct connection and >cut out the middleman. I mean, if you're going to make the phone >call anyway, you might as well do it right. I'd love to. How do you set up a direct connection to BITNET sites? Les Mikesell les@chinet.chi.il.us
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/22/90)
Something that has worked at sgi.sgi.com for several years is the following:
1) Define a sendmail class set with an
"FB /usr/lib/uucp/Systems #bad822 %s"
to define a class of UUCP neighbors that think a!b@c is parsed a!(b@c).
or that prepend "theirname!" to perfectly good "b@c" From:'s.
2) Define a sendmail class set with an
"FG /usr/lib/uucp/Systems #domain-host %s"
to define a class of UUCP neighbors that understand RFC-822.
3) Accept all reasonable and many unreasonable mixtures of RFC-822 addresses,
822-source routes, UUCP routes, and so on
In S0, rewrite everything into 822, converting ! routes to source routes.
The class B defined in #1 is useful here.
4) resolve to different mailers depending on whether the destination
is (a) reached via SMTP, (b) reached via UUCP but the first hop is to a
member of the class G defined in #2 above, or (c) dumb UUCP.
In the mailers (a), (b), & (c), do the following to To: From: Cc: etc.:
(a) -convert all UUCP to 822 source routes. (Yes, source routes
are deprecated in 1123, but how else to comply with what
is may be a human's routing directive?)
-Leave simple 822 addresses alone.
(b) -leave receipent (To: Cc:...) UUCP routes with more than one host
alone (of course after stripping our own hostname).
(e.g., a!b!c is unchanged, as is a!b.dom.ain!c)
-Convert a!b into b@a.
-Prepend our UUCP hostname to UUCP sender (e.g. From:) a!b!c
-Leave good 822 addresses alone.
(c) -convert everything to ! routes, and prepend or strip
our UUCP hostname as required.
The main point is to rewrite addresses gatewayed to and from the UUCP
universe, and to distinquish between neighbors in the UUCP universe from
those in the RFC-822 universe who just happen to reached via UUCP
transport. That latter happens fairly often, when it is inappropriate to
use NFSNET or when it would be nice to send email complaining that an
Internet link is broken.
Even when you have 50 or 100 active UUCP links, it turns out to be easy
to maintain this scheme. Gradually, most of our UUCP neighbors have been
marked in what is now /usr/lib/uucp/Systems as understanding RFC-822.
"Be liberal in what you accept, conservative in what you send" applies
without saying.
The sendmail.cf files on the thousands of machines on the SGI network
are maintained with vi/emacs/etc. That is not a big deal, because there
are only about 4 distinct files, with the rest being rcp'ed by
one of 3 shell scripts which change something like 3 lines to do things
like setting the local DNS domain and choosing a smart relay for strange stuff.
Vernon Schryver
Silicon Graphics
vjs@sgi.comoc@vmp.com (Orlan Cannon) (07/22/90)
In article <720@logicon.com>, Makey@Logicon.COM (Jeff Makey) writes: > In article <26A76773.3660@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > > How do you know which is the appropriate host? Letting uunet handle > mail to unrecognized domains and unregistered hosts is nothing more > than a cop-out, as uunet must maintain the routing information that > you don't. Wait. I think I'm missing something here. How can you possibly say that letting uunet maintain the proper routing information is a "cop-out"? I thought that was one of the reasons uunet was created, to be that all-important link between uucp and internet, between dumb mailers and smart mailers, between sites that don't keep a database of destination sites and the rest of the world... Sure it costs money, but some people are willing to pay for the price of having a site that can *correctly* translate their mail from whatever they choose to send into something that the destination site wants to receive. That's what we're talking about here, isn't it. Uunet does a really good job at this. (So does osu-cis and several other sites. I won't talk about rutgers.) The people who complain about uunet's "munging" of headers are sites that never told uunet what they want to receive. Out of necessity, they assume that most uucp sites are "dumb" sites. Not a bad assumption, from my point of view. > As a site that is directly on the Internet, and also speaks UUCP, I > consider it an important feature of UUCP that it is completely > independent of the Internet. My 56Kb Internet connection is great, > when it works, but it is occasionally unavailable for some reason or > another (e.g., hardware problems, usage policy). When this happens, > UUCP will still get the mail through. All the more reason for small sites to pass their mail traffic directly to uunet and let *them* figure out the best way to *deliver* the message. You can't expect everyone to have the same resources that you do. -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. (800) 627-4551 Oradell, NJ 07649
amanda@mermaid.intercon.com (Amanda Walker) (07/22/90)
In article <720@logicon.com>, Makey@Logicon.COM (Jeff Makey) writes: > How do you know which is the appropriate host? Letting uunet handle > mail to unrecognized domains and unregistered hosts is nothing more > than a cop-out, as uunet must maintain the routing information that > you don't. It's not a cop-out. I don't *expect* anything but a domain address or a straight UUCP path to work, and I will not bother tracking down mail problems that involve anything but the first. However, if I see an address I can't route to, I will give uunet a crack at it, for two reasons: (a) If it's offsite, it's going to go through them anyway in our case. We are willing to pay a marginal amount to send randomly addressed mail off to them on the chance that it will work. It's not as if we only hand them mail that we can't route ourselves :-). (b) uunet is willing to take a crack at it. If uunet weren't a local phone call away, the "marginal amount" in (a) might become sufficiently large that we would only send mail that was a pure UUCP path starting with "uunet" or destined to a real-live top level DNS domain. If (b) changes, it's very little skin off our nose. "Not guaranteed" mail would just become "Not supported" mail until and unless the site in question got a domain name or gave us a full UUCP path. If uunet wants to be the Mail God, that's their business. One's enough, though... I see no reason to devote a significant amount of my resources to maintaining a model of the entire Usenet and affiliated networks, which is guaranteed to be inaccurate. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/22/90)
In article <719@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: > In article <W.R4HSA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >In article <714@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: > [...] > >> Pure DNS mail, for a UUCP-only site, is an oxymoron. > >Nonsense: Just create a file called "/usr/lib/uucp/paths" containing > >the single line "smart-host uunet!%s 0". > Nice try, but /usr/lib/uucp/paths is not part of the Domain Name > System. Hello. Anyone home? If you do this, all your mail will be resolved by the Domain Name System. Not at your site, but at UUNET. Jeeze. There are sites that do this. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/22/90)
In article <1990Jul22.013945.4041@vmp.com> oc@vmp.com (Orlan Cannon) writes: > All the more reason for small sites to pass their mail traffic > directly to uunet and let *them* figure out the best way to *deliver* > the message. You can't expect everyone to have the same resources > that you do. Small sites are generally least able to afford to send all their mail via uunet. They should at least keep up a map of all sites within a local call or so. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/22/90)
In article <26A92ED4.4209@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > If uunet weren't a local phone call away, ... I knew it. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/23/90)
In article <269B82AE.415E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: In article <100@raysnec.UUCP>, shwake@raysnec.UUCP (Ray Shwake) writes: > As to the address formats, there are really only two that could > remotely be considered "intuitive", viz: > > user@sitename (specified user AT specified sitename) > site!...!site!user (reach user by following this path) Fine so far. However, the second is not an address. It is a route. There are many mailers that blur the distinction, but it is there nonetheless. This is not entirely right. This is a *relative* name (interview to Peter Honeyman, some issue of Unix Review of a few years back). Used as a name, it is like a japanese address: a!b!c!u says that I want to send the mail to user 'u' at the host called 'c' which is a neighbour of 'b' which is a neighbour of 'a'. It *does not* imply that the mail will pass thru 'a' and 'b' on its way to 'c', even if this is the most common intepretation. Actually, if you do not do aggressive rerouting, this may well be used as an underspecified route, e.g. something where the current host has all liberties in choosing which path to use to get to 'a', and then 'a' chooses by which path reach 'b', and 'b' gets to 'c' by any path. This is my favourite compromise between relative naming and source routing, and does blur the two a bit, but conveniently. Note that strictly speaking the relative address, even if used as a route, ought not be trimmed as you get nearer the destination, because it is a *name*, and moreover it is kind of 'absolute'; it identifies host 'c' near 'b' near 'a', and it is only ambiguous if there is another 'c' near a 'b' near an 'a'. In a sense this gives unique host naming by pattern matching instead of rooting. Let me repeat my impossible dream of the Internet switching to bang addresses, possibly underspecified source routing, and relative naming... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
tp@mccall.com (07/23/90)
In article <712@logicon.com>, Makey@Logicon.COM (Jeff Makey) writes: > > I should have been more specific: I have configured sendmail on my > Internet<->UUCP gateway to rewrite *all* headers into bang-only form > when the mail is being delivered via UUCP. The From_ line, in > particular, is rewritten, but sendmail also rewrites From:, To:, Cc:, > Reply-To:, etc. in a similar manner. If it comes from my machine via > UUCP, there are no @-signs in the headers. I realize that this > violates RFC 822, but such behavior is recommended in section 2.1 of > RFC 976 ("UUCP Mail Interchange Format Standard"): > > ``Because of the confusion surrounding hybrid addresses, we recommend > that all transport layer software avoid the use of hybrid addresses > at all times. A pure bang syntax can be used to disambiguate, being > written c.d!a!b in the first case above, and a!c.d!b in the second. > We recommend that all implementations use this "bang domain" syntax > unless they are sure of what is running on the next machine.'' Please note that in your quote from RFC976 it is talking about transport layer software. The transport layer software uses the envelope address, not the header addresses. RFC976 cites full compliance with RFC822, which explicitly prohibits the rewrite that your are performing. RFC976 gives several examples, all of which show bangpaths as envelope addresses, and unmodified RFC822 compliant addresses in headers. It does not recommend rewriting these, it forbids it! > It works, too. If you've been in on this discussion from the beginning, you'll recall that much of it derived from some of us complaining bitterly that it does not work, and we don't like being victimized in this way. > It's the sites that *don't* prepend their own names to the header > addresses that cause problems. More precisely, the problem is caused > by the fact that some sites prepend their own names and others don't. > If everybody did it, headers would all have nice complete bang-paths > in them. If nobody did it, you would only be able to reply to sites > listed in the UUCP Map. Sites that prepend their names to a bang path are doing something nice (I recommend it, in fact, as do most people in this discussion). It isn't required by RFC822, since the message in question ALREADY violates RFC822, because a pure bang path is not a valid address. It is a convention which works well (given that there is already a bang path there, I'm not referring here to the rewriting mentioned above!), but has no backing in a standard. If you want everyone to do it, get it put into a standard (of course you'll have to extend the standard to allow bang paths in the first place). Much software will then be upgraded and most sites will do this. You'll never get them all, but most sites that pass a lot of mail care at least enough to keep their software current. I even think you'll get a fair bit of support, provided you stay backward compatible. -- 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 (07/23/90)
In article <721@logicon.com>, Makey@Logicon.COM (Jeff Makey) writes: > where "bozo-site" is the UUCP name of such a site. I am not one of > these sites, but when I ship such mail out via UUCP with > > From: snoopy!fully.qualified.domain!user > > I can sleep well knowing that I am immune from such lunacy. While I > currently do this for all UUCP traffic, I am beginning to be convinced > that I should only do this if bozo-site is the next UUCP hop. Not immune, but well protected. I think you should certainly not do this for people running smart mailers. You must for people with half-wit mailers (cf. AT&T). You don't need to (and therefore shouldn't) for dumb mailers, since they ignore the headers anyway. Your definition of a bozo-site in this context is a site that knows about From: lines just well enough to destroy them, but doesn't understand RFC822. It is ridiculous that vendors are shipping such systems. I don't think we should break the whole net on their account. I'd just do the rewrites you are doing for those sites only, and not for sites that are either smart enough to cope with RFC822 or dumb enough to leave the headers alone. -- 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
kjones@talos.pm.com (Kyle Jones) (07/23/90)
Kyle Jones writes: > Eh? If it's important, then we set up a direct connection and > cut out the middleman. I mean, if you're going to make the phone > call anyway, you might as well do it right. Leslie Mikesell writes: > I'd love to. How do you set up a direct connection to BITNET sites? Well, of course there has to be a common file transfer program that runs on both systems. It doesn't have to be uucp--- kermit, xmodem or whatever will do. Once the mail file is on the other system you can inject it into the mail system, put it into the recipient user's home directory or whatever. The point I was making was that the one-time setup costs to get two systems to talk to one another are easily made up by not having to re-enter all the documents you subsequently send over the link. There's no way I'd consider using FAX for something that's going to go right back into a computer anyway.
les@chinet.chi.il.us (Leslie Mikesell) (07/24/90)
In article <3143.26a2edd9@mccall.com> tp@mccall.com writes: >Has anyone simply refused a link to a broken machine that is not and >end-node? When you get a new link and uucp the news software down to them, >send them smail too, and tell them to get registered. Also tell them that >if they don't get registered, they must remain an end node, or you will >drop your link with them. >I'll get flamed for that, but I think it is a reasonable condition. I can >give links to whoever I want, and I am doing them a favor. I feel I'm >justified in putting conditions on my favors, and I feel that that >particular condition is reasonable, since it is not too tough to get >registered. Implicit in the requirement is my help (as someone who has done >it) to get registered. If you are the primary mail feed to someone else, why not just give them a subdomain under your own domain? No one else needs to get involved at all that way. > 2) If an end-node with dumb mail software generates bad addresses > that people can't reply to, that's also his problem, he won't get > his mail. No, that's not just his own problem. The person sending the reply is also screwed. I don't agree with your terminology of "bad" addresses either. Uucp addressing is self-consistent and not "bad" unless it is passed unmodified to a system that doesn't understand it. Thus the problem is that uucp <-> internet gateways see themselves as simple forwarders instead of doing everything that is needed to correctly make the two systems understand each other. Les Mikesell les@chinet.chi.il.us
tneff@bfmny0.BFM.COM (Tom Neff) (07/24/90)
In article <720@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: >How do you know which is the appropriate host? Letting uunet handle >mail to unrecognized domains and unregistered hosts is nothing more >than a cop-out, as uunet must maintain the routing information that >you don't. No, it's more than a cop-out. UUNET pays people to do it right, and they do it in one place. I trust them more than I trust a thousand twisty little sites out there trying to keep maps up to date and in synch. Have you noticed the death of the long bang path? Read signatures. The MOST you see these days -- usually as an alternative to a FQDN -- is {bigsite1,bigsite2}!site3!site4!user i.e., two hops off the backbone. And even that's rare as more and more people register with the NIC and/or sign up with outfits like UUNET. The importance of pure UUCP route optimization today is largely local. If every site in the country maintained pathalias just two hops deep and smart-host'ed everything else, you'd never notice the difference. -- 1955-1975: 36 Elvis movies. | Tom Neff 1975-1989: nothing. | tneff@bfmny0.BFM.COM
fitz@wang.com (Tom Fitzgerald) (07/24/90)
> In article <aq3svf.axd@wang.com> fitz@wang.com (Tom Fitzgerald) writes: >> If valid RFC822 addresses weren't rewritten into ! addresses in the first >> place, this wouldn't be a problem. > [...] >> And the fact remains that not all sites prefix the path with their >> nodename. Makey@Logicon.COM (Jeff Makey) writes: > The one problem you fail to take into account is the sites (and there > are plenty of them) that rewrite > From: user@fully.qualified.domain > into the completely wrong form of > From: bozo-site!user@fully.qualified.domain Yup, this is trashed. > when I ship such mail out via UUCP with > From: snoopy!fully.qualified.domain!user > I can sleep well knowing that I am immune from such lunacy. This is better in the short run, but will still cause problems in the long run. If the mail is due to go a few more hops before it reaches its final destination, there's a fair chance that some of the intermediate hops are going to prepend their node names to the path; some are going to forget to; one may decide to gate it onto the Internet rewritten as: > From: user%fully.qualified.domain%snoopy@gateway.site The next may gate it off the Internet as: > From: gateway.site!user%fully.qualified.domain%snoopy and after a while it will be rewritten beyond recognition. I've gotten things like this more often than I want to think about. I think the moral of this is: "Changing RFC822 conformant headers to be nonconformant always does more harm than good." > While I > currently do this for all UUCP traffic, I am beginning to be convinced > that I should only do this if bozo-site is the next UUCP hop. This would be better. If you have identified such bozosites, it might be even better to start a (polite) mail campaign, getting a whole lot of people to write to them (politely) asking them to knock it off, rather than trying to compensate for one problem with a lesser problem. Your solution will make it look like your site is responsible for the failed mail, instead of the real bozosites you're covering for. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
Makey@Logicon.COM (Jeff Makey) (07/24/90)
In article <F1R44SF@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) wrote: >Pure DNS mail, for a UUCP >site, is like making all your phone calls via your long-distance carrier. and in article <714@logicon.com> I responded: >Pure DNS mail, for a UUCP-only site, is an oxymoron. After having received a couple of nastygrams about this from people who should really know better, I think I understand the confusion -- which was predicted over 2 years ago in section 2.1 of RFC 1034, "Domain Names - Concepts and Facilities": The terms "domain" or "domain name" are used in many contexts beyond the DNS described here. Very often, the term domain name is used to refer to a name with structure indicated by dots, but no relation to the DNS. This is particularly true in mail addressing. A UUCP-only site, in order to make indirect use of the DNS, must route mail to an Internet host. Such routing cannot possibly use the DNS (as defined by RFC 1034) in any way that could be construed as "pure." If, on the other hand, one considers the DNS as nothing more than a means of addressing mail (having naught to do with routing), then UUCP-only sites can easily do "pure DNS mail" by supporting only addresses of the form "user@domain.name". In a the context of a newsgroup with a name like comp.mail.uucp it was inappropriate to ^^^^ object to such usage, and I apologize for distracting us all from some of the more important topics we have to discuss. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
tneff@bfmny0.BFM.COM (Tom Neff) (07/24/90)
In article <26A76773.3660@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Ideally, in my opinion, the transport-level destination should just be a >copy of the RFC822 "To:" address, but that is currently impractical given >the number of RFC822-ignorant UUCP sites out in the world. This I regard >as an opportunity for improvement :-). This might be ideal for single user communications, but is not really practical for mailing lists. There may be dozens of destination addresses in a single transport request, while the RFC822 "To:" header in the message itself specifies only the list address. It would be awkward and obnoxious to list every individual recipient in the To: field. It would also be a waste of bandwidth to duplicate this information. (The alternative, to require a separate transport event for each recipient's copy of a mailing list issue, is even worse!) -- 'We have luck only with women -- not spacecraft!' \\ Tom Neff -- R. Kremnev, builder of failed Soviet FOBOS probes // tneff@bfmny0.BFM.COM
emv@math.lsa.umich.edu (Edward Vielmetti) (07/25/90)
In article <26A92ED4.4209@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
If uunet wants to be the Mail God, that's their business. One's enough,
though... I see no reason to devote a significant amount of my resources
to maintaining a model of the entire Usenet and affiliated networks, which
is guaranteed to be inaccurate.
Amanda, I'm sure that you would agree that if a sufficiently
reliable uunet competetor (with all the attendant services,
good people running the show, good connectivity and all that)
were to appear offering you a significantly lower cost per
month for your mail, that you'd have to consider switching.
There are considerable distance considerations to make; since
uunet is a local call for you it would have to be an extraordinarily
better system to make you switch. I know that PSI has set up
a similar hub intended to compete with uunet, and I think they
have won some customers. Anyone hoping to sell their services
to others is going to need to keep their mail setup up-to-date and
accurate. I think that's going to be more than one site, but
due to the wonders of commerce, it doesn't have to be yours.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>tp@mccall.com (07/25/90)
In article <1990Jul23.185016.7921@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <3143.26a2edd9@mccall.com> tp@mccall.com writes: >>registered. Implicit in the requirement is my help (as someone who has done >>it) to get registered. > > If you are the primary mail feed to someone else, why not just give them > a subdomain under your own domain? No one else needs to get involved > at all that way. That's always an option, but he may want his own domain. Also, doing so means my company's name is on all mail and postings emanating from his site. That implies some degree of trust that this person won't embarass me/us. It isn't obvious to anyone seeing the address that this person isn't affiliated with the company. >> 2) If an end-node with dumb mail software generates bad addresses >> that people can't reply to, that's also his problem, he won't get >> his mail. > > No, that's not just his own problem. The person sending the reply is > also screwed. I tend to think that not getting a reply to a message is most often a detriment to the original sender (the guy whose address was unreplyable when the mail was received) although that certainly isn't always the case. I tend to think that a reply is generally an answer to a question or request. In that case, it is clearly the person who asked the question and got no answer who is the worst off. In any case it is certainly less of a problem to others than a site that breaks addresses on mail that is passing through. > I don't agree with your terminology of "bad" addresses > either. Uucp addressing is self-consistent and not "bad" unless it > is passed unmodified to a system that doesn't understand it. Uucp addressing in the envelope of a message (the transport layer) is not only self-consistent and "good", it is absolutely required (by all the uucp implementations I've seen). Uucp addressing in From: lines (the topic under discussion, unless one of us is misunderstanding the other) is bad. From: lines are specified by RFC822. Uucp addresses are not rfc822 compliant. Therefore any From: line that contains a uucp address is inherently invalid. The fact that any mail systems at all understand these is because it is such a common error that people have compensated for it. It is still an error. The fact that vendors ship mail systems that ONLY work with invalid headers is a significant source of most of the problems this discussion thread has addressed. > Thus > the problem is that uucp <-> internet gateways see themselves as simple > forwarders instead of doing everything that is needed to correctly > make the two systems understand each other. Internet sites, including gateways, are not required to do anything regarding the format of mail messages except comply with RFC822. The fact that many do more is because they are nice. You certainly can't expect everyone to do more, because there isn't a standard to tell them what they should be doing. Until a standard exists that covers these situations, you can't even get agreement on what the gateway should be doing. The only fault one could find with the people running these gateways is that they've perhaps been overly generous. They've been willing to connect their standard compliant mail systems to mail systems that are not standard compliant. This may have been the initial mistake. If every site insisted that sites connecting to it must be standard-compliant, we wouldn't be discussing these problems, as they would not exist. I suggest as a compromise allowing non-compliant sites to connect, but only as end-nodes. This can cause problems, and as you point out, not only for the non-compliant site. There will be, however, fewer problems than we have now. -------- [end of reply, beginning of general statement of opinion] ------ As far as mail is concerned, the subset of the uucp mail network consisting of hosts with registered internet domains IS a part of the internet. For such hosts, mail is predictable and reliable as long as it (a) never leaves the internet (as defined here), and (b) never crosses a host that does improper (non-compliant) things to the message. The most common cause of (b) is that hosts are trying to compensate for the existance of that subset of the uucp mail network (and others) consisting of hosts that are NOT registered. (It is assumed here that an RFC822 compliant mailer is a prerequisite to having a registered domain name!) Many of these hosts make the totally erroneous assumption that all uucp connected hosts are NOT RFC822 compliant. Anyone that wants good mail service should get registered. Experience shows that complaining to people about how they handle your non-standard addresses is unlikely to do you a tremendous amount of good (there are too many people to complain at, too many different ways of handling it, and probably everyone that's tried to fix it has been told his fix is wrong at least once). For the benefit of the net as a whole, we should try to restrict the sites that cause problems to being end-nodes (to minimize the problems they can cause), or better yet, help them fix the problems. We should also try to get sites to stop rewriting messages when it isn't needed. If you have a smart mailer and your neighboring site rewrites your headers anyway, at least discuss it with them. -- 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
peter@ficc.ferranti.com (Peter da Silva) (07/25/90)
In article <15697@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: > Have you noticed the death of the long bang path? ... as more and more > people register with the NIC and/or sign up with outfits like UUNET. ... and as more and more sites run pathalias and smail. That statistic does not necessarily imply that the PSTN is useless as a transport agent, nor that the UUCP maps are useless. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
scs@lokkur.dexter.mi.us (Steve Simmons) (07/26/90)
In article <3143.26a2edd9@mccall.com> tp@mccall.com writes: >Has anyone simply refused a link to a broken machine that is not and >end-node? Yes. We cut off one local system that wouldn't get it's modems fixed -- a week of news backup did horrid things to /usr/spool. Another site simply turned their system off for weeks on end. les@chinet.chi.il.us (Leslie Mikesell) writes: >If you are the primary mail feed to someone else, why not just give them >a subdomain under your own domain? No one else needs to get involved >at all that way. There is no way in hell I want local bbss, peoples houses, and other peoples businesses appearing in my employers domain. We're a good guy and forward mail, MX, etc -- but won't list those sites as if we were organizationally responsible for them. Would you expect chinet.att.com were chinet still getting it's main feed from ihnp4?
les@chinet.chi.il.us (Leslie Mikesell) (07/27/90)
In article <3209.26adae8e@mccall.com> tp@mccall.com writes: >In article <1990Jul23.185016.7921@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: >> If you are the primary mail feed to someone else, why not just give them >> a subdomain under your own domain? No one else needs to get involved >> at all that way. >That's always an option, but he may want his own domain. Also, doing so >means my company's name is on all mail and postings emanating from his >site. That implies some degree of trust that this person won't embarass >me/us. It isn't obvious to anyone seeing the address that this person isn't >affiliated with the company. This points out the fact that using a token with a defined purpose of denoting mail administrative authority for something else is a bad idea. A mail forwarder obviously has an administrative relationship to the mail of the connected sites so it would make sense to me to make that connection visible, although perhaps not with a name that would identify the organization in other contexts. Does anyone know why uunet is phasing out the use of anymachine.uunet.uu.net where anymachine is one of their suscribers? >Internet sites, including gateways, are not required to do anything >regarding the format of mail messages except comply with RFC822. The fact >that many do more is because they are nice. You certainly can't expect >everyone to do more, because there isn't a standard to tell them what they >should be doing. Until a standard exists that covers these situations, you >can't even get agreement on what the gateway should be doing. This is exactly the problem - there is no defined way to encapsulate local syntax within an RFC822 address. Unless you believe that every mailer in the world is going to become RFC822 complaint, this is a fatal flaw. >If every site insisted >that sites connecting to it must be standard-compliant, we wouldn't be >discussing these problems, as they would not exist. I suppose X.400 complaint sites will be more careful to avoid this mistake. Les Mikesell les@chinet.chi.il.us
tp@mccall.com (07/27/90)
In article <1990Jul26.203210.25331@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <3209.26adae8e@mccall.com> tp@mccall.com writes: >>In article <1990Jul23.185016.7921@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: >>> ... why not just give them >>> a subdomain under your own domain? ... >>That's always an option, but ... > > This points out the fact that using a token with a defined purpose of > denoting mail administrative authority for something else is a bad > idea. A mail forwarder obviously has an administrative relationship > to the mail of the connected sites so it would make sense to me to make > that connection visible, although perhaps not with a name that would > identify the organization in other contexts. ... Actually, I think the administrative hierarchy inherent in domain names is in general good. I don't think my mail forwarder has any administrative authority over me. I can always get another one, and I can even pay for the service (uunet), in effect giving me administrative authority over my forwarder (if you believe, as I do, that a service provider is responsible and accountable to its customers). The up side of the administrative hierarchy is precisely the ability you first referred to of being able to administrate subdomains without anyone else being involved. My possible reluctance to do it comes less from the administrative authority I'm expected to exert over the subdomain (which is slight to say the least), as the fact that my company name would appear in his address. It's a corporate image thing. If I had a domain name for a home machine, or something of that sort, I'd very likely be willing to hand out subdomains with little or no reservation. > This is exactly the problem - there is no defined way to encapsulate local > syntax within an RFC822 address. Unless you believe that every mailer > in the world is going to become RFC822 complaint, this is a fatal flaw. You can encapsulate it just fine in the local part of a legal address. The problem is that with uucp addresses, this generates the dreaded hybrid address. If all mailers that received a hybrid address were RFC822 compliant, and all mailers that passed such an address were at least compliant enough not to alter it, it would work perfectly well. Using a pure bang-path in a From: line won't work precisely because it is not legal. There are conventions on what to do with such a thing, but they aren't universally followed, and won't be unless they are added to the standard. >>If every site insisted >>that sites connecting to it must be standard-compliant, we wouldn't be >>discussing these problems, as they would not exist. > > I suppose X.400 complaint sites will be more careful to avoid this mistake. I expect they will, since the implicit assumption seems to be that ALL email will at some future time be x.400 compliant (at least that's what it seems from what I've read). -- 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
shwake@raysnec.UUCP (Ray Shwake) (07/27/90)
tp@mccall.com writes: >Uucp addressing in the envelope of a message (the transport layer) is not >only self-consistent and "good", it is absolutely required (by all the uucp >implementations I've seen). Uucp addressing in From: lines (the topic under >discussion, unless one of us is misunderstanding the other) is bad. From: >lines are specified by RFC822. Uucp addresses are not rfc822 compliant. >Therefore any From: line that contains a uucp address is inherently >invalid. While I agree completely with your first contention, a return to first principles will clarify the common misunderstandings associated with the second part. Electronic mail as handled by UUCP involves two files: The D.* file (DATA) is the actual text of the message; the X.* file (EXECUTE) is the command file. The latter constitutes the envelope, and traditionally includes only a bang path, but may contain an address of any format acceptable by the intermediary mailer - indeed, may contain any command recognizable by the remote host. The From: line is found in the D.* file, NOT the X.* file. Such modifications of the From: line as have been discussed (and often sanctioned) in this thread violate the integrity of the message, by UUCP standards, but not by RFC-type mailers who have a different sense of "envelope" and "text". Quoting from Honeyman's January, 86 interview in Unix Review: The delivery agent should do nothing more than receive an envelope, read it, and pass it along. But *sendmail* breaks the rules not only by opening the letter and inspecting it but by actually modifying its contents. That's illegal! That's immoral! That's outrageous! How could you [Allman] possibly write a program that does that? The >From lines PREpended to the text by intermediary UUCP- conformant mailers provide supplementary information, and do not constitute violations of the text. Validity, therefore, depends on the rules of the environment. Smart mailers operating in a UUCP environment which attempt to conform to RFC rules typically end up violating UUCP rules.
karl_kleinpaste@cis.ohio-state.edu (07/30/90)
shwake@raysnec.uucp writes:
While I agree completely with your first contention, a return to
first principles will clarify...
No offense, but seeing that opener makes me think, "oh, spare me..."
Electronic mail as handled by UUCP involves two files: ...
Yes, but my mail transports here involve considerably more than UUCP.
I use sendmail as a transport-independent router. Mail comes in via
four transports; it goes out by a choice of five. Most sites have
similar problems, that they can't discuss email "as handled by UUCP,"
because it's not productive to leave the transports wholly separated
as you seem to suggest.
By the time mail gets into sendmail, I no longer concern myself with
the transport by which it arrived. I am deciding the transport by
which it should leave. I make decisions based on how the recipient
will react to things, not how the sender viewed it. An example:
So I get mail on the transport commonly called UUCP; rmail picks it up
during uuxqt, showing an envelope origin of "thatsite!user" and a
destination of "osu-20!JoeSchmo", and...and...and it's supposed to
head out of here via SMTP to the DEC-20 down the hall, BUT Bozo
Originating User didn't put FQDNs in either his envelope or headers.
BOGON ALERT: That DEC-20 runs MAISER and gets really uptight because
It Believes In The RFCs ("Do YOU believe, brother?" "I *BELIEVE*!"),
and (can you guess?) your mail won't get delivered UNLESS I hack BOTH
the envelope AND the header.
Less catastrophic examples abound -- I see a lot of $#!+ flow through
here. UUCP does not exist in isolation. If it did, you would have a
point; it doesn't, you don't.
Existence proof.
[quoting Honeyman's UNIX Review interview:]
The delivery agent should do nothing more than receive an
envelope, read it, and pass it along. But *sendmail* breaks
the rules not only by opening the letter and inspecting it
but by actually modifying its contents. That's illegal!
That's immoral! That's outrageous! How could you [Allman]
possibly write a program that does that?
Easy. I _expect_ that both the envelope and headers are going to be
broken and unreplyable; see above. I make a very good attempt at
seeing to it that what leaves my system is replyable.
Validity, therefore, depends on the rules of the environment.
Yes, it does. The problem is that UUCP must co-exist within an
environment that includes the Internet, even though it sometimes seems
to believe it exists by itself.
--karlpeter@ficc.ferranti.com (Peter da Silva) (07/31/90)
In article <KARL.90Jul30112619@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: > Easy. I _expect_ that both the envelope and headers are going to be > broken and unreplyable; see above. What, because the DEC-20 down the hall violates the common sense guideline (be conservative in what you generate, be liberal in what you accept) you jump to the conclusion that everyone does? The number of unreplyable messages that *I* get are tiny... most bounces seem to be caused by temporary hardware or resource problems. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
karl_kleinpaste@cis.ohio-state.edu (08/01/90)
peter@ficc.ferranti.com writes:
What, because the DEC-20 down the hall violates the common sense
guideline you jump to the conclusion that everyone does?
You're evidently on a "pure leaf" site, Peter. How easily you seem to
conclude that I'm making these sorts of decisions rashly.
I don't jump to that conclusion. I walk there slowly through a fair
amount of experience. Yes, I expect broken headers and envelopes all
the time. My syslogs show quite clearly that I can expect as much
broken garbage as cleanliness.Makey@Logicon.COM (Jeff Makey) (08/01/90)
In article <8M-4O=A@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >What, because the DEC-20 down the hall violates the common sense guideline (be >conservative in what you generate, be liberal in what you accept) you jump to >the conclusion that everyone does? It seems to me that Karl has delegated the "DEC-20 down the hall"'s obligation to be liberal in what it accepts to some other machine. This doesn't seem any worse than, say, delegating the resolving of domain names to uunet. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
peter@ficc.ferranti.com (Peter da Silva) (08/01/90)
In article <734@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: > It seems to me that Karl has delegated the "DEC-20 down the hall"'s > obligation to be liberal in what it accepts to some other machine. I'm not worried about what the DEC-20 down the hall does. It's when people start munging headers on the way to machines they don't *know* need it that bothers me. Particularly when Ohio State and UUNET *both* munge headers, but in exactly opposite ways, and with the explanation that they have found empirically over time that it works better that way. At least UUNET will quit munging if you ask them to. I mean, Karl makes a good case. I'm not going to argue about it any longer. I just worry about it... because UUNET makes a good case too. Sigh. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
les@chinet.chi.il.us (Leslie Mikesell) (08/10/90)
In article <KARL.90Jul31130726@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >I don't jump to that conclusion. I walk there slowly through a fair >amount of experience. Yes, I expect broken headers and envelopes all >the time. My syslogs show quite clearly that I can expect as much >broken garbage as cleanliness. Around here, at least half of the mail traffic has the header and envelope generated automatically by a user agent as a "reply" to something that has been received. If these come out "broken" it's because something in the transport re-wrote something incorrectly. Have you made an effort to see if the broken stuff is on its first pass through the site or if any of it is coming back as replies based on headers that may have been altered on the way there? Les Mikesell les@chinet.chi.il.us
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/11/90)
In article <1990Aug09.183952.14944@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > > Around here, at least half of the mail traffic has the header and > envelope generated automatically by a user agent as a "reply" to > something that has been received. If these come out "broken" it's > because something in the transport re-wrote something incorrectly. Some return address problems are caused by MUAs, not MTAs. There are very old bugs in the stock 4.3BSD Mail that cause it to destroy perfectly reasonable but long or complicated return addresss. There are also some wonderful features in SVR3.2 /bin/mail and mailx. Vernon Schryver vjs@sgi.com