tkevans@fallst.UUCP (Tim Evans) (07/08/88)
I've recently installed HDB UUCP on my Microport SysV/AT and curious
things are happening--actually just one curious thing happening over
and over. My system refuses to pass mail on from the _one_ non-HDB
system to which I talk. All mail coming from other systems--running
HDB--passes through just fine.
The uuxqt log file shows _rmail_ being denied for this system.
Yet, uucheck tells me that this system is fully authorized to do
rmail.
So, I'm stumped. Hope someone can help.
Tim Evans
********************************************************************
UUCP: ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
OTHER: ...!attmail!fallst!tkevans
US MAIL: 2201 Brookhaven Court, Fallston, MD 21047
PHONE: (301) 965-3286
********************************************************************tkevans@fallst.UUCP (Tim Evans) (07/10/88)
A fews days back, I asked help in solving a problem which I thought
had to do with HDB uucp/Version 2 uucp communication. (Briefly,
mail from the Version 2 system routed through the HDB system was
not being passed on, although mail addressed to users on the HDB
system was being delivered.)
I have diagnosed the problem, and want to first thank Peter Honeyman
(who told me where to look) and the others who have responded to my
plea for help.
The problem turns out NOT to have anything to do with HDB <--> Version 2
interaction, but rather to malformed uucp work files being created on
the other system which, when delivered to the HDB system, could not
be executed by uuxqt. Below is a sample 'X.' file:
U root woodb
F D.woodbB0ma2
I D.woodbB0ma2
C wb3ffv!rmail tkevans <-- HERE IS THE PROBLEM
As you can see, the last line of the file has a malformed command;
it should, of course, read:
C rmail wb3ffv!tkevans
Now, the solution of the problem lies with the vendor who installed the
system which creates such incorrect files. The mailer (a proprietary
mailer for use within an Ethernet network of several LAN's) needs fixing
so that it creates proper work files to pass on to uucp.
For the record, Peter's suggestion was to:
o mv uuxqt uuxqt.real
o queue mail on the offending system and pass it to this system
(since uuxqt won't be found, the work files will be left in
the spool directory)
o manually execute 'uuxqt.real' with debugging turned on and watch
for errors
This worked, turning up the incorrect command "wb3ffv!rmail tkevans"
Again, thanks to Peter and to others who offered suggestions.
********************************************************************
UUCP: ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
OTHER: ...!attmail!fallst!tkevans
US MAIL: 2201 Brookhaven Court, Fallston, MD 21047
PHONE: (301) 965-3286
********************************************************************clif@clif.UUCP (Clif Flynt) (07/13/88)
In article <391@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes: >I've recently installed HDB UUCP on my Microport SysV/AT and curious >things are happening--actually just one curious thing happening over >and over. My system refuses to pass mail on from the _one_ non-HDB >system to which I talk. All mail coming from other systems--running >HDB--passes through just fine. > ... Odds are fair that you haven't set up the Permissions file correctly for everything. Here's an excerpt from my Permissions file, which might clear up some questions: LOGNAME=uucp \ REQUEST=yes \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ COMMANDS=rmail:rnews \ SENDFILES=yes As of January, on the 386 port of HDB, there was good documentation on every file except the Permissions file, where there was no documentation at all. I assume this is better now, since I got copies of the manual pages when I asked for them in March or so. -- -------------------------------- Clif Flynt -------------------------------- --------------------------- uunet!umix!clif!clif --------------------------- ---------------- This space reserved for a witty disclaimer ----------------