oneill@ulowell.ulowell.edu (Brian 'Doc' O'Neill) (06/11/91)
Sigh. I am still trying to get Sendmail 5.65b/IDA working as a DECnet/Internet mail gateway. Here is the setup: MicroVAX-II running Ultrix 4.1 and sendmail5.65b/IDA1.4.3, called "ulowell", DECnet node name "DGATE". MicroVAX-II running VMS 5.4-1, called condor. Domain is ulowell.edu. condor is listed in the DECnet nodes database. I also have this entry in a mailertable database: Dmail:%s .DNET And this entry in a domaintable database: condor.dnet.ulowell.edu condor.dnet All mail to condor.dnet.ulowell.edu is forwarded via MX record to ulowell. When run in address test mode, with "user@condor.dnet", it seems to work fine, with Ruleset 26 reporting the use of Dmail. However, given the fully-qualified name of "user@condor.dnet.ulowell.edu", Ruleset 8 strips the ".dnet.ulowell.edu" off the end, apparently when it uses the resolver to fully qualify the address. As a temporary hack, I modified the configuration to look in domaintable first, it tested properly, but still does not deliver the mail in reality. Any ideas? -- ======================================================================= Brian O'Neill - Systems Manager, Computer Science, University of Lowell Internet: oneill@ulowell.edu (508) 934-3645 UUCP: harvard!ulowell!oneill
rickert@mp.cs.niu.edu (Neil Rickert) (06/11/91)
In article <1991Jun10.182322.24341@ulowell.ulowell.edu> oneill@ulowell.ulowell.edu (Brian 'Doc' O'Neill) writes: > >When run in address test mode, with "user@condor.dnet", it seems to work >fine, with Ruleset 26 reporting the use of Dmail. However, given the >fully-qualified name of "user@condor.dnet.ulowell.edu", Ruleset 8 strips the >".dnet.ulowell.edu" off the end, apparently when it uses the resolver to It sounds like a combination of the following: 1. An entry in /etc/hosts (or in your YP hosts map) of the form 1.2.3.4 condor condor.dnet.ulowell.edu and 2. A broken gethostsbyname() which looks in your hosts table/map before consulting your name server. If this is the case, do yourself a favor and build a resolver library from the bind 4.8.3 sources, then use that library for building your sendmail. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
brw@hertz.njit.edu (Brian White) (06/12/91)
In article <1991Jun10.214235.23180@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1991Jun10.182322.24341@ulowell.ulowell.edu> oneill@ulowell.ulowell.edu (Brian 'Doc' O'Neill) writes: >> >>When run in address test mode, with "user@condor.dnet", it seems to work >>fine, with Ruleset 26 reporting the use of Dmail. However, given the >>fully-qualified name of "user@condor.dnet.ulowell.edu", Ruleset 8 strips the >>".dnet.ulowell.edu" off the end, apparently when it uses the resolver to > > It sounds like a combination of the following: > > 1. An entry in /etc/hosts (or in your YP hosts map) of the form > > 1.2.3.4 condor condor.dnet.ulowell.edu > >and > 2. A broken gethostsbyname() which looks in your hosts table/map before > consulting your name server. > One of the few things DEC does right is the /etc/svc.conf (on Ultrix versions >= 4.0) file. You can tell the resolver routines where to look first (hosts, DNS,YP-Hesiod) when doing a name lookup. Possibly the order in this file is incorrect for Mr. O'Neill's purposes. Brian White, System Manager New Jersey Institute of Technology brw@hertz.njit.edu brw@njit.edu
rickert@mp.cs.niu.edu (Neil Rickert) (06/12/91)
In article <1991Jun11.173526.15436@njitgw.njit.edu> brw@hertz.njit.edu (Brian White) writes: > >One of the few things DEC does right is the /etc/svc.conf (on Ultrix versions >>= 4.0) file. You can tell the resolver routines where to look first (hosts, >DNS,YP-Hesiod) when doing a name lookup. Possibly the order in this file is >incorrect for Mr. O'Neill's purposes. Or perhaps the whole idea of using that file (/etc/svc.conf) is wrong. Could it be that the appropriate order for interactive commands like telnet and ftp should different from the order in non-interactive processes such as sending mail? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kre@cs.mu.oz.au (Robert Elz) (06/12/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: > Or perhaps the whole idea of using that file (/etc/svc.conf) is wrong. Yes. >Could it be that the appropriate order for interactive commands ... No, I don't think that's it, you do want consistent answers. Its just that there is no excuse at all for not using the DNS exclusively when its available. What's more, if the DNS doesn't answer (or doesn't answer soon enough), or says "host unknown", or "name exists but no data", its simply wrong to go and try some other lookup method. Only if the DNS is not operating at all (ie: during boot) should anything else be used, and that should be /etc/hosts, which need contain mappings for just those few hosts needed to mount filesystems to get the DNS started. What svc.conf should do is specify which of the lookup methods to use. That way people without the DNS can configure the system to use /etc/hosts (or, if they're really desperate, YP - I'd prefer to set up a private DNS than that). Specfiying the order in which they're to be used is just wrong. kre
kucharsk@solbourne.com (William Kucharski) (06/12/91)
In article <kre.676674893@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: >rickert@mp.cs.niu.edu (Neil Rickert) writes: >Its just that there is no excuse at all for not using the DNS exclusively >when its available. What's more, if the DNS doesn't answer (or doesn't answer >soon enough), or says "host unknown", or "name exists but no data", >its simply wrong to go and try some other lookup method. Only if the DNS >is not operating at all (ie: during boot) should anything else be used, >and that should be /etc/hosts, which need contain mappings for just those >few hosts needed to mount filesystems to get the DNS started. I don't know about this. I've seen more than a few systems that want to keep internal network details from the Internet yet which run DNS. It would be real handy to be able to query the network directly for information on remote hosts without publishing your hosts to the network; e.g. use /etc/hosts for local host information; if it's a host in any other domain go check with DNS. The machinations you have to go through to do this otherwise are not (at least conceptually) pretty... -- | William Kucharski, Solbourne Computer, Inc. | Opinions expressed above | Internet: kucharsk@Solbourne.COM | are MINE alone, not those | uucp: ...!{boulder,sun,uunet}!stan!kucharsk | of Solbourne... | Snail Mail: 1900 Pike Road, Longmont, CO 80501 | "It's Night 9 With D2 Dave!"
kmk@cc.tut.fi (Kai 'Kaizzu' Kein{nen) (06/12/91)
On 11 Jun 91 18:29:58 GMT, rickert@mp.cs.niu.edu (Neil Rickert) said:
Neil> Or perhaps the whole idea of using that file (/etc/svc.conf)
Neil> is wrong. Could it be that the appropriate order for
Neil> interactive commands like telnet and ftp should different from
Neil> the order in non-interactive processes such as sending mail?
Well, in RISC/os (at least from 4.50 on, haven't checked the old ones)
a user or even process may override the order with an environment
variable called VIS_SERVICES (the concept as a whole is called VIS,
Virtual Information Service). I just don't somehow like the idea that
a user may say that 'su' does its getpwent():s from NIS iff the user
so wishes, though...
(I know, this has nothing to do with sendmail. We're happily running
5.65b+IDA1.4.3 here. Thanks for a great Sendmail.mc, Neil!)
--
------------------------------------------------------
- Kai 'Kaizzu' Kein{nen < - > kmk@cc.tut.fi -
- Tampere University of Technology, Computing Center -
------------------------------------------------------kre@cs.mu.oz.au (Robert Elz) (06/12/91)
kucharsk@solbourne.com (William Kucharski) writes: >I've seen more than a few systems that want to keep >internal network details from the Internet yet which run DNS. That's security through obscurity, and it doesn't work. Much better would be to install filters on the gateway, and prevent packets getting near hosts that aren't supposed to receive them, than to try and keep name->address translations hidden from the world. kre
barnett@grymoire.crd.ge.com (Bruce Barnett) (06/14/91)
In article <kre.676685552@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: > kucharsk@solbourne.com (William Kucharski) writes: > > >I've seen more than a few systems that want to keep > >internal network details from the Internet yet which run DNS. > > That's security through obscurity, and it doesn't work. Much better > would be to install filters on the gateway, and prevent packets getting > near hosts that aren't supposed to receive them, than to try and keep > name->address translations hidden from the world. Security is one thing. Advertising unconnected networks is another. Example: The internal GE network is a Class A network. It is not connected to the Internet. Our Internet gateway is on both networks, and has to forward mail between the internal and external network. If the internal network numbers were advertised to the outside then we would get grief for discussing IP addresses that are unreachable. Bad Manners. Filters wouldn't help because the response to address queries are suppose to go out. The BIND software does not give different responses based on where the request came from. It always responds the same. Our gateway is on both networks, but only advertises one address. Our internal machines are in the local host table, but missing from the DNS. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
kre@cs.mu.oz.au (Robert Elz) (06/14/91)
barnett@grymoire.crd.ge.com (Bruce Barnett) writes: >If the internal network numbers were advertised to the outside >then we would get grief for discussing IP addresses that are >unreachable. Bad Manners. I disagree - there's no problem sending back (properly allocated) numbers if someone queries for them, regardless of whether they are reachable or not. I would have no problem getting back a 3.a.b.c address were I to ask for the IP address of grymoire.crd.ge.com. Of course, there's no reason why I should ever want to do that, the MX for that name is crdgw1.ge.com and its that address that I need to find, if you give me both the 192.35.44 and 3.x.y.z addresses for that, that's fine, I can reach one of them (ideally you should return the class C address first for requests from hosts not on net 3, so people will try the right one - that BIND is able to do for you). I assume here that you aren't about to advertise grymoire as an anon ftp site, or suggest that people telnet to it, that would result in annoying timeouts, or unreachables - but no worse than "No address associated with name" what is what I get now if I attempt to telnet to there (I understand it, but I'm not sure your average user would). kre
barnett@grymoire.crd.ge.com (Bruce Barnett) (06/14/91)
I added the tcp-ip newsgroup to the distribution. Follow-ups to comp.protocols.tcp-ip The discussion concerns if it is useful to have an /etc/svc.conf file. I mentioned that GE's mail gateway has the equivalent, so that we don't advertise any addresses in the 3.0.0.0 network (which is unconnected to the Internet). In article <kre.676867753@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: >I disagree - there's no problem sending back (properly allocated) >numbers if someone queries for them, regardless of whether they are >reachable or not. I would have no problem getting back a 3.a.b.c >address were I to ask for the IP address of grymoire.crd.ge.com. Well, I may be missing the fine points, but I believe NYSERNET, et. al. do not like to see any packets addressed to the 3.* network. This causes unnecessary traffic, and people monitor such packets and let us know if we are "leaking" anything when we should not be doing so. If we make the 3.* addresses available (i.e. "A" Records) while advertising a "*.ge.com MX record to crdgw1.ge.com on its Class C network, we could cause a lot of problems on the Internet. I believe. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett