SCO Unix MMDF problem

[David Fiander]

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 at daredevil.hut.fi> orava at 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.