SVR4: smtpqer, and remote printer configuation problems... HELP!!

[Israel Pinkas]

In article <RJC.91Apr2220026 at devo.unify.com> rjc at devo.unify.com (Ronald Cole) writes:

> I am having problems configuring my Sony NWS-3860, running System V
> Release 4.0, to send mail over our local ethernet and printing to a
> remote printer.

> Anyway, the _System Administrator's Guide_ has a section (relegated to
> the appendix, no less!) "Administering SMTP" on page F-8.  Step 1
> tells me how to successfully edit /etc/mail/mailsurr (I also set
> SMARTERHOST=unify in /etc/mail/mailcnfg).  Sending local mail works
> fine, but remote mail bounces like this:

>    ----- Transcript of session follows -----
> >>> HELO unify.com
> <<< 553 Local configuration error, hostname not recognized as local
> 554 <unify!mcm>... Service unavailable: Bad file number

> Step 2 at the bottom of the page says that I must specify a list of
> machines that will accept SMTP mail (I just want to add the one I
> specified in the mailcnfg file) by using the netdird(1M) service(!).
> Well, this man page doesn't exist.  In the same manual, on page 7-12,
> the section _Setting Up the Name-to-Address Mapping Libraries_
> describes what is probably the missing piece... however, the example
> is completely meaningless and useless to me.  Attempting to set up a
> remote printer has led me to the same section in the manual (jobs
> queue up but don't seem to make it off the machine)...

I can't guarantee that this will solve all your problems for mail and
printing, but this is what I did on my i386 and i860 workstations.  I use
my machine to read and send mail and I set everything up so that I print on
my NeXT cube.  For printing, I just used sysadm.  The only change that I
had to make was a result of a bug in my (early) version of SVR4.  Sysadm
did not properly save the bsd value, so my system kept trying to connect to
a SysV printer port on the NeXT.



Create /etc/mail/mailcnfg.  My machines did not have this file.  My file
contains the following:

DEL_EMPTY_MFILE=no
SMARTERHOST=hermes
DOMAIN=.intel.com

The first line prevent mail/mailx from deleting user's mail files in
/var/mail when the file is empty.  This allows the user to set permissions
on the file and not lose them when there is no mail.

The second line names a machine that is "smarter".  When my workstations do
not have a TCP/IP address for a machine, or when the machine is not on a
reachable network, the mail is forwarded to this machine.

The third line names the domain that this machine is under.  Note that the
eading period is necessary, as this string is concatenated onto the end of
you machine name.

>From the transcript you provided, it almost looks like your Sony
workstation is identifying itself as unify, which is incorrect.
SMARTERHOST must name some other machine.  If you don't have a smarter
host, don't name one.  (The output of the SMTP session shows your machine
identifying itself as unify.com.  The second line is an error from the
remote machine, which states that the name unify.com was not recognized as
the local machine.  Since you defined SMATERHOST to by unify, your machine
is talking to unify and telling it that it is unify.com.)

I also had to make some changes to /etc/mail/mailsurr.  You mileage may
vary, as I am using a slightly older version of SVR4, but I will try to
identify what is happening.  When all else fails, mailsurr is described in
the mailsurr(4) man page and is relatively easy to understand.  Since the
default file is not too long, and has decent comments, you should be able
to figure out what is going on by hand.

The first change I had to make was to comment out the line that translates
addresses of the form @domain1[, at domain2]*:user at domain3 to domain1!...  The
reason for this is that the rewrite rule fails (IMHO) when , at domain2 type
addresses are used.  If users at you site need this feature, run a few
examples through by hand (or with mail -T) to verifycorrect operation.

The next change that I made was to comment out the line that tries to mail
with /usr/bin/uux and uncomment the line that tries to mail with
/usr/lib/mail/surrcmd/smtpqer.  The comment above states that uucp is first
because it is more universal, but everybody here seems to disagree.

The next change I made was to uncomment the line that sends mail to
SMARTERHOST.

I also had to enable the crontab entries in root's crontab that run
smtpsched periodically.


Hope this helps.

-Israel Pinkas
 Intel Corp.
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.

UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas
ARPA:	pinkas%st860.intel.com at relay.cs.net
CSNET:	pinkas at st860.intel.com