eichelbe@NADC (07/02/86)
In regard to the changes in the host table to fully support domains: Yes, this is "breaking" the mail system at some sites. Due to legal problems which I won't discuss here, I am stuck with an smtp mail system on a 4.1 BSD UNIX system for a VAX 11/780. Going to 4.2 BSD or 4.3 BSD (which I assume will support the domain stuff) is not presently and may never be an option for my site. Since I do have source code and I am a C programmer, fixes to the source are possible. Does anyone have an idea of the magnitude of the changes that are required? (That was not a rhetorical question!) I'd be interested in some informal help. The code looks like it was originally produced by BB&N since the code has bug fixes in it which are labeled as from BB&N. When I called BB&N they told me that they were not supporting the code. Although I can make the mail headers for my /usr/spool/netmail/arpa* files (mail to be sent) have the complete system name (e.g., aim.rutgers.edu) the smtp mailer says that no such site exists. This is evidenced by the command "host" which is supossed to return information from the host table existing on MY system when a site name is provided. If I type: host nadc I get back: nadc.arpa nadc:26.0.0.24 hostcap=1 tcp/ftp tcp/smtp tcp/telnet which is fine. But it has always been true for my "host" command that typing: host nadc.arpa returned: host: bad host: network not found and typing: host ru-aim returns: aim.rutgers.edu ru-aim ru-aim.arpa:128.6.4.15 hostcap=1 tcp/finger tcp/ftp tcp/smtp tcp/telnet but typing: host aim.rutgers.edu returns: host: bad host: too many address components --- So it becomes obvious that low-level routines in the mailer do not under- stand domain-type information. Are code changes required? Maybe there is something I should be placing in my NETWORKS file to tell the mailer about .arpa and .edu? The mailer has obviously always assumed .arpa. Any help or ideas on what I can do to join everyone else here in 1986 would be appreciated. Thank you. Jon Eichelberger eichelbe@NADC.ARPA
wales@LOCUS.UCLA.EDU (Rich Wales) (07/02/86)
In article <8607020415.AA11796@ucbvax.Berkeley.EDU> eichelbe@NADC.ARPA writes: > In regard to the changes in the host table to fully support domains: > > Yes, this is "breaking" the mail system at some sites. . . . I am > stuck with an SMTP mail system on a 4.1 BSD UNIX system for a VAX > 11/780. . . . Since I do have source code and I am a C programmer, > fixes to the source are possible. . . . The code looks like it was > originally produced by BBN. . . . I assume you were one of those sites whose legal staff refused to go along with some of the disclaimer language in Berkeley's 4.2/4.3 license agreements. I remember that unfortunate problem. In any case . . . we (at UCLA) ran the BBN network code on a 4.1BSD system for some time here, and I modified it to accept domain naming. (We have since scrapped the BBN code in favor of a combination of 4.2BSD network code and home-grown mail software.) I don't know where our old modified sources are any more, so I can't simply send them to you, but I think I remember bits and pieces of what I had to do to get the stuff to work. > Although I can make the mail headers for my /usr/spool/netmail/arpa* > files (mail to be sent) have the complete system name (e.g., > aim.rutgers.edu), the smtp mailer says that no such site exists. This > is evidenced by the command "host". . . . It has always been true for > my "host" command that typing: > > host nadc.arpa > > returned: > > host: bad host: network not found > > and . . . typing: > > host aim.rutgers.edu > > returns: > > host: bad host: too many address components > > So it becomes obvious that low-level routines in the mailer do not > understand domain-type information. Are code changes required? > Maybe there is something I should be placing in my NETWORKS file to > tell the mailer about .arpa and .edu? The mailer has obviously > always assumed .arpa. > > Jon Eichelberger > eichelbe@NADC.ARPA In our case (and presumably in yours as well), the problem turned out to be that the BBN host-name routines interpreted something like XXX.YYY as meaning "host XXX, using an address on network YYY". In today's world of domain naming, this is completely bogus. Some early -- or not-so- early -- domain-naming implementations still incorporated this idea, though -- as evidenced by names of the form *.UUCP, *.CSNET, *.BITNET, etc. Even today, a handful of mail systems still in use continue to insist (incorrectly) that ".ARPA" may freely be added to -- or removed from -- any Internet host name at will. I no longer have our old sources readily available, as I said, but my recollection is that I fixed this problem by redefining the "host.net" notation in the BBN library routines to use a dollar sign instead of a period (i.e., "host$net"). I may also have had to fiddle with some other parts of the code in order to allow periods to be part of a host name. This is about as specific as I can remember. I hope it helps. I would *NOT* recommend trying to get around your problem by adding extra entries to your network list. Even if such an approach would work (and, believe me, it wouldn't), domain naming has nothing whatever to do with physical networks; the existence of a name like "PODUNK.EDU" does *NOT* mean that there is a network somewhere called "EDU". -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA wales@LOCUS.UCLA.EDU ...!(ucbvax,ihnp4)!ucla-cs!wales "Sir, there is a multilegged creature crawling on your shoulder."