Xref: utzoo comp.mail.misc:5031 comp.unix.sysv386:5907 Newsgroups: comp.mail.misc,comp.unix.sysv386 Path: utzoo!censor!comspec!scocan!david From: david@sco.COM (David Fiander) Subject: Re: SCO Unix MMDF problem Organization: SCO Canada, Inc. Distribution: comp Date: Tue, 12 Mar 91 13:53:24 GMT Message-ID: <1991Mar12.135324.20578@sco.COM> References: Sender: news@sco.COM (News administration) NOTE: somebody forwarded this article to me via mail, and I responded via mail. Now that the article has arrived via news, I am posting my response since it might be of general interest. In article orava@daredevil.hut.fi (Petri Wessman) writes: |MCHN badhosts, show="Smarthost Routing", que=badhosts, tbl=smtpchn, | ap=same, pgm=smtp, mod=imm, host=cerebus.inter.fi | |This works just fine for addresses that the AIX host sendmail |recognizes (and passes on), but in the case of an address that has an |invalid top-level domain (i.e. an address the the AIX sendmail |rejects) we have problems. Namely, MMDF doesn't notify the sender of |the mail of the failure in any way, and just stores the message in |/usr/spool/mmdf/locks/home/DeadLetter! From reading the manuals I get |the impression that MMDF should bounce all failed messages back to the |sender, and only if that was impossible save them in the DeadLetter |file. I have absolutely no idea why MMDF can't return the message back |to the sender in this case! Any help would be appreciated, it is |*very* annoying for users to have mail with bad addresses simply |vanish... I remember seeing this problem shortly after SCO Canada took over the development work for MMDF, but I can't reproduce it any more. The first thing to do is to check and make sure that the mail support address MSUPPORT, as defined in mmdftailor is a valid address, because failed mail will be sent there before it is put into DeadLetter. That way somebody will be told at least. A better solution is to run the program "/usr/mmdf/bin/checkup -p". This is my stock answer when people have problems with SCO MMDF. As it is currently shipped, SCO MMDF installs with the wrong permissions on several files and directories (this is going to be fixed in the next release). When you have run checkup, it will complain about a variety of things. Note that it will complain that the permissions should be "707". That is not quite true; checkup doesn't bother to check the group permission bits, so they can be anything at all. 777 is probably best for the directories in the spool area. If, after you have done that, you still have problems, get back to me. |Oh, and another question for those of you who know anything about the |SCO MMDF setup: I can't seem to get .forward files to work. Apparently |.forward file handling is a compile-time option, has SCO simply left |it out or can I configure it in somehow? I got mail forwarding to work |(sort of) with a .maildelivery file, but it's pretty ugly. No, it's not a compile time option with the version of MMDF that SCO ships. .forward support did not appear until the release of University MMDF after the one that SCO is currently shipping. The .forward code that exists there _is_ a compile-time option, and we will be providing support for .forward files, _but_ we do not use the university code because it allows arbitrary users to become root. Right now, .maildelivery is your only option. Sorry. - David J Fiander SCO MMDF Development Team SCO Canada, Inc.