SCO Unix MMDF problem

Petri Wessman orava at daredevil.hut.fi
Wed Mar 6 05:28:34 AEST 1991


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



More information about the Comp.unix.sysv386 mailing list