🚀 go-pugleaf

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

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.

Since the case of x!y@z is ambiguous, isn't the right thing to do to
bounce the letter, preferably with a message stating that the address is
ambiguous?  The fault can be attributed to whoever generated the address,
so why not just send it back?  This seems like the right thing to do; At
least the sender will *know* what happened to the letter, rather than
having it potentially get lost at a bad address.

Aren't there other ambiguous cases?  I can't think of any off the top of
my head, but what do people usually do with ambiguous addresses?
-- 

Mark Sirota
 msir_ltd%tut.cc.rochester.edu@cs.rochester.edu (rochester!ur-tut!msir_ltd)

> 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.

Yes, Peter Honeyman wrote a paper on doing just that (including heuristics
to disambiguate in case there wasn't an obvious answer in terms of simple
connectivity).  It's entertaining reading, but frankly, I think this is
a very bad idea in practice.  Basically, the only solution is to resolve
the issues at the RFC level and get everybody fixed up who does it wrong.

RFC976 and smail is a very good pass at it, but even in that case, it has
some problems with embedded "%" in the case of an unregistered machine
(one without a proper domain address).  If everyone gets domain addresses,
the problem disappears (as long as RFC976 and the other RFCs are obeyed).

John Diamant
SDE				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett-Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO