Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!nsc!aleph!svnet!harry From: harry@svnet.UUCP (Harry Skelton) Newsgroups: comp.mail.sendmail Subject: Re: SCO Unix sendmail initialization problem Summary: SCO MMDF is a bit broke. Message-ID: <2626@svnet.UUCP> Date: 10 Jun 91 14:09:59 GMT References: <7647@spdcc.SPDCC.COM> <8987@gollum.twg.com> Organization: SVNet, San Jose, CA 95128 Lines: 152 In article <8987@gollum.twg.com>, david@twg.com (David S. Herron) writes: - 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 - >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?" - - Ah, but MMDF *is* superior. (At least from a design perspective, - sendmail is "better" in a couple of respects, one of which being that - lots of people understand it and you can ask questions and get answers. - Fortunately I understand MMDF and can likely answer your questions.) *sigh* I have been in talks with DELL, SCO, and others regarding the shipping of MMDF and Sendmail on the same machine and letting the user choose which one they want to use. SCO's attitude is that MMDF is the way to blaze a new trail and to take a step back from the BSD/AT&T norm. BUT, NOT TO START A FLAME WAR: Here is a way you can configure sendmail on your SCO system. Quick and easy!!! mkdev sendmail-init It will move MMDF out of the way and put sendmail in it's place. The only thing the mkdev script failes to do is remove the *mmdf out of /etc/rc?.d areas. Sendmail init in already included in the *tcp rc scripts. You might want to test the new sendmail.cf file before you have it run. I think the way it handles domain headers on outbound mail is a bit funny. Also, it "defaults" to uunet for all *.uucp traffic. ------- Now back with the MMDF issues: SCO MMDF does NOT have nslookup. They are hoping to have a release out this fall with the lookup ability. Along with that are some ODT fixes (I hope) as well. I have been talking with the "port" person at SCO on the MMDF project. It seems they have been taken back by a prior person(s) lag in developement. They are working on the "bugs" and they have been very helpful. But, as I explained to him, I have my main servers running sendmail. My addresses are handled with 'user@site.domain' (Not the "VIRGIN RFC" format of '@site.domain:user,user,...@routesite.domain'). I told him that SCO should "get real" and let the user's choose. Additionally, the channels provided for SMTP should allow for two formats. The "old" rfc format of user@site.domain (perhaps in a smtp.old channel) and the newer rfc (but I feel less used) format as mentioned above. - - Getting MMDF to communicate with sendmail's is trivial. It happens - all the time. There's this protocol which runs over TCP/IP - which is called SMTP. Go read RFCg821 if you want a description uh...isn't that 822? - of the protocol. To get MMDF to send mail through SMTP you enable - a SMTP channel (should already be there in the mmdftailor file). Fat chance. SCO's default config is Mic-net (remember from the old Xenix 1.0 days?)!!! Additionally, the SMTP channel must be included in the MMDF rc files. (Personally, I think it should be handled at install time or with a mkdev script). - You then put host names & addresses in the SMTP channel table like - - e.ms.uky.edu: 128.163.128.5 - - and run dbmbuild. This'll provide you with hostg>IP Address mappings - and it'll work fine. - - MMDF does do domain names, however I have been told that the - version which SCO shipped did not. So instead of putting in - a static table for the SMTP channel you'd put - - MTBL name=chnsmtp, ... flags=ns - MCHN name=smtp, table=chnsmtp, ... Tell him there is more to it than that. There are other configs you must update to forward mail correctly. - And it works. I use it all the time. The support for this - in update 43 (the current version) is much better than the - support in update 32 (the version SCO shipped). Again, I have - been told that SCO will be shipping a new version sometime soonish - which is update 43 plus whatever they do to it. I don't follow - SCO very closely so I don't know what their schedule is, or if - they've already done it at all. They are working on it but don't hold your breath on it being 43. It's still pretty old version being released. - >I'd like to hear from anyone who has had to set up egmail on a TCP/IP- - >based LAN containing SCO Unix systems mixed with others (AIX, NCR, and - >so on), using a sendmail daemon on a nongSCO 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 worldgwide Internet.) - - With MMDF; to do that "pass unknown stuff to a smart host", you enable - a "badhosts" channel by doing something like: - - MTBL name=cbadhosts, file="Channels/badhosts", show="Bad Hosts" - MCHN badhosts, que=badhosts, tbl=cbadhosts, pgm=smtp, - mod=imm, mod=reg, ap=822, host="ddnvax.twg.com", - confstr="Obelix.twg.com" [ issues about conforming to MMDF headers deleted ] - You should also endeavor to make your headers look like - - From: David Herron - To: Joe Bloe , Dave Crocker - - Because it looks nicer than any other format. Yeah but get MMDF to ship it out in that format! I have yet to see an SMTP channel that does the old RFC formatting, from MMDF. UUNET and Telebit both went to the "MMDF Format" and both got flamed by the attached sites. I think that even with the newer RFC's, using something that is "standard" and supported by almost every TCP/IP mailer in existance, should not be messed with. In short: If it ain't broke, don't fix it. - - >grich - David - MMDF and MHS in the same room! AAAAAHHHGGGGGG!!!! No wonder the U.S. DOT is so screwed up. (See Also OATS(faa)) 8-) 8-) - $+ $#error $:$1: evolution error - no core