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