As SCO sinks into oblivion, the prospect of configuring MMDF or Sendmail becomes decidedly unnatractive. MMDF is ancient and keeping even reasonably up to date on Sendmail can be extraordinarily difficult. As there are very definite security considerations, you really don't want to be running old versions, but unless you really enjoy frustration, compiling new versions for SCO is far from fun.
If the only need is for emailing stuff from scripts, there's really no reason to run MMDF or Sendmail. Why deal with the security issues at all if the server doesn't need incoming Internet email? That's just one more attack vector that a creaky old SCO system does not need.
On Linux systems, I've been using CleanCode Email. It's slick and simple and does the job, but I haven't tried compiling it on SCO (it did compile easily on Mac OS X, though), and you may not have SCO compilers anyway.
When I happened to have a nearby mail enabled Linux box, I've written little daemons that look for a client on the SCO side to shoot over whatever it wants to be emailed. That works, but at the cost of yet another client/server connection to maintain.
In other cases, I've written Perl scripts. There are lots of Perl SMTP modules to choose from, so it's not particularly hard to clobber up something.
I've never had the energy to piece together anything that would be general purpose, however. Too lazy and my Perl skills aren't all that strong anyway. I was therefore happy to find this GPL'd Perl sendEmail program.
I haven't actually had a recent need for this. SCO work is slim pickings today and when any does come along, I usually try to steer them to Linux for what I hope are obvious reasons. However, I did see this SCO newsgroup post where at least two people said they had used this, so I have pretty good confidence that it will work. I don't see any module dependencies that should break it on SCO (maybe if you need TLS), so it should be ready to roll.
If you are inserting this into a transplanted/upgraded system that used to depend upon Sendmail or MMDF, you'll need to figure out how to best deploy it. You could change all your calling scripts or you could hack this so that it would expect the flags and arguments they send, or you can put a "glue" script in between that translates arguments. If you aren't sure just where and when other scripts are doing their things, a "glue" script might make the most sense.
Of course this would also work on Linux and Mac OS X. Running it with "--help" gives the following output:
sendEmail-1.56 by Brandon Zehm <firstname.lastname@example.org>
Synopsis: sendEmail -f ADDRESS [options]
-f ADDRESS from (sender) email address
* At least one recipient required via -t, -cc, or -bcc
* Message body required via -m, STDIN, or -o message-file=FILE
-t ADDRESS [ADDR ...] to email address(es)
-u SUBJECT message subject
-m MESSAGE message body
-s SERVER[:PORT] smtp mail relay, default is localhost:25
-a FILE [FILE ...] file attachment(s)
-cc ADDRESS [ADDR ...] cc email address(es)
-bcc ADDRESS [ADDR ...] bcc email address(es)
-xu USERNAME username for SMTP authentication
-xp PASSWORD password for SMTP authentication
-b BINDADDR[:PORT] local host bind address
-l LOGFILE log to the specified file
-v verbosity, use multiple times for greater effect
-q be quiet (i.e. no STDOUT output)
-o NAME=VALUE advanced options, for details try: --help misc
-o message-file=FILE -o message-format=raw
-o message-header=HEADER -o message-charset=CHARSET
-o reply-to=ADDRESS -o timeout=SECONDS
-o username=USERNAME -o password=PASSWORD
-o tls=<auto|yes|no> -o fqdn=FQDN
--help the helpful overview you're reading now
--help addressing explain addressing and related options
--help message explain message body input and related options
--help networking explain -s, -b, etc
--help output explain logging and other output options
--help misc explain -o options, TLS, SMTP auth, and more