phil@amdcad.UUCP (Phil Ngai) (01/08/87)
I used to send mail to decwrl!dec-site!person and it worked fine.
Return mail would come back through decwrl just like it was supposed
to. Now I am phil@amdcad.amd.com, which decwrl thinks is an Internet
site. Decwrl looks us up and discovers that sun is the approved
gateway to us and ships my mail to sun which finally sends it to me.
Now all my mail from DEC's enet gets to pass through an extra site,
sun, to get to me. Obviously an improvement. (sarcasm)
I hate smail.
--
Butter and salt can make almost anything taste good.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comschoff@rpics.RPI.EDU (Martin Schoffstall) (01/08/87)
I'd imagine that it is because decwrl either isn't running the domain-server or its sendmail can't handle MX records or its .cf file doesn't support them well. Probably the latter. Its done by SUN, RPI and a million others in between. You should probably flame at decwrl. -- marty schoffstall schoff@csv.rpi.edu seismo!rpics!schoff
david@ukma.ms.uky.csnet (David Herron, NPR Lover) (01/10/87)
In article <14239@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >... Now I am phil@amdcad.amd.com, which decwrl thinks is an Internet >site. Decwrl looks us up and discovers that sun is the approved >gateway to us and ships my mail to sun which finally sends it to me. The first thing is I see in the current map that the d.* files lists a gateway for .amd.com ... so far so good. Now, when decwrl gets your message it has two choices of how to route your message ... one is the MX record which sun is maintaining for you (which causes the routing over the internet), and the other is the uucp route. It's possible their sendmail configuration does not allow them to take those two choices into consideration. It's also arguable that relaying mail over the Internet is more reliable (in the general case) than relaying over a UUCP route. For what cases does it make sense to prefer the MX record over the UUCP route (or vice versa)? In MMDF the decision is wired into the tailoring file depending on which channel I mention first. (If I mention the SMTP channel first (and *if* we were on the Internet) then the MX record would take precedence ... that is barring the authorization stuff from saying no-no to a route over the Internet). -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet (I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...) "Don't put your money in South Africa -- Give it to me!" -- Cerebus
emc@unicus.UUCP (Eric M. Carroll) (01/13/87)
david@ukma.ms.uky.csnet (David Herron, NPR Lover) writes: > > Now, when decwrl gets your message it has two choices of how to > route your message ... one is the MX record which sun is maintaining > for you (which causes the routing over the internet), and the other > is the uucp route. > > It's possible their sendmail configuration does not allow them to > take those two choices into consideration. I happen to quite like smail. David and Phil have pointed out a special case of a problem that smail does not address. The problem is that given an address (NOT a uucp-style explicit routing path) the address must be resolved into TWO things: a route and a *transport mechanism*. Right now, if you don't run sendmail, you are stuck. sendmail's way of resolving this problem with psuedo-domains (.ether, .tcp, .csnet, .uux, etc) is bogus, and quite frankly, still a mystery to me (we run sysV). Really what I need is a table that associates a domain to my prefered transport mechanism (ie resolve the physical network to be used), then does the routing lookup inside the associated connection graph for that physical network. That way, if a site or gateway is a member of more than one physical network, it can have a priority scheme of how to send things. I like the trend towards domaining very much, but due to its ARPA origins in a homogenous physical network, the difficulties of a multi-connection site were not fully resolved. smail simply reflects this fact, but in a uucp enviroment instead. PS: Any arpa sites with x.25 out there? ----------------------- Eric Carroll Unicus Corporation, Toronto Ont. {utzoo!utcs!yetti, seiemo!mnetor}!unicus!emc maybe soon: emc@unicus.com (Any ARPA sites with x.25 out there?)
greg@ncr-sd.UUCP (Greg Noel) (01/16/87)
In article <467@unicus.UUCP> emc@unicus.UUCP (Eric M. Carroll) writes: >..... the address must >be resolved into TWO things: a route and a *transport mechanism*. .... Really >what I need is a table that associates a domain to my prefered transport >mechanism (ie resolve the physical network to be used), then does the routing >lookup inside the associated connection graph for that physical network. We at NCR modified smail to do something like this. But we used a trick to embed the routing network directly into the pathalias output. We just define a connection to each physical network with a routing cost of HIGH; e.g., ncr-sd via-ethernet:(HIGH) and then define our actual connections as originating in this artificial site: via-ethernet neighbor(DEMAND) (For external consumption, a script converts the via-ethernet to ncr-sd, so the rest of the world sees the description in a reasonable way.) The resulting pathalias output for neighbor is: neighbor via-ethernet:neighbor!%s Our version of smail uses this line to invoke the ethernet mailer to send mail to neighbor. (If you don't specify a mailer, a default mailer is selected.) The description of the mailer invocations is contained in a configuration file, so it is easily changeable without recompilation (or sources, for that matter). There is no default knowledge of the UUCP network; all such knowledge is in the configuration file. Before you ask, no, you can't get the modified smail from us. But we have sent the modifications to Larry Auton, so it might eventually see the light of day in an official distribution. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
phil@amdcad.UUCP (Phil Ngai) (01/16/87)
In article <467@unicus.UUCP> emc@unicus.UUCP (Eric M. Carroll) writes: >Really >what I need is a table that associates a domain to my prefered transport >mechanism (ie resolve the physical network to be used), then does the routing >lookup inside the associated connection graph for that physical network. No, you're making the same mistake that I complained about originally. You need to associate a transport mechanism with an *address*, not a domain. My site (amdcad) is in the .COM domain but that does not mean we are on the ARPA Internet, much to the surprise of many people's mailers. -- Warning: the California AAA is pursuing a policy which would spend gasoline taxes on mass transit instead of roads. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
david@ukma.UUCP (01/16/87)
In article <467@unicus.UUCP> emc@unicus.UUCP (Eric M. Carroll) writes: >david@ukma.ms.uky.csnet (David Herron, NPR Lover) writes: > Really >what I need is a table that associates a domain to my prefered transport >mechanism (ie resolve the physical network to be used), then does the routing >lookup inside the associated connection graph for that physical network. >That way, if a site or gateway is a member of more than one physical >network, it can have a priority scheme of how to send things. interesting ... this is very nearly what MMDF does ... In MMDF you first have a group of tables describing the known domains. There's some additional code to help in finding partial cases (for instance, if you just say "seismo" to mmdf and you have a .css.gov table which says "seismo" in it you'll find seismo.css.gov -- it finds the first instance in the first table). The domain tables relate an arbitrary name to an official name... That is, you can have a uucp domain table entry which says "seismo: seismo.css.gov" meaning that you know about seismo.uucp which is really seismo.css.gov. The other half is in the channel tables ... A channel program is associated with each physical medium over which you can route mail. To each channel you attach a table which says which domains you can send mail to through that channel. To continue the example, there's an entry in the uucp channel saying "seismo.css.gov: cbosgd!seismo!%s". You can mention the domain name in multiple channels if you like ... Normally it chooses the first channel which mentions the the domain name, however there is an authorization feature which blocks users/hosts from sending mail through certain channels. (I don't know enough about this feature (yet) to really know how it works). -- ----- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet ----- (also "postmaster", "news", "netnews", "uucp", "mmdf", and ...) ----- (and the Usenet map maintainer for Kentucky.) ----- "Don't put your money in South Africa -- Give it to me!" -- Cerebus
emc@unicus.UUCP (Eric M. Carroll) (01/17/87)
phil@amdcad.UUCP (Phil Ngai) writes, quoting me: >>Really >>what I need is a table that associates a domain to my prefered transport >>mechanism (ie resolve the physical network to be used), then does the routing >>lookup inside the associated connection graph for that physical network. > > No, you're making the same mistake that I complained about originally. > You need to associate a transport mechanism with an *address*, not a > domain. My site (amdcad) is in the .COM domain but that does not mean > we are on the ARPA Internet, much to the surprise of many people's > mailers. But that is my point. .com implies nothing about how to get there. You cannot associate a transport mechanism to the address "Eric.M.Carroll@bar.foo.unicus.com" because you know nothing of the structure of the Unicus Zone. You will, however, recognize the domain .unicus.com, because we are both registered in the Uucp Zone. Thus you have an implicit transport mechanism (uucp, which is assumed by smail) and a route (from the pathalias database). Your problem is one of a multi-connection site not knowing that it shared a zone with you. Say I am on an x.25 network, ethernet and uucp. When I recognize a domain, say ".c.d" in the address "user@a.b.c.d" I now need two more things: what to use to get there, and how to send it. I know about an internal Unicus Zone (possibly all on the ethernet, but not necessarily) and all its subdomains (I am the authority for it), gateways connected to the x.25 network and gateways available via uucp (registered in the uucp Zone). So recognizing the gateway then allows me to find a transport mechanism (ie. the common physical connection, possibly multi-hop), and a route over it. If there is no common connection, it is unreachable, and perhaps I shouldn't know about it; either way I kick it up to the ".d" authority in one of the Zones I am registered in, or ask a specially designated peer (a domain server) who to send it to instead of really delivering it. What you saw was a "punt" decision reached without resolving the domain with respect to all the domains that the gateway in fact knew about. And that is because things like smail and sendmail have built-in assumptions about what transport mechanism to use, and getting around that requires unpleasant special-casing. The concept of one domain to one network is still with us from the origins of domaining in the Arpa community - it really was a homogenous enviroment there, and the assumption was valid. It is not valid any longer. Sorry for the length, but I wanted to make this clear. If I have misunderstood something, I need to find out about it! Eric Carroll Unicus Corporation, Toronto Ont. {utzoo!utcs!yetti, seismo!mnetor}!unicus!emc maybe soon: emc@unicus.com (Any ARPA sites with x.25 out there?)