roberts@edsews.UUCP (Ted Roberts) (10/24/87)
During an install of smail 2.5 on a SUN 3/280 running version 3.2 of the operating system, I ran into a problem with the domainname macro (normally $D). Even though the domainname is defined in sendmail.cf, SUN appears to redefine it to be the Yellow Pages domainname. Has anybody found a resonable workaround for this problem short of redefining the YP domainname. -- Ted Roberts EDS TSD roberts@edsews.EDS.COM cbosgd!edstb!edsews!roberts
dave@rosesun.Rosemount.COM (Dave Marquardt) (10/27/87)
In article <315@edsews.UUCP> roberts@edsews.UUCP (Ted Roberts) writes: >During an install of smail 2.5 on a SUN 3/280 running version 3.2 of the >operating system, I ran into a problem with the domainname macro (normally >$D). Even though the domainname is defined in sendmail.cf, SUN appears to >redefine it to be the Yellow Pages domainname. Has anybody found a resonable >workaround for this problem short of redefining the YP domainname. No, the only reasonable workaround I found was to upgrade to SunOS 3.4. Dave
kyle@xanth.UUCP (Kyle Jones) (10/28/87)
In article <315@edsews.UUCP>, roberts@edsews.UUCP (Ted Roberts) writes: > During an install of smail 2.5 on a SUN 3/280 running version 3.2 of the > operating system, I ran into a problem with the domainname macro (normally > $D). Even though the domainname is defined in sendmail.cf, SUN appears to > redefine it to be the Yellow Pages domainname. Has anybody found a resonable > workaround for this problem short of redefining the YP domainname. I found that if you do not freeze the configuration file the domain name is not changed. The documentation SAYS that the YP domain name and the organizational name are separate, but sendmail thinks otherwise, at least when the sendmail.cf is frozen. I don't know whether this is true of later Sun OS 3.x sendmails; I became so enraged with Sun's sendmail that I ported real sendmail (4.3 BSD sendmail) to our Suns and have been happy since. kyle jones <kyle@odu.edu> old dominion university, norfolk, va usa
shprentz@bdmrrr.UUCP (10/29/87)
In article <315@edsews.UUCP>, roberts@edsews.UUCP (Ted Roberts) writes: > During an install of smail 2.5 on a SUN 3/280 running version 3.2 of the > operating system, I ran into a problem with the domainname macro (normally > $D). Even though the domainname is defined in sendmail.cf, SUN appears to > redefine it to be the Yellow Pages domainname. Has anybody found a resonable > workaround for this problem short of redefining the YP domainname? We encountered this problem in February when we installed Sun's release 3.2. I checked with Sun's Tech Support and they said that there was a known bug in sendmail that caused this behavior. It should be fixed in release 3.4. The workaround is to delete the frozen configuration file, /usr/lib/sendmail.fc, and to skip the installation step that creates it. In other words, do not execute the command /usr/lib/sendmail -bz. The problem is only present in frozen configuration files. -- Joel Shprentz Phone: (703) 848-7305 BDM Corporation Uucp: {rutgers,vrdxhq,rlgvax}!bdmrrr!shprentz 7915 Jones Branch Drive shprentz@bdmrrr.bdm.com McLean, Virginia 22102
wyle@ethz.UUCP (Mitchell Wyle) (11/01/87)
All of the suns here are "public;" users go to the nearest un-occupied machine to work; the machine=domain naming scheme is therefore not acceptable. What should my sendmail.cf files look like to have one central mail server, but let users read their mail from ANY machine? Mitch -- Mitchell F. Wyle | csnet or arpa: wyle%ifi.ethz.ch@relay.cs.net Instituet fuer Informatik | uucp: wyle@ethz.uucp ETH Zentrum / SOT | Telephone: 011 41 1 256 5237 8092 Zuerich, Switzerland
dudek@ubglue.ksr.com (Glen Dudek) (11/04/87)
In article <234@bernina.UUCP> wyle@ethz.UUCP (Mitchell Wyle) writes: >All of the suns here are "public;" users go to the nearest un-occupied >machine to work; the machine=domain naming scheme is therefore not >acceptable. What should my sendmail.cf files look like to have one >central mail server, but let users read their mail from ANY machine? > I set up a network of Suns which remote mount /usr/spool/mail from the master mail server. This allows users to read their mail from any machine. Rather than let mail be delivered to mailboxes on any machine, I made a one line change to the sendmail.subsidiary.cf to forward local mail to the central mail server. This helps avoid locking problems, and also prevents strange error conditions and dropped mail if the central mail server is down and a client tries to deliver mail. Since the client will try to forward the mail to the mail server, sendmail will simply queue the mail and retry periodically until the mail server reboots. You still need to be careful about mail programs which try to use flock to lock the mailbox, since flock isn't supported across NFS, but I am pretty sure Sun mailers do NOT use this. Emacs and mh and others should be compiled not to use flock. Note that this change requires that the master mail host also be the host which you mount /usr/spool/mail from. sendmail.subsidiary.cf diffs ------------------------------- 422,423c422,423 < # everything else is a local name < R$+ $#local $:$1 local names --- > # everything else is a local name, send to mail host > R$+ $#$M $@$R $:$1 local names ------------------------------- I also made a change to sendmail.main.cf so that mail addressed to other Suns on our network is just delivered locally on the master mail host. This is just an optimization, since otherwise the master mail host will send the mail to the client mail host, which will strip its hostname and send it back to the master. You should not make this optimization if you have other SMTP hosts on your ethernet which do not remote mount /usr/spool/mail from this master. sendmail.main.cf diffs ------------------------------- 406,407c406,408 < # deliver to known ethernet hosts explicitly specified in our domain < R$*<@$*$%y.LOCAL>$* $#ether $@$3 $:$1@$2$3.$D.$U$4 user@etherhost.sun.uucp --- > # deliver mail for known ethernet hosts explicitly specified in our domain > # to us > R$*<@$*$%y.LOCAL>$* $@$>30 $1 432c433 < R$*<@$*$%y>$* $#ether $@$3 $:$1@$2$3$4 user@etherhost --- > R$*<@$*$%y>$* $@$>30 $1 ------------------------------- Glen Dudek dudek%ksr.UUCP@harvard.harvard.edu
steve@mimsy.UUCP (Steve D. Miller) (11/09/87)
In article <191@ksr.UUCP> dudek@ksr.UUCP (Glen Dudek) writes: [ ... ] >sendmail.subsidiary.cf diffs >------------------------------- >422,423c422,423 >< # everything else is a local name >< R$+ $#local $:$1 local names >--- >> # everything else is a local name, send to mail host >> R$+ $#$M $@$R $:$1 local names >------------------------------- > [ ... ] > Glen Dudek > dudek%ksr.UUCP@harvard.harvard.edu This sort of reforwarding of local mail will cause some problems. We do something like this (for now) at Maryland, and our users can't send mail to files or to programs on our Sun clients. Such mail gets forwarded to the local mail gateway, which gripes about not accepting mail to files/programs via SMTP. (Your sendmail might possibly deliver such reforwarded mail, but if it does, that's a big security hole. I don't remember enough of sendmail's history to know if it ever pulled such shenanigans....) If you don't care a whole lot about this feature, then its absence is no problem. It would be nice if sendmail's local mailer was a bit less arbitrarily knowledgeable, and if dealing with quote marks in sendmail config files was possible. (Is it? I tried, and could never get it to do what I wanted. Any rule I could come up with that might match "|$*" failed in interesting ways.) Mail is such fun... -Steve -- Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1516 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742