rbraun@spdcc.COM (Rich Braun) (05/25/91)
If I reboot my SCO Unix system, incoming SMTP mail gets put into the queue (deferred, I think due to a host-name lookup failure) and not ever unqueued. If I kill the sendmail daemon and restart it, the queue gets emptied out properly to the appropriate users' mailboxes. Apparently sendmail is getting started before some other task on which it depends, but I haven't a clue as to how to solve this problem. For now, I've been manually restarting the daemon after the boot sequence completes. SCO ships the system with mmdf, and there may be an interaction problem with the mmdfdeliver daemon which is always there sitting in the background. I'd just as soon dump mmdf entirely, though SCO's documentation implies that mmdf is superior and one should dump sendmail instead. If mmdf is superior, then my first question is "How can I make it communicate with remote sendmail daemons?" and my second is "Why doesn't mmdf handle domain name service?" I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- based LAN containing SCO Unix systems mixed with others (AIX, NCR, and so on), using a sendmail daemon on a non-SCO system to relay mail to the Internet via UUCP. (I've got my domain name server set up to recognize systems on a domain called "kronos.com", and I've got SCO sendmail configured to relay all mail addressed to external domains to a given system on the LAN that knows how to pass it along to the world-wide Internet.) -rich
Rich.Braun@sunbrk.FidoNet.Org (Rich Braun) (05/26/91)
If I reboot my SCO Unix system, incoming SMTP mail gets put into the queue (deferred, I think due to a host-name lookup failure) and not ever unqueued. If I kill the sendmail daemon and restart it, the queue gets emptied out properly to the appropriate users' mailboxes. Apparently sendmail is getting started before some other task on which it depends, but I haven't a clue as to how to solve this problem. For now, I've been manually restarting the daemon after the boot sequence completes. SCO ships the system with mmdf, and there may be an interaction problem with the mmdfdeliver daemon which is always there sitting in the background. I'd just as soon dump mmdf entirely, though SCO's documentation implies that mmdf is superior and one should dump sendmail instead. If mmdf is superior, then my first question is "How can I make it communicate with remote sendmail daemons?" and my second is "Why doesn't mmdf handle domain name service?" I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- based LAN containing SCO Unix systems mixed with others (AIX, NCR, and so on), using a sendmail daemon on a non-SCO system to relay mail to the Internet via UUCP. (I've got my domain name server set up to recognize systems on a domain called "kronos.com", and I've got SCO sendmail configured to relay all mail addressed to external domains to a given system on the LAN that knows how to pass it along to the world-wide Internet.) -rich * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
david@sco.COM (David Fiander) (05/27/91)
In article <7647@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >SCO ships the system with mmdf, and there may be an interaction problem >with the mmdfdeliver daemon which is always there sitting in the >background. I'd just as soon dump mmdf entirely, though SCO's This is your problem exactly. If you really want to run sendmail, you have to uninstall mmdf, because they both attempt to listen for SMTP connections (actually the inetd and sendmail both attempt to listen). >documentation implies that mmdf is superior and one should dump >sendmail instead. If mmdf is superior, then my first question is "How >can I make it communicate with remote sendmail daemons?" and my second >is "Why doesn't mmdf handle domain name service?" In reverse order: You cannot configure the version of mmdf that you are running to talk to the nameserver. This has been corrected in the next release of SCO MMDF. The way to get mmdf to communicate with remote sendmail daemons is to properly configure MMDF to do so. Since you have been spending all your time trying to fix you perceived sendmail problems, you probably haven't worked very hard on MMDF (that's not a flame, I would have done the same thing). MMDF is only better that sendmail in one (very important) way: normal human beings can understand how to configure it in about 15 minutes, and can read the configuration files without having the manual beside them. Aside from that, MMDF and Sendmail solve basically the same problem in basically the same way. > >I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and >so on), using a sendmail daemon on a non-SCO system to relay mail to You're talking to one (but we didn't relay things through sendmail to the Internet, just the rest of UUCPnet, but the idea is the same for the MMDF nodes). >the Internet via UUCP. (I've got my domain name server set up to >recognize systems on a domain called "kronos.com", and I've got SCO >sendmail configured to relay all mail addressed to external domains >to a given system on the LAN that knows how to pass it along to >the world-wide Internet.) This is very trivial to do with MMDF as well. Phone SCO support and ask for the fax-pack which describes configuring SCO MMDF in a TCP/IP environment (it's also been posted to this newsgroup at least once). -- David J. Fiander SCO MMDF Development Team SCO Canada, Inc.
David.Fiander@sunbrk.FidoNet.Org (David Fiander) (05/28/91)
In article <7647@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >SCO ships the system with mmdf, and there may be an interaction problem >with the mmdfdeliver daemon which is always there sitting in the >background. I'd just as soon dump mmdf entirely, though SCO's This is your problem exactly. If you really want to run sendmail, you have to uninstall mmdf, because they both attempt to listen for SMTP connections (actually the inetd and sendmail both attempt to listen). >documentation implies that mmdf is superior and one should dump >sendmail instead. If mmdf is superior, then my first question is "How >can I make it communicate with remote sendmail daemons?" and my second >is "Why doesn't mmdf handle domain name service?" In reverse order: You cannot configure the version of mmdf that you are running to talk to the nameserver. This has been corrected in the next release of SCO MMDF. The way to get mmdf to communicate with remote sendmail daemons is to properly configure MMDF to do so. Since you have been spending all your time trying to fix you perceived sendmail problems, you probably haven't worked very hard on MMDF (that's not a flame, I would have done the same thing). MMDF is only better that sendmail in one (very important) way: normal human beings can understand how to configure it in about 15 minutes, and can read the configuration files without having the manual beside them. Aside from that, MMDF and Sendmail solve basically the same problem in basically the same way. > >I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and >so on), using a sendmail daemon on a non-SCO system to relay mail to You're talking to one (but we didn't relay things through sendmail to the Internet, just the rest of UUCPnet, but the idea is the same for the MMDF nodes). >the Internet via UUCP. (I've got my domain name server set up to >recognize systems on a domain called "kronos.com", and I've got SCO >sendmail configured to relay all mail addressed to external domains >to a given system on the LAN that knows how to pass it along to >the world-wide Internet.) This is very trivial to do with MMDF as well. Phone SCO support and ask for the fax-pack which describes configuring SCO MMDF in a TCP/IP environment (it's also been posted to this newsgroup at least once). -- David J. Fiander SCO MMDF Development Team SCO Canada, Inc. * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
tim@dell.co.uk (Tim Wright) (05/28/91)
In <1991May27.143614.7239@sco.COM> david@sco.COM (David Fiander) writes: >MMDF is only better that sendmail in one (very important) way: normal >human beings can understand how to configure it in about 15 minutes, and >can read the configuration files without having the manual beside them. >Aside from that, MMDF and Sendmail solve basically the same problem in >basically the same way. Don't undersell it :-) Blatant MMDF plug. It also supports authorisation by channel. This is useful if you have "free" links and "paying" links or you happen to have a few international modem links that you don't want people to use as gateways. As you say the real advantage is human-readable configs. There also seem to be fewer buggy versions around. Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Smoke me a Kipper, I'll be back for breakfast - Red Dwarf
rbraun@spdcc.COM (Rich Braun) (05/28/91)
A followup: via e-mail, a couple of people told me how to fix sendmail to work properly under SCO Unix. This is a bug in the Unix system itself, and can be corrected by substituting the following in /etc/tcp: In place of /usr/lib/sendmail -bd -q1h ; echo "sendmail \c" use su root -c "/usr/lib/sendmail -bd -q1h" ; echo "sendmail \c" Though sendmail is shipped configured to setuid to root, this is not sufficient. Doing the above fixed my problem. Regarding mmdf, I turned it off by simply typing "chmod -x /usr/mmdf/bin/ deliver", rather than deinstalling it. I'll revisit mmdf as soon as SCO ships the version which supports domain name service. It's amusing running into mmdf again. It was written at the U. of Delaware at the time I was a student there, but I was not involved with it. I was instead hacking RDMAIL, a program written in SAIL, for the DEC-10. I disagree that mmdf configuration can be figured out in "15 minutes". It's quite complex, requiring 56 pages in the administrator's guide, and needs every last detail specifically mentioned in its config files. I would suggest to our mmdf person at SCO that much more needs to be done to it than mere addition of domain name server support, if you want Average Joe to be able to configure it in 15 minutes. (Admittedly, it took me a month of posting _Help!_ messages on USENET before I figured out sendmail...mmdf isn't _that_ bad.) That 56-page manual section needs rewriting, too, in order to explicitly spell out SMTP support; it got me _quite_ confused, because it never says anywhere that one _cannot_ run sendmail and mmdf together; indeed it seems like one _needs_ to run sendmail in order to talk SMTP, which isn't the case. -rich
Tim.Wright@sunbrk.FidoNet.Org (Tim Wright) (05/29/91)
In <1991May27.143614.7239@sco.COM> david@sco.COM (David Fiander) writes: >MMDF is only better that sendmail in one (very important) way: normal >human beings can understand how to configure it in about 15 minutes, and >can read the configuration files without having the manual beside them. >Aside from that, MMDF and Sendmail solve basically the same problem in >basically the same way. Don't undersell it :-) Blatant MMDF plug. It also supports authorisation by channel. This is useful if you have "free" links and "paying" links or you happen to have a few international modem links that you don't want people to use as gateways. As you say the real advantage is human-readable configs. There also seem to be fewer buggy versions around. Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Smoke me a Kipper, I'll be back for breakfast - Red Dwarf * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
Rich.Braun@sunbrk.FidoNet.Org (Rich Braun) (05/29/91)
A followup: via e-mail, a couple of people told me how to fix sendmail to work properly under SCO Unix. This is a bug in the Unix system itself, and can be corrected by substituting the following in /etc/tcp: In place of /usr/lib/sendmail -bd -q1h ; echo "sendmail \c" use su root -c "/usr/lib/sendmail -bd -q1h" ; echo "sendmail \c" Though sendmail is shipped configured to setuid to root, this is not sufficient. Doing the above fixed my problem. Regarding mmdf, I turned it off by simply typing "chmod -x /usr/mmdf/bin/ deliver", rather than deinstalling it. I'll revisit mmdf as soon as SCO ships the version which supports domain name service. It's amusing running into mmdf again. It was written at the U. of Delaware at the time I was a student there, but I was not involved with it. I was instead hacking RDMAIL, a program written in SAIL, for the DEC-10. I disagree that mmdf configuration can be figured out in "15 minutes". It's quite complex, requiring 56 pages in the administrator's guide, and needs every last detail specifically mentioned in its config files. I would suggest to our mmdf person at SCO that much more needs to be done to it than mere addition of domain name server support, if you want Average Joe to be able to configure it in 15 minutes. (Admittedly, it took me a month of posting _Help!_ messages on USENET before I figured out sendmail...mmdf isn't _that_ bad.) That 56-page manual section needs rewriting, too, in order to explicitly spell out SMTP support; it got me _quite_ confused, because it never says anywhere that one _cannot_ run sendmail and mmdf together; indeed it seems like one _needs_ to run sendmail in order to talk SMTP, which isn't the case. -rich * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
chip@chinacat.unicom.com (Chip Rosenthal) (05/29/91)
In article <675397058.24@sunbrk.FidoNet> Rich.Braun@sunbrk.FidoNet.Org (Rich Braun) writes: >I'd just as soon dump mmdf entirely, though SCO's documentation implies that >mmdf is superior and one should dump sendmail instead. SCO MMDF is quite usable - though the way it's distributed and the documentation (or lack thereof) might lead you to believe otherwise. To get the system happy, you absolutely need to do two things: - Run `/usr/mmdf/bin/checkup' and heed it's advice. And if you reconfigure `mmdftailor', run `checkup' again. - Get the documentation posted in two parts to the net (several times!) on how to setup SCO MMDF. Part two is chock full of examples of how to do it in a networked environment. >"How can I make it communicate with remote sendmail daemons?" You need to enable the `MCHN smtp' line in the `mmdftailor' file. It is probably also a good idea to edit `/etc/rc2.d/S86mmdf' to run `deliver' on the smtp channel. (SCO 3.2v0.0 didn't even start deliver - so first thing to do would be to create this file. Better yet, upgrade to 3.2v2.0.) >and my second is "Why doesn't mmdf handle domain name service?" Yes, that is a drag. Although I use a static hosts table, it would be nice if SCO MMDF did a gethostbyname() instead of making me retype `/etc/hosts' into `/usr/mmdf/table/smtp.chn'. >I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and >so on) I've run an ODT box connected into a network consisting of an NCR Tower, a 3B2, and an ISC box. (Hi Bill!) All were running smail3.1, not sendmail, but the point is that SCO MMDF is an upright network citizen. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play that Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
david@sco.COM (David Fiander) (05/29/91)
In article <7665@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I disagree that mmdf configuration can be figured out in "15 minutes". >It's quite complex, requiring 56 pages in the administrator's guide, and >needs every last detail specifically mentioned in its config files. I >would suggest to our mmdf person at SCO that much more needs to be done >to it than mere addition of domain name server support, if you want >Average Joe to be able to configure it in 15 minutes. (Admittedly, it The 56 pages of (not very good) documentation in the system admin guide go into a lot of gory detail which is not required by most simple configurations. I explained the basic theory of MMDF configuration to my manager in about 15 minutes. Now, he probably wouldn't be able to configure mmdf without help, but he could look at the existing mmdf configuration and figure out what was happening to his mail and why, and he would also be able to _maintain_ the existing configuration. This is the most important part. One only needs to be an MMDF guru to generate a configuration from scratch (if then). Once one has a running mail system, maintaining it in the face of changing connections and user community is basically a no-brainer (since one of our Computing Services people left last month, our MMDF configuration has been running on auto-pilot with no real maintenance being done, aside from the cron job which cleans the log files). -- David J. Fiander SCO MMDF Development Team SCO Canada, Inc.
rvdp@sow.econ.vu.nl (Ronald van der Pol) (05/30/91)
rbraun@spdcc.COM (Rich Braun) writes: >If I reboot my SCO Unix system, incoming SMTP mail gets put into the >queue (deferred, I think due to a host-name lookup failure) and not >ever unqueued. If I kill the sendmail daemon and restart it, the >queue gets emptied out properly to the appropriate users' mailboxes. You have to run MMDF's deliver daemon instead of the sendmail daemon. >SCO ships the system with mmdf, and there may be an interaction problem >with the mmdfdeliver daemon which is always there sitting in the >background. I'd just as soon dump mmdf entirely, though SCO's >documentation implies that mmdf is superior and one should dump >sendmail instead. If mmdf is superior, then my first question is "How >can I make it communicate with remote sendmail daemons?" and my second >is "Why doesn't mmdf handle domain name service?" It (like sendmail) talks to an SMTP daemon at the other side (port 25). Because SCO (like always) installed an old version (and did it wrong too!). MMDF supports DNS! I find MMDF much easier to configure than sendmail. You should get the official MMDF documentation though!! Don't rely on SCO. >I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and >so on), using a sendmail daemon on a non-SCO system to relay mail to >the Internet via UUCP. (I've got my domain name server set up to >recognize systems on a domain called "kronos.com", and I've got SCO >sendmail configured to relay all mail addressed to external domains >to a given system on the LAN that knows how to pass it along to >the world-wide Internet.) We run SCO with MMDF and all our mail goes to an IBM-RT with sendmail. No problems at all (besides working with PC's :-). >-rich -- Ronald van der Pol rvdp@sow.econ.vu.nl rvdp@cs.vu.nl
jim@tiamat.fsc.com ( IT Manager) (05/30/91)
In article <1991May29.032142.16176@chinacat.unicom.com>, chip@chinacat.unicom.com (Chip Rosenthal) writes: - In article <675397058.24@sunbrk.FidoNet> - Rich.Braun@sunbrk.FidoNet.Org (Rich Braun) writes: - >I'd like to hear from anyone who has had to set up e-mail on a TCP/IP- - >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and - >so on) - - I've run an ODT box connected into a network consisting of an NCR - Tower, a 3B2, and an ISC box. (Hi Bill!) All were running smail3.1, - not sendmail, but the point is that SCO MMDF is an upright network - citizen. When we recently installed on ODT 1.1 system (Unix 3.2v2 as the OS base), we didn't even install the MAIL package. Instead, we simply mounted /usr/local from another SCO Unix machine which already had smail3.1 and elm installed under that heirarchy. Then we told smail to look for a second "config" file in /etc/config.smail, which could then be tailored to the needs of the ODT box. To satisfy programs which expect a "mail" program to exist somewhere, I copied the mail binary, and the /usr/lib/mail directory (well, not the whole thing, but the parts I knew were needed) off the other Unix machine. Whole thing works great. If you're installing on the only SCO machine available, try this: - install MAIL package - save the mail binary, and /usr/lib/mail directory - remove the MAIL package - install smail3.1 and elm - copy what you saved earlier back - install the execmail replacement (part of the smail3.1 package) There are probably other ways to use smail3.1 and elm without using any of SCO's MAIL stuff, and still have a "mail" binary around (I don't think elm can completely replace mail), but this is what I've had success with. ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651