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
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.
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
david@twg.com (David S. Herron) (05/30/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 >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.) 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 RFC-821 if you want a description of the protocol. To get MMDF to send mail through SMTP you enable a SMTP channel (should already be there in the mmdftailor file). 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 host->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, ... 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. >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.) 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" Then, since pgm=smtp, the file referenced in the MTBL declaration must be in a form the SMTP channel will accept. See the host: IP addr discussion above. Something you should *DEFINITELY* do is make sure that all your addresses in the headers get fully qualified domain names attached to them all the time. There are two problems being attacked by this suggestion -- Headers like To: joe, bob, riggs From: david What happens to this header when it escapes from the local system? Normally people try to only attach domain names to mail if it is leaving the system through an MTA. However if the message leaves embedded inside another message, for instance as part of a digest, then it will be unreplyable. -- Non fully qualified domain names are better than no domain names. But it can cause problems, again, if the message escapes without having its domain names fully qualified. In general, though, it's one less thing to worry over if you go ahead and put the right answer there. You should also endeavor to make your headers look like From: David Herron <david@twg.com> To: Joe Bloe <joe@acme.com>, Dave Crocker <dcrocker@nsl.dec.com> Because it looks nicer than any other format. >-rich David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
harry@svnet.UUCP (Harry Skelton) (06/10/91)
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 <david@twg.com> - To: Joe Bloe <joe@acme.com>, Dave Crocker <dcrocker@nsl.dec.com> - - 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 - <g David Herron, an MMDF & WIN/MHS guy, <david@twg.com> MMDF and MHS in the same room! AAAAAHHHGGGGGG!!!! No wonder the U.S. DOT is so screwed up. (See Also OATS(faa)) 8-) 8-) - <g "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future ---- Harry Skelton - Senior Systems Administrator - UniForum, 408-986-8840 ext 25 "Strange women lying in raised floors distributing passwords is no basis for a system of administration!" -- Harry Skelton | harry@usrgrp.uniforum.org Senior Systems Administrator | ..!uunet!usrgrp!harry UniForum | 408-986-8840 x25 RBIFF<@$+>$+ $#error $:$1: evolution error - no core