PKARP@IU.AI.SRI.COM (Peter Karp) (04/06/88)
An optimal solution may be to parse "x!y@z" both ways and determine which of the hosts z and x are known by the local host. This provides a way of disambiguating the syntax. Peter -------
jbs@fenchurch.MIT.EDU (Jeff Siegal) (04/06/88)
In article <12821@brl-adm.ARPA> PKARP@IU.AI.SRI.COM (Peter Karp) writes: >An optimal solution may be to parse "x!y@z" both ways and determine >which of the hosts z and x are known by the local host. This provides >a way of disambiguating the syntax. What if both hosts are known? Also, if you're talking about a gateway machine between two or more networks, the hostnames may well be ambiguous. Jeff Siegal
jsloan@wright.EDU (John Sloan) (04/06/88)
in article <12821@brl-adm.ARPA>, PKARP@IU.AI.SRI.COM (Peter Karp) says: > An optimal solution may be to parse "x!y@z" both ways and determine > which of the hosts z and x are known by the local host. This provides > a way of disambiguating the syntax. Doesn't the name space of UUCP and ARPANET (and nearly everyone else) overlap? Isn't that the reason for RFC920 domains (and earlier, RFC882 domains like wright.CSNET)? A more fundemental question is where is user y? Unless by some concidence the same user is on both x and z, then if you make the wrong decision, either the mail will be bounced by x's or z's mailer or it will be delivered to the wrong person who just happens to have the same name (like postmaster or root). If both hosts are known to the system, then how do you decide how to route? Even if you're only considering local hosts, like UUCP sites one hop away and local TCP/IP hosts, you still have to make a (potentially wrong) decision. And if you're into using pathalias and name servers on your mail gateway machine, then it's highly likely that x and z will both be "known" to you (read: both will be potential targets, whether they are local machines or not). In this case, how do you evaluate which choice to make? The only way I can think of other than having a simple default (like always choosing z) is on the basis of cost. For example, your UUCP link may be a local phone call, and your internet link may be a long distance call to the CSNET/Phonenet relay. Making a decision on this basis doesn't mean you'll make the correct decision, it just means that the cost of wrong decisions may be minimized. A similar approach (and one I am considering, when our computer center brings up their BITNET link) is routing everything questionable through another deparment's network connection and let them pay the bills for your mistakes. -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
Lennart_Lovstrand.EuroPARC@Xerox.COM (04/08/88)
Sorry, that won't work either. Two examples: 1) Localhost is connected to two machines 'unics' and 'relayhost', but does not have access to any name server. It does, however, know that 'relayhost' can take care of most unknown addresses. In comes now the following address: unics!gobblygook@acme.com Should this be sent to the local 'unics' just because there happened to be one in the neighborhood? I say no, it is just as plausible that acme.com also has a local machine called 'unics' and that the message should be sent to 'relayhost'. 2) Localhost is both on the Internet and the UUCP network and has access to bind. In comes the following addresses: rambo.gov!gobblygook@state.edu Both rambo.gov and state.edu are on the Internet and are therefore known to localhost; to which destination should it send the message? It's not even safe to use different parsing strategies depending on from what network the message came, as UUCP more and more is adopting domain style addressing. The answer is that there is no patent proof way of disambiguating the mixed !/@ syntax. Heuristics may help, yes, but as long as these hybrid addresses are being used there will always be confusion and misunderstanding by the people and machines that have to deal with them. Only by persuading one of the communities to adopt the other's standard can we get rid of this pain -- or by scrapping them both and universally start using something like X.400. In the mean time, I think it's better to keep a firm parsing policy which favors exactly one of the above -- and if you're connected to the Internet, you know which one to choose. :-) --Lennart