[comp.sys.sgi] sendmail.cf

S090726@UMRVMA.UMR.EDU (Bob Funchess) (02/26/90)

All right, I give up.   What is the sendmail.cf file supposed to look like?
The SG supplied one (yes, I reloaded from tape) won't build the aliases
(also the one supplied).  This disturbs me somehow.  Our situation is:

1 Silicon Graphics Personal Iris 4D/20, on Ethernet, name
  blumiris.chem.umr.edu.  It does NOT have modems.  All I want is for
  it to send outgoing mail to an SMTP forwarder (in this case,
  umrvmb.umr.edu) to be passed along, and for it to receive incoming
  mail for <user>@blumiris.chem.umr.edu.  I don't need anything fancy like
  forwarding to UUCP sites, etc.

By editing the GA Tech sendmail.cf file from comp.sources.unix, I have managed
to get OUTGOING mail working.  INCOMING mail gets to the machine and bounces
with
      setsender:  can't even parse postmaster!

which gets prepended to the message and zapped back to the original sender.

Yes, the local user does exist (root).
The mail is obviously getting to the Iris, since that is noted in the bounced
message.
The only thing that I know of that is weird in the .cf file is the fact that
I want forwarding to be handled at a level which is technically one up from
ours (.umr.edu instead of .chem.umr.edu).  Our domain is defined as umr.edu,
and the machine is defined as blumiris.chem.  Is this the source of the
problem?  If so, how can I work around it?

                             < Bob | S090726@UMRVMA.UMR.EDU | Funchess >
                                    University of Missouri - Rolla
Disclaimer:  If the university shared my opinions,
             would I have an ID like S090726 ???

wlim@gdstech (Willie Lim) (05/25/90)

[Dave Englund is the person who fixed our sendmail.cf file to make
outgoing and incoming mail work.---wlim]

Date: Fri, 25 May 90 07:52:21 EDT
>From: dave@hayslip.LOCAL (Dave Englund)
To: wlim@gdstech.grumman.com
Subject: sendmail.cf


The problem: Our PI was not receiving mail. 

The search for enlightenment:
	1)  Our hostname is "hayslip".

	2)  We could send mail from hayslip to other machines.

        3)  We could only receive mail sent from hayslip to hayslip
using addresses consisting only of user names. For example:
		 	To: wlim 
			From: dave

	4)  Using "sendmail -bt", we found that the address
"dave@crcvs" (where crcvs is another host on our network) was expanding as follows.
rewrite: ruleset  3   input: "dave" "@" "crcvs"
rewrite: ruleset  3 returns: "dave" "<" "@" "crcvs" ">"
rewrite: ruleset  0   input: "dave" "<" "@" "crcvs" ">"
rewrite: ruleset  0 returns: "^V" "ether" "^W" "crcvs" "^X" "dave" "<" "@" "crcvs" "." "LOCAL" ">"

	5) Expanding the address "dave@hayslip":
rewrite: ruleset  3   input: "dave" "@" "hayslip"
rewrite: ruleset  3 returns: "dave" "<" "@" "hayslip" ">"
rewrite: ruleset  0   input: "dave" "<" "@" "hayslip" ">"
rewrite: ruleset  0 returns: "^V" "ether" "^W" "hayslip" "^X" "dave" "<" "@" "hayslip" "." "LOCAL" ">"
			
	6) The error message we got from hayslip when trying to use
the above address was: "I refuse to send mail to myself."
>From 4 + 5 above, it seemed that hayslip thought it had to send mail
to itself over ethernet. It didn't recognize itself!

	7) Using "sendmail -bt -d21.99", we found that the expansion
of "dave@hayslip" began as:
		dave @ hayslip
		dave < @ hayslip >
		dave < @ hayslip . LOCAL >

	8) At this point, the rewrite rules try to strip off the local
host name. None of the appropriate rules would match this though, so
the expansion continued along the same lines as for a remote host.


The FIX:
	Add a rewrite rule to convert things like "dave<@hayslip.LOCAL>"
to "dave".

	In ruleset 0:

# ??? unusual rule
# Assume that all unqualified, canonical names are local.  This is
#	not necessary unless /etc/hosts contains entries whose first
#	name does not contain periods.
R$*<@$=S>$*		$1<@$2.$D>$3

# now delete the local info
R$*<@$=w>$*		$@$>29$1$3			retry thishost
R$*<@$j>$*		$@$>29$1$2			even if it has dots
# daves hack
#R$*<@$=w.$D>$*		$@$>29$1$3			retry this host.LOCAL
# end of hack
R$*<@$D>$*		$@$>29$1$2			retry LOCAL
R$*<@.$D>$*		$@$>29$1$2			retry .LOCAL
R$*<@$=w.UUCP>$*	$@$>29$1$3			retry thishost.UUCP
R$*<@$j.UUCP>$*		$@$>29$1$2
R$*<$*.>$*		$1<$2>$3			drop trailing dot
R<@>$*			$@$>29$1			route strip & retry
R$*<@>			$@$>29$1			strip null & retry


This worked just fine!

stewart%gandal.dnet@ASMUS1.GENETICS.UGA.EDU (10/19/90)

This is a question regarding configuration of sendmail.cf in IRIX 3.3.1.
I would like to be able to send my mail through a forwarding host not
on my local domain, e.g. the forwarding host is mail.cc.uni.edu, whereas
my local machine is iris.dd.uni.edu.  I cannot seem to configure sendmail.cf
to do this properly.  (I can make other irises use this forwarder, however,
they are in the local domain, e.g. xxx.cc.uni.edu). 

I am also interested in knowing how to make the iris utilize a nameserver
without this hanging NeWS whenever the nameserver is down.  I was under
the impression from conversations with the hotline that this would be
fixed in 3.3.  Apparently not.

David Stewart
University Computing and Networking Services, The University of Georgia
E-mail STEWART%GANDAL.DNET@ASMUS1.GENETICS.UGA.EDU

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/21/90)

In article <9010191244.AA12309@asmus1.genetics.uga.edu>, stewart%gandal.dnet@ASMUS1.GENETICS.UGA.EDU writes:
> ...
> I am also interested in knowing how to make the iris utilize a nameserver
> without this hanging NeWS whenever the nameserver is down.  I was under
> the impression from conversations with the hotline that this would be
> fixed in 3.3.  Apparently not.


`man gethostbyname` and several other man pages direct you to the
resolver(4) man page.  There you can read how to tell the system what to do
if the various name services are unhappy.  If you chose to check the
BIND/named/DNS service before your local host file, then name service
clients including the news_server will still have to wait long enough to
distinquish a slow nameserver from a dead one.  Instead, if you put your
local /etc/hosts first, keep that file minimal, and tell the system to keep
looking if it cannot find the answer, then you may get what you want.

You can independently configure the way the system resolves names for
individual users, for individual programs, and for all programs by setting
evironment variables, calling functions, or by changing
/usr/etc/resolv.conf.

It is as fixed as it can be, given the nature of the beast.


Vernon Schryver,    vjs@sgi.com

root@CAPAT.GSO.URI.EDU (Super-User) (06/04/91)

Just received a new PI 4D/35 and am having trouble with the SGI supplied
sendmail.cf file.  Does anyone have a version that works with name servers?
Thanks in advance.

lewsr@capat.gso.uri.edu

dellwo@OTTAWA.SCS.UIUC.EDU ("Martin J. Dellwo") (06/05/91)

> Just received a new PI 4D/35 and am having trouble with the SGI supplied
> sendmail.cf file.  Does anyone have a version that works with name servers?
> Thanks in advance.
>
> lewsr@capat.gso.uri.edu

We have a few 4D/25's and /35's and I've used the sendmail.cf with no
problems.  I'm running named as a caching only server.  The only
things I changed in the standard sendmail.cf were:
  DD - to full local domain (gso.uri.edu)
  DF - the local host, fully qualified. (capat.gso.uri.edu)
  CF - also the local host but _not_ qualified.  (capat)
  DR,CR - similar to F class and macro, except I put in a nameserver
name.  I actually don't thing this 'works' except with the named
running locally, it never gets 'relayed' anyway--the forwarding host
is sufficient.

The other thing to note is that with the named running, we have a
'domain' entry in the resolv.conf file (in /usr/etc).  The domain in
this file should be the same as in the DD macro in sendmail.cf.  If
you change resolv.conf while sendmail is running, sendmail will be
confused and you need to kill and restart it.  Do a 'ps -ef' to see
what actual arguments were given to run sendmail, kill it and restart
it with the same arguments.  It may also be that you could just send
it a 'kill -HUP' but I don't know this...  The only other thing is
that we're running Yellow Pages, if you are not you may want to add
the line 'hostresorder local bind' to the resolv.conf file.  This
makes sure that it doesn't try to look for yp host entries.  I don't
remember if this is necessary, but you might think about this if you
still have difficulties after following the other suggestions.

Martin Dellwo
dellwo@ottawa.scs.uiuc.edu