lamy@ai.utoronto.ca (Jean-Francois Lamy) (06/28/89)
Karl's solution is purely syntactic; in such a case short-circuiting uucp1!uucp2!uucp3!domain.name!user into domain.name!user is not necessarily a good idea if domain.name happens to be a UUCP-only site... You may be closer to domain.name than the official forwarder, and you leave users no way to route around broken forwarders (such things do happen). A solution to this problem would likely have to be far more involved (and I'm ignoring things like the fact that it is often the case that uucp3 will know how to rewrite headers to please domain.name, whereas you may end up generating addresses that they won't like one bit). To reiterate: a domain name does not imply direct internet connectivity. The canadian domain, .Ca, contains machines that are exclusively on Bitnet (oups, NetNorth/CardPunchNet :-), CDNNET (X.400), UUCP and the Internet. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (06/28/89)
My solution, while purely syntactic, is nonetheless correct for bona fide, registered domains. If there exists a `.' somewhere in a !-path, then that is an absolute address from that entity rightward. A problem with a dead MX forwarder not responding is, quite frankly, not my problem - if someone's MX is dead, s/he had better find a way to get a different MX fast or there will be surely hell to pay for far deeper and more important reasons than my particular preference to short-circuit !-paths to the rightmost domain. As for rewriting headers in a way palatable to the destination by a UUCP neighbor, that is not an acceptable reason for requiring respect of the !-path. If the entity is a valid domain, then anyone on the (physical, IP-based) Internet may send mail to user@domain.name (possibly via the MX, if the domain.name is not IP-connected) and expect that The Right Thing will happen - such special cases cannot be enforced by anyone, and I see no reason to try. My preferred transport is "Internet via domain-based addressing" (modulo the special cases of our immediate UUCP neighbors, in which case it becomes "UUCP via domain-based addressing"), and if mail is going to pass through my machines, then it's going to be treated in like manner. I am a Domain Absolutist, for which I do not apologize. The critical point of my short-circuit is nothing more than the observation of both `.' and `!' in a !-path. --Karl
woods@ncar.ucar.edu (Greg Woods) (06/29/89)
The problem with short-circuiting bang paths is that YOU DO NOT KNOW WHAT EVERYONE IS DOING, and there may be a very good reason why the path is the way it is. For example, if you look up the MX record for "*.fidonet.org", which is a valid, registered domain, you will see that it points at my machine handies.ucar.edu. We, however, do not have a direct connection to everyone in fidonet.org. No one on the Internet does. So what do I do? I generate a BANG PATH. This means that addresses that look like user@f###.n###.z#.fidonet.org get sent to handies, which converts them into a form like path!to!appropriate!fidogateway!f###.n###.z#.fidonet.org!user. Now, take a guess what happens if some too smart site tries to short-circuit the bang path? Can you say infinite loop? In fact, what was once a trivial service to provide for the Fidonet folks is now becoming a real pain, precisely because some sites insist on short-circuiting bang paths. I have to find out which sites these are (always the hard way) and then mark them DEAD in my pathalias database. Please, DON'T reroute explicitly-specified paths!! I am sure that fidonet.org is not the only valid domain that does something like this. Thanks. --Greg
matt@oddjob.uchicago.edu (Matt Crawford) (06/29/89)
I still disagree with Greg, even though I gave in (for now) and altered my sendmail rules to accommodate fidonet.org and another domain that had the same problem. I think that if fidonet or anyone else wants to have mail from the internet enter their realm at a point chosen by them, then they should provide a person (or some automated tool) to keep up the MX records at the required level of detail. The domain's nameserver does not need to be on the same host as any of the MX records point to. In fact, in fidonet.org's case they aren't. They're at orst.edu. Some fidonet ruler ought to replace the single all-encompassing wildcard record with a more detailed set. Mail for each zone or subnet can then be handed directly to a willing internet- to-fidonet forwarder by any internet site, and each such forwarder can confidently inject all received fidonet mail at the nearest fidonet entry point. Side questions: Is fidonet not fully connected internally? If they are not, then how do they forward among disjoint components? Not over the internet, I hope! And if they are fully connected internally, why should the UUCP or internet world be expected move fidonet's mail around when fidonet is capable of, but not willing to, do so itself? ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu
woods@ncar.ucar.edu (Greg Woods) (06/29/89)
In article <4147@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >I think that if fidonet or anyone else wants to have mail from the >internet enter their realm at a point chosen by them, then they should >provide a person (or some automated tool) to keep up the MX records at >the required level of detail. I agree that they "should" do this, but in the net world, where people are often maintaining the software unofficially in their "spare" time, lots of people do things that just get the job done without necessarily being the "best" way to do it. That is the reality we live in. We all depend on other sites to provide service for us without any benefit to themselves; without this, the net as it is now couldn't exist. I don't know about anyone else, but my philosophy is always to ask for the lowest level of service that is absolutely necessary to get the job done. To do as Matt suggests above would require either asking for access to the orst.edu machine or having someone there willing to do frequent updates for them. If it were my machine providing that service, I wouldn't like being asked (in fact, I was already asked to install patches to the UUCP maps to get Fido nodes reachable faster than the usual map posting procedure and I refused because I didn't want to make the time commitment. And I can imagine what my bosses would say if they actually went so far as to ask for an account on the machine!) The only reason I agreed to provide routing service for them is because it was trivial to implement and requires no maintenance on my part (or didn't, until sites started doing aggressive rerouting!) All the maintenance is done by their gateway administrators who post appropriate map entries. I wonder how many domains would fall apart if we made them all maintain complete MX information like they "should" do? --Greg
lear@NET.BIO.NET (Eliot Lear) (06/29/89)
Imagine, a message from someone at Princeton to a person at a fidosite at Rutgers has to pass through ncar, go all the way to San Francisco, and then back through the phone lines to New Jersey? Now that's efficient. -- Eliot Lear [lear@net.bio.net]
lmb@vicom.com (Larry Blair) (06/29/89)
In article <4147@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes:
=I think that if fidonet or anyone else wants to have mail from the
=internet enter their realm at a point chosen by them, then they should
=provide a person (or some automated tool) to keep up the MX records at
=the required level of detail.
I think you've missed a more important reason: cost. Suppose I have
my uucp site registered, with uunet as my forwarder. If you short circuit
bang paths you may either cost me $1.50 for a daytime delivery or hold
up my mail until uunet calls me at night.
This is a tired, old, subject. Don't reroute, it's RUDE.
--
Larry Blair ames!vsi1!lmb lmb@vicom.comjbaltz@cunixc.cc.columbia.edu (Jerry B. Altzman) (06/29/89)
In article <1989Jun28.215826.19489@vicom.com> lmb@vicom.COM (Larry Blair) writes: > >This is a tired, old, subject. Don't reroute, it's RUDE. Damn straight. I send mail often from a site that ends up routing it's uucp mail through rutgers. I send mail, rutgers looks ahead, decides that the wendy that I'm sending mail to is the one at Wellesley College, instead of the one *I* wanted to send mail to, somewhere near San Jose... If I remember, about 2 years ago, Paul Vixie (from decwrl at the time; anyone know where he is?) went on a "no reroute" tirade. Any mailer that reroutes my *explicitly* routed mail should be taken out and shot. :) These are definitely my opinions, and not Columbia's. >-- >Larry Blair ames!vsi1!lmb lmb@vicom.com I don't speak for Columbia, and Columbia doesn't speak for me. /jerry altzman -- jerry altzman "We've got to get in to get out" 212 854 3538 jbaltz@cunixc.cc.columbia.edu jauus@cuvmb (bitnet) ...!rutgers!columbia!cunixc!jbaltz (bang!) NEVIS::jbaltz (HEPNET)
gmp@rayssd.ray.com (Gregory M. Paris) (06/29/89)
Just to note a case where short-circuiting uucp paths to the rightmost
domain doesn't work:
hop!abc.xyz.com!node.decnet!user
I see these things all the time. I believe something called Ultrix
generates them. :-) If you short circuit to the rightmost domain,
then letters so addressed cannot be delivered. Isn't the ultimate
goal to provide better service?
Since this is uucp we're talking about, I don't think you can say that
node.decnet or node.dnet is illegal, though I'd agree heartily that it's
ugly and disgusting.
--
Greg Paris <gmp@ray.com>
{decuac,necntc,uiucdcs,uunet}!rayssd!gmp
"You! What planet is this?!"matt@oddjob.uchicago.edu (Matt Crawford) (06/30/89)
Jerry B. Altzman rants: ) I send mail, rutgers looks ahead, decides that the ) wendy that I'm sending mail to is the one at Wellesley College, instead of ) the one *I* wanted to send mail to, somewhere near San Jose... Are you following the topic carefully, Jerry? The rest of us are talking about skipping ahead in the bang path only to a fully- qualified domain name. This cannot possibly cause the problem you complain about. In fact, sometimes it will prevent the problem! ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu
matt@oddjob.uchicago.edu (Matt Crawford) (07/04/89)
) Matt Crawford sez: ) >I think that if fidonet or anyone else wants to have mail from the ) >internet enter their realm at a point chosen by them, then they should ) >provide a person (or some automated tool) to keep up the MX records at ) >the required level of detail. And Greg Woods sez: ) I agree that they "should" do this, but in the net world, where people ) are often maintaining the software unofficially in their "spare" time, lots ) of people do things that just get the job done without necessarily being the ) "best" way to do it. ... ) We all depend on other sites to provide service for us without any benefit ) to themselves; ... my philosophy is always to ask for the lowest level ) of service that is absolutely necessary to get the job done. To do as Matt ) suggests above would require either asking for access to the orst.edu machine ) or having someone there willing to do frequent updates for them. You're interpreting this situation as if it were some project of your own and you are asking ORST for a favor. It's the other way around - Fidonet asked ORST for one favor and you for another, but is not providing the effort they should to make it all work. As a consequence, you, I, and others wind up having to provide them MORE than "the lowest level of service that is absolutely necessary to get the job done." If the Fidonet people can keep their UUCP maps up to date, then they can keep MX records up to date at an equal level of detail. And they should, if they want to work with the internet community. ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu
woods@ncar.ucar.edu (Greg Woods) (07/08/89)
> Matt Crawford sez: > If the Fidonet people can keep their UUCP maps up to date, then they can > keep MX records up to date at an equal level of detail. I do not believe that this is true. Consider this example: suppose a path to one of the Fido subzones (a real-life example, BTW) looks like ncar!asuvax!stjhmc!%s How does one take this and determine that "asuvax" happens to be the rightmost host in this path on the Internet, and therefore that the MX record should point to asuvax (and while we're at it, that the real name of "asuvax" is "asuvax.eas.asu.edu")? And how does one then insure, without asking the site admin of asuvax (and all the other 100 hosts that will have MX's pointing at them) that mail addressed to that Fido subzone will be properly delivered to stjhmc? Answer: you can't. Actually I shouldn't say that what Matt says "isn't true", it's just "incomplete", because he leaves out the fact that it would be orders of magnitude more work to do it this way and would require the cooperation of dozens of people instead of just one or two as the current method does. My feeling on it is that whether they "should" do it with 100 MX records or not, until someone can point out an official Internet document (RFC?) that specifically prohibits the way they are doing it now, is just a religious argument. --Greg
lear@NET.BIO.NET (Eliot Lear) (07/08/89)
Greg Woods says: > ncar!asuvax!stjhmc!%s > > How does one take this and determine that "asuvax" happens to be the > rightmost host in this path on the Internet, and therefore that the > MX record should point to asuvax (and while we're at it, that the real name > of "asuvax" is "asuvax.eas.asu.edu")? net> uuhosts asuvax UUCP mail path from bionet to asuvax: asuvax: asuvax.eas.asu.edu!%s UUCP mail information for host asuvax (#USENET lines show USENET news links): #Name asuvax #System-CPU-OS VAX-11/780, 4.3BSD-tahoe #Organization Arizona State University, Engineering Computer Services #Contact Marc Lesure #Electronic-Address ncar!noao!asuvax!lesure, or lesure@asuvax.asu.edu #Telephone (602) 965-7873 #Postal-Address Tempe, AZ 85287-5206 #Latitude-Longitude 33 25 N / 111 56 W city #Remarks aka asu.edu on CSNET/ARPA #Written-by web per Marc Lesure 04/08/89 #USENET noao # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv asuvax = asuvax.eas.asu.edu, enuxva.eas.asu.edu <*<*<*<*<*<*<*<*< ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ asuvax anasaz(POLLED), apciphx(POLLED), btc(POLLED), enuxha(LOCAL), gtephx(POLLED), hrc(POLLED), mcdphx(DAILY), noao(DEDICATED), sssphx(EVENING), stjhmc(POLLED), xroads(EVENING) Of course, one must now make a check to see if an A record exists.
woods@ncar.ucar.edu (Greg Woods) (07/13/89)
In article <Jul.7.21.34.59.1989.1538@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >asuvax = asuvax.eas.asu.edu, enuxva.eas.asu.edu <*<*<*<*<*<*<*<*< >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Of course, one must now make a check to see if an A record exists. And how, pray tell, does one do this if one does not have an Internet connection? That is what the Fido folks are faced with. This discussion was in response to a statement that the Fido folks could just as easily maintain an MX database as a UUCP paths database. Without an Internet connection, that just ain't so. --Greg
matt@oddjob.uchicago.edu (Matt Crawford) (07/14/89)
) >Of course, one must now make a check to see if an A record exists.
Greg Woods writes:
) And how, pray tell, does one do this if one does not have an Internet
) connection? That is what the Fido folks are faced with.
Gimme a break, Greg! Their (currently rudimentary) MX database is
installed on a machine with an internet connection, ISN'T IT????
Mattwoods@ncar.ucar.edu (Greg Woods) (07/14/89)
In article <4426@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >Gimme a break, Greg! Their (currently rudimentary) MX database is >installed on a machine with an internet connection, ISN'T IT???? Yes, but THEY DO NOT HAVE ACCESS to this machine! In other words, unlike in the case of maintaining routing via the UUCP maps, they have to depend on SOMEONE ELSE to do the work. This is a VERY IMPORTANT difference! --Greg
matt@oddjob.uchicago.edu (Matt Crawford) (07/18/89)
(Greg and Matt are still at it ...) ) >Their MX database is ) >installed on a machine with an internet connection, ISN'T IT???? ) ) Yes, but THEY DO NOT HAVE ACCESS to this machine! Their MX data flows INTO the machine. With a dab of effort they could either first get out the relevant "A" data before preparing their MX data, or they could send in a canned script to produce the MX from the A. The people invloved in maintaining the domain fido.org are not doing what I think they should do. Greg thinks the rest of us ought to arrange things so that groups like FIDO can get by with a bare (sub-) minimum of effort. I think we'll continue to disagree. ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu