orava@daredevil.hut.fi (Petri Wessman) (03/06/91)
Hello all. I'm having slight problems with SCO MMDF, it might just be a case of RTFM but I haven't bumped into the right FM yet. The problem is this: we have a bunch of 386 boxes with SCO 3.2.0 in a local network together with an RS/6000 running AIX 3.1 (and sendmail). The AIX machine is a UUCP link to the outside world, so I want to have the SCO machines forward all unrecognized mail to it for more processing. Well, I got this to work, sort of, by defining a badhosts MMDF channel as follows in the mmdftailor file (cerebus is the AIX machine): 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... 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. Sigh... BTW, if any of you feel like commenting "get rid of MMDF and use sendmail": I tried. On the AIX box sendmail works like a dream, but on SCO it refuses to cooperate in any fashion, and I got tired of hacking at it. Grumble. //Petri
david@sco.COM (David Fiander) (03/12/91)
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.91Mar5202834@daredevil.hut.fi> 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.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/17/91)
As quoted from <1991Mar12.135324.20578@sco.COM> by david@sco.COM (David Fiander): +--------------- | support for .forward files, _but_ we do not use the university code | because it allows arbitrary users to become root. Right now, +--------------- !!!!! I didn't notice that. Time to reload the source and do some hacking... ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH