Date: Sun, 25 Aug 96 21:25:44 EST From: Dwight McKay (The Moderator) Reply-To: Suns-at-Home@net-kitchen.com Subject: Suns-at-Home Digest V9 #31 To: Suns-at-Home-List Suns-at-Home Digest Sun, 25 Aug 96 Volume 9 : Issue 31 Today's Topics: Dead keyboard on 3/60 SunOs 4.0.2 Suns-at-Home Digest V9 #30 uucp problem resolved! +--------------------------------------------------------------------+ | Submissions: suns-at-home \ | | Requests: suns-at-home-request > @net-kitchen.com | | Archives: suns-at-home-archives / | | WWW Archive access: http://www.net-kitchen.com/~sah | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Sat, 17 Aug 96 20:26:34 PDT From: perryh@pluto.rain.com (Perry Hutchison) Subject: Dead keyboard on 3/60 To: mikec@cam-ani.co.uk > Date: Thu, 15 Aug 1996 16:01:02 +0100 > From: "Mike Causer" > > Arghhhh.... keyboard died on my 3/60 ... The hardware reference says that > the keyboard/mouse and the serial ports go through the Zilog UARTS, and > then lists driver chips, but doesn't say which are keyboard and which > serial port. I would start by checking the keyboard fuse (and I hope the hardware reference says where it is -- I don't know). - ------------------------------ Date: Wed, 21 Aug 1996 16:02:15 +0000 From: Royce Priem Subject: SunOs 4.0.2 To: Suns-at-Home@tigger.net-kitchen.com I have a 386i and would like to upgrade to 4.0.2. Does anyone know where I can download a copy from the net? cxc1.msu.edu no longer offers this.. kind regards royce priem - ------------------------------ Date: Fri, 23 Aug 1996 14:41:43 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) Subject: Suns-at-Home Digest V9 #30 To: Suns-at-Home@tigger.net-kitchen.com > Date: Mon, 12 Aug 1996 08:24:02 -0700 > From: bandy@cinnamon.com (Andy Beals) > Subject: Gary Sabot's uucp problem > To: Suns-at-Home@ecn.purdue.edu > > Forget Sun's UUCP. It is incredibly ancient and has obscure bugs. > Grab a copy of Taylor UUCP [aka gnu uucp] and use that instead. I confess I don't remember what problems Gary was having with UUCP.... However I'd like to point out that Taylor UUCP isn't necessarily the answer to all UUCP problems, particularly not if you're using a fairly straight-forward dial-up 'g' protocol setup with UUCP on SunOS-4.x (i.e. HDB-UUCP). The biggest advantage of sticking with the HDB version is that Sun's documentation, as well as most any SysV-UUCP docuemtation will remain accurate. Yes, there are some minor problems with HDB-UUCP, some unique to SunOS-4.x, esp. in the lesser explored regions. However if you're not tripping over known problems, I would suggest sticking with it rather than inviting a whole new set of problems possible with switching systems. -- Greg A. Woods - ------------------------------ Date: Mon, 19 Aug 96 10:19:21 EDT From: gary@sabot.com (Gary Sabot) Subject: uucp problem resolved! To: Suns-at-Home@ecn.purdue.edu Someone on comp.mail.uucp solved my uucp problem for me. My ISP made the appropriate changes described below, and the problem went away. It is possible that changing from Sun's UUCP to Taylor UUCP would have solved the problem as well, but no one is really sure about that (although Taylor definitely would have forwarded the bad message to root rather than dropping it). I prefer to avoid messing with UUCP configuration if I can avoid it... Forwarded message: ------------------ From: gerg@netcom.com (Greg Andrews) Subject: Re: vanishing mail Organization: Deep Thought of the Day: A day without sunshine is like night. Date: Tue, 13 Aug 1996 15:20:46 GMT sabot@mit.edu (Gary Sabot) writes: > My ISP tells me that the problem has something to do with the header >of the vanishing message containing a bad username (instead of being >"username@foo.com", it is "@gateway:username@foo.com"). The bad >username occurs in the "From " field; the value in the "From: " is >correct. My understanding is that most Unix mailers just ignore the >"From " field, but apparently the uucp I am using does not (what does >Taylor do?) > Your ISP is mistaken about the nature of the problem. Their Sendmail is causing it. It's not any of the addresses in the messages headers. It's the envelope sender address that appears in the "R" line of the UUCP work file (the one named X.blahblah on your machine). If you look at those files, you'll find that the sucessful mail messages have an "R" line that looks like this: R @dom.ain:user@dom.ain or R host!@dom.ain:user@dom.ain The failing ones look like this: R host!<@dom.ain:user@dom.ain> The "<" and ">" are the problem. Your ISP is using Berkeley Sendmail version 8.6.10 or higher. The recent versions of Sendmail insist on re-inserting those angle brackets around source-route style addresses, even if the address processing stripped them off. They are appropriate for RFC 822 transport environments (which is why sendmail made that change), but UUCP isn't that kind of environment. At Netcom we had to modify the Sendmail source code to comment out the line that adds those brackets. After that, our UUCP customers had no further problems. I don't know if switching to the Taylor uuxqt on your end will help or not. It's worth a try. Your best ammunition toward convincing your ISP that they need to make a change would be to collect copies of the files that you're receiving via UUCP before your uuxqt processes them. The best way to do that is to rename your uuxqt so uucico can't run it. That will leave the "X.blahblah" and "D.blahblah" files in your spool directory where you can make copies of them. Then rename uuxqt and re-run it manually to process the files. If you have your ISP make copies of the same files before you call and pick them up, you can assure your ISP that the files weren't mangled during the transfer, and the "R" line was bad on their machines. -Greg - ------------------------------ End of Suns-at-Home Digest ******************************