Sendmail problems on RS/6000 (+ othe UUCP stuff)

[Peter Jeffe 512.823.4091]

In article <1990Aug14.044632.13957 at edm.uucp> geoff at edm.uucp (Geoff Coleman) writes:
> [ Paul Root's problems with uucp mail ]
>	I to saw the same problem when I first installed the OS in our
>6000. The message is a no @ in the SMTP address error. Seeing as the path
>given to mail was machine!user I didn't expect to see an @. I played around
>with the cf file with no luck so I took the easy way out and put smail 3.1
>on the box.

OK, to clear this mess up, the AIX 3.1 sendmail definitely has a
problem dealing with non-domain addresses in special cases.  If either
a sender or recipient address doesn't have a '@' in it, but ruleset 0
resolves it to the tcp mailer, then sendmail complains with a "No '@'
found in SMTP recipient" error.  This should only happen if you are
routing uucp (or local) mail through an smtp host, e.g. if you have
defined the U macro.  Otherwise, it handles uucp and other mail just
fine.

This problem will be fixed in the September update.

>	Right now I'm wary of anything that uses UUCP. I came across a 
>problem today with uux. On our System V (actualy CTIX 6) we do remote 
>prinitng by putting the line
>
>uux -c machine!lp !$file
>...
>When sending files to the 6000 for this it returns a message to uucp account
>that the spooler can't find /usr/spool/uucp/.Xqtdir/<filename>.

This sounds like a uucp problem that will be fixed in the September
update, but the way to find out is to report it to IBM.  In both these
cases, if you would call the problem in to IBM service, then they will
open a record on it, and customer problems get the *highest* priority
for resolution around here.  If anyone has had any frustrations with
this process, or has any reasons why they choose not to report
problems, please let me know and I'll try to apply heat to the proper
areas.

Basically, reporting a problem ensures that: 1) it gets immediate
atttention (if I didn't read this group, the sendmail bug wouldn't have
gotten into the Sept. update); 2) it doesn't fall through the cracks;
3) and MOST IMPORTANT, you can get immediate fixes if you need them bad
enough.

I can't think of any reason to go through all the frustrations of
dealing with broken software when one phone call could get you up and
running within days.

-------------------------------------------------------------------------------
Peter Jeffe   ...uunet!cs.utexas.edu!ibmaus!auschs!sandino.austin.ibm.com!jeffe
        first they want a disclaimer, then they make you pee in a jar,
                   then they come for you in the night