dwd@hall.cray.com (Dave DeHerder_Jr.) (01/14/88)
A little while ago there was a discussion of duplicate site names and the answer was to use domains because then the fully qualified site name WILL be unique. WELL... I got some mail with a from that looked like: "From: texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!onion.SanDiego.NCR.COM!bethh@tundra.UUCP" First it is confusing because all the sites are in order except that "tundra.UUCP" is our nearest neighbor. Why that is at the end is a mystery to me. OK. So I figure that this is just a foible of the conventions and try to create a return path and come up with: "To: tundra!texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM" Is this correct or am I all screwed up? This mail gets bounced back to me with: "554 texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM... Unknown domain COM" I also tried bethh@onion.ncr.com thinking that upper case was causing me difficulties (well it worked on other stuff). No dice. Bounced with the same message. Can anyone tell me what the problem is?
woods@hao.ucar.edu (Greg Woods) (01/15/88)
In article <2987@hall.cray.com> dwd@hall.cray.com (Dave DeHerder_Jr.) writes: >WELL... I got some mail with a from that looked like: >"From: texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!onion.SanDiego.NCR.COM!bethh@tundra.UUCP" >First it is confusing because all the sites are in order except that >"tundra.UUCP" is our nearest neighbor. Why that is at the end is a >mystery to me. OK. So I figure that this is just a foible of the >conventions and try to create a return path and come up with: >"To: tundra!texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM" >Is this correct or am I all screwed up? You have now changed the ultimate destination of the message. The problem is, an address like host1!user@host2 is inherently ambiguous. Does it mean send to host1, for a user who is on host2, or send to host2, for a user that is on host1? The official mail addressing standard (I think it's RFC822) does not even officially recognize bangs (!) as addressing characters. Technically, address@host should always be sent to the host on the left of the @-sign first. How "address" is interpreted there is not specified (which allows things like the % kludge to work). In this case, the first address above is perfectly valid since it means send to tundra via UUCP and let tundra worry about interpreting the bang path. Unfortunately, the second address says something different. It says send to onion.SanDeigo.NCR.COM for eventual delivery to "bethh" on host "ncr-sd", which is not where this user is. From the first path, the user "bethh" appears to be at onion.SanDiego.NCR.COM. Therefore the second path is incorrect. If you'd left it in pure bang form, i.e. tundra!texsun!...!ncr-ds!onion.SanDiego.NCR.COM!bethh it MIGHT have worked. At least it would have gotten sent to tundra which is the first hop in the path. > >This mail gets bounced back to me with: >"554 texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM... Unknown domain COM" > ..which confirms what I said earlier: it was trying to send to onion directly, which isn't what is intended. It looks to me as though your site does not have a domain-compatible mailer. If it doesn't even know about ".COM" that is very likely to be the case, in which case a pure bang path is most likely to work from your site. Not having a domain-compatible mailer at YOUR site does not mean you can't use domains at all; it does mean that an address of the form "user@host.domain" isn't going to work. What you will have to do is something like bang!path!to!smarthost!host.domain!user, which looks like a pure bang path until it gets to smarthost, which will turn it into a domain address. If "ncr-sd" is such a host, then the above suggested path would work in this case. --Greg
woods@hao.ucar.edu (Greg Woods) (01/15/88)
In article <1091@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: >Technically, address@host should always be sent to the host on the left >of the @-sign first. Of course, that should be "sent to the host on the RIGHT of the @-sign first". Sorry, it's one of those days. --Greg
matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (01/15/88)
In article <2987@hall.cray.com> dwd@hall.cray.com (Dave DeHerder_Jr.) writes: >WELL... I got some mail with a from that looked like: >"From: texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!onion.SanDiego.NCR.COM!bethh@tundra.UUCP" As Postmaster of ncr-sd.UUCP and SanDiego.NCR.COM I can explain what probably happened. The From: header line was added by tundra.UUCP as none was previously present. The system onion is running stock V.2 with mailx as the user agent, and mailx does not generate a From: header line. Tundra is probably running sendmail (it's a Sun) and the stock sendmail configuration file tends to do things like create very ugly From: and To: headers when none are previously present. The return path should have been tundra!texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!onion.SanDiego.NCR.COM!bethh so it doesn't end up a mixed-mode path. Remember that '@' normally has precedence over '!' when parsing addresses, except that many UUCP sites ignore '@' completely. >First it is confusing because all the sites are in order except that >"tundra.UUCP" is our nearest neighbor. Why that is at the end is a >mystery to me. OK. So I figure that this is just a foible of the >conventions and try to create a return path and come up with: >"To: tundra!texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM" The tundra.UUCP is at the end because the '@' has higher precedence. The new form is wrong since if everybody worked right (which they won't) the address passed to onion would be tundra!texsun!...!ncr-sd!beth which would fail since onion does not communicate with tundra. >This mail gets bounced back to me with: >"554 texsun!sun!hplabs!hp-sdd!sdcsvax!ncr-sd!bethh@onion.SanDiego.NCR.COM... Unknown domain COM" > >I also tried bethh@onion.ncr.com thinking that upper case was >causing me difficulties (well it worked on other stuff). No >dice. Bounced with the same message. > >Can anyone tell me what the problem is? Any domain server that does not know about the COM domain is very broken. It is a requirement of EVERY domain server that it know all the top-level domains. In actuality lots of machines just pass unknown top-level domains off to a smarter neighbor, but the end affect is still the same. You should inform the postmaster of the machine the rejection came from that COM was unknown and that they had better fix it. From the remaining path it looks like the problem was at tundra.UUCP, which figures ... -- Matt Costello <matt.costello@SanDiego.NCR.COM> +1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET> {sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt
braun@drivax.UUCP (Kral) (01/20/88)
We are running BSD4.2 on a Vax 11/780.
Does one have to use a particular mailer to be 'domain smart', or does it
require having certain info in the mail databases? Our mailer is the standard
mailer that comes with Berkeley.
--
kral [THERE ARE NO ORDINARY MOMENTS]
408/647-6112 ...{ism780|amdahl}!drivax!braun
"Dream lightyears... Challenge miles... Walk in steps"
DISCLAIMER: If DRI knew I was saying this stuff, they would shut me d~-~oxxrosalia@mozart.UUCP (Mark Galassi) (01/24/88)
In article <2965@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >We are running BSD4.2 on a Vax 11/780. >Does one have to use a particular mailer to be 'domain smart', or does it >require having certain info in the mail databases? Our mailer is the standard >mailer that comes with Berkeley. If you have 4.2, you get the sendmail program, which can be made "domain-smart" by tuning the sendmail.cf. This is a horrible task, but there are ways of making it easier: First of all, get the smail mailer from the source archives (if you cannot do that, let me know and I can send them to you. Then you follow the steps to replace your "rmail" and "binmail" with what comes in the smail package, and then they have a script which customizes the sendmail.cf file for you. I have used smail both with and without sendmail, and with sendmail it did both arpanet mail (over IPC channels) and uucp mail (where the sendmail.cf file hands the jobs over to smail), and it works beautifully. So my advice sums up to: use smail with sendmail if you have it, but by itself otherwise. -- Mark Galassi ...!{sbcs,icus}!mozart!rosalia { these opinions are mine, and should be everybody else's :-) }
mcr@julie.UUCP (Michael Richardson) (03/17/89)
A recent question about maps, and what to do with them reminded me that I hadn't registered julie as a node, and she isn't in the maps yet. (As soon as I remember where I put my atlas, I'll pop it off..) But this brings up a question of domains --- specifically, I'd rather be known by one (and I suspect from the stuff that my upfeed sent me, anyone with any maps around would rather I was known as julie.ott.something.somenet) Rick Adams writes: >Wrong. ALL legitimate domain names are required to have an Internet >forwarder. If there is a local site, that has no internet mail forwarder, then >it is not properly registered. (There's more to registration than >just starting to use a domain style name) What _is_ involved? I can think of two ways that me, as a more or less private node could be known: julie.amiga.cbm.com (if CBM was willing) [I presume that CBM would necesarily be in the .com domain, although I don't think they currently are in any) or maybe julie.ott.ca But, my current uucp link is nrcaer, part of the National Research Council, (they don't have a domaine name either, or don't know it) but I would guess they'd wind up under ".edu", except that most universities in Canada are known in the ".ca" domaine? I suspect that there is a conference somewhere under comp.mail or net. to deal with this, but my conference lists are currently somewhere else. (with my disk space) -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
dtynan@altos86.UUCP (Dermot Tynan) (03/22/89)
In article <0812.AA0812@julie> mcr@julie.UUCP (Michael Richardson) writes: > >Rick Adams writes: >>Wrong. ALL legitimate domain names are required to have an Internet >>forwarder. > > What _is_ involved? I can think of two ways that me, as a more or less >private node could be known: > > Michael Richardson Amiga Well, the easiest way is to cough up $35.00/month and get an account on UUNET. That way, Rick will let you use UUNET as a forwarder. He will also register your machine with the NIC for free, if you are a UUNET customer. Other than that, you could contact mark@stargate.com. If I remember correctly, they are also offering a registration service (albeit more expensive). Welcome to the wonderful world of domains... - Der
mark@cblpf.ATT.COM (Mark Horton) (03/24/89)
In article <877@altos86.UUCP> dtynan@altos86.UUCP (Dermot Tynan) writes: > Well, the easiest way is to cough up $35.00/month and get an account on > UUNET. That way, Rick will let you use UUNET as a forwarder. He will > also register your machine with the NIC for free, if you are a UUNET > customer. > Other than that, you could contact mark@stargate.com. If I remember > correctly, they are also offering a registration service (albeit more > expensive). Welcome to the wonderful world of domains... > - Der Stargate (The UUCP Zone) doesn't do registrations anymore. UUNET is doing it for a one time $35 fee, and we're referring people to them. Contact them at domain-request@uunet.uu.net or 1-703-528-8649. Mark Horton
rick@uunet.UU.NET (Rick Adams) (03/24/89)
> Contact them at domain-request@uunet.uu.net or 1-703-528-8649.
That should be +1 703 876 5050gore@eecs.nwu.edu (Jacob Gore) (03/24/89)
/ comp.mail.uucp / mark@cblpf.ATT.COM (Mark Horton) / Mar 23, 1989 / >Stargate (The UUCP Zone) doesn't do registrations anymore. UUNET is >doing it for a one time $35 fee, and we're referring people to them. >Contact them at domain-request@uunet.uu.net [...] Should organizations already in d.* maps re-register through UUNET? Are the u.* files and d.* files going to be merged? Are they updated through the same address ("uucpmap@rutgers.edu"?) now? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
asp@cos.com (Andrew S. Partan) (04/01/89)
In article <3400010@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: > Are the u.* files and d.* files going to be merged? Are they updated > through the same address ("uucpmap@rutgers.edu"?) now? As far as I can tell, most of the d.* maps have already been merged into the u.* maps. The only d.* maps that I have now (that actually have something in them other than comments saying that they have been merged with the u.* map) are: d.[A-Z]* d.usa.hi.1 d.kor.1 Disclaimer: I am not part of the uucp maping project & have no connections with them. --asp (Andrew Partan @ Corporation for Open Systems) -- asp@cos.com or asp%cos.com@uunet.uu.net -- {uunet, sundc, decuac, hqda-ai, hadron}!cos!asp ASN.1 Object Identifier: "{joint-iso-ccitt mhs(6) group(6) 157}"
dpz@pilot.njin.net (David Paul Zimmerman) (04/03/89)
I would think that you don't have to do anything about reregistering until your UUCP Zone service is used up, which should be within a year at the latest. At or near that point, yes, you should check into registering with UUNET if you want to have similar service. Mail to domain-request@uunet.uu.net for more info. With the winding down of the UUCP Zone, we decided at the Winter 1989 USENIX that it was time for the u.* and d.* files to be merged, at each map coordinator's convenience. Most have done so by now. In any case, the merging has not changed the UUCP map submission address, which is still "uucpmap@rutgers.edu". David -- David Paul Zimmerman Rutgers University dpz@pilot.njin.net rutgers!dpz dpzimmerman@zodiac.bitnet